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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
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
There are a few scenarios today where one might deliver content
to a machine via an external transport. For example, take the
scenario of a single server updated via USB drive. While we
can provide a refspec...what should the remote be? (This gets
into ostree collections). There's nothing really that can
happen when typing `rpm-ostree upgrade` unless the USB stick
is plugged in. That type of scenario should be emphasized
by pinning the commit - the machine is updated via an external
script.
Another case: we're experimenting embedding OSTree commits inside OCI
containers. Here again since rpm-ostree can't understand how to
pull content from containers, it's saner to drop the refspec
bits, and pin to a commit.
Further enhancements will follow to make the admin experience more
obvious.
Closes: #1396
Approved by: jlebon
Follow-up from #1344.
In the case where a cached update is created from an `upgrade` operation
(and soon, "stage" auto-update policy runs), we can just print the diff
and advisory info together with the pending deployment. This makes the
output look much more natural.
Closes: #1350
Approved by: cgwalters
In #1344, we changed `upgrade` to always write the cached update. One
thing I hadn't noticed was that with pkglayering, loading the sack twice
meant we printed all that gory repo info twice.
Really, the much nicer thing to do is just to make an effort to try to
*keep* the original sack that the core used so that we skip all that
overhead completely.
Closes: #1357
Approved by: cgwalters
Now that infrastructure for this has landed in libostree,
let's make it easy for people to opt-in to testing it. This is a distinct first
step for adding it as an update policy.
Closes: #1352
Approved by: jlebon
Right now, cached updates generated during "check" policy runs are
completely decoupled from upgrade operations. This can lead
to the surprising situation where the "Available update" is *older* than
a freshly deployed pending tree with `rpm-ostree upgrade`.
We should just generate a cached update after upgrade operations. This
is also prep for staged deployments, where we'll want to do this as
well.
Note that we write out the cached update here even if automatic updates
are turned off since it's essentially free. I've been thinking about
always displaying that information after an `rpm-ostree upgrade` in
`status`. Though not sure if we should keep it in a separate "Available
update" section, or somehow morph it as part of the pending deployment
output.
Closes: #1344
Approved by: cgwalters
Building on:
- 9cbec27d4c
- e7a42f70a9
I was looking at a rpm-ostree run that imports a variety of rpmmd-repos,
and information about the source repositories is really useful for determining
the up-to-dateness. We've been capturing this data for a while, it's
about time we started showing it somewhere.
This does make `status --verbose` notably more verbose, but eh, that
seems fine for now.
See also https://github.com/projectatomic/rpm-ostree/issues/774Closes: #1345
Approved by: jlebon
This came up in a few places recently; it happens for RHEL in some
cases, and in general we don't want to completely fail the daemon
start if someone messes up their remote config.
Closes: https://github.com/projectatomic/rpm-ostree/issues/1301Closes: #1302
Approved by: jlebon
Implemented in libostree in https://github.com/ostreedev/ostree/pull/1464
Let's display it - wrapping the command will come later.
I also just noticed `rpmostree_syscore_filter_deployments()` at least is
going to have to learn about pinning; will need to improve the test suite
around this too.
Closes: #1292
Approved by: jlebon
Rather than recalculating `cached-update` as part of transaction
cleanups and RpmostreedOS internal reloads, write it directly to a file
from `deploy_transaction_execute`. This gives two major benefits:
1. Auto-updates now has virtually zero impact to daemon startup time.
2. We get to directly use the `DnfSack` created during metadata refresh
rather than reconstructing it later on. This greatly simplifies code.
This makes use of new APIs in libdnf to skip filelists and load
updateinfo metadata right from the start.
Closes: #1268
Approved by: cgwalters
This renames the API functions in the core and origin, and also fixes up the
fact that we were still looking for `jigdo/` refs in the pruning code.
Closes: #1279
Approved by: jlebon
We're continuing an incremental renaming process; previously we changed
the most user-visible strings. Now we're doing some internal variables,
and notably the cached refs and the origin files - the latter set is
things that end up on disk.
This leaves the biggest items; renaming APIs, files, and tests.
Closes: #1276
Approved by: jlebon
What's happened up till now is supporting `rojig://` in the same way as
`ostree://`. However, part of the high level goal here is to reduce
the need for system administrators to understand ostree.
This patch set starts to introduce some of the ideas for client-side
changes as part of jigdo ♲📦:
https://github.com/projectatomic/rpm-ostree/issues/1081#issuecomment-348540604
Concretely, we start using `${repo}:${nevra}` instead of `rojig://`.
(v2): Keep `Version` (plus timestamp) as a split out field for maximum visual aid.
Also, let's be opinionated here and entirely drop the `Commit` checksum by
default. I believe the Cockpit guys were right here - versions are for humans.
The fact that we have a checksum is powerful; and we still show it with `status
-v`. The way I think of it is: the checksum shows we're really an image system.
But we don't need to show it by default.
Closes: #1240
Approved by: jlebon
Pick up security advisories when checking for pending updates and
include them in the `cached-update` property. On the client-side,
display them in the output of `status`.
This was part of the original vision for how useful a smart `check` mode
could be. It directly impacts how one manages their individual system
(e.g. when to reboot), and paves the way for integration into
higher-level apps that act at the cluster level.
Closes: #1249
Approved by: cgwalters
Fix logic to make sure we check if the refspec is of type `ostree://`
even when it's explicitly specified. Also fix `Deploy` in the case where
we didn't just `Download` the RPM diff by adding a new @checksum
parameter to the higher-level API.
Finally, add a basic test for the `GetCached*RpmDiff` APIs so we have at
least *some* coverage. This is also good prep for making sure we don't
break anything when we convert those APIs to use the more efficient
pkglist metadata. The tests completely ignore the `DownloadRpmDiff`
paths for now though.
Closes: #1250Closes: #1253
Approved by: cgwalters
This is an initial drop of support for:
`rpm-ostree rebase rojig://fahc:fedora-atomic-host`. We also
then support `rpm-ostree upgrade` from that.
There's a lot that could be improved here; the test coverage is relatively
minimal. A blocking issue there is having a realistic jigdo setup, and that's
going to require changing how we do testing. For now, this means that if we want
to e.g. change the format we'll have to temporarily disable this test, get the
format change in, update FAHC, then re-enable the test.
Closes: #1166
Approved by: jlebon
There are types that we want to share between the daemon and the client
for deduplication. Those are, as expected, related to D-Bus things like
formats and enums. Let's create a new file for it rather than shove it
in `rpmostree-util.h`. As mentioned in the file, some of these probably
belong better directly in the public API.
Closes: #1147
Approved by: cgwalters
This patch introduces a new `AutomaticUpdatePolicy` configuration. This
was a long time coming for rpm-ostree, given that its update model makes
it extremely apt for such a feature.
The config supports a `check` mode, which should be very useful to
Atomic Workstation users, as well as a `reboot` mode, which could be
used in its present form in simple single node Atomic Host situations.
There is still a lot of work to be done, including integrating
advisories, and supporting a `deploy` mode. This feature hopefully will
be leveraged as well by higher-level projects like GNOME Software and
Cockpit.
Closes: #1147
Approved by: cgwalters
It makes it harder to keep track of ownership except in the trivial
`_new ()` case for which they were designed (i.e. shoving straight into
another glib GVariant function that takes ownership of it right away).
Closes: #1160
Approved by: cgwalters
Prep for more work.
We actually pass a `GError` to the gpg results function and fail for any
other failures than gpg signature verification. (In that case, we want
to make sure that information gets to the D-Bus API level, so killing
the daemon would be the wrong choice).
I also factored out all the logic in
`rpmostreed_commit_generate_cached_details_variant` into a separate
function. This is prep for reusing it elsewhere.
Closes: #1160
Approved by: cgwalters
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
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
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
When commit metadata contains ostree.endoflife attribute,
its information will be added to the deployment Variant,
which will later be shown as a red & bold message when
'rpm-ostree status' command is called.
A test is added for future regression
Closes: #889
Approved by: cgwalters
Add experimental support for replacing packages from the base layer with
local RPMs. This is useful for example, to cherry pick a fixed package,
or to roll back to a previous package version. Like with pkg removals,
only files in /usr are actually replaced.
This patch also contains a few usability improvements as well, e.g.
showing the full NEVRA of removed packages rather than just their names,
and support for resetting overrides using either the pkgname or NEVRA.
Closes: #852
Approved by: cgwalters
The property of removal overrides dropping out if the package was
removed from the base layer felt a bit too magical and hacky. We really
should remember that wish and re-apply it if the pkg comes back. This is
similar to package layering: requests can become inactive (seems like a
better word than "dormant") if the package is already part of the base
layer, but they don't really go away.
This patch reworks the logic so that removal overrides work the same
way. In the status output, we now have both "RemovedBasePackages" and
"InactiveBaseRemovals" (which is only printed in verbose mode),
similarly to how we have "LayeredPackages" and "InactiveRequests". And
similarly, we also print out in the upgrader during a transaction all
the inactive base removals.
Another cool thing is that we now allow any pattern to be specified at
the CLI. E.g. `ex override remove /usr/bin/strace` will resolve to
strace.
Closes: #836
Approved by: cgwalters
This is one more step towards making rpm-ostree more powerful in its
quest to be the ultimate *hybrid* image/package system. Package layering
allows us to add packages on top of the base package set received from
the content provider. However, we're not able to remove or replace
packages in the base set itself.
This patch introduces a new `override` command, which is for now nested
under the experimental `ex` command. The `override` command will allow
users to modify the base package set itself. The first implemented
subcommands are `remove` and `reset`.
A stub has been provided for the more useful `replace` subcommand,
though much of the needed logic for that operation are implemented in
this patch as part of the `remove` subcommand.
Part of: https://github.com/projectatomic/rpm-ostree/issues/485Closes: #797
Approved by: cgwalters
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639Closes: #652
Approved by: jlebon
Before this commit, in the case where we have 3 deployments, the rollback code
would pick the merge/pending deployment. This is understandable since that logic
predates us potentially creating 3 deployments.
For livefs, I want rollback to actually go to the rollback, not the pending.
Add an API to find the pending/rollback, and put it in syscore, since we have
other similar functions to this there. (Perhaps in the future we'll figure out a
way to dedup the deployment walking/filtering logic a bit).
Port the two callers to it.
Closes: #767
Approved by: jlebon
Prep for livefs; there we're storing live update state as xattrs on the
deployment root, and hence we need access to the sysroot to query it.
Closes: #706
Approved by: jlebon
Currently we propagate the version field from the base to derived,
but the status UI shows the timestamp from the derived commit.
I found this *extremely* confusing when I was trying to reason about the
up-to-dateness of my system. The version and timestamp should be locked
together so we display them consistently.
When we generated the local commit isn't really useful information; conceptually
we have the base timestamp, plus timestamps for the rpm-md repos. We should
display the latter instead.
(This also adds `base-timestamp` and `base-verison` to the JSON; only
the former is new information, but the latter helps us be consistent)
Closes: #697
Approved by: jlebon
Allow users to directly specify an RPM file on the command-line. The
"packages_added" array of the PkgChange() method can now contain
absolute paths to RPM files.
Grow the origin format to have a new "requested-local" key. This is
similar to the "requested" key, except that the packages are always
installed from cache. The "requested-local" array values also embed the
SHA-256 of the header we expect.
There is now a new "LocalPackages" line in the status. These packages
are a subset of the "packages" element (which are printed as
"LayeredPackages") and represent the packages that are explicitly marked
for installing from cache.
Interesting design choices/notes:
- Just as before, even with foo-1.0-1.x86_64 installed from RPM, a
user can still request "/usr/bin/foo": it will be made dormant. As
soon as foo stops being explicitly layered from the RPM, it will try
to fulfill the request by going to the repos. This allows users to
"pin" a layered package to a certain RPM, and then unpin it.
- The strings/NEVRAs in "requested" and "requested-local" are strictly
distinct. This allows us to be able to tell what the user means
exactly when they do "rpm-ostree uninstall".
Closes: #657
Approved by: cgwalters
Pull #646 introduced a subtle regression: we went from always including
a "packages" entry to only including it if there are packages present.
Albeit it's easy to guard against, though to be nice, let's make it
easier for consumers by always including it.
Reported-by: Micah Abbott <miabbott@redhat.com>
Closes: #670
Approved by: cgwalters
This is the culmination of the work paved by the previous commits. We no
longer handle package set mutations in the upgrader, but rather let
clients modify the origin as needed for that. As such, the upgrader is
now completely memoryless. We no longer try to error out if a package is
already in the base and we no longer drop out packages previously
layered packages that are now in the base. *Which* packages actually get
layered is determined during deployment and not coded in the origin.
At an API level, the deployment variant returned (and thus what gets
printed by `status --json`) now has both "packages" and
"requested-packages". The former retains its original semantic: it's the
set of packages that are *actually* layered. The latter contains
everything from the origin, which includes the former set + dormant
packages.
Accordingly, the output of `rpm-ostree status` also now distinguishes
between "RequestedPackages" and "LayeredPackages". Extra: we now quote
provides that contain spaces.
Closes: #646
Approved by: cgwalters
Ideally, we want to parse out everything in the origin on init and then
cache the values to make it even easier to inspect it. We make this more
explicit by renaming the struct members to "cache_*" and also caching
the initramfs args. This doesn't actually save any allocations right
now (though it might in the future), but we do the same for everything
else, and it's nice to be consistent.
Closes: #646
Approved by: cgwalters
There are multiple reasons for this. The first is that with the
introduction of "dormant" packages, it becomes impossible from simply
looking at a deployment's origin whether it was layered or not. We
*could* make the upgrader turn around and insert back the "real" final
packages that were layered. But we're really trying to reinforce the
concept that the origin is mutable and represents an input for the
upgrader. Derived data shouldn't live there.
Whether a deployment is actually layered or not instead is determined by
the deployment commit itself. The embedded treespec records the exact
packages that were layered, which we will later use to enhance status
output.
Closes: #646
Approved by: cgwalters
This is a follow-up to 775c781 (#626). Really, RpmOstreeOrigin shouldn't
concern itself with whether the origin is unconfigured. Its main goal
should be to parse it out and make it easy for users to modify it. That
sort of business logic lives in the upgrader, which *should* be
concerned if the origin in unconfigured.
Closes: #634
Approved by: cgwalters
As part of an earlier cleanup of origin parsing, we started checking
the origin `unconfigured-state` even just starting the daemon, which
is kind of bad.
It's tempting to flip the default for the parser so that we *only* check
unconfigured state if we go to upgrade, but let's not do that in this patch.
Closes: #626
Approved by: jlebon
One thing that's very confusing about OSTree is there are two layers -
deployments and the refs/commits. If one does an `rpm-ostree upgrade`, but then
e.g. `ostree admin undeploy 0`, you still have the new revision in the repo.
We don't do a good job of displaying this state, or helping people clean
it up.
Down the line, I also want to better support something like `rpm-ostree pull` to
cache updates explicitly *without* deploying.
This commit just adds a bit of information to the status display. We might want
to have better formatting, but I think this an OK start.
Closes: #595
Approved by: jlebon
Currently we push for a model where the initramfs is
generated (in non-hostonly mode), and merely replicated.
However, to support a few unfortunate corner cases like dm-multipath which wants
to inject a config file into the initramfs, we need to support regenerating it
client side too.
Down the line, we'll need this to support overriding the kernel too.
This changes things in the core to add the concept of an "empty"
`RpmOstreeContext`. I initially tried skipping it, but that was too much
duplication. We still want all of the core ostree-related logic that lives in
that code too.
The treespec bits barfed if the spec didn't have a `tree/packages` key. It was
simplest to change that to allow it - and because that was the only case where
we errored out in parsing, I dropped the error handling.
There was another place in the upgrader that now needed to be fixed to handle
transitioning from just regenerating initramfs to not.
Closes: #574
Approved by: jlebon
In prep for adding "regenerates initramfs" to "is locally assembled",
we need more abstraction. I previously introduced a helper function, but
I'd still need to touch every call site when changing that.
Rather than having each caller re-parse the origin, let's parse it once into a
structure, and then have error-free accessors for it (that also don't malloc).
This way when adding a new flag, I don't need to touch every call site.
Notes:
- Some places in the code (like the deployments -> variant bits) tried to
handle deployments without an origin gracefully. That's no
longer true. I'm not sure how much we care - do we?
- There are a few places where I changed `packagelist.len() > 0` to
`is_locally_assembled()`. I think this is right, but we'll need
to be sure the "no packages to overlay, just initramfs" case
works when that lands.
Closes: #566
Approved by: jlebon
