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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As a followup to renaming the "rpm" command to "db", split the "db"
subcommands into separate source files in the style of "ostree admin"
and "rpm-ostree compose".
Also create rpmostree-rpm-util.[ch] as a place for common rpm-related
functions needed by the "db" subcommands.
No intentional functional changes here, just a bunch of copy-n-paste
and minor cleanup.
Eliminates some confusion between "rpm-ostree rpm" (or "atomic rpm")
commands versus actual "rpm" commands.
The "rpm" subcommand is retained as a hidden alias for the "db"
subcommand for backward-compatibility. It is not listed in --help
output.
Fixes#22
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.
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?
Some downstreams want the ability to separate the compose tooling from
the client, for e.g. support reasons.
This approach supports generating a tarball without the source for the
compose command, and requires specifying a config option to disable
it.
This improves on the check-diff option by only downloading the
/usr/share/rpm directory to do a package diff. This prevents downloading
the whole deployment and the necessity to do a cleanup later.
It currently has the following sub-commands:
diff COMMIT COMMIT
for rpmtree diff.
list [prefix...] COMMIT...
for "yum list" like command.
version COMMIT...
for "yum version" like command.
...bunch of FIXME's, UI output isn't great, needs docs.
We also don't use the same code as the treediff on upgrade atm.
This allows administrators to configure between deployments and easily see which deployment
they are booted into as well as indicating which is chronologically most recent. This makes
the process more user-friendly, rather than requiring the user to remember which deployment
checksum corresponds to the most recent upgrade.
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.
This is exactly the code from "ostree admin switch", except it's
called "rebase" because in the future it will also carry along any
locally layered packages.
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.
The way this works is still fairly naive in that we hash in two
inputs:
1) The treefile JSON
2) The result of rpm -qa
If both of those are a hit, we reuse the existing commit.
This is just the start of moving more functionality into rpm-ostree,
with the goal of more tightly binding the rpm and ostree worldviews.
For exmaple, supporting package installation on top, showing the
package-level diff between trees, etc.
The web page previously bounced out to the "fedora-atomic" component -
but we really want a bit of web UI that's shared between products.
Like how Koji is a generic frontend.
In particular, this now comes with a start of a generic "repoweb".
We use the new unified OSTree API (OstreeSePolicy) to perform
labeling, rather than having our own here.
Also create a new rpm-ostree-relabeling-helper that is run to label
any leftover files such as /etc/fstab that we create offline, and also
to relabel the entire disk.
This allows us to skip the whole install process if the
RPMs haven't changed, which is a rather large win.
Part of this commit involves some code to attempt to talk to "yum
shell" for dependency resolution, in an attempt to avoid depsolving
twice, which just isn't really going to work, since "yum shell" isn't
an API as it turns out.
The only other real alternative is doing something PackageKit-like,
which is ~4000 lines of very nontrivial Python.
There are two major reasons:
1) I want to do things like process SELinux labels here, and that
type of thing is best done in C.
2) There are presently 3 languages in this code, and this takes us
down to just two.
