Concept: Simple Update Server Support (and Life Cycle Handling)

[ejoerns]

Problem

So far, the options for using RAUC in network-based OTA update scenarios are:

• set up a hawkBit deployment server and use it with e.g. rauc-hawkbit-updater as a client
• use a simple HTTP web server, place a bundle at a well-known location, and let RAUC download it
• have a custom (proprietary) deployment server with a custom client (perhaps integrated with the main application)

Typical features that can be required by an OTA update server are:

• Rollout scheduling to avoid updating all devices at once
• Deploy updates only to specific devices
• Monitoring of devices and basic device properties
• Notification after successful update + reboot (and collection of errors)

Excluding the custom server approach, the other two options are on opposite ends of the spectrum:

• hawkBit provides a rich feature set but is complex to set up and manage.
• A simple HTTP web server is easy to set up and manage but has hardly any capabilities for controlling update rollouts.

Now, since RAUC can directly download/stream bundles from an HTTP server, the idea is to equip RAUC with capabilities that support the above-mentioned features with a simple HTTP server (and optionally with little custom application logic).

Some of the required RAUC-side capabilities are currently missing for all scenarios. The most important one is the lack of update life-cycle state handling that would allow RAUC to more reliably detect and report a successful reboot of a just-updated system.

Possible Solution

The following generic features can be implemented in RAUC to support the usage of simple update servers.

• RAUC should optionally send some HTTP headers to the server. In the simplest case, this information can be logged by the server and introspected by the rollout operator. In more complex setups, the server can add some custom application logic and use the headers for filtering etc.

• The information reported to the server should be configurable and can be either standard information that is already available in RAUC or additional information retrieved by the system-info handler.

• System state information like a boot id, an update transaction id, and a general update cycle state should be generated and stored to allow RAUC to conclude if the system actually rebooted, if it rebooted to the expected system, etc.

• Automated polling for updates at a defined location (URL) can be implemented as part of the RAUC service.

• Simple rollout 'scheduling' can be realized by configuring an update time range for the devices. Each individual target chooses its point in time (in a reproducible manner) where it actually performs the download and update. This ensures not all platforms update at once to limit server load and allows operators to stop rollouts.

[ejoerns]

Note that a notable number of features from the list above already made their way into RAUC.

With #1152 we can now actually configure RAUC to expose information like boot id, transaction id on the first HTTP request. See https://rauc.readthedocs.io/en/latest/advanced.html#additional-http-header-information.

More advanced features like polling or rollout scheduling are still to be done.