dbus: rauc: replace tacd-based update polling with native update polling#90
Open
hnez wants to merge 21 commits intolinux-automation:mainfrom
Open
dbus: rauc: replace tacd-based update polling with native update polling#90hnez wants to merge 21 commits intolinux-automation:mainfrom
hnez wants to merge 21 commits intolinux-automation:mainfrom
Conversation
RAUC is in the process of adding native update polling support. Re-introspect the dbus service to add the new APIs. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This exposes the status of the RAUC daemon to users inside and outside of the tacd. As of now neither of them exist, but in the next few commits support for re-starting the RAUC deamon to reload its configuration will be added. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This allows us to add methods like "get the primary channel", that operates on all update channels at once, to this `Channels` type later on. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Member
Author
…stall Right now the UpdateRequest object also only contains the URL, just like before, but in the future we will at least add a `manifest_hash` field that ensures that the user gets exactly the update bundle they agreed to install. The change is backwards-compatible. Incoming requests to the `/v1/tac/update/install` endpoint are first parsed as JSON object (the new UpdateRequest object) and if that fails as simple string (the old URL string) and then transformed transparently. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This makes sure that an user gets exact the bundle they intended to install, e.g. the bundle was not replaced by a newer one on the server or otherwise tampered with. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
RAUC is in the process of adding native polling support, which we want to integrate into the tacd. To do the switch in a reviewable way first remove the tacd-based polling and then add the native support in separate commits. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
RAUC native update polling only supports a single update channel,
while our native update polling did support multiple
(all channels which RAUC would have accepted updates from,
based on the enabled signing certificates, were polled for updates and the
user was asked if they wanted to install updates from them).
Prepare for the change by adding a concept of a single primary update
channel. The primary channel is the first enabled one. Based on the
channel definition file name.
E.g. on production TACs these channel files are available:
root@lxatac-00011:~# ls /usr/share/tacd/update_channels/
01_stable.yaml 05_testing.yaml
They are sorted by name when they are read from disk, so if both
`stable.cert.pem` and `testing.cert.pem` are found
in `/etc/rauc/certificates-enabled/`, then the stable channel will be
the primary channel, but bundles from the testing channel may still be
installed via the command line interface (e.g. to facilitate a channel
switch).
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This restricts the sources that the `/v1/tac/update/install` will accept update requests from to only the primary channel. The web interface has not exposed the feature to install arbitrary URLs for some time now and users that want to do so are better served by using the command line interface instead. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This configures RAUC to poll for updates on our behalf. We do not use the information yet or enable automatic installation but those are next steps. We also need to trigger RAUC to re-read the file for this to be useful. All of these features are added in follow-up commits. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This uses the existing systemd DBus API integration to trigger a daemon restart (there is no support to just reload the config as of now) and keep track of the following state changes. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
RAUC native polling provides us with information about the recent poll attempts. This includes information about the bundle version and wether it is an update over what is currently running on the device. In other words: it gives us everything we need to show update notifications again. Forward this information to the same places we used with the tacd-based update polling. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
The RAUC native polling interface provides more information than
just the basic `compatible` and `version` fields.
Among these extra informations are the following:
- `manifest_hash`
By using the `manifest_hash` in the `InstallBundle` call we can
(cryptographically) ensure that the exact bundle (content) that the
user agreed to install is actually being installed and that no switch
has happened in between.
- `effective_url`
This is the bundle URL after all HTTP redirects have been followed.
This is e.g. relevant when a "clever" update server is used that
redirects poll requests to specific bundles to e.g. implement staged
rollouts or prevents updates from incompatible bundle versions.
By using this one can ensure that the bundle URL used matches
the `manifest_hash` provided and that the redirects did not change
(e.g. because the next step in a staged update was reached)
between the last poll and the user accepting an update.
The update dialog on the LCD is updated to use this mechanism now,
while the web interface will be updated later.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Automatic installation and boot of updates can be useful when managing a fleet of devices. This is however a feature that requires strict user consent, hence why it is off by default. Add backend-support for enabling this feature. Frontent support in the web interface will be added later. We always enable auto-reboot together with auto-install, since the migration scripts only run once at the end of the installation. A system that is updated, but not rebooted, would thus accumulate changes that are not migrated to the other slot. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Users managing a fleet of devices with custom-built update bundles and update channel may want to automatically enable update polling and automatic installation of updates without having to do so explicitly via the web ui. (At least we at Pengutronix do). Enable this usecase by adding optional `force_polling` and `force_auto_install` config options to the update channel definition files. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
The native RAUC polling feature allows configuring when a new update bundle is even considered as an update candidate (`candidate_criteria`), when it is considered for automatic installation (`install_criteria`) and under which conditions to auto-boot into another slot after installation (`reboot_criteria`). The defaults we have chosen in previous commits generally make sense, but allow users with custom update channels to customize them if they deem it necessary. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This is to prevent a situation where a user enables auto-install in the
setup mode and an update starts immediately, does a migration of whatever
the user has configured so far and triggers a reboot while the user is
still configuring things in the web interface.
This should make the user experience a bit better:
- Unbox TAC.
- Enter setup mode.
- Enable update polling and auto install.
(A poll for updates will trigger immediately, but no auto install)
- Configure the rest of the system.
- Leave the setup mode.
- Another poll for updates may be triggered and if available an
installation will start.
- The user is greeted by the normal web interface showing a notification
about the ongoing installation.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
We include the `boot-id` and `uptime` options in the RAUC `send-headers` config in the hopes of detecting boot-loops during update roll-out. This was not anticipated when writing the setup page, so we add it now. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
The channel list in the web interface now contains a "Upgrade" column
with one of the following:
- "Not enabled" for channels which are not enabled, which means bundles
from it can not be installed for it.
- "Not primary" (this one is new) for channels which are enabled,
but are not the primary one and are thus not polled by the native RAUC
polling feature.
- "Polling disabled" if the polling feature is not enabled.
- A spinner if we do not know the status yet.
- "Up to date" if the TAC is in sync with this update channel.
- "Upgrade" (a button) if an update is available.
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
This ensures that the exact bundle (content) that the user agreed to install is actually installed. Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Member
|
I've created a RAUC feature request to support service config reloading: rauc/rauc#1709 |
jluebbe
requested changes
May 13, 2025
| let dynamic_conf = { | ||
| match poll_section(primary_channel, enable_polling) { | ||
| Ok(Some(ps)) => { | ||
| // We use the config in /etc as a template ... |
Member
There was a problem hiding this comment.
You mean the one in /usr/lib/rauc/?
Comment on lines
90
to
96
| // Allow polling for updates, but not automatically installing them | ||
| // while the user is still in setup mode. | ||
| // Otherwise they may unbox a TAC, click through the setup process, | ||
| // activate auto installation, and then an installation starts in the | ||
| // background without them even noticing. | ||
| let polling = enable_polling || force_polling; | ||
| let auto_install = enable_auto_install || force_auto_install; | ||
| let auto_install = (enable_auto_install || force_auto_install) && !setup_mode; |
Member
There was a problem hiding this comment.
Couldn't this use the inhibit file mechanism to prevent polling while in setup mode?
| let mut section = String::new(); | ||
|
|
||
| writeln!(&mut section)?; | ||
| writeln!(&mut section, "[poll]")?; |
Member
There was a problem hiding this comment.
We've decided to rename the section from poll to polling.
Suggested change
| writeln!(&mut section, "[poll]")?; | |
| writeln!(&mut section, "[polling]")?; |
Also update the comment above and in update_system_conf().
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This uses the native RAUC update polling support introduced in rauc/rauc#1672 to replace the tacd-internal update polling.
Among the various benefits of this approach are the following:
Other PRs related to this one:
TODO before un-drafting: