Note
|
We recommend that you view this article in our documentation portal. Not all of our articles render correctly in GitHub. |
Here, we provide reference documentation on aktualizr’s usage and configuration. However, if you need to go further than what’s possible with the command-line interface, you can also use libaktualizr to make your own client. In fact, aktualizr is a fairly thin wrapper around libaktualizr itself, and we provide also an even simpler example client along with doxygen docs of the libaktualizr API.
Aktualizr is configured via .toml
config files. One or more files or directories can be passed to the application via the --config
flag (one per file or directory).
-
If
--config
is not specified on the command line, aktualizr searches the following directories for files with a.toml
extension:-
/usr/lib/sota/conf.d
-
/etc/sota/conf.d/
-
Aktualizr searches for and processes these config files in systemd style using the following rules:
-
If multiple files are found with the same name, the last detected file overrules and hides the others.
-
Files are then processed in alphabetical order with the following conditions:
-
If a config option is specified in multiple files, the last entry overrules the previous entries.
-
But if a config option is specified in the first file but unspecified in the last file, the last entry does not overrule the previous entry.
-
For examples of configuration files, see the following resources:
All fields are optional, and most have reasonable defaults that should be used unless you have a particular need to do otherwise.
Some options can also be set on the command line. The command line input always takes precedence over the config files. See the aktualizr source (or run aktualizr --help
) for the available command line options.
Configuration for the logger.
Name | Default | Description |
---|---|---|
|
|
Log level, 0-5 (trace, debug, info, warning, error, fatal). |
Options for using a PKCS#11 compliant device for storing cryptographic keys.
Note
|
The key ID options require the corresponding options in the tls or uptane section to be set to pkcs11 .
|
Name | Default | Description |
---|---|---|
|
Path to the shared object HSM driver. |
|
|
Password for accessing the HSM. |
|
|
Key ID of the Uptane key in the HSM. |
|
|
Key ID of the TLS root CA certificate for authenticating the server. |
|
|
Key ID of the client’s TLS private key. |
|
|
Key ID of the client’s TLS certificate. |
Configuration for client-server TLS connections.
Name | Default | Description |
---|---|---|
|
Server URL. |
|
|
Path to a file that contains the server URL. |
|
|
|
Where to read the TLS root CA certificate from. Options: |
|
|
Where to read the client’s TLS private key from. Options: |
|
|
Where to read the client’s TLS certificate from. Options: |
Note that server_url_path
is only used if server
is empty. If both are empty, the server URL will be read from provision.provisioning_path
if it is set and contains a file named autoprov.url
.
Options for how the device is provisioned with the backend.
Name | Default | Description |
---|---|---|
|
Server provisioning URL. If empty, set to |
|
|
Password for PKCS#12 encryption. |
|
|
|
Provided in the |
|
Path to an archive containing provisioning data. See the reference documentation for the specification of the contents of this file. |
|
|
Device ID of the Primary ECU. If left empty, a random name will be generated. |
|
|
Serial number of the Primary ECU. If left empty, a random serial will be generated. |
|
|
The hardware ID of the Primary ECU (e.g., |
|
|
ECU registration URL. If empty, set to |
|
|
|
See the provisioning documentation for more details. Options: |
If you intend to provision with a server by using meta-updater, you will probably want to set provision.provision_path = "/var/sota/sota_provisioning_credentials.zip"
.
Options for Uptane.
Name | Default | Description |
---|---|---|
|
|
Interval between polls (in seconds). |
|
Director server URL. If empty, set to |
|
|
Image repository server URL. If empty, set to |
|
|
|
Where to read the device’s private key from. Options: |
|
|
Type of cryptographic keys to use. Options: |
|
false |
Forces installation completion. Causes a system reboot when using the OSTree package manager. Emulates a reboot when using the fake package manager. |
|
|
Secondary json configuration file. Example here: ../config/secondary/virtualsec.json |
|
|
Time to wait for reachable secondaries before attempting an installation. |
|
|
If this file exists, and a flock() lock is held then updates will be disabled. |
The default for update_lock_file
depends on the setting of the TORIZON
build flag.
When not building in TORIZON mode update_lock_file
defaults to ``.
Options for package management and update installation. Note that this only coincidentally shares the name with the ArchLinux pacman
tool.
Name | Default | Description |
---|---|---|
|
|
Which package manager to use. Options: |
|
OSTree operating system group. Only used with |
|
|
Path to an OSTree sysroot. Only used with |
|
|
OSTree server URL. Only used with |
|
|
|
Path to a file for storing package manifest information. Only used with |
|
|
Directory to store downloaded binary Targets. Only used with |
|
false |
Simulate a wait-for-reboot with the |
Options for how aktualizr stores data locally.
Name | Default | Description |
---|---|---|
|
|
What type of storage driver to use. Options: |
|
|
Directory for storage. This should be a directory dedicated to aktualizr data. Aktualizr will attempt to set permissions on this directory, so this option should not be set to anything that is used for another purpose. In particular, do not set it to |
|
|
Relative path to the database file. |
|
|
Path to the uptane metadata store, for migration from |
|
|
Relative path to the Uptane specific private key, for migration from |
|
|
Relative path to the Uptane specific public key, for migration from |
|
|
Relative path to the TLS root CA certificate, for migration from |
|
|
Relative path to the client’s TLS private key, for migration from |
|
|
Relative path to the client’s TLS certificate, for migration from |
The only supported storage option is now sqlite
.
Old systems configured with filesystem
can be migrated by changing the type
field to sqlite
and keeping all the other fields as-is.
At the next aktualizr run, the migration procedure will then run automatically and move existing data inside the database.
Options for importing data from the filesystem into the storage.
Name | Default | Description |
---|---|---|
|
|
Path to a common root directory to the subsequent files |
|
Path to the device’s private key. |
|
|
Path to the device’s public key. |
|
|
Path to the TLS root CA certificate. |
|
|
Path to the TLS private key. |
|
|
Path to the TLS client certificate. |
Options for configuring how aktualizr communicates with the server.
Name | Default | Description |
---|---|---|
|
|
Enable reporting of device networking information to the server. |
Options for configuring boot-specific behavior
Name | Default | Description |
---|---|---|
|
|
Controls rollback on supported platforms, see rollback.adoc. Options: |
|
|
Base directory for reboot detection sentinel. Must reside in a temporary file system. |
|
|
Name of the reboot detection sentinel. |
|
|
Command to reboot the system after update completes. Applicable only if |