IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
"rpm-ostree compose {tree,sign} --help" acted as if no subcommand was
given. But the compose subcommands each have a good number of options
so it's particularly important to list them.
Currently adding human users to a system group such as 'wheel' does
not work with shadow-utils as it exists now. This is admittedly
a hack; basically we single out "wheel" as going in /etc/group, via:
"etc-group-members": ["wheel"],
A more comprehensive solution to this will be:
https://github.com/projectatomic/rpm-ostree/issues/49
Originally I was trying to have all of the treefile parsing
in treecompose, and then call other functions as API. But that
turns out to be unrealistic. We'll need finer grained control
over this in the future.
Therefore, let's move the boot-location handling down, in preparation
for further commits which parse the treefile in the commit phase.
This is the equivalent of the 'removefrom' verb in Lorax's templating.
It's a lot more robust than a generic "rm-rf" type thing, because most
often you only want to remove files from particular packages.
It seems clearer to me if all code which is operating on the content
(such as enabling systemd units) is under -postprocess. The "compose
tree" code should be tying everything together and calling out to
sub-components.
This is prep for adding more postprocessing code.
We might as well do what systemd does and have a big header which
defines all of them, to more conveniently share them for libraries
that don't include them (like hawkey/librepo, as well as things that
libgsystem doesn't yet cover).
For some reason we ended up defining our own macro to define cleanup
functions, when libgsystem has a usable one. Switch to that, fewer
lines of code, more consistency.
I was looking again at using hawkey/librepo, and realized just how
much I'd have to fight all of these libraries to avoid affecting
the running system.
What we really want to do with librepo/hawkey is run them effectively
unprivileged, and to hide the system's RPM database from them. This
is a baby step towards that, by confining our existing yum.
- /usr, /etc, and /var/lib/rpm are mounted read-only
- yum is now run under CLONE_NEWPID, to avoid stray %post scripts
affecting system processes
This is taking us closer to deeper integration in the treecompose side
with RPM instead of forking out to things.
It works except...we end up with the dreaded __db.001, .dbenv.lock
files =/ Best option would be to teach RPM how to open a database
really read-only. Failing that, could use the immutable bit?
These lock and dbenv files are created by RPM when it accesses the
database read-write, but we only want read-only. Sadly that turns out
to be very, very hard to plumb through all the layers in
hawkey/libsolv etc.
So let's just forcibily remove them after postprocessing.
Since we're only quering the database once (and at least
one of the locations is going to be read-only), don't
create the cache.
Noted while just reading the code while working on something else.
I'd been resisting this for a long time - I really wanted the tree to
be a reflection of the packages; and not go down the path of
"forking".
The lorax model has shown that while you can definitely get a large
space reduction that way, you're going to be perpetually chasing
changes in the packages. No matter how good your templates are.
Furthermore, lorax is just to generate the installer - it's an OS that
runs a single app. Whereas here we're generating the target runtime
system; we can't add bugs.
Nevertheless, reality is that sometimes it's just too hard to change
the input package set - there's a risk of breaking things. Namely,
we're introducing a new update system here, but obviously there's a
previous one: yum. Upstream packages keep growing a dependency on it.
Note this patch allows *not* removing all files from the package,
because it's possible that other things (e.g. subscription-manager)
import it as a library.
So in the meantime while we're iterating on this, let's support:
"remove-files": ["usr/bin/yum"],
The code is generic beyond yum for obvious reasons, but I don't
think we should use it for a lot more than that.
