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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's make this test work across major version rebases of the FAHC
treecompose job by not hardcoding a specific `%{dist}` here. It's strong
enough to check that the `deploy` operation has the expected previous
version.
I did bump the FAHC buildroot so that next version of the rojig RPM will
be f29, but I don't want to wait until the job has composed at least two
of them.
Closes: #1787
Approved by: cgwalters
Let's output to `ex-container-logs`, which matches the directory we
currently have specified in `artifacts:` so that we actually get test
logs uploaded.
Closes: #1787
Approved by: cgwalters
Otherwise, glib will complain if the array is empty since it can't infer
the type of the item.
While we're here, just `git grep` all instances of
`G_VARIANT_TYPE_ARRAY` and make sure they use a fully-specified format.
I added a test to sanity check that glib is happy to synthesize empty
`GVariant` arrays from `g_variant_builder()` if the format string is
specified.
Closes: #1783
Approved by: cgwalters
And this (for now at least) completes the epic journey of the
"where's the kernel"? With this it's found solely in
`/usr/lib/modules/$kver`.
There are a few reasons to do this; most prominent is that
it avoids duplicating the content as the locations may have
different SELinux labels.
Closes: #1773
Approved by: jlebon
I'd like to add a new `boot-location: modules`. In prep
for that, let's remove the legacy `both` which drops into
`/boot`.
The libostree support for handling `/usr/lib/ostree-boot` has
existed for over 4 years:
```
commit 37a059925f6b96d30190b65bee6bdde0ae1c6915
Commit: Colin Walters <walters@verbum.org>
CommitDate: Sun Nov 30 23:14:05 2014 -0500
deploy: Ensure that we can deploy using only /usr/lib/ostree-boot
```
I think we assume now that no one is now making *new* treecomposes and needs
a newer rpm-ostree and that they expect people to be able to use as an
upgrade target from a libostree that predates that.
Closes: #1773
Approved by: jlebon
Add a `basearch` key to the manifest. This can be used at compose time
to assert the architecture the compose is running on. Though my
motivation is for the common case where it gets omitted from the input
manifest and gets automatically added by rpm-ostree into
`/usr/share/rpm-ostree/treefile.json` for introspection on the client.
(The crucial part here is that the treefile created by rpm-ostree
remains deserializable into a `TreeComposeConfig`).
Closes: https://github.com/coreos/fedora-coreos-tracker/issues/154Closes: #1766
Approved by: cgwalters
Manually patch `file_contexts.subs_dist` so that `/home` is equivalent
to `/var/home`. This is required now that the generated homedirs rules
use `/var/home`. Otherwise, `matchpathcon` for example will return wrong
results.
This patch also includes the *removal* of `/var/home -> /home` so that
we're not dependent on this selinux-policy patch making it at the same
time as downstream:
https://src.fedoraproject.org/rpms/selinux-policy/pull-request/14
(See the conversation there for more information.)
Closes: #1754
Approved by: cgwalters
It's possible for some postprocessing scripts to affect the final
SELinux policy. This is the case for the new `/etc/default/useradd` edit
we now do (#1726), but it could've been the case beforehand too with
user scripts modifying e.g. booleans (though ideally all these
modifications would be part of RPMs).
Do a final `semodule -nB` during postprocessing so that the final policy
we commit is "up to date". Otherwise, users may only see changes take
effect if they layer packages that trigger a rebuild.
The motivation for this is specifically for `/etc/default/useradd`.
There is magic in `selinux-policy` that parses the file and generates
templated rules from the value of `HOME`.
For more info, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1669982https://src.fedoraproject.org/rpms/selinux-policy/pull-request/14Closes: #1754
Approved by: cgwalters
RPM-OSTree has been pretty good so far at consuming the exact same RPMs
used for traditional OSes without modifications. This is important,
because shielding RPMs from the OSTree abstraction means we remain
compatible with a large portion of the ecosystem.
However, there are some apps that definitely require rethinking their
approach. The example right now is akmods, which has a patch proposed to
build kmods at `%post` time on OSTree systems instead of from the
daemon.[1]
In such situations, scriptlets need something to key off of for the
OSTree-specific approach. The `/run/ostree-booted` file is the de facto
API to determine if we're running on an OSTree system or not. This patch
simply extends this API so that scriptlets can naturally make use of
them.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1667014Closes: #1750
Approved by: cgwalters
There's lots of gyrations here for unified-core vs not; it's
been broken in the case of `--unified-core` for a while I think.
In that case our workdir is tmpdir, so rename that directory.
Closes: #1743
Approved by: jlebon
Teach rpm-ostree to interpret rebases where the remote component is a
path to a local repo, e.g.:
rpm-ostree rebase /mnt/ostree/repo:my/target/ref
Essentially, the local remote in this case is considered "ephemeral".
It's kind of the equivalent of, on traditional systems:
dnf install --repofrompath repo,/path/to/repodata ...
The use case for this is in OpenShift v4, in which upgrades are done
from containers containing the OSTree commit. There, we want to point
RPM-OSTree directly at the repo in the mounted container and rebase to
the checksum.
For now, the option is marked experimental. One major reason for this is
that the way we pass the repo differs on RHEL7 vs other platforms. (See
comment block in `rpmostree-dbus-helpers.c` for details).
Related: https://github.com/openshift/machine-config-operator/issues/314
Co-authored-by: Colin Walters <walters@verbum.org>
Closes: #1732
Approved by: cgwalters
This adds an optional date field to the prefix
passed by automatic_version_prefix. An example of specifying
the field is as follows:
10.<date:%Y>
And the fields progress like:
10.2018.0
10.2018.1
10.2018.2
10.2019.0
The date format creates a new "current date" string using
valid date directives passed into g_date_time_format().
If there is a problem reading the given date format,
an error is given and the next version is returned as NULL.
If no <date:...> tag is detected in the auto version prefix,
the same behavior as before (appending .1 and incrementing) occurs.
This may be helpful to avoid writing glue code to auto-update
the version if a date string in the commit version is desired.
Otherwise, --add-metadata-string=version= is an alternative for
complete customization.
Fixes: #1712Closes: #1721
Approved by: jlebon
We were using `g_strfreev()` to free the string array, but the strings
themselves were owned by the `modifiers` GVariantDict. Fix this and make
the comments about it more explicit. On my computer (and at least
Dusty's), this was only actually tripping up libc when passing more than
just one package on the CLI.
Closes: #1707Closes: #1709
Approved by: cgwalters
When handling `GetDeploymentBootConfig()`, we would trip an assertion
when trying to read the full bootconfig from a staged deployment, which
of course doesn't have a full bootconfig yet. Rework this to add a new
`staged` key to the returned dict, in which case only `options` is
included. (Which is all `rpm-ostree kargs` needs anyway).
Closes: #1708
Approved by: cgwalters
If no cache dir is given in the workdir, we would alias the cache dir fd
to the workdir fd. But of course, this meant that we'd try to close the
same fd twice when freeing the compose context. Instead, let's just copy
the fd as is also done in the non-unified path.
Closes: #1697Closes: #1698
Approved by: lucab
One question I often have when looking at the output of `status -a`:
```
AvailableUpdate:
Version: 29.20181202.0 (2018-12-02T08:37:50Z)
Commit: dece5737a087d5c6038efdb86cb4512f867082ccfc6eb0fa97b2734c1f6d99c3
GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
SecAdvisories: FEDORA-2018-042156f164 Unknown net-snmp-libs-1:5.8-3.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-core-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-modules-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-modules-extra-4.19.5-300.fc29.x86_64
FEDORA-2018-f467c36c2b Moderate git-core-2.19.2-1.fc29.x86_64
Diff: 67 upgraded, 1 removed, 16 added
```
is "How serious and relevant are these advisories to me? How soon should
I reboot?". For the packages that I'm most familiar with, e.g. `kernel`
and `git-core`, I usually look up the advisory and check why it was
marked as a security update, mentioned CVEs, and how those affect me.
The updateinfo metadata includes a wealth of information that could be
useful here. In Fedora, CVEs treated by the security response team
result in RHBZs, which end up attached to the advisories and thus make
it into that metadata.
This patch tries to reduce friction in answering some of those questions
above by checking for those CVEs and printing a short description in the
output of `status -a`. Example:
```
AvailableUpdate:
Version: 29.20181202.0 (2018-12-02T08:37:50Z)
Commit: dece5737a087d5c6038efdb86cb4512f867082ccfc6eb0fa97b2734c1f6d99c3
GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
SecAdvisories: FEDORA-2018-042156f164 Unknown net-snmp-libs-1:5.8-3.fc29.x86_64
CVE-2018-18065 CVE-2018-18066 net-snmp: various flaws [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1637573
FEDORA-2018-87ba0312c2 Moderate kernel-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-core-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-modules-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-modules-extra-4.19.5-300.fc29.x86_64
CVE-2018-16862 kernel: cleancache: Infoleak of deleted files after reuse of old inodes
https://bugzilla.redhat.com/show_bug.cgi?id=1649017
CVE-2018-19407 kernel: kvm: NULL pointer dereference in vcpu_scan_ioapic in arch/x86/kvm/x86.c
https://bugzilla.redhat.com/show_bug.cgi?id=1652656
FEDORA-2018-f467c36c2b Moderate git-core-2.19.2-1.fc29.x86_64
CVE-2018-19486 git: Improper handling of PATH allows for commands to executed from current directory
https://bugzilla.redhat.com/show_bug.cgi?id=1653143
Diff: 67 upgraded, 1 removed, 16 added
```
Including the CVE name and RHBZ link also makes it easier to look for
more details if desired.
Closes: #1695
Approved by: rfairley
Minor regression from #1587. There were places that were still doing
`dnf_context_set_cache_age()` manually, but those calls didn't exactly
have the intended effect since the core now handled caching itself.
The actual result was that the metadata was still being updated, but not
during the `dnf_repo_check` pass that the core does, but rather the
`Importing rpm-md` pass it does right after. So then, we were
incorrectly printing `(cached)` even though we'd update it afterwards.
Switch to the new way of doing things.
Closes: #1686
Approved by: cgwalters
This is relatively uncontroversial functionality that has already proved
useful when helping folks debug their stuff. Let's promote it to the
stable interface.
Closes: #1682
Approved by: rfairley
To make it more obvious what the difference between "Importing metadata"
and "Importing" is, add "rpm-md" to the first and "packages" to the
second.
Closes: #1681
Approved by: cgwalters
In general our current CI/test system is susceptible to drift
between the container and AH. The direction we should be
going is to have coreos-assembler solve this problem with
a SDK, but for now, let's ensure that the container's libsolv
makes it to the host, same thing we do for libostree.
Closes: #1676
Approved by: cgwalters
This turned out to be messier than I thought, because of two primary
factors; the biggest mess here of course is the indirection
through the DBus API.
The other problem is that previously we passed the string to render
each time, and with current indicatif that'd trigger a rerender.
Since (usually) don't change the "prefix string", rework the API.
Change the "percent/n_items" bits to use autocleanups as well, and
to take the prefix string as an initial argument.
Since the state expands to multiple components, also change the
API to use the `0-initialized` pattern rather than trying to
return an aggregate.
We also gain a "sub message" which we use to display e.g.
package names as we're doing checkouts. Note this ends up
at the end, since otherwise everything else jumps around.
Closes: #1661
Approved by: rfairley
External tools often want to parse the ref; for example coreos-assembler
currently does so. Let's ensure `${basearch}` is expanded with
`--print-only` so they can parse that JSON to get the expanded version
reliably.
Implementation note: this is the first Rust code which exposes a
"GLib-like" C API, notably with GHashTable, so we're making more use
of the glib-rs bindings.
Closes: #1653Closes: #1655
Approved by: jlebon
This currently requires a `--i-know-this-is-experimental` flag;
I know it'd be a bit more consistent to have it under `ex`, but
what feels weird about that is *most* of the `ex` commands people
use are client side. This is where we want it to ultimately end
up.
We've landed a lot of prep patches, but I know there's still
a notable amount of code duplication with `compose tree`. What's
left is about ~700 lines but it's mostly not hard/complex code
anymore.
In the future, I'd like to extract more of the compose code
to a `rust/src/compose.rs` or so, but I think this is sustainable
fow now.
My high level goal is to get this into coreos-assembler and stand
up a Silverblue build that uses it.
Closes: #1512
Approved by: jlebon
While serde gives us type checking, it of course doesn't understand
semantics beyond that. One example is checking the compatibility of
`add-files` entries with the OSTree model. This is something we can do
upfront early on to avoid surprises for users.
Also tweak the docs to reflect this new check.
Related: #1642Closes: #1643
Approved by: cgwalters
Add a `selinux` verb to treespec, and bind it from treefile. If
set, use it in the core to load an initial policy before import,
if we didn't already set a policy.
In practice right now this is only used from the compose path
since the SysrootUpgrader uses the policy from the merge deployment.
Unset the policy if rojig mode is enabled.
Now, non-SELinux use cases are required to set `selinux: false`
in the treespec. For `ex container` I just set it in our example
specs. Probably that should forcibly disable it in the
treespec but eh, it's experimental.
The other case I can think of is client-side layering; before
we would create a policy using the target root, but it
wasn't a *hard* requirement, i.e. we didn't error out if
`policy_get_name() == NULL`. Let's preserve that semantic by
hooking off of whether `_new_system()` was used.
Prep for sharing code with `compose rojig`.
Closes: #1630
Approved by: jlebon
This way when debugging if I want to preserve the state so I can
go there and rerun command under gdb for exmaple, all I need
to do is set `env TEST_SKIP_CLEANUP=1` rather than also needing
to find a separate dir and also set `env RPMOSTREE_PRESERVE_TMPDIR=1`.
Closes: #1630
Approved by: jlebon
In preparations for https://github.com/ostreedev/ostree/pull/1740, just
hard enable this path unit for now since centrally-maintained distro
presets still need to be updated.
Closes: #1617
Approved by: cgwalters
Try to tease out a bit more info from the journal by looking at the
systemd message when the service transitions to the dead state or even
looking at the OSTree output itself.
Example outputs:
```
[root@f28-ros ~]# rpm-ostree status
State: idle
Warning: failed to finalize previous deployment
error: opendir(ostree/deploy/fedora-atomic/deploy/887c95887a3047a60372016a0d84536530755b60df3cca33c819f7606e220adf.0): No such file or directory
check `journalctl -b -1 -u ostree-finalize-staged.service`
AutomaticUpdates: disabled
...
```
```
[root@f28-ros ~]# rpm-ostree status
State: idle
Warning: failed to finalize previous deployment
ostree-finalize-staged.service: Failed with result 'timeout'.
check `journalctl -b -1 -u ostree-finalize-staged.service`
AutomaticUpdates: disabled
...
```
Closes: #1601
Approved by: cgwalters
Sample output:
```
$ rpm-ostree status
State: idle
Warning: failed to finalize previous deployment
check `journalctl -b -1 -u ostree-finalize-staged.service`
AutomaticUpdates: disabled
...
```
(Though open to tweaking it).
I also played with directly invoking `journalctl` for the user, but that
can get really spammy with e.g. `os-prober` output and such.
I wrote this in Rust using journal API wrappers because I also plan to
implement the `history` command in Rust and will also enhance that new
`journal` module there for that.
Requires: https://github.com/ostreedev/ostree/pull/1750
Requires: https://github.com/jmesmon/rust-systemd/pull/54
(Though I've pointed the manifest at my branch for now for CI).
Closes: #1567Closes: #1601
Approved by: cgwalters
This is prep for running inside (unprivileged) Kube containers
as they exist today: https://github.com/projectatomic/rpm-ostree/issues/1329
Sadly FUSE today uses a suid binary that ends up wanting CAP_SYS_ADMIN.
I think there's some work on FUSE-in-containers but I'm not sure of
the current status.
What rofiles-fuse here is doing here is protecting is the hardlinked
repo imports. But if `--cachedir` isn't specified, that repository
gets thrown away anyways. So there's no real value to using FUSE
here.
Also since nothing is cached, disable the devino cache.
We also make use of --force-copy-zerosized that just landed
in libostree: https://github.com/ostreedev/ostree/pull/1752
Down the line ideally we gain the capability to detect if either
unprivileged overlayfs/FUSE are available. Then if `--cachedir`
is specified we can make things work.
Closes: #1591
Approved by: jlebon
Split out of supporting "pure rojig" work. We also want
to support this for doing "oscontainers" as is planned for
Red Hat CoreOS. The user experience in both cases is oriented
around versioning of the external wrapper, not the inner ref/commit.
Note for users/builders who want to make use of this feature:
You probably want to mirror the changes in our test suite here to
use the compose JSON and parse the resulting `ostree-commit` out of that.
Closes: #1603
Approved by: jlebon
Drop the `rpmostree.rpmdb.pkglist` keys from the deployment metadata
since users shouldn't need it and it greatly increases the size of the
output.
Closes: #1577
Approved by: cgwalters
