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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
A lot of history here. Long before the YAML treefiles, I was
dissatisfied with the JSON treefile syntax, and also wanted
to create a format that could be used by the (still experimental)
`container` builtin, and chose to use GKeyFile.
I don't think that really worked out; the Rust YAML is just way
better.
In the future we probably want to more cleanly split off the
"compose only" aspects of the treefile. But for now, it's rather
tedious to pass down flags from the treefile into the keyfile/gvariant.
Let's just give direct access to the treefile to the core.
Prep for sysusers.
Closes: #1764
Approved by: jlebon
We should only be calling into GIO once we've set our preparatory
environment variables etc. Not fixing anything today that I know
of, just noticed while looking at the code.
Closes: #1763
Approved by: jlebon
This removes the "transaction monitor". Originally the idea
here was things would queue, but we never really made that
work. Since transactions started grabbing the
libostree sysroot lock in particular.
Rip out the transaction monitor code with the queue and have
a singleton txn ref in the sysroot object. This should ensure
that if a txn is active, one always gets an error message about
which one.
Next, add a 30s timeout for connections to the transaction DBus
sockets after they're complete.
This should address https://github.com/projectatomic/rpm-ostree/issues/1692
which is a case where gnome-software was leaking the txn DBus
connection and keeping it alive.
Closes: #1755
Approved by: cgwalters
There's no reason to keep this around, we aren't going to use it.
Motivation here is the lifetime of transactions is currently
entangled with the bus connections from clients, and we don't
want to hold them open unnecessarily.
Also, we were adding a notify on the wrong object. I think it
was just working before because something else ran the mainloop
and we got the property notification anyways.
Closes: #1759
Approved by: jlebon
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
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 uses the `Context` feature of the failure crate to make error
messages more useful when we fail to open a file. The difference with
`map_err` is that one can still obtain the underlying error from the
context if need be. Though surprisingly, the normal `Display` for a
`Context` doesn't include the original error, so we essentially have to
do a prefix here (see [1]).
Before:
```
error: Failed to load YAML treefile: No such file or directory (os error 2)
```
After:
```
error: Failed to load YAML treefile: Can't open file "treecompose-post.sh": No such file or directory (os error 2)
```
[1] https://github.com/rust-lang-nursery/failure/issues/182Closes: #1735
Approved by: cgwalters
These are more files that get mangled at `%configure` time. These two
new ones specifically, I tripped on while building on ppc64le for RHEL7.
See https://bugzilla.redhat.com/show_bug.cgi?id=1113618 for more info.
Closes: #1731
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
Obviously doing these trivial functions in parallel doesn't matter,
but I wanted to dip my toes into Rayon (and Rust parallelism in
general).
`try_for_each()` is just...staggeringly simple and beautiful.
Closes: #1727
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
We've been seeing more breakage recently due to much of the Rust
ecosystem sticking to minimum rustc versions more recent than ours. A
lockfile now means we have to periodically update it, but at least we
have much better control over our CI system and when we want to spend
time resolving package bump conflicts vs. just trying to get a small
patch in.
Closes: #1719
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
And `config.guess` and `config.sub`. These files get mangled by the
`%configure` macro when it tries to insert hardening compile flags and
so the checksums no longer match. This is an ugly hack akin to #1554
that requires an incision in the cargo vendor JSON.
Fedora does package a lot of these crate sources now which we
could use to drop these hacks, but not all the crates are packaged (I
counted 4 unpackaged top-level crates), and I'm not sure what their
states are in RHEL7/8 either.
Closes: #1715
Approved by: cgwalters
The latest backtrace release isn't compatible with 1.26.2. A patch for
this is underway in:
https://github.com/alexcrichton/backtrace-rs/pull/137
Though for now, let's just restrict the version since we should be
bumping our minimum rustc requirement soon-ish anyway.
Closes: #1713
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
This was omitted since in practice we aren't actually testing it,
the container path is mostly via `ex container` which uses keyfiles.
Closes: #1701Closes: #1702
Approved by: jlebon
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
