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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
I spent quite some time trying to figure out why the last run timestamp
of the autoupdate service wasn't showing up in `status`. It turned out
to be that systemd only keeps that information around if an associated
timer unit is active.
Thinking more, I think it makes sense to split out the case where the
timer isn't even running explicitly, rather than just reporting "no runs
since boot".
Closes: #1242
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
Prep for auto-updates. Let's not print the "Pending*" keys anymore. With
automatic updates, we'll have a whole other section of the output just
for that.
Closes: #1212
Approved by: cgwalters
Prep for auto-updates. Use different functions for printing the daemon
state and printing the deployments themselves.
Closes: #1212
Approved by: cgwalters
In preparation for rojig (rpm-ostree jigdo) client work. Changing
all of the code where we currently use refspecs (i.e. pure ostree)
to also learn about jigdo would be really painful - basically adding
new DBus APIs and all of the places we pass through data.
A simpler path then is to overload the meaning of refspecs to have an (optional)
URI scheme. If we don't recognize the scheme, assume it's ostree for now.
Change the status command to parse and then render as a way of "canonicalizing"
so that we have the same behavior as before of rendering with `ostree://`.
Closes: #1208
Approved by: jlebon
With automatic updates, I'd like to make the outputs of `upgrade
--check/--preview` very similar to parts of `status`. E.g. timestamp,
version, GPG signature printing. So let's factor those out into
`libbuiltin`.
Note that unlike the others, `rpmostree_print_gpg_info` deals directly
with a `GVariant` received from D-Bus, so it felt more appropriate to
place it in `dbus-helpers`. Plus, `rpmostree_print_signatures` was
already there, so it simplified things a bit.
This also sneaks in a nicer way of printing padded strings using the
argument field width syntax.
Closes: #1196
Approved by: cgwalters
Make use of the new `glnx_stdout_is_console ()` rather than caching our
own result of `isatty()`. Add helper functions in `libbuiltin.h` to
retrieve escape characters. Prep for using them from other files.
Update submodule: libglnx
Closes: #1196
Approved by: cgwalters
This is prep for automatic updates. There, we want to know which D-Bus
we're connected to and e.g. only try to reach out to other services like
systemd if we're on the system bus.
Closes: #1191
Approved by: cgwalters
We've had many bugs from internal helpers using `return EXIT_FAILURE` rather
than `return FALSE`. The reason we need exit codes is to handle the
`RPM_OSTREE_EXIT_UNCHANGED` case. I realized recently that we had the handy
`RpmOstreeCommandInvocation` which we can use to signal back this special case.
Then all of our functions otherwise are just normal `GError`.
One minor wart here is the two cases of "usage error" versus "command
invocation" in `main.c`, but IMO the general cleanup is well worth that.
Closes: #1169
Approved by: jlebon
Rather than letting the terminal wrap our line and go unindented on the
next line, let's do the wrapping ourselves to tidy up the output.
Closes: #1159
Approved by: cgwalters
Depends: https://github.com/ostreedev/ostree/pull/1296
As I mention in the commit there, I see two uses for this in rpm-ostree; first
in our test suite, and second for OCI-built image imports.
I also took a step further here and inject an `original-origin` metadata
key, though we aren't actually using that yet. The problem I'm trying
to solve there is that repeated `make vmoverlay` starts chaining things up,
but that gets very confusing. I think we should always have `vmoverlay` unwind
back to the base ref. (Or at least do that by default)
Closes: #1069
Approved by: jlebon
Minor detail. We still need to support the `--pretty` flag, but it
doesn't do anything anymore, so let's just hide it to clean up the help
output.
Closes: #1060
Approved by: cgwalters
There are (somewhat hard to avoid) race conditions for the client
to find the active transaction and connect to it. This approach
adds a retry loop, and teaches the status builtin to use it.
The status code becomes a lot less ugly. Prep for:
[rpm-ostree cancel](https://github.com/projectatomic/rpm-ostree/pull/1019)
Closes: #1033
Approved by: peterbaouoft
I suspect a common pattern with local replacement overrides is to
simultaneously replace a group of packages that depend on each other in
one shot, as is the case with docker, docker-common, and
docker-rhel-push-plugin currently in Fedora Atomic Host. In such cases,
we can print a cleaner diff in the status to make it easier to grok.
Before:
ReplacedBasePackages: strace 4.18-1.fc26 -> 4.19-1.fc26, docker-common 2:1.13.1-22.gitb5e3294.fc26 -> 2:1.13.1-21.git27e468e.fc26, docker 2:1.13.1-22.gitb5e3294.fc26 -> 2:1.13.1-21.git27e468e.fc26, docker-rhel-push-plugin 2:1.13.1-22.gitb5e3294.fc26 -> 2:1.13.1-21.git27e468e.fc26
After:
ReplacedBasePackages: docker-common docker docker-rhel-push-plugin 2:1.13.1-22.gitb5e3294.fc26 -> 2:1.13.1-21.git27e468e.fc26, strace 4.18-1.fc26 -> 4.19-1.fc26
Closes: #1004
Approved by: cgwalters
Before, when using rpm-ostree -h command, the command
description was shown together with the command itself
Now, we separate the command description out, providing
user a better view of the description.
Closes: #916
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
In the JSON output, the "requested-packages" holds *all* the requests
for package layering, whereas the "packages" key holds only those
requests which actually caused a package to be layered.
When outputting RequestedPackages, we try to be nice and print only the
"dormant" packages, i.e. those requests which did not require any
packages to be layered since the base layer already fulfilled them. This
is the subset of "requested-packages" not also in "packages". But then,
we could call this subset something much more appropriate than
"RequestedPackages" when outputting.
This patch renames it to "InactiveRequests" to reflect the "dormant"
aspect of them. We also make it only be output in verbose mode, since
it's not as interesting as what was *actually* layered when trying to
understand what the host is currently running. But we do adapt the
upgrader so that it prints out inactive requests during transactions.
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's a lot that could be done to improve this; we're not setting a title for
`rollback` etc. But I think in practice right now the "deploy" path (which
includes upgrade/install) etc. is most important.
Re-synthesizing a human readable string here is definitely a bit fragile and
going to be a maintenance pain. One thing I debated is having the client send
its commandline as a string. But that would only work for `/usr/bin/rpm-ostree`,
not e.g. Cockpit.
Anyways for now, this is useful and we can always improve it later.
Closes: https://github.com/projectatomic/rpm-ostree/issues/454Closes: #814
Approved by: jlebon
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
`Commit` is useful in cases where one wants to e.g. run `rpm-ostree db diff`.
`StateRoot` however is going to be in the vast majority of cases identical
across deployments.
Closes: #743
Approved by: jlebon
See: https://github.com/ostreedev/ostree/pull/794
I originally tried to do this ~a year ago in:
https://github.com/projectatomic/rpm-ostree/pull/295
But Micah pushed back at the time. I'd still like to do this
though, since I personally find `OSName` *more* confusing
than `StateRoot`.
One specific rationale I have for making this change is that
I rebased a home server from CentOSAH to FAH - and I feel
it's just saner to see `StateRoot: centos-atomic-host` instead
of `OSName: centos-atomic-host` underneath the fedora refspec.
Closes: #743
Approved by: jlebon
Add support for --install/--uninstall to upgrade/deploy/rebase by
calling out to UpdateDeployment(). Since it's not released yet, back out
the support for install-local-packages in the options variant for
PkgChange(), and make it instead use UpdateDeployment() as needed.
Closes: #711
Approved by: cgwalters
One interesting note here was that I couldn't use glnx_throw in as many
places as I wanted because EXIT_SUCCESS/EXIT_FAILURE are the exact
opposite of that semantic. It was still convenient to use though as a
short-form for g_set_error().
Closes: #704
Approved by: cgwalters
Following up on the previous commit regarding timestamps - the checksum of the
derived commit isn't very useful. It's not going to be the same between any two
people's systems. What we should show instead is the rpm-md repository
timestamps.
In the short term though, I think omitting this even without the rpm-md
timestamps is better. Less visual clutter.
Closes: #697
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
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
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
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
The API for json_generator_to_stream() says:
Return value: %TRUE if the write operation was successful, and
%FALSE on failure. In case of error, the #GError will be filled
accordingly
When in fact, because it just gives back what g_output_stream_write(),
1. it doesn't strictly return TRUE/FALSE, but a full-range uint, and
2. it will return -1 (which is as good as anything > 0 for success
checks) when an error occurs.
Although a simple <= 0 would fix it, let's just be extra strict and also
check for an error.
Closes: #468Closes: #469
Approved by: miabbott
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
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
I really want a command to cancel the running transaction, but as a
preparatory step, let's display what's going on in `status`.
The text output here is really a demonstration - I'll improve it but I
want to rework the internals first.
Closes: #320
Approved by: jlebon
In the future I want to add more content in the status such
as active operations, so let's make the "deployments" just
one entry in an object.
Closes: #320
Approved by: jlebon
It's really simple to reflect the DBus API into JSON, which tools like
Ansible or `jq` from the command line or whatever can parse to find
interesting things like the current version.
Closes: #301Closes: #315
Approved by: jlebon
