Skip to content

dbus: rauc: replace tacd-based update polling with native update polling #90

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 21 commits into
base: main
Choose a base branch
from
Open

dbus: rauc: replace tacd-based update polling with native update polling #90

wants to merge 21 commits into from

Conversation

hnez
Copy link
Member

@hnez hnez commented Apr 2, 2025 •
edited
Loading

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:

  • ETag-based check for changed bundles on the server. This means unchanged bundles do not have to be inspect on every poll.
  • Automatic installation and boot into new bundles.

Other PRs related to this one:

TODO before un-drafting:

  • Write proper commit messages

hnez added 3 commits April 3, 2025 09:02
@hnez
tacd: dbus: rauc: re-introspect services
ac2e0c4 
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>
@hnez
dbus: systemd: also monitor rauc.service
77aafa2 
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>
@hnez
dbus: rauc: add Channels type to use instead of Vec<Channel>
a164327 
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>
@hnez hnez marked this pull request as ready for review April 3, 2025 07:19
@hnez hnez requested a review from jluebbe April 3, 2025 07:22
@hnez
Copy link
Member Author

hnez commented Apr 3, 2025

Hi @jluebbe,

I'd suggest you go first and review the polling integration first and maybe in a next step we ask @KarlK90 to have a look from a Rust point of view?

hnez added 18 commits April 3, 2025 09:24
@hnez
dbus: rauc: use a UpdateRequest object instead of a simple URL for in…
0833495 
…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>
@hnez
dbus: rauc: allow restricting installation to a specific manifest_hash
b1d8baa 
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>
@hnez
dbus: rauc: remove tacd-based update polling
46cb875 
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>
@hnez
dbus: rauc: update_channels: add a concept of a single primary channel
6a43333 
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>
@hnez
dbus: rauc: only install bundles from the primary channel
42b959f 
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>
@hnez
dbus: rauc: system_conf: write runtime RAUC config with poll section
2b84818 
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>
@hnez
dbus: rauc: reload rauc daemon when required
008b883 
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>
@hnez
dbus: rauc: trigger a single poll for updates after reloading the daemon
632685f 
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
dbus: rauc: forward poller status to broker
0ab21a3 
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>
@hnez
dbus: rauc: add manifest_hash und effective_url to UpstreamBundle
911e489 
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>
@hnez
dbus: rauc: add support for enabling the auto install feature
f6d6b46 
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>
@hnez
dbus: rauc: implement forced polling via update channel files
79f970f 
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>
@hnez
dbus: rauc: allow configuring the *_criteria in channel files
e5c3a3c 
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>
@hnez
dbus: rauc: prevent auto updates while in setup mode
31dd189 
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>
@hnez
web: setup: inform the user about additional headers that are sent now
cb89591 
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>
@hnez
web: indicate to the user when a channel is enabled but not primary
9f5d256 
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>
@hnez
web: add toggle switches to enable automatic installation of updates
84c6b9e 
Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
@hnez
web: use manifest_hash and effective_url when triggering an install
4e711b3 
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>
This was referenced Apr 3, 2025
Draft
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jluebbe jluebbe Awaiting requested review from jluebbe

At least 1 approving review is required to merge this pull request.

Assignees

@jluebbe jluebbe

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@hnez @jluebbe