901917ff85
The current motivation for this is that https://github.com/fedora-infra/fedmsg-atomic-composer started using mock --new-chroot (which uses systemd-nspawn) to run rpm-ostree, which in turn uses systemd-nspawn to run the post script. Now systemd-nspawn is not really nestable (it wants to link up journald, resolv.conf handling, etc). First, dropping nspawn and going to raw containers fixes the nesting problem. Second, we don't need all the features of systemd-nspawn. We are ok with log messages going to stdout, and we don't use networking, so no resolv.conf is needed. Third, this sets a bit of a stage for more sandboxing internally when run on real systems. I already have a prototype branch which runs librepo as an unprivileged user, that could be combined with this for even stronger security. Why not use systemd? Well...I'm still debating that. But the core problem is systemd isn't a library in the C sense - to use its sandboxing features we have to use unit files. It's harder to have a daemon that looks like a single service from a management perspective, but uses sandboxing internally. |
||
---|---|---|
design | ||
doc | ||
man | ||
packaging | ||
scripts | ||
src | ||
tests | ||
.gitignore | ||
autogen.sh | ||
configure.ac | ||
COPYING | ||
Makefile-decls.am | ||
Makefile-man.am | ||
Makefile-rpm-ostree.am | ||
Makefile-tests.am | ||
Makefile.am | ||
README.md | ||
TODO |
rpm-ostree, aka /usr/bin/atomic
An system to compose RPMs on a server side into an OSTree repository, and a client side tool to perform updates.
The project aims to bring together a hybrid of image-like upgrade features (reliable replication, atomicity), with package-like flexibility (seeing package sets inside trees, layering, partial live updates).
rpm-ostree is in beta!
While many of the underlying technologies here are stable, if you are considering using this in your organization, you should perform a careful evaluation of the whole stack. Software updates are obviously critical, and touch on many areas of concern.