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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is just a tech demo. Example usage:
```
mkdir -p ~/.cache/rpmostree-containers
cd ~/.cache/rpmostree-containers
rpm-ostree container init
cp /etc/yum.repos.d/CentOS-Core.repo rpmmd.repos.d
rpm-ostree container assemble bash
rpm-ostree container assemble httpd
```
This is part of taking over from librpm. The most important high
level goal is fully unprivilged operation.
Right now we're basically starting to do what
http://libguestfs.org/supermin.1.html does, except in C, and
faster.
There's no reason that `compose tree` should require privileges.
However right now, things like `%post` scripts will want to run in the
target root - so we'd have to require `linux-user-chroot`.
Regardless of unprivileged operation though, another major thing we
can do is use our control over the unpacking process to do a lot more
sophisticated caching. We can build up a precise mapping of (rpm
ENVR, file path, selinux label) -> object and avoid rechecksumming
each time.
And even for files that aren't known, we can parallelize commit with
unpacking, etc. (Ok assuming treecompose-post won't mutate anything).
I'd like to experiment with different things that end up
reusing chunks of the rpm-ostree internals, such as libhif, the
helpers we already have around RPM, etc.
In this particular case I'm experimenting with unpacking/committing
RPM packages as non-root. Eventually most of this should end up as
internal private shared library, but it's convenient to have an
ABI-unstable and hidden "internals" command to run things directly.
This commit though just adds the scaffolding for "internals".
This is a step forward to deduplicating; the client tooling now calls
into the public API for diffs, rather than using the older internal
function.
Note: this patch also links the client against the public library.
On the plus side, we share some code between the library and the
binary now. On the downside, because `librpmostreepriv.la` is a
noinst library, its code text is duplicated between the shared library
and binary, at least until we either:
- Have the binary solely use the public shared library (like ostree does)
- Install `librpmostreepriv.so` to e.g. `/usr/lib64/rpm-ostree/librpmostreepriv.so`
without the headers being public
We currently have an internal-only library, but the sources for it are
in the same dir as the app. For future work on a public shared
library, we'll need a clearer source structure.
Start by just renaming the app files into `src/app/`, and the internal
private library into `src/libpriv/`, with the appropriate
`Makefile.am` changes.
Closes: https://github.com/projectatomic/rpm-ostree/pull/123
The high level goal is to deprecate libgsystem. I was trying to share
code between ostree/rpm-ostree, but it was too painful to commit to
forver frozen ABI for new utility APIs.
The git submodule approach will much more easily allow breaking
API/ABI, and iterate on APIs until they either land in GLib or not.
Note that libglnx will not use GFile*, so a full port to it will
involve also not using that. Thus, it will be necessarily
incremental; in the meantime we'll link to both libgsystem and
libglnx.
Remove redundant function _rpmostree_pull_progress().
Bumped ostree requirement to 2014.13, but this isn't quite right because
we actually need (unreleased) 2014.14. Post-release version bumps would
be useful here.
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
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".
