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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As Colin mentioned in #1035, the new `--cache-only` implemented only the
rpmmd half of the story. Here we complete that story by also ensuring
that when in cache-only mode, we don't download new ostree data nor new
packages. We try to complete the requested operation with what we have.
To do this, we add support for the same `SYNTHETIC` pull that was added
in ostree[1] so that we don't actually pull, but still perform timestamp
checking.
On the pkgcache side, we disable all remote repos and instead insert all
our cached RPMs into the `DnfSack`. Care is taken to still perform
SHA256 verification for local pkg installs/replacements.
[1] https://github.com/ostreedev/ostree/pull/642Closes: #687Closes: #1049
Approved by: cgwalters
The new idle exit behaviour is nice, but it makes debugging it harder
because you have to be fast enough to attach or place your breakpoints
and trigger it before it auto-exits. Add a compile-time flag that
developers can easily turn on to disable the auto-exit behaviour.
Closes: #1052
Approved by: cgwalters
In prep for potentially changing it:
http://lists.rpm.org/pipermail/rpm-maint/2017-October/006681.html
Of course actually doing a transition would be harder than this, as we'd need to
add a compat symlink, and even that wouldn't quite be enough as e.g. the
"preview" code would need to learn how to follow the symlink (or just try both
locations).
In practice I think we'd need to land the code to handle both locations, let
that trickle out for e.g. 3 months, then make the switch in our treecomposes.
But, might as well make this change now; using a `#define` makes it slightly
easier to find places that need changing later.
Closes: #1048
Approved by: jlebon
This is the equivalent version of `yum/dnf -C`. It goes together with
the new `makecache` command to allow completely asynchronous cache
update and usage.
Closes: #1035
Approved by: cgwalters
This is essentially the `dnf/yum makecache` equivalent for rpm-ostree.
To complete the picture, this goes hand in hand with the `-C`
equivalent, which is added in the next patch.
Closes: #1035
Approved by: cgwalters
Add a function in the core that knows how to take a deployment and point
its passwd dir and libdnf's repos dir to it. We call it the
"configuration deployment", because those are configuration files which
should be inherited from the config merge, not the origin merge.
Prep for `makecache`.
Closes: #1038
Approved by: cgwalters
Now that we have the ability to both track clients and our active transaction,
and the `RegisterClient` call acts "atomically", let's start doing exit-on-idle
and return the RAM to the people.
Closes: #606
Approved by: jlebon
Was just reading the initramfs bits while talking to rubao about kargs work, and
noticed we had a lot of "old style" declarations.
Closes: #1020
Approved by: jlebon
Amazingly we had 3 variations of this bug in the different
layers above using the `RpmOstreeContext` API (in compose, container,
and layering).
We fixed the first two already, this fixes the last one. We
get a warning if librpm holds a ref to a deleted rpmdb.
Closes: https://github.com/projectatomic/rpm-ostree/issues/987Closes: #994
Approved by: jlebon
Also something I noticed while working on #981. When sitting on a livefs
commit, once a user does `rpm-ostree cleanup --pending --rollback`, it's
impossible to redeploy the same booted commit. Let's allow users to do
this.
Closes: #984
Approved by: cgwalters
Currently, when setting the `override-commit` key in the origin, the
upgrader pulls that commit checksum directly and then updates the
refspec to point to it. This behaviour was inherited from its ostree
version; at the time it was implemented, the pull code didn't support
passing a specific commit for a given refspec. However, we now have
the override-commit-ids option, which will make libostree update the ref
for us.
We change the code here to make use of it and simplify the function.
This also fixes the corner case of local branches: we shouldn't change
the ref if we're on a local branch. This is actually what drove me to
this patch as I was debugging #981.
(Aside: I'm still not convinced updating the refspec is always the
correct thing to do even in the remote case, though it's a bit messy to
disentangle).
Closes: #984
Approved by: cgwalters
Prep for changing `boot_location: new` to use `/usr/lib/ostree-boot`
and `/usr/lib/modules`. Rework our kernel postprocessing
so that we unify the `boot_location` handling with initramfs generation.
Instead of doing the initramfs first in postprocessing, we do it nearly last,
after e.g. `etc` is renamed to `usr/etc`. This has some consequences, such as
the fact that `run_bwrap_mutably()` is now called in both situations. In
general, our handling of `etc` is inconsistent, although understandably so.
As part of this, I finally got around to implementing the bit from
https://github.com/systemd/systemd/pull/4174 however suboptimal it is; need the
unified core so we can cleanly ignore the posttrans like we do others. We
intentionally keep the file around in the generated tree so that installing a
kernel RPM per client doesn't try to do any of this either.
This all gets folded together so that the logic for handling the bootloader gets
simpler - in the Fedora case, we now know to find kernels in `/usr/lib/modules`
and can ignore `/boot`.
Closes: #959
Approved by: jlebon
This fixes `rpm-ostree reload` as root, and supports configuring
it to be enabled for other users as well. This was overlooked
in the polkit work originally.
Closes: https://github.com/projectatomic/rpm-ostree/issues/976Closes: #977
Approved by: jlebon
The core use case always enabled this; we exposed it on the command line, but
honestly I think it's a lot simpler if our imports always enable this. If we
need to *undo* it (for example, generating a "traditional feeling" OCI/Docker
image a la <https://github.com/projectatomic/rpm-ostree/pull/367>), we can
easily do that as postprocessing afterwards.
Closes: #951
Approved by: jlebon
It was partially removed in 325ee354e9
from PR #873 - this removes all of the rest of the layers in
the daemon and core for this.
Note that while working on this I found it astoundingly confusing that
`rpmts_add_install()` and `add_install()` had separate orderings for `gboolean
noscripts, is_install`. That's fixed by having the latter lose the `noscripts`
flag entirely, but while we're here change `rpmts_add_install()` to use flags
for clarity.
Closes: #938
Approved by: jlebon
Lots of cleanups, and this also allows us to fully port to new style in several
places.
We can drop our own `rpmostree_mkdtemp()`.
Update submodule: libglnx
Closes: #928
Approved by: jlebon
Since we have a copy of this libostree code, pick up the new
changes from <https://github.com/ostreedev/ostree/pull/1055>.
Note the added test doesn't really test our logic since
we're only doing local pulls, but at least we have something.
Closes: #932
Approved by: jlebon
Make use of the new journal-msg signal that OstreeSysroot emits. Since
we now also only rely on the output API to print messages, this allows
us to drop the outrageous hacks we had to do to watch our own stdout,
part of which Coverity didn't like.
Coverity CID: 163694
Closes: #919
Approved by: cgwalters
There were places where we were relying on the stdout self read hack to
relay messages to clients. Fix those by explicitly using the output API
in all spots where the daemon may pass. Really, we should exclusively be
using the output API in the daemon and libpriv trees, though many other
instances exist for now.
Closes: #919
Approved by: cgwalters
This closes a longstanding bug - since package layering first
landed, we only checked for newer RPMs if the base tree changed.
In some scenarios like RHELAH, this doesn't matter much by default
since they move at the same cadence. Except if you use EPEL for example.
In Fedora, today the FAH releases are async of the rpm-md repos, and
there's also COPR which can update more than once a day even.
We should check for both update sources. Luckily we'd already introduced logic
for this in the treecompose case (checksumming the depsolved package sack). We
just need to start using it for client side assembly too.
Closes: https://github.com/projectatomic/rpm-ostree/issues/391Closes: #911
Approved by: jlebon
This is no longer necessary since we switched to tracking livefs state in the
origin, and we don't support changing content outside of `/usr` right now
via livefs.
Just noticed this while looking at the livefs code.
Closes: #912
Approved by: jlebon
The new API to find pending and rollback deployments do so relative to
the booted deployment. This caused an interesting behaviour: the first
time a user uses "rpm-ostree rollback", it would (as expected) move the
previous deployment first. but the second call to "rpm-ostree rollback"
would fail since there were now no more rollback deployments.
We fine tune the logic here to allow this, as well as the more general
case of putting the booted deployment back on top.
This fixes a subtle regression from b7cf58e
(https://github.com/projectatomic/rpm-ostree/pull/767).
Closes: https://github.com/projectatomic/rpm-ostree/issues/906Closes: #907
Approved by: cgwalters
Now that the query_deployment() function was upstreamed in ostree (see
https://github.com/ostreedev/ostree/pull/897), let's just use it from
there and drop our copy here.
Closes: #907
Approved by: cgwalters
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
This is a followup to https://github.com/projectatomic/rpm-ostree/pull/888
but more comprehensive; in the layering case, the sanitycheck runs
after all the `%posttrans` scripts, so we'll get a consistent error message
for the `rm -rf /` test.
We also do the sanitycheck for the "pure ostree" case, as well as cases
where we didn't actually layer packages (including `ex override remove` as
well as simply regenerating an initrd).
There's obviously a lot more we could do in a sanitycheck; as I say in the
comment it's tempting to consider trying to boot systemd (in a fully volatile
config), but for now let's do this. In the end of course the admin has rollback
too.
Closes: #892
Approved by: jlebon
Drop the root check for RegisterClient() so that any UID can use it to
then safely invoke methods. UIDs which already have an active session do
not need to authenticate for RegisterClient().
In order to implement this, we move the polkit authority setup into the
RpmostreedSysroot object and enable polkit on the interface.
Closes: #894
Approved by: cgwalters
Closes: https://github.com/projectatomic/rpm-ostree/issues/546
Previously, we'd open up the host's rpmdb for both `compose tree`
and `ex container`. In the first case, because we require root, we'd
succeed. For `ex container`, we'd spew an error.
Fixing this was trickier than I thought. First because there was
*also* a libdnf bug here: https://github.com/rpm-software-management/libdnf/pull/307
Second, there's a compatibility hazard here for anyone using `.repo` files that
reference `$releasever`. This actually happened to me with `ex container` as I'd
just done a `ln -s /etc/yum.repos.d/fedora.repo rpmmd.repos.d`. I fixed
that first by doing a `sed -i -e 's,$releasever,26,' rpmmd.repos.d/*.repo`.
As far as I can see today, none of Fedora Atomic or CentOS AH rely on this. But
in order to enhance compatibility, let's add a "releasever" option. This makes
it easier again to reuse stock `.repo` files if we wanted to do so.
(Also, I realized we can just use `/usr/share/empty` as *the* canonical immutable
empty directory)
Closes: #875
Approved by: jlebon
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
This function was already mostly in the new style. Just moving the
declarations closer to where they are used. No functional changes. The
logic will be tweaked in an upcoming commit.
Closes: #859
Approved by: cgwalters
I initially planned to use the metadata tmp dir for another reason than
just in finalize_overlays(), but I will not anymore. Regardless, this
seems like a nice patch which also allows us to complete the style
conversion in this file.
Closes: #847
Approved by: cgwalters
This is an extension to the previous change to distingush between
"caller" and "client". Now for clients we log the uid (both
in the message and structured).
This is a natural followon from the polkit work, since now different
uids can invoke us.
Closes: #838
Approved by: jlebon
A "caller" is a bus address that hasn't called `RegisterClient`.
Prep for things like unifying the bus name tracking between the transaction and
the daemon; right now it's a bit silly that the txn code also monitors the
caller's bus name. So down the line we could change that code to call into the
daemon and use its tracking for registered clients.
Closes: #837
Approved by: jlebon
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
Example of what the new macros look like when applied on a whole
codebase. It definitely feels much nicer to work with!
Update submodule: libglnx
Requires: https://github.com/GNOME/libglnx/pull/55Closes: #834
Approved by: cgwalters
This allows non-root users access to the rpm-ostree daemon, which is
a pre-requirement for gnome-software rpm-ostree support.
Closes: #745Closes: #825
Approved by: cgwalters
This is just a cosmetic patch that ensures we use the same names for the
same things everywhere to make it easier to follow along.
Closes: #829
Approved by: cgwalters
Only add information to it re. installing/uninstall/local installs after
we check that the corresponding arrays are not `NULL`.
Closes: #826Closes: #827
Approved by: cgwalters
This is part of the saga of permissions and checkouts that
came about thinking about flatpak, but suid and world-writable dirs
are also an issue for us.
There's no reason to make suid binaries accessible temporarily
to users while we're computing a new root. Similarly, we don't
want anyone to actually *write* to our temporary `/tmp`. The
simple fix is to make an intermediate dir that's `0700`.
See: https://github.com/ostreedev/ostree/pull/909
See: https://github.com/flatpak/flatpak/pull/843Closes: #821
Approved by: jlebon
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
1. There's no point in passing a GCancellable in those cases. All the
manipulations should be short-lived.
2. Rename delete_packages to remove_packages, since "remove" is the
proper antonym of "add".
Closes: #819
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's a subtle but classic issue in this code: calling `continue`
really just continued the inner loop, whereas we meant continuing the
outer loop.
Fix this by making the prefix lookup check a proper predicate function.
Place that function somewhere public, because we'll make use of it in
base overrides as well.
Closes: #807
Approved by: cgwalters
At this point, there are many helper functions that really should just
be made upgrader-aware to make it easier to follow. For example, now
both find_missing_pkgs_in_rpmdb() and generate_treespec() are passed the
Upgrader object directly, allowing us to avoid having to thread through
multiple arguments everywhere. Another example is that the Upgrader now
carries the list of final packages that need to be overlaid rather than
passing it around.
We also rename the functions to better reflect what they actually do.
Closes: #804
Approved by: cgwalters
Since we now use a predictable directory for the rootfs checkout and
assembly operation, there's no need for a tmprootfs variable anymore.
Closes: #804
Approved by: cgwalters
It's less cumbersome to check for this in the origin. Factor it out
there so that it's easier to modify it in the future.
Closes: #804
Approved by: cgwalters
In all cases, we always do download_metadata() followed by prepare().
Let's just make life easier for callers by inlining this in prepare(),
much like what libdnf does. The function is still public in case some
use case calls for making them separate.
Closes: #805
Approved by: cgwalters
There's not much use in having RpmOstreeInstall be separate now that
it's completely private. Let's just make it part of the main context
object rather than making callers allocate space for it and pass it to
the various context methods.
We also rename `prepare_install` to `prepare` since it will (soon) do
more than just installs (and sometimes only pure uninstalls).
Closes: #805
Approved by: cgwalters
Splitting this out before I keep hacking on this file. Pretty
straightforward stuff. There is one legitimate use of the `goto out`
pattern left in which we clean up a tmpdir.
Closes: #788
Approved by: cgwalters
This was a kind of last-minute bug introduced when I tweaked the
checkout to use `.` to avoid a `mkdir()` for files. But there were
multiple bugs with that; for files that are in subdirectories of `/etc`
we obviously need to get the right subdir and not use `/etc`.
Second, we need to handle the case where we're adding new subdirectories.
This change fixes `rpm-ostree install firewalld + rpm-ostree ex livefs`.
Closes: #783
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
I noticed I had `/tmp/rpmostree-metadata*` directories, and there
were two cases where we created those dirs. Astonishingly,
*both* had bugs that prevented cleaning up.
Rename one of them so in the future it'll be clearer which is buggy (or both).
Closes: #772
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
I didn't realize we had this dbus method. It was added in the initial
drop of the DBus API, and AFAICS nothing uses it; it's not exposed
via the cmdline, and a quick `git grep` in Cockpit shows it's
not used there either.
It's tempting to delete it.
However, before we take that step, let's reimplement it in terms of the new,
shiny, more powerful "cleanup" txn.
The particular reason I'm doing this is I want to change how we handle
rollbacks.
Closes: #767
Approved by: jlebon
This is a follow-up to commit 77acf62. There, we added support for
rebasing from a local branch to another local branch. But in testing,
it's also really useful to be able to rebase from a remote-based refspec
to a local branch. We allow this here by slightly expanding the syntax
of allowed refspecs.
Now, we can use rpm-ostree all the time rather than fallback to `ostree
admin deploy`, which isn't pkg-aware.
Closes: #764
Approved by: cgwalters
While nothing else besides cleanup right now would call this directly, the code
should live close to the other very similar function:
`rpmostree_syscore_add_deployment()`.
Closes: #709
Approved by: jlebon
This is prep for livefs. We need to tweak the logic from what
core libostree has in `ostree_sysroot_simple_write_deployment()`,
and while we could land improved logic there, I think it makes
sense to carry this here until we're confident enough in the logic
to make it ABI.
This does depend on a [new libostree API](https://github.com/ostreedev/ostree/pull/745)
that allows writing deployments without doing cleanup.
The `bump_mtime()` bit is also prep for livefs, carrying in this patch to avoid
splitting things too much.
Closes: #709
Approved by: jlebon
This is preparatory for future changes which will make use the newer sysroot
writing API. But in this change, we can drop all of our version ifdef'd code.
Closes: #740
Approved by: jlebon
Otherwise dracut will just default to the running kernel, which will be
wrong if the pending deployment doesn't have the same kernel. Use --kver
rather than appending to be more explicit.
Closes: #722
Approved by: cgwalters
The new UpdateDeployment() method wraps the full capability of the
deploy transaction handler. Modifiers indicate how one wants to change
the origin, and options indicate extra behaviours.
One interesting note here is that all the options "come together" for
the first time: some of them were user-specified options (reboot,
skip-purge, dry-run), some were internal only (no-pull-base), and some
were both (allow-downgrade).
This means we now have to handle interesting cases, e.g.:
- We check for option conflicts between "no-pull-base" and
"set-refspec"/"set-revision" (similarly for "skip-purge").
- We enable "allow-downgrade" by default if the refspec or revision is
changing.
- Previously, "dry-run" could only be specified through PkgChange().
Rather than making it only valid when pkgs are overlayed (which
itself wasn't that meaningful since the introduction of dormant
package requests), we generalize it so that "dry-run" just means:
stop right before actually deploying the tree.
Closes: #711
Approved by: cgwalters
If available, using the also-new `OSTREE_CHECK_VERSION`. I dropped the `path`
argument from one of the internal APIs since it made the code simpler, and every
caller except one was passing `.`.
Closes: #712
Approved by: jlebon
All the handlers that eventually create a deploy transaction can share
much more code. This will make it easier to implement pkg
install/uninstall for all of them in one place.
Closes: #710
Approved by: cgwalters
Right now, the `rpm-ostree cleanup` logic calls into a "public static" method of
`RpmOstreeSysrootUpgrader`. That's because today, a lot of the high level "core
server side" logic lived in that class. However, it's only for upgrades (well,
really "generating pending deployments").
As I'm working on "livefs" which is really something different, I find it needs
to interact with some of `SysrootUpgrader`'s logic. Let's introduce a "sysroot
core" which is just a set of static functions taking an `OstreeSysroot*`, and
then all 3 of cleanup, (upgrade|deploy) and livefs can use these.
Closes: #708
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
Rework pkg_change() so that the core functionality is implemented by a
helper function. Also convert it to the new style.
I also renamed the "local-packages" to "install-local-packages".
Contrast with the future values: "install-packages" and
"uninstall-packages".
Closes: #704
Approved by: cgwalters
This is the same change that was done for PkgChange(). It will be
required if we want to support specifying local packages through e.g.
--install switches.
Closes: #704
Approved by: cgwalters
Just like `rpm-ostree ex`, for things like `ex livefs` that have DBus
interfaces, we should segregate these off so that people know they're unstable.
And conversely that they can test for the presence of the method on the main
interface for stability.
I initially tried having the same `RpmostreeOS` object implement both
but couldn't work out how to do that; see https://mail.gnome.org/archives/gtk-app-devel-list/2017-March/msg00161.htmlCloses: #701
Approved by: jlebon
This is a follow-up to commit 81c43e8 (#657). That commit extended the
definition of "packages_added" to also support local RPMs. We revert
that here, and instead open the RPM file ourselves and send the fd over
D-Bus. We add support for a "local-packages" option containing the fd
indices to process.
It's just cleaner and safer overall; the daemon and client might not
even be sharing the same view of the filesystem!
Closes: #696
Approved by: cgwalters
Add an annotation so that the generated D-Bus code allows rpm-ostree to
pass fds through messages. Note that this doesn't change the API itself,
only how rpm-ostree uses the GDBus library. Clients should still be able
to invoke PkgChange() as before.
Closes: #696
Approved by: cgwalters
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
This takes commit c437f90 a bit further. We delete more #ifdef 0 blocks
which can just be revived later on if we need it.
Closes: #695
Approved by: cgwalters
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
Down the line we should have a saner stringification, and also
log things like the invoking `loginuid` etc.
But this gets us something.
Closes: #660
Approved by: jlebon
Preparation for idle exit - the daemon knows when it should idle exit. It's
tempting to move all of the mainloop logic there, but it'd be more code churn
than I want to do right now.
Closes: #660
Approved by: jlebon
This is part of the idle exit work - the higher level daemon logic needs to
track running transaction state, so we can combine that with whether we have `> 0` clients.
(Yes, we need a better stringification of txns)
Closes: #660
Approved by: jlebon
Now `systemctl status rpm-ostreed` will show it. In future patches I plan to add
whether we have an active txn and our pending idle exit timeout.
Closes: #660
Approved by: jlebon
This is like what bluez does. With this, we have a stronger mechanism to avoid
races with future work to auto-exit on idle. Registered clients
hold a reference to the daemon effectively.
Note that calling `UnregisterClient` is optional if the calling process is going
to exit soon - as is the case for using the command line binary via e.g.
`rpm-ostree status`.
Closes: #660
Approved by: jlebon
These were leftovers from the very original code which did support exit-on-idle;
we're going to do it differently now.
Closes: #659
Approved by: jlebon
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
There are two main issues right now; first, we don't pick up manual changes to
`.origin` files, which occurs when one needs to sed it to remove `unconfigured`
for example. Second, we need to reload changes to the remotes.
Closes: #598
Approved by: jlebon
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
This is the beginning of a move towards making the upgrader more
stateless and less hysteretic. Ideally, the only input required should
be an origin file. Users of the upgrader are in charge of modifying the
origin as needed. The main goal of this is to simplify the upgrader
model and a better separation of concerns.
This was already done for the initramfs-related entries. This patch
formalises this for most of the other inputs, except packages, which
will be done soon.
Closes: #634
Approved by: cgwalters
This functionality is disabled right now, and if we want to re-enable
it, we'll want to do it in a way that ensures the ignore scripts are
permanent.
Closes: #634
Approved by: cgwalters
Let's not hardcode a broken English-only version of `ngettext` here; rework the
message to avoid requiring pluralization.
Closes: #632
Approved by: jlebon
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
The hash tables are only initialized if the initable init completes, but it
won't if something goes wrong there. In this case, an origin
`unconfigured-state`.
Closes: #626
Approved by: jlebon
We sometimes talk about using `ostree admin undeploy`, but that
doesn't know about the pkgcache, and hence space there leaks
until the next rpm-ostree operation.
Just for this, we need to expose a cleanup command (and API). But
we also need to support cleaning:
- repomd
- downloads (repo/tmp)
So let's start implementing that.
Closes: #614
Approved by: jlebon
I debated just putting this in the supported list, but decided against
it in the end. This really should be something that happens
transparently, and if it doesn't then something else is probably wrong.
Closes: #617
Approved by: cgwalters
Until now, we always used the booted deployment, and would
garbage collect the "pending" deployment. This is the
way OSTree was designed, but I think for rpm-ostree given
how mutable we are on the client side, there's a much stronger
argument for being more stateful too.
This is a relatively simple code change to split the "merge deployment"
concept into two. There's now the "config merge deployment" and the
"origin merge deployment".
Basically, `rpm-ostree install foo; rpm-ostree install bar` will
now install both `foo` and `bar`. But we will still use the booted
deployment for `/etc`.
Down the line, I think I'd like to drive into OSTree the concept of
a "staged" deployment, that has the hardlink checkout done, but doesn't
have the config merge.
But we don't need to change the OSTree core for this yet; we can
do it here in rpm-ostree, and this relatively simple code change
fixes many issues at once.
For example, `rpm-ostree upgrade && rpm-ostree install foo` now
does what you expect as well.
Obviously, we want to enable doing multiple things in *one* transaction,
and we're not far away, but I think this is also the right thing to do now.
I'm relatively confident it won't break anyone's workflow, as what
we did before wasn't generally that useful. However, people will
need to learn to `ostree admin undeploy 0` if they *don't* want
this behavior. (We need to have `rpm-ostree cleanup`).
Closes: https://github.com/projectatomic/rpm-ostree/issues/406Closes: #611
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
The actual problem I am trying to fix with this is fallout from the
introduction of `/usr/libexec/rpm-ostreed`, which required a SELinux
policy change. Specifically for CentOS, the base policy is rev'd
slowly.
My hope was that by merging the daemon code back into `/usr/bin/rpm-ostree`
which is labeled `install_exec_t`, starting via systemd would do
the right thing. It turns out that doesn't happen.
Now later, I'm picking this patch back up because I want to do multprocessing in
the daemon (and in the core), and it makes sense to share code between them,
because multiprocessing will need to go through a re-exec path.
Another benefit is we avoid duplicated text (libglnx, internal helpers) between
the two binaries.
Closes: #292
Approved by: jlebon
When we checked out the base tree for package layering, we would create
the directory in which ostree did the checkout. This meant however that
ostree wouldn't apply xattrs on the root directory itself. This would
cause the directory to be mislabeled (as system_conf_t instead of
root_t), which in turn cause SELinux violations on reboot when systemd
tried to make the root mount shared.
This patch fixes this by first settling on a permanent directory in
which to do checkouts -- really, we'll never have multiple package
layering operations going on at the same time. Once we know that we have
a reserved path, we can safely let ostree create it for us with the
proper xattrs.
Resolves: RHBZ#1318547
Closes: #605
Approved by: cgwalters
In the previous commit I changed to abspath, since when reworking things the
relative path broke (I'm still not entirely sure why, but we were basically
lucky before). However I then later realized this wouldn't be right if
rpm-ostree was started with a `--sysroot` argument from Anaconda.
What we can do instead (at least until libdnf grows fd-relative APIs)
is to make it a fd-relative abspath.
Closes: #596
Approved by: jlebon
The next step will be to design a DBus + commandline API for this. In the
meantime, there are some small subtle new features like honoring the dry-run
option for upgrade. I'm not testing that explicitly yet, but I think that's OK.
Closes: #593
Approved by: jlebon
3 bools in parameters is too many; time to do flags. This also will lead to
deduplicating with the pkg txn flag type when we merge that in. Also, we dedup
the gvariant parsing code.
Closes: #593
Approved by: jlebon
Following on the previous commit, this drops the last bit of state that we
threaded through various calls. We only need one reference.
Closes: #590
Approved by: jlebon
I was going to do some work here, and adding another parameter to thread down
through these function calls got painful. We already have an object to store
state in, so do it. This makes us more consistent.
Closes: #590
Approved by: jlebon
Upgrade is just a special case of rebase conceptually where:
- We fetch the latest tip
- We enable downgrade protection
This is part of a larger effort where I am aiming to have a *single* transaction
type for system mutation, so we can do both upgrades and package layering and
enable initramfs all in one go.
Closes: #589
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
Working on initramfs, I hit a subtle issue with the fact that
I was trying to "redeploy", but with the origin file changed
during the process.
Previously, it was a bit unclear which parts of the upgrader logic are operating
on the *new* origin versus the "original origin".
The package layering code in the upgrader explicitly carries a delta on top in
the "add/remove" hash sets, which means it isn't visible to
`rpmostree_origin_is_locally_assembled()`.
Whereas for initramfs, I set a new origin. This broke things since we were
expecting to find a parent commit, but the original origin wasn't locally
assembled.
When looking more at this, I realized there's a far simpler model -
rather than keeping track of commit + origin, and using the origin
to try to determine whether or not the commit is layered, we can
keep track of `base_revision` and `final_revision`, and the latter
is only set if we're doing layering.
The diff speaks for itself here - a lot of fragile logic looking at the origin
drops away.
The next step here is probably to drop away the package layering hash sets, but
I'm trying to not change everything at once.
Closes: #579
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
We should really be logging more into the journal in general,
but particularly this will make it easier to find errors
in the test suite.
Right now we only dump script stderr into the journal.
Closes: #560
Approved by: jlebon
