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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
Not that it matters much since that function can't fail right now
(though it does have a precondition check). But this just matches what
we do elsewhere and prepares us in the event the function becomes
fallible.
Closes: #1783
Approved by: cgwalters
Minor regression from #1755. Noticed this after seeing the following in
the journal:
```
Mar 01 02:41:03 f29-ros rpm-ostree[3931]: Failed to GetConnectionUnixUser for client /org/projectatomic/rpmostree1/fedora_atomic: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get UID of name '/org/projectatomic/rpmostree1/fedora_atomic': no such name
Mar 01 02:41:03 f29-ros rpm-ostree[3931]: Failed to GetConnectionUnixProcessID for client /org/projectatomic/rpmostree1/fedora_atomic: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not get PID of name '/org/projectatomic/rpmostree1/fedora_atomic': no such name
```
Closes: #1769
Approved by: cgwalters
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
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
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
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
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
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
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
I was playing with https://crates.io/crates/indicatif
and this is prep for using it.
By using autocleanups here we ensure that the output state
ends even if we encounter an error. We previously had a few
explicit `failed` prints in cases where failure was more common
such as dependency resolution, but that was far from consistent.
Now we will always ensure a newline is printed even if an error
occurs, and we won't have to worry about missing calls to
`_task_done()` in the success case.
The downside of this is that we lose the `done` bit in the success
path...I thought about maybe taking a pointer to the error and
printing `done` or `failed` depending on whether it's non-`NULL`
but eh...the `done` is implied by us going on to the next line.
Also that issue will be fixed with the indicatif work.
Closes: #1640
Approved by: jlebon
It still takes a noticeable amount of time to stage a deployment, so
just give some feedback so we don't just hang there.
Closes: #1594
Approved by: cgwalters
Make sure we can open and query the rpmdb when creating new deployments.
This should help filter out cases where somehow librpm failed to
actually write the rpmdb but didn't error out.
This requires splitting the sanity checking in two so that we still get
that nice error first on scripts that do `rm -rf`.
See: #1566Closes: #1584
Approved by: cgwalters
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
Check if we can reuse the base rpmdb from the pending deployment if it
matches the base rev we're targeting. This allows us to avoid checking
out the tree early only to later on discard it. Such cases include
layering existing packages and inactive requests.
Closes: #1502
Approved by: cgwalters
Prep for another patch. Some callers will need to know whether some
layers contain certain fixes before proceeding. We already have that
information handy so just expose it.
We should probably do something about that massive argument list... will
return to that at some point. But at least with the new base layer
accessor from the previous patch, there aren't many callers affected by
the added argument.
Closes: #1560
Approved by: cgwalters
In the majority of cases, we just want to know if a deployment is
layered and what the base commit is. Make a simpler accessor for this.
We can further simplify the logic on the client side here by relying on
the fact that there is only a base layer iif we're layered, so we don't
need two output variables.
I find it also makes things much easier to grok in some places, e.g. in
`rpmostreed-deployment-utils.c`, we now have:
const char *current_base_checksum = current_base_checksum_owned ?: current_checksum;
which better crystallizes what we want to get at.
Or e.g. in the sysroot upgrader, we can drop a comment which states
something that is now completely obvious.
Closes: #1560
Approved by: cgwalters
This removes the logic around supporting opting out of the staging
feature. We don't want to support multiple configurations here, and at
this point, staging should be considered stable.
Closes: #1546
Approved by: cgwalters
We've put a lot of work into staged deployments, it's time
to pull the trigger and turn them on by default. This is
a key step for enabling `stage` mode automatic updates by
default in e.g. Fedora CoreOS/Silverblue.
We add a new `--disable-staged` build-time option to flip
things back.
Closes: #1430
Approved by: jlebon
Staging fixes the `/etc` bug for livefs. There's actually more
we could do here around taking advantage of staging for livefs;
for example, I think once the livefs is complete, we could just delete
the staged deployment. And then we don't need to render on the next
boot the live status, etc.
Anyways, all that can come in the future. This is prep for
enabling staging by default.
Closes: #1430
Approved by: jlebon
And don't mention "replace" in the error texts.
This is (now) known broken with kernel updates; making that not
dangerous isn't going to be easy. I debated entirely removing it
but for now let's just make it harder to use.
Ref: https://github.com/projectatomic/rpm-ostree/issues/1495Closes: #1497
Approved by: jlebon
Add a new `install/uninstall --idempotent` option to make it easier to
interact with the CLI through scripts. E.g. one doesn't have to check
first if a request has already been installed/uninstalled.
Closes: #1467Closes: #1478
Approved by: cgwalters
The `cached-update` variant would mark a bunch of RPMs as upgraded even
if they didn't actually change. The issue turned out to be we were doing
the diff all wrong in the staged deployment case. I'm not sure what I
was thinking in #1344, but essentially, we were marking all layered RPMs
in the staged deployment as updates instead of only marking those
layered RPMs which were actually changed EVR.
We just simplify the approach here by directly doing a pkglist diff
between the booted and staged deployments and consuming that. That's
really all there is to it! Reduces the code quite a bit too.
Closes: #1446Closes: #1455
Approved by: cgwalters
We're looking to embed an ostree commit inside a container image,
to make it easier to transport around with other images.
Conceptually here the host system is tracking a container (just
like for rojig we're tracking an RPM). This is the first step
towards making that support nicer; tooling can do
`rebase --custom-origin-url oscontainer://quay.io/exampleos@sha256:...`
and have that show up in `rpm-ostree status`.
There are two values, one intended to be machine readable (like
the `ostree://` and `rojig://` and one for humans which we
display when an admin types `rpm-ostree upgrade`.
This builds on prior work in
27bd7b97bb from #1396 .
Closes: #1406
Approved by: jlebon
Use the new API introduced in
9131d8a4cc
which helps avoid relying on the magical deployment refs. I thought
this would help with a livefs+staging issue, but it doesn't. But we might
as well do it, it's adding another level of safety.
Closes: #1439
Approved by: jlebon
Follow up to #1434. I was testing this inside my test VM, which didn't
have a rollback deployment (i.e. it was just the staged deployment and
the booted deployment). Testing the upcoming release on my real system
showed that this wasn't correctly fixed.
Closes: #1437
Approved by: cgwalters
It doesn't make sense to rollback a staged deployment. Give a hint
instead to use `cleanup -p` if needed. Otherwise, we dump core later on
in libostree.
This is technically a breaking change once staged deployments become the
default. However, I think it makes sense overall. We'll have to make
some noise about it.
Closes: #1434
Approved by: cgwalters
Add a new `reset` command that makes it easy to blow away all
customizations: overlays, overrides, and initramfs. One can use flags to
only reset some of the customizations.
I placed this under `ex` out of conservatism. It's a pretty simple
command with simple behaviour, though the features it relies on
(no-layering, no-initramfs) are brand new. We can move it out of there
in a release or two?
Closes: #1387Closes: #1419
Approved by: cgwalters
It's been in experimental for a while now, and we've had good feedback
that it's working. With #1392 fixed, it seems in a good position to
declare stable and commit to that API. This also helps empty out `ex` a
bit.
Closes: #1428
Approved by: cgwalters
We added the `no-layering` option, but made it conflicting with
`--install`. This loosens that requirement so that one can do e.g.
rpm-ostree uninstall --all -install foobar
to essentially remove all layered packages and then add back `foobar`.
Prep for `reset` command.
Closes: #1424
Approved by: cgwalters
Kernel arguments added from `rpm-ostree ex kargs` can be lost
after doing multiple deploy related operations (e.g upgrade, install etc).
The root cause of that is because when doing the deployment
(ostree_sysroot_deploy_tree), the kernel arguments from the
pending deployment were never passed in.
This commit adds logic to pass in kernel arguments from pending deployment
to fix the above mentioned problem
Closes: https://github.com/projectatomic/rpm-ostree/issues/1392Closes: #1420
Approved by: cgwalters
Fewer variables and avoid extra strdupv calls. I also fixed
handling of refspec canonicalization that I broke with a previous
change (we weren't actually setting `self->refspec` to the canonicalized
version).
Closes: #1414
Approved by: jlebon
It's just all-around simpler if we only parse the vardict
and avoid exploding everything into enums/parameters. Previously
we were converting the variant into parameters and flags, and
then in most cases converting the flags back into booleans!
This should make it easier to add new parameters.
Closes: #1412
Approved by: jlebon
This is one part of #1387 and is prep for a single higher level command
that makes it easier to remove all customizations (layering *and*
overrides).
Closes: #1408
Approved by: cgwalters
We were also counting the `NULL` element we added at the end of the
array when appending how many local installs we were doing. Fix this by
just reading the array length before adding the `NULL` terminator.
Closes: #1407
Approved by: cgwalters
We were previously relying on `!self->revision` to determine what
message to print in the no-op case. This made `override reset --all`
also print `No upgrade available.`.
Fix this by using the stronger `is_upgrade` instead.
Closes: #1407
Approved by: cgwalters
