This sections lists all the configuration options in mender.conf
.
There are two options for specifying verification keys:
ArtifactVerifyKey
is a single path to a key.ArtifactVerifyKeys
is a list of paths to keys. When multiple keys are
specified, the keys will be
tried in order, and the first key that verifies
an artifact signature will be
used. This is useful for key rotation or
signing different types of artifacts.Only one of ArtifactVerifyKey
or ArtifactVerifyKeys
may be specified.
When set, the Mender client verifies the following:
See also the section about signing and verification.
This option is deprecated and does not exist anymore in Mender Client v4.0 and later. For earlier versions, please see documentation for Mender 3.6 or older.
This option is deprecated and does not exist anymore in Mender Client v4.0 and later. For earlier versions, please see documentation for Mender 3.6 or older.
This option is not supported starting from the Mender client version 4.0, and all the HTTP requests will be sent without the Keep-Alive header.
Allows you to configure additional connection-related settings.
This option is not supported starting from the Mender client version 4.0, and all the HTTP requests will be sent without the Keep-Alive header.
If set to true, disables the connections keep alive in general. All the HTTP transactions will cause a new connection to be created.
This option is not supported starting from the Mender client version 4.0, and all the HTTP requests will be sent without the Keep-Alive header.
Specifies the time after which a connection is terminated. The larger it is, the longer keep alive traffic will happen, as the client will maintain the connection.
Introduced in Mender client 3.3.
Example:
"Connectivity": {
"DisableKeepAlive": false,
"IdleConnTimeoutSeconds": 30
},
The above will cause the client keep a connection and to terminate it after 30 seconds. During the 30 seconds each request will reuse an existing connection, which should in principle reduce the bandwidth, as we avoid a TLS negotiation and connection establishing every time the client has to contact the server.
Allows you to configure the certificate, private key, and SSL Engine id to use during the SSL handshake. If you provide the certificate and private key as locally accessible files you don't have to specify
SSLEngine.
If you want to use a Hardware Security Module (HSM) you can provide the private
key as a PKCS#11 URI and in that case
you must also specify the SSLEngine
.
Note that the client will not use this key for signing authentication requests, which is always
required, even when using SSL client certificates. For that you need to use
Security.AuthPrivateKey
.
A path to the file in pem format holding the certificate.
Either a valid PKCS#11 URI or a path to a file holding the private key.
Example (with HSM, using Nitrokey HSM):
"HttpsClient": {
"Certificate": "/certs/cert.pem",
"Key": "pkcs11:model=PKCS%2315%20emulated;manufacturer=www.CardContact.de;serial=SOMESERIAL;token=UserPIN%20%28SmartCard-HSM%29;id=%10;object=Private%20Key;pin-value=1234;type=private",
"SSLEngine": "pkcs11"
},
where "pkcs11:" means that Mender should load the key not from the file but using PKCS#11 URI. The above can have the following example OpenSSL configuration present: You can accompany the above with the following OpenSSL configuration:
[openssl_init]
engines=engine_section
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
MODULE_PATH = /usr/lib/arm-linux-gnueabihf/opensc-pkcs11.so
init = 0
Example (plain files):
"HttpsClient": {
"Certificate": "/certs/cert.pem",
"Key": "/keys/private/key.pem"
},
where "/certs/cert.pem" holds the certificate and "/keys/private/key.pem" the private key.
An integer that sets the number of seconds to wait between each inventory update. Note that the client may occasionally post its inventory more often if there has been recent activity on the device. See also the section about polling intervals.
An integer that sets the number of seconds to wait between each check for a new update. Note that the client may occasionally check more often if there has been recent activity on the device. See also the section about polling intervals.
An integer that specifies the number of seconds that an update module is allowed to run, before it is considered hung and killed. The process will first be sent a SIGTERM signal, and one minute later, if it has not exited, a SIGKILL signal is sent. The default is 4 hours.
The maximum number of tries that the Mender client performs when contacting the Mender Server.
If the setting is zero (the default), the maximum number of retries is 3 * ceil(log2(RetryPollIntervalSeconds) + 1)
.
Introduced in Mender client 3.3.
An integer that sets the number of seconds to wait between each attempt to communicate with the server. Note that the client may attempt more often initially to enable rapid upgrades, but will gradually fall back to this value if the server is busy. See also the section about polling intervals.
As of Mender client 3.3 this one also applies to inventory updates.
The Linux device that contains root filesystem A. The build system (ie Yocto or mender-convert) sets this variable so it is rarely modified manually.
Note: Starting with Mender client v4.0, this configuration option is no longer parsed by the client,
but instead by the rootfs-image
update module. For most users this does not make any difference,
but for advanced users it allows changing how it is handled, since the update module is a shell
script.
The Linux device that contains root filesystem B. The build system (ie Yocto or mender-convert) sets this variable, so it is rarely modified manually.
Note: Starting with Mender client v4.0, this configuration option is no longer parsed by the client,
but instead by the rootfs-image
update module. For most users this does not make any difference,
but for advanced users it allows changing how it is handled, since the update module is a shell
script.
Allows you to specify the basic security options, AuthPrivateKey
and SSLEngine
, which you can use for signing of authentication requests.
A path to the file in pem format holding the private key, or a PKCS#11 URI.
The SSLEngine to use.
An array of json objects on the form [{"ServerURL": "https://mender-server.com"}, {"ServerURL": "https://mender-server2.com"}, ...]
, where ServerURL
has the same interpretation as the root ServerURL
attribute. If Servers
entry is set, the configuration cannot
contain an additional ServerURL
entry in the top level of the json
configuration. Upon an unserved request (4XX/5XX-response codes) the client
attempts the next server on the list in the given order.
The server URL is the basis for API requests. This needs to point to the
server which runs the Mender Server services. It should include the whole URL,
including https://
and a trailing slash. NOTE: This entry conflicts with
Servers
attribute, i.e. the server only accepts one of these entries.
The location of the public certificate of the server, if any. If this certificate is missing, or the one presented by the server does not match the one specified in this setting, the server certificate is validated using standard certificate trust chains.
This variable relates to state scripts returning 21
- meaning retry-later
.
This variable specifies how long time should elapse from the retry-later
until
the script is rerun.
Example:
"StateScriptRetryIntervalSeconds": 30
If set, the client retries the state-script every 30 seconds as long as it keeps returning retry-later
.
Default value is: 60
See also the section about state scripts.
Note: Before mender v2.0.0 release, this option used to be called
StateScriptRetryTimeoutSeconds
.
This variable specifies how much time a state script can consume by returning
retry-later
, meaning retry with StateScriptRetryIntervalSeconds
for the
period of StateScriptRetryTimeoutSeconds
.
You can not wait indefinitely but the StateScriptRetryTimeoutSeconds
variable
is only limited by the size of an int
.
It is recommended to set a sane maximum value to handle unexpected behavior, as this could potentially disable OTA capabilities on your device for long periods of time.
Example:
StateScriptRetryIntervalSeconds: 30
StateScriptRetryTimeoutSeconds: 86400
The above example will allow a state script to return retry-later
for 24 hours before
aborting and marking the update as failed.
Default value is: 1800
(30 min)
See also the section about state scripts.
Note: Before mender v2.0.0 release, this option used to be called
StateScriptRetryIntervalSeconds
.
This variables specifies the timeout value for a state-script while executing, measuring time from start of script until is returns an exit code. This is to prevent a script "hanging/freezing" or taking too long executing a specific command. If the timer elapses the state-script will be "killed" by the Mender client and the update marked as failure.
The default value needs to be tolerant of most scripts, hence you should base it on the expected execution time of your scripts.
Default value is: 3600
(60 min)
See also the section about state scripts.
A token which identifies which tenant a device belongs to. This is only relevant if using a multi-tenant environment such as hosted Mender. Always treat the tenant token as a secret.
The location where to store the deployment (update) log. This must be on a persistent partition to avoid losing the logs due to a root filesystem update.
The location where to store the device_type. This must be on a persistent
partition to avoid it accidentally changing due to a root filesystem update. The
default location is /var/lib/mender/device_type
This option is not supported starting from the Mender client version 4.0. For server-side support duration, please refer to our blog post.
The expire time in seconds for an update control map. The value provides the time window for an application using the update control dbus API to refresh the update control map before it enters the expired state. Defaults to 2*UpdatePollIntervalSeconds
This option is not supported starting from the Mender client version 4.0. For server-side support duration, please refer to our blog post.
The maximum expire time in seconds after startup for an update control map. The value provides an upper bound on the update control map expire time after system startup. Defaults to 600 (10 minutes)
This option is not supported starting from the Mender client version 4.0. For server-side support duration, please refer to our blog post.
The polling interval at which the client checks for new control maps once the deployment has started to take place. This influences how quickly will the device respond to continuing after a pause. It can not be higher than UpdateControlMapExpirationTimeSeconds / 2. Defaults to UpdatePollIntervalSeconds.
The log level for when the daemon is running. Note that this option will get overridden by the cli option --log-level
.
Introduced in Mender client 3.4.
© 2024 Northern.tech AS