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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
I kept thinking `^a&s` was sufficient for allocation-free reading
of `as`, but it's not, we need to free the outer buffer. Other
minor cases were using `s` instead of `&s`.
Closes: #533
Approved by: jlebon
It's really in-your-face for admins to see `(unsigned)` which originally
was intentional, but in practice right now at least several major
users (Fedora, RHEL) don't enable GPG signatures.
So let's just hide it if not enabled.
Perhaps in the future we should add a `-v` option or something which
would show all of the fields even if not enabled.
Closes: #399Closes: #402
Approved by: jlebon
Previously in #353 we changed this to not resolve the rev, but
that breaks the `CachedUpdateDetails` which actually wants it
to be resolved, to show pending updates.
This effectively reverts 749a5f03a8586392cafff949075c45a040d4e984
and changes things so we set `allow_noent=TRUE` and if there is
no ref, just return the deployment checksum.
Fixes: 749a5f03a8586392cafff949075c45a040d4e984
Closes: #392Closes: #398
Approved by: jlebon
In looking at this code, I noticed we were incorrectly mixing
`Option(GVariant)` with GError handling. If the deployment
had no refspec we'd return `NULL` but not set `error`.
Fix this by requiring a respec, and change the single caller that
relied on this to check outside.
Closes: #398
Approved by: jlebon
The origin might have an empty "requested" key in the "packages"
section, which is probably an indication that packages were once added
but were then removed.
Explicitly check the length of the pkg array in case it's actually
empty before adding the base-checksum to the deployment variant.
Closes: #371
Approved by: cgwalters
During the initialization of the daemon, it would try to load the
deployments and cache a few things. One of these steps wanted to look up
the rev of the deployment. However, if the rev no longer exists (e.g. we
just did a rebase, purged the ref, and rebooted), this would error out.
Replace the lookup by simply directly using the csum from the
deployment.
Closes: #353
Approved by: cgwalters
Now that the `status` command learned a `--json` option, we can pretty
much avoid parsing human-readable output. The only piece of information
that is missing from the JSON output compared to the output for humans
is *which* deployment we're currently booted in.
This patch fixes that shortcoming by adding a "booted" boolean variant
to the deployment variant.
Closes: #350
Approved by: cgwalters
We don't currently expect people to sign commits locally.
However, long term, I would like to support a verified boot model
where we still support layered packages. A system administrator could
log in and perform changes, and possibly use a remote hardware token
to sign the commit. Anyways that's for the future.
Closes: #346
Approved by: jlebon
I think most users are really going to be interested in the base/origin
commit, and not whatever the stuff they made locally happened to hash
to.
Closes: #295
Approved by: jlebon
I really don't like doing a `g_warning()` in the middle of a call
stack and stumbling onwards. If we fail to load a commit, we should
pass the error back up to toplevel boundary - normally a DBus method
invocation. As opposed to giving partial or incorrect data.
This is a preparatory (git) commit for adding more data from the
(ostree) commit to the deployment variant.
Closes: #295
Approved by: jlebon
This builds upon the earlier prototype in
https://github.com/cgwalters/atomic-pkglayer
The `.origin` file says for a replicated installation:
[origin]
refspec=local:rhel-atomic-host/7/x86_64/standard
If you then run `rpm-ostree pkg-add strace`, it will result in a new tree with:
[origin]
baserefspec=local:rhel-atomic-host/7/x86_64/standard
[packages]
requested=strace;
Work still remaining here is to teach `rpm-ostree status` and
`rpm-ostree upgrade` about this.
Closes: #289
Approved by: cgwalters
We can't rely on the the GLib hash functions not changing (or being
stable across host systems). Basically here we have a "stringified"
deployment...it might be simpler to just declare this stable.
rpmostreed_commit_generate_cached_details_variant() returns NULL if the
origin checksum of an OstreeDeployment matches the checksum of a refspec,
which may also be the OstreeDeployment's origin.
I don't understand the reasoning for that, especially since none of the
callers are prepared to deal with a NULL return. Nor is there a comment,
so remove the check.
This was making the daemon crash on
rpm-ostree deploy --preview <current-deployment-checksum>
which should just indicate no package differences.
Adds a CachedUpdate property that allows clients
to see version, timestamp and other detailed
information for pending updates. Additionally
changes to this property signal clients that a
new rpm-diff can be fetched with GetCachedUpdateRpmDiff.
This will be used by the Cockpit interface.
