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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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
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
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
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
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
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
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
Expand the available options in the Rebase() D-Bus method to also have a
"revision" key. Its value has the same semantics as the "revision" key
in the Deploy() method (e.g. the "revision=" and "version=" prefixes are
also supported). Also expand the rebase CLI to allow for specifying the
revision as an additional argument.
This allows users to rebase to a specific version or checksum, rather
than only to the latest. Conceptually, this is the equivalent of doing a
rebase followed by a deploy. I.e. we specify an override-commit in the
origin and expect the same behaviours that apply after a deploy to also
apply here.
Closes: #212Closes: #555
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 need the ability to both add and remove packages as one
transaction in the general case (`Conflicts:`), plus it'd
be quite nice to allow users to do multiple package things
before rebooting.
And finally, this deletes a lot of duplicate code.
Where I'm really thinking this should go is we only have one
transaction type internally for at least upgrade/pkg as a group.
Closes: #326
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
Deploy(revision) pulls and deploys a particular revision on the
branch of the currently booted deployment. The revision can be
expressed as a SHA256 checksum or as a version metadata value.
Allows clients to see version, timestamp
and other detailed information along with
the rpm diffs for cached updates and rebases.
This will be used by the Cockpit interface.
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.
So the client side can read it back.
This replaces the GObject "sysroot-path" property in the wrapper class,
which created some additional daemon refactoring.
Few things to note:
- Cancelling a transaction no longer immediately destroys it.
- Transaction is destroyed when finished (or cancelled) and has
no client connections.
- If a client attaches to a finished transaction and calls Start(),
the transaction will re-emit the Finished signal to that client.
- The transaction bus address is not yet shared across multiple
clients, so multiple connections doesn't actually work from the
outside yet. It's just supported internally.
Change the ActiveTransaction property from the bus address of the active
transaction to a string tuple: (method name, sender name)
The bus address was only a placeholder, and not very useful since each
transaction only accepts one connection (presumably the method caller).
Since the daemon can detect when the client closes its peer-to-peer
connection, simplify the API by converting the Finish() method to a
Finished signal that is only emitted once.
Internally, add a "closed" signal to transactions (triggered by a
closed GDBusConnection), and have the transaction monitor use that
instead of "finished" to know when to dispose of the transaction.
Transaction progress and message signals are really only intended for
one recipient: the client that invoked the method. Use a peer-to-peer
connection for transactions so we're not spamming the system bus.
This entails returning a bus address rather than an object path in
methods that use transactions. The client opens a connection to the
bus address, connects handlers to the Transaction interface (on path
"/"), and then invokes the Start() method.
To finish a transaction, the client need only close the connection,
either explicitly or by terminating. The server will detect this
and clean up resources for that transaction.
Turns out we do still need a Start() method after all. Not for lack
of trying, but I can't get away from the client and server doing some
sort of handshake at the beginning to avoid either raciness on the
client side or artificial delays on the server side.
I don't particularly like the "start" signal I've added -- I'd much
prefer subclassing -- but I'm trying to keep the changes incremental.
The ProgressEnd signal indicates to clients there will be no more
DownloadProgress or SignatureProgress signals in the transaction,
and any further Message signals should be output as separate lines
instead of replacing the previous progress message.
In other words, it's just a way of driving GSConsole remotely.
A few changes:
- Modify the D-Bus API to include a Finish() method instead of a Start()
method, the idea being the client calls Finish() to obtain the final
status and optional message once the transaction indicates it's done.
Calling Finish() also removes the transaction object from the bus.
- Introduce Transaction class as a thin wrapper for RPMOSTreeTransaction.
Stores the status info for Finish(), detects when the caller's bus name
vanishes, and emits various status signals to TransactionMonitor.
- Introduce TransactionMonitor as a factory class for Transactions that
also handles book keeping chores like tracking the active Transaction.
The Sysroot and OS interfaces share a TransactionMonitor instance.
Returns the object path for the given OS name.
This can be done entirely client side, but it requires connecting to
the object manager interface, requesting all the objects and sifting
through them to find the one with a matching Name property.
For some use cases this method is just more convenient.
