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 checking code from #56 landed, and started triggering for me on
the `dockerroot` user. It's nice to know it works. Then the issue
is... "what now"?
It turns out in the case of `dockerroot` it's actually unused, so we
could fix this by deleting it. But in general we need to support
dynamic uids/gids/. And we can't yet take a hard dep on #49.
So this patch changes things so we take a copy of the passwd/group
data from the previous commit. Any users subsequently added in the
*new* commit will be additive.
Closes: https://github.com/projectatomic/rpm-ostree/issues/78
Verify uid/gid on files, directories and symlinks
Just output a msg when user/group is removed with no files
json-parsing: Add functions for strictly dealing with ints
passwd/json: Add simple scripts to convert passwd/group files to json data
docs: Check-passwd/groups and ignore-remove-users/groups JSON config. entries
Refactor command-line parsing to better utilize GOptionContext. This
eliminates most of the manual parsing and global options are now shown
in the help output.
Some of the changes here are not strictly necessary for rpm-ostree,
but are done for consistency with ostree's command-line parsing.
The "rpm" subcommand needs some extra attention, so that's been split
into a separate commit.
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.
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.
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).
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?
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.
Having content in /boot in OSTree was always ugly, because we ended up
mounting over it in the deployment location at boot.
This was even worse in the anaconda rpmostreepayload code, because of
the juggling of the mount point that needed to take place.
Trying to add a GRUB2 backend to OSTree is what finally forced this
change. Now, we put kernels (in the tree) by default in *both* /boot
and /usr/lib/ostree-boot.
OSTree itself knows to look in both locations. Anaconda is going to
just hard require trees with the new location though.
This would probably be best if we invoked systemctl in the compose
tooling, but at the moment we don't have any execution of target code
on the host. It's fine to assume that it's in /usr/lib.
We can revisit this if we start doing chrooted/containerized
execution.
Since the treefile format now supports includes, we would need to
either include the whole chain, or just the expanded portion we use in
the compose. This patch does the latter.
This should allow a client to take the same treefile and generate a
similar tree (if they want to reproduce with the same RPMs, those can
be extracted from the RPM database inside the tree).
As a developer, a workflow I have for testing things is to create
an RPM, toss it into a local yum repository, then do a compose.
However at the moment to add the local overrides I have to edit the
treefile, which is annoying. Let's add a commandline override for
this.
Note this also deletes the old "repos_data" code which was not being
used.
In 827e711 we stopped running two yum transactions. This means the
code that detects if the repodir exists in the yum installroot will
always return false and the code is dead.
I had an epiphany today while working on
https://bugzilla.redhat.com/show_bug.cgi?id=1098304 - I realized that
I can just do an install, and then copy over everything except the
root entries from /etc/passwd into /usr/lib/passwd.
No need for a patched shadow-utils. No need to modify the
/etc/nsswitch.conf before doing the install root. It totally works.
I have no idea why I originally overcomplicated this.
The thing that sucks a bit about this code is that I have to drop to
the FILE * APIs so that I can use the glibc APIs for processing
group/shadow.
Also, the way I deduplicated the code paths for processing
passwd/group is crappy, but I think it's better than duplicating them
(as systemd-sysusers does).
The good: We don't need a two-step RPM transaction, we don't need
a patch for shadow-utils, it's just saner
The bad: Code is not the most beautiful? Not really bad.
The ugly: I didn't think of this in the first place and spent
months beating my head against the wall of shadow-utils...
They get deleted anyways since we blow away the tmpdir, but we expect
people to be using a local HTTP proxy. We stopped trying to cache
packages internally as that caused conflicts with the yum lock with
concurrently executing composes.
Currently the systemd RPM ships with default.target ->
graphical.target, which is either itself changed by Anaconda (via
parsing /etc/sysconfig/desktop, which...anyways let's stop here).
Or anaconda might set it directly to multi-user.target.
For rpm-ostree, we perform some minimal level of "preconfiguration"
per tree, so they are directly usable without an intervening
installer.
As an example for fedora-atomic/base/core, we just want
multi-user.target. Thus, this patch provides the treefile author a
declarative mechanism to set it.
Currently on an Atomic compose, I'm seeing abrtd trying to write to
/usr/share/rpm/.dbenv.lock, which is denied by policy because it's
usr_t. There are multiple ways to address this, but there's no good
reason to leave the lock files and __db* files around.
rpm appears to operate correctly without them if calling process
merely gets EROFS.
And do the same for "sign". This way we can have the compose server
utilities cleanly separated from what most people will see, which is
the client side tools.
