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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
I've become quite fond of the `--changelogs` switch lately on my
Silverblue. I find it useful as a first step when nailing down a
regression, or just to peruse the churn of changes after an update.
One annoyance is that the same changelog gets printed multiple times for
each RPM that shares the same SRPM. This patch does a naive lookahead to
dedupe them. Example output:
```
NetworkManager 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-adsl 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-bluetooth 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-config-connectivity-fedora 1:1.12.6-4.fc29.noarch -> 1:1.12.6-5.fc29.noarch
NetworkManager-libnm 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-ppp 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-wifi 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
NetworkManager-wwan 1:1.12.6-4.fc29.x86_64 -> 1:1.12.6-5.fc29.x86_64
* Mon Jan 14 2019 Beniamino Galvani <bgalvani@redhat.com> - 1:1.12.6-5
- improve Wi-Fi PMF support (rh #1665694)
```
I say "naive" because this doesn't catch the case where a binary RPM is
named differently enough that they're not consecutive. Anyway, this
simple heuristic cleans up the output nicely.
Closes: #1738
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
I'd been seeing hangs sometimes in "Importing metadata" and had
thought it was libsolv being slow, but actually the problem is
that while we explicitly check the libdnf repos,
`dnf_context_setup_sack_with_flags()` checks them again using
its `cache_age`.
Set the libdnf context's expiry to "never" after we've done the
checking so it's not checked twice.
This PR brought to you by airplane 🛫 travel and not wanting
to pay for expensive WiFi 💸.
Closes: #1723
Approved by: lucab
This is a very commonly hit issue in Fedora land. Add some explanation
so users aren't just confused, as well as the `cleanup -m` pointer. Also
link back to the main issue.
Closes: #1717
Approved by: cgwalters
The problem here is that bare-user has `user.ostreemeta` xattrs,
`tmpfs` (which bwrap uses for `/var/tmp` by default) doesn't support that.
Pass through the tmpdir to the target rootfs, which is the same place
as the repo in unified-core mode.
Ref: https://github.com/coreos/coreos-assembler/issues/254Closes: #1716
Approved by: cgwalters
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
Right now, if we want to commit onto the same ref, we require the full
previous commit. The previous commit full root is currently used as
follow:
- for handling `check-passwd` in the `previous` case
- as an optimization for SELinux policy matching (#1659)
Let's change the logic so that we gracefully handle partial commits.
This patch lowers full commit root loading in the one function that
really needs it (`rpmostree_passwd_compose_prep()`). We also turn off
the SELinux optimization if the commit is partial.
My goal here is to use this in coreos-assembler to seed the repo just
enough to keep the commit history intact. (Though we do have cache so
that we can still profit from the SELinux optimization if it's
populated).
Closes: #1704
Approved by: cgwalters
In the passwd/group migration code, rather than do a bunch of work and
then check for the error cases where we only migrate one of passwd and
group, just bring those checks and and queue the work at the end. This
simpifies the logic a bit since we don't have to maintain a
`perform_migrate` variable as well and instead can just return early in
the trival cases.
Closes: #1704
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
Capturing the system state at boot aids debugging. This is a
trivial implementation; we could in the future do structured
logging too.
The high level goal here is to help us track system state in
Red Hat CoreOS.
Closes: #1693
Approved by: jlebon
Avoids passing an allocated buffer from Rust to C; there's
controversy in the PR I sent to rust-lang around defining this as
supported.
Closes: #1691
Approved by: jlebon
For consistency with the rest of the codebase. There were also a few
spots which were missing the space between the function name and the
opening parenthesis.
Closes: #1687
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
Drop the `force_refresh` boolean parameter since we only ever call it
with `TRUE`. I think this dates from an earlier implementation where we
did call it with differing values.
Small prep for next patch.
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
It said so right there; "nuke in next version". No need to carry this
stuff forever. It's the final phase of feature promotion, like when one
officially moves out of their parents'.
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
While we had an override for both the Fedora `glibc-all-langpacks.posttrans`
version and the RHEL7-era `glibc-common.post`, there were two
problems.
First, the RHEL7 version's lua calls `rpm.expand()` internally
rather than flagging the script itself for expansion.
Second, we also need to disable rofiles-fuse for it.
Closes: #1678
Approved by: jlebon
Otherwise, the object might still own an idle source on the main
context, which will cause issues if another pull operation happens
again. This wasn't causing issues before because in places where we did
do multiple pull operations, we would reuse the same
`OstreeAsyncProgress` object, and the second pull operation *did* do
`ostree_async_progress_finish()`. But that's no longer the case now with
66761916.
Closes: #1676
Approved by: cgwalters
This is not strictly necessary since the progress is considered ended on
the client side when the transaction is finished, but let's be nice.
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
Prep for indicatif, the new progress implementation, which is now
more strict about overwriting tasks. The `OstreeAsyncProgress`
object lingered on and could own tasks on the mainloop. Narrow
the scope and avoid having one that crosses multiple pull requests.
Closes: #1661
Approved by: rfairley
The previous behaviour was to simply return "Invalid signature"
if the corresponding GPG public key wasn't found.
This status message wasn't clear enough that the key is missing.
If the GPG public key is now missing, a corresponding status message will be issued.
Closes: #1650
Approved by: rfairley
Otherwise we can get fun undefined behaviour like the caller thinking
there was a change when we didn't even install anything.
Closes: #1669
Approved by: cgwalters
That was the last bit in which we referred to the old unified core
option. Also change it in the source itself for completeness.
Closes: #1668
Approved by: cgwalters
We don't need to run the bwrap self test if we just want to print the
manifest. I played with putting the self test in `impl_install`, though
e.g. `postprocess` also needs this so it wasn't quite right.
Closes: #1666
Approved by: cgwalters
Previously, we were limiting the target repo in unified mode to be a
bare-user repo located on the same filesystem (see message of previous
commit). This patch lifts this restriction by making a distinction
between the *build repo* and the *final* target repo.
To do this, we create a bare-user repo located near the pkgcache to
take advantage of hardlinks and devino caching at commit time. And only
after committing do we essentially `pull-local` into the final target
repo. This of course allows us to avoid potentially pulling across the
two filesystems file objects that are already present in the target
repo.
This will be used by coreos-assembler:
https://github.com/coreos/coreos-assembler/pull/190Closes: #1490Closes: #1657
Approved by: cgwalters
This ensures that we always get hardlinks when checking out of the
pkgcache. This works right now because we indirectly require the target
bare-user repo and the pkgcache to be on the same filesystem by setting
`no_copy_fallback` in the core (I say "indirectly" because that setting
only enforces the workdir to be on the same filesystem as the pkgcache
repo, but since the workdir is currently placed inside the bare-user
repo...).
However, I'd like to change the requirement of a bare-user repo so that
one can commit into a repo on a different file system or a repo of a
different type (e.g. archive repo). This is prep for that.
Closes: #1657
Approved by: cgwalters
Rather than defaulting to the host system's SELinux policy, we can be
much more efficient here if we instead use the policy of the last commit
if available. Likely, the pkgcache is currently labeled with that
policy, which means we skip the relabeling phase before checkout. But
also, if the policy didn't change at all in the new rootfs, we also skip
the second relabeling phase after assembly.
Closes: #1659
Approved by: cgwalters
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
Make sure we always pass an integer and not a float to
`glnx_console_progress_text_percent`. And also make sure we clamp the
value we pass to 100. Not sure how I hit this, somehow the byte counting
we do upfront before committing is *less* than the addition of all the
`g_file_info_get_size()`s?
Closes: #1658
Approved by: cgwalters
Didn't hit this but this will be useful for a following commit which
delays committing to the final repo until the end.
Closes: #1658
Approved by: cgwalters
We don't actually need the repo in `rpmostree_passwd_compose_prep()`
since we're already passed the OstreeRepoFile root of the previous
commit as a separate arg.
Closes: #1658
Approved by: cgwalters
Just a minor readability tweak. Wasn't clear what `read_xattrs_cb`
meant. Also inline an indexing var into the loop.
Closes: #1658
Approved by: cgwalters
If the policy didn't change, then it's safe to use the devino cache
regardless of the repo type. This dates from #1123; I think the
rationale there was so that it only affects the pkglayering path, where
the system repo is bare. But really, it should be fine to generalize
this since we don't have any xattr callbacks.
Closes: #1658
Approved by: cgwalters
This is slight bikeshed, though this comment took me a second to parse
because it says "not do it" right before we do it. Let's just move it up
to right outside where the condition is actually tested.
Closes: #1658
Approved by: cgwalters
