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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We removed this in review, but I rediscovered why I added it. We
fail the `g_assert (sepolicy_matches)` if we already had packages
done with the final label when we go to reuse the cache.
(Basically, if we use the cache multiple times it's hard to avoid
relabeling all the time which is unfortunate...gets back a bit to
a way to annotate pkgcache commits as supporting multiple policies)
Closes: #1109
Approved by: jlebon
I didn't try porting some of the other contexts yet...I want to see
if this works.
Note that FAHC was switched to 27, so it's only luck that things
work on 26.
Closes: #1108
Approved by: jlebon
The "--ex" prefix here means it's an experimental option. A tremendous change
here is that start to support non-uid 0, but there are various things to fix there;
the unpacker for example needs to learn to set imported objects fully based
on the rpmfi information (i.e. default to uid 0, since libarchive gives the
current uid by default).
And even when run as uid 0, there are some bugs, though I'm not sure
of any showstoppers yet. For example, dracut's `dracut-install` calls
`cp --preserve=xattrs` which fails to copy the `user.ostreemeta` xattrs
from a checkout (it shouldn't be copying that anyways...)
Nevertheless, the infrastructure behind this really helps (is almost a hard
requirement for) the [jigdo effort](https://github.com/projectatomic/rpm-ostree/issues/1081).
Which is really only true due to SELinux - we need to import the packages,
then generate the final tree to get the final policy, then use that policy
to relabel all of the packages.
Closes: #940
Approved by: jlebon
In an unprivileged case, we can't do this on the real filesystem. For
`ex container`, we want to completely ignore uid/gid. I added a test
installing `httpd` which failed previously.
TODO: For non-root `--ex-unified-core` we need to do it as a commit modifier.
Closes: #940
Approved by: jlebon
It seems that libarchive ends up returning `getuid()` actually,
possibly because the cpio doesn't actually have ownership information?
Anyways, what we really want here is to set `0/0`, which is what
happens for the `ex container` path via
`OSTREE_REPO_COMMIT_MODIFIER_FLAGS_CANONICAL_PERMISSIONS`.
Prep for unified core 🌐.
Closes: #940
Approved by: jlebon
Not immediate prep for anything, I'd just been looking at this
code recently.
(Also a bit of `glnx_throw_errno` porting)
Closes: #1107
Approved by: jlebon
More work for unified core; this was one of the biggest parts of the `ostree
diff` when comparing a unified core treecompose of Fedora Atomic Host versus
the libdnf path.
This is also the first case where we're teaching the pkgcache to redownload
based on state.
Closes: #1105
Approved by: jlebon
Previously in 4a86bdd196 "postprocess: Undo Fedora SELinux policy move"
we fixed things for SELinux policy to move it out of /var and back
into /etc.
But for unified core where we're importing the RPM, the default "/var →
tmpfiles.d" kicks in before this can run. So teach the unpacker to do it too.
This is even less nice than what we had in the postprocessing code, as there we
went to some effort to handle non-targeted policy (e.g. MLS). That said I am not
super concerned about that right now...we can always deal with MLS or other
policies later. I'd be more inclined really to try to take the issue of moving
back to /etc (or implementing /usr with /etc overrides) to SELinux upstream.
Closes: #1105
Approved by: jlebon
For unified core work, we'll be caching the "has docs" flag in the pkgcache
commit. So let's load the commit object earlier rather than having each function
load it.
Closes: #1104
Approved by: jlebon
Avoid the `goto` by initializing the output variables directly early, so we can
do a full new style consistently. Prep for unified core work.
Closes: #1104
Approved by: jlebon
Prep for unified core 🌐. First, right now `shadow-utils` always opens those with
`O_RDWR`, so let's break those links even if we don't have `usr/lib/passwd`.
Also, while not strictly requried, let's also handle the `merge_passwd_dir`
being `NULL`, as that happened when I was trying a variant of this patch.
Closes: #1098
Approved by: jlebon
Prep for unified core 🌐. Here we don't have `/usr/lib/passwd` at the start, but
we still want to load the `usr/etc` copies for processing rpmfi overrides.
Closes: #1098
Approved by: jlebon
Prep for unified core 🌐. On the treecompose path we inject
`/usr/etc/passwd`, and trying to overlay the setup package on top
with the default `UNION_IDENTICAL` fails.
This is obviously a hack; but I can't think of a way to do this significantly
better. (We could do a DB query for the owner of `/etc/passwd`, but eh.)
Closes: #1098
Approved by: jlebon
I was trying to figure out why:
rpm-ostree compose tree --repo repo/ manifest.json
would result in:
error: opendir(manifest.json): No such file or directory
It turned out to be because we had `--repo` in *both* the `install`
options and the `commit` options. This makes sense since both these
subcommands need to be given a repo. However, in the `tree` case, we
were adding both arrays, which meant we inherited two `GOptionEntry`s
for `--repo`. This confused glib2 which consumed not one but two CLI
arguments when looking for the argument associated with `--repo`.
Our CI didn't notice this because it uses the `--repo=foo` notation,
which doesn't throw off glib2.
Fix this by factoring out the `--repo` option into a separate array so
that in the `tree` case, it only gets added once. Exercise the fix in CI
by using the two argument notation for `--repo`.
Closes: #1101
Approved by: cgwalters
In git worktrees, `.git` is not a directory but a regular file
containing the path to the real git directory. This was causing us to
not use `git describe` in the versioning info, which is really useful to
sanity check that you're running the code you think you're running. Fix
this by just checking that a `.git` entry exists.
Closes: #1102
Approved by: cgwalters
The jigdo work is turning into "partial unified core 🌐" (mostly due to SELinux,
but that's an aside); we made a change here previously to avoid using
the journal if `uid != 0`, but it's more correct to check whether or
not we're already using the journal.
Concretely this fixes calling `rpmostree_context_assemble_tmprootfs()` as uid 0
inside my dev container, running `rpm-ostree compose commit2jigdo`.
Closes: #1084
Approved by: jlebon
Needed for unified core work for the treecompose side; there
`/var` may not actually be on the same mount as the repo.
Do what we do in a ton of other places (and should probably push
into ostree somehow): allocate a tmpdir in `${repo}/tmp`.
Closes: #1095
Approved by: jlebon
The maintainer can't apparently be bothered to review my patch,
and we don't need the `%post` anyways - and this is now blocking
my jigdo work.
Closes: #1092
Approved by: jlebon
We have a *lot* of experimental functionality. I think the
`override` bits are fleshed out enough now that we can lift
the `ex` designation. For example, jlebon fixed SELinux
labeling in the presence of override-replace.
Closes: #1089
Approved by: jlebon
The `ex container` path was already doing this - lower the logic
into the core so I can use it for the jigdo path. I think it's just
clearer as well even for the sysroot pkglayering path.
Closes: #1083
Approved by: jlebon
Rather than passing it to the assemble functions.
Prep for jigdo work. I'm trying to move more logic
from the system upgrader path to the core, since some of
it is needed for jigdo and "unified core".
Closes: #1083
Approved by: jlebon
We already called the `workaround_selinux_cross_labeling_recurse()`
in the postprocessing path, there's no need to do it again during
commit.
Just making this change as I was going to do some SePolicy stuff
for the [jigdo work](https://github.com/projectatomic/rpm-ostree/issues/1081)
and stumbled again into the ugly mess that is the cross-labeling
hack.
Closes: #1082
Approved by: jlebon
Added unit tests for rpm-ostree ex kargs --delete,
--append and --replace.
Also exposed two getter functions for kargs table
and array so people can retrieve information from
kargs.
Also includes a minor fix for a bug caught by the unit
test.
Closes: #1013
Approved by: cgwalters
Refined a bit for the previous written kargs test.( mainly for
checking kargs after rollback )
Added tests for import-proc-cmdline and deploy-index option
Closes: #1013
Approved by: cgwalters
Refactor the similar code portion from delete option into
a new function, and reuse it in the replace logic.
Add the replace functionality to allow kernel arguments
replacement. Now support two different types of replacement:
1: replace by key=value when there is only one key existing
e.g we have 'hi=hello' as our one of the arguments (hi only has
one value associated with it) , and 'rpm-ostree ex kargs --replace hi=new'
will replace the value and change hi=hello into hi=new.
2: replace by key=value=new_value for all other replacements
( this will work for swapping single value pair too !)
Some tests for rpm-ostree ex kargs --replace are added
for future regression.
Closes: #1013
Approved by: cgwalters
Tests are introduced in this commit to test the basic
functionality for rpm-ostree ex kargs --append,
and rpm-ostree ex kargs --delete.
Those tests are added for future regression.
Closes: #1013
Approved by: cgwalters
Some new functions are added to handle delete operations
for kargs. We are now able to do the following delete operations kargs:
1: delete by key, if there is only one value associated with the key
we directly remove it
2: delete by key=value, it will find that specific key/value pair
and remove it from the kernel arguments
Similar to append functionality introduced, delete will
also create a new pending deployment that is rollbackable
Closes: #1013
Approved by: cgwalters
API functions from ostree-kernel-args.c
are copied to libpriv. The append functionality
reuses _ostree_kernel_args_append_argv() for
collecting added kernel arguments.
Also added handlation in rpm-ostree upgrader
to allow deployments happen with kernel arguments.
Now, the user is able to add kernel arguments via
'rpm-ostree ex kargs --append key=value'
or 'rpm-ostree ex kargs --append key' if they
want to have an empty value with key.
The user is also able to display the current
kernel arguments via 'rpm-ostree ex kargs'
In addition, this functionality will create a pending deployment,
and will update the conf file in /boot/loader/entries/ostree-$osname-0.conf upon success.
Closes: #1013
Approved by: cgwalters
This is initial groundwork for https://github.com/projectatomic/rpm-ostree/issues/594.
This commit sets up most of the required
front end logic( arg parsing, transaction handling), and will
be used in the following commits.
There is nothing really fancy in this commit, as most of the code
shares the similar style between other dbus related commands.
Closes: #1013
Approved by: cgwalters
This is a revisit of a PR for client-side layering: https://github.com/projectatomic/rpm-ostree/pull/1072
Here though we're doing this by default for server-side composes.
There are a few reasons to do this; first, I'm seeing an issue
in some of our Jenkins jobs for Fedora that hit "mirror roulette"
and end up creating commits that "revert" to older versions temporarily.
While I've [certainly pitched](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IMPE6KCRBHCEJH5VBE6ZFIRLPAD743JT/) this as a feature, I think
we really want something like `--force-older-timestamp` - basically
error out if the timestamps on one or more input repos were older.
Not doing that in this patch, but it paves the way to do so.
Second, I'd like to use this data in the `ostree.source-title`
metadata key down the line. Something like:
`└ rpmmd: fedora-26 (20170310), fedora-26-updates (20171101)`
(This could be a lot nicer if we drive versioning in to the rpm-md repo info,
and e.g. there's some friendly "week number" style versioning for the updates
repo now that it's batched...for now we have timestamps)
For CentOS/RHELAH this gets interesting and potentially more verbose,
to the point where we may want to render it more explicitly.
But anyways, let's do this now, as it will be useful even without
an explicit rendering, since users can do e.g. `ostree show` on
a base commit hash to dump the data.
I had a concern that some users may not want to emit this metadata;
they can currently do `--add-metadata-string rpmostree.rpmmd-repos ''`
and that will "win".
Closes: #1079
Approved by: jlebon
Now that there's a new libostree out, let's cut one here too, since we have a
fair bit accumulated, and I think it'd be good to have the oustanding kargs PR
to soak in master for a bit after landing.
Closes: #1080
Approved by: jlebon
Related to: https://github.com/projectatomic/rpm-ostree/issues/49
We want to support "name binding" per client system, rather than
having a hardcoded mapping in our tree. Currently if e.g. a new
daemon is added as a dependency (or as part of e.g. systemd) it's
easy to silently miss it.
This is prep for doing that binding client side consistently, which is what we
do with package layering.
Closes: #1077
Approved by: jlebon
We won't have done the postprocessing, so `/usr/lib/passwd` won't exist. Trying
to use `compose install` with current fedora-atomic failed (I *really* should
have tested that at least manually with the final patchset). Add `check-passwd`
to the test suite so this gets coverage too.
Closes: #1076
Approved by: jlebon
This is a cleanup I was going to do before, but had dropped. It's a general
followup to the `compose` rework; there's not much point to having a high level
wrapper, given that we generally need to do some postprocessing. Inline it into
the `ex container` code, which makes the core more "core".
Closes: #1074
Approved by: jlebon
I got a critical from an nonexistent `DESTDIR` in `rpm-ostree compose install`.
(I'm probably going to do a patch to add `rpmostree_command_invocation_set_exit_code()`
so the "exit 77" case can use that and everything else can `s/return EXIT_FAILURE/return FALSE/`
and we'll be free of these bugs)
Closes: #1075
Approved by: jlebon
Related to: https://github.com/projectatomic/rpm-ostree/issues/774
We aren't yet trying to render this in any way on the client side, but let's
start capturing the timestamp data now so that we can make use of it later
in e.g. `rpm-ostree status -v`.
Closes: #1072
Approved by: jlebon
Right now `rpm-ostree compose tree` is very prescriptive about how things work.
Trying to add anything that isn't an RPM is absolutely fighting the system. Our
postprocessing system *enforces* no network access (good for reproducibilty, but
still prescriptive).
There's really a logical split between three phases:
- install: "build a rootfs that installs packages"
- postprocess: "run magical ostree postprocessing like kernel"
- commit: "commit result to ostree"
So there are two high level flows I'd like to enable here. First is to allow
people to do *arbitrary* postprocessing between `install` and `commit`. For
example, run Ansible and change `/etc`. This path basically is like what we have
today with `postprocess-script.sh`, except the builder can do anything they want
with network access enabled.
Going much farther, this helps us support a "build with Dockerfile" style flow.
We can then provide tooling to extract the container image, and combine
`postprocess` and `commit`.
Or completely the other way - if for example someone wants to use `rpm-ostree
compose install`, they could tar up the result as a Docker/OCI image. That's now
easier; an advantage of this flow over e.g. `yum --installroot` is the "change
detection" code we have.
Related issues/PRs:
- https://github.com/projectatomic/rpm-ostree/pull/96
- https://github.com/projectatomic/rpm-ostree/issues/471
One disadvantage of this approach right now is that if one *does* go for
the split approach, we lose the "input hash" metadata for example. And
down the line, I'd like to add even more metadata, like the input rpm repos,
which could also be rendered on the client side.
But, I think we can address that later by e.g. caching the metadata in a file in
the install root and picking it back up or something.
Closes: #1039
Approved by: jlebon
Depends: https://github.com/ostreedev/ostree/pull/1296
As I mention in the commit there, I see two uses for this in rpm-ostree; first
in our test suite, and second for OCI-built image imports.
I also took a step further here and inject an `original-origin` metadata
key, though we aren't actually using that yet. The problem I'm trying
to solve there is that repeated `make vmoverlay` starts chaining things up,
but that gets very confusing. I think we should always have `vmoverlay` unwind
back to the base ref. (Or at least do that by default)
Closes: #1069
Approved by: jlebon
In another PR I did the manual bridging of commit metadata to deployment
property, but that's annoying. Let's just bridge all commit metadata.
Closes: #1069
Approved by: jlebon
