Parameters

This configuration allows the definition of shared parameters and secrets which can be used in other configurations. Parameters defined on a certain level can be used by other configurations on the same level and all children levels.

Parameters and secrets can be used in other configurations by use of $(parameter) placeholders.

For example: In file distribution we can use it to select a source file or populate its template parameters with shared parameter value.

Secrets¶

Secrets work just like parameters with the exception that they cannot be retrieved once saved and will be redacted from the logs created by the device. A device will only receive values for secrets when requesting its configuration. From the API and UI perspective, only the internal reference of the secret will be returned.

For example: Setting a secret value to "abc123" (once saved), will return the secret's reference instead of its value.

The reference is just a random value used to identify the secret in qbee internal secret storage and cannot be used to guess the value of the secret.

Secrets are immutable, therefore setting a new value for a secret, will override the existing reference with a new reference value. Saving a secret reference, will keep the underlying secret value unchanged.

Extending parameters configuration¶

Parameters defined on a parent level can be overridden.

For example: Let's say that we have defined the following parameters on the "All devices" level:

• brand="My Brand"
• db-user="dbUser"

And decided that we need to change the branding only for devices under group_A. We would achieve that by setting only "brand" parameter to a new value - "Custom Brand". The result would be, that devices under group_A would now get the following parameters:

• brand="Custom Brand"
• db-user="dbUser"

Device resolved parameters (system parameters)¶

As of agent version 2024.05, the qbee agent can make use of locally resolved parameters for ease of defining configuration. Eg. if you have a fleet of devices where you want to install a certain package, but the system architecture differs, you could refer to package files throught their Package Manager defined architecture (ie. instead of my-software_1.0.0_amd64.deb you could use my-software_1.0.0_$(sys.pkg_arch).deb). This would allow you to set up the same configuration across system architectures.

The currently supported system parameters are:

$(sys.host)¶

The system hostname

$(sys.pkg_arch)¶

The package architecture as reported by the package manager of the system, eg. amd64

$(sys.pkg_type)¶

The package type for the system, eg. deb or rpm

$(sys.os)¶

The operating system of as reported by uname -s

$(sys.arch)¶

The architecture of the system as reported by the kernel (uname -m)

$(sys.os_type)¶

Canonified version of kernel name and machine. Essentially the canonified output of uname -sm.

$(sys.flavor)¶

A canonified label indicating the system distribution, eg. ubuntu_20

$(sys.agent_version)¶

The current qbee agent version

$(sys.long_arch)¶

Full kernel version identifier. Essentially a canonified version of uname -a

$(sys.boot_time)¶

The boot time of the system in Unix epoch

Example of how they are resolved locally:

sys.host=qbeedemo
sys.pkg_arch=amd64
sys.pkg_type=deb
sys.os=linux
sys.arch=x86_64
sys.os_type=linux_x86_64
sys.flavor=debian_12
sys.agent_version=2024.19
sys.long_arch=linux_x86_64_6_1_0_20_amd64__1_SMP_PREEMPT_DYNAMIC_Debian_6_1_85_1__2024_04_11_
sys.boot_time=1714117208