Configuration management

This is the key functionality of qbee. Through smart grouping and configuration profiles it is possible to control thousands of devices through a defined set of configurations. One example is the definition of firewall rules or software configurations through a simple and consistent interface across different device types. The configuration engine for qbee is state based and extremely flexible. It takes a bit of practice to understand this concept but then it is very helpful and flexible. Just use nay device like a Raspberry Pi and our free trial to configure your firewall, ssh keys, users or even do complex package mangement.

Configuration Management with is a pull based configuration management tool. It will always converge to the defined state or give an error message. The local qbee agent on the device queries the centralized server with a set interval and checks if new configuration information is available. If not it just checks if it still complies to the current state and goes to sleep again. Otherwise it downloads the new configuration and then converges towards the new configuration. This concept has many advantages as the agent can operate and maintain configuration even if the network is down. Also devices that come later into a group (spare parts, replacements) will always get the latest configuration with latest ssh keys and user definitions. Some practical implications are:

  • configuration is only becoming valid if you commit it

  • configuration management works pull based and by converging to the defined state

  • it will take at least until the next connect interval of the agent until it receives the configuration

  • the qbee agent will report success or an error if it cannot reach its state

  • the qbee agent maintains its defined state. If a managed password or firewall setting is change manually on the device qbee will revert it in the next run (and send a log message about this). This is also true for files that are played out.

  • in very few cases the agent cannot converge to its defined state due to conflicting setup. Then an error message is displayed (for example a file is played out that does not have correct access rights, or a process should be started that does not exist)

  • This allows to update a large number of devices in a very short time. It takes 5 minutes (or one agent interval) to update one device. It also takes just 5 minutes to update thousands of devices.

In the configure menu the top selector defines for which device or group of devices configuration is applied. "All devices" will enable this for the main branch of the tree. All subsequent groups and devices that do not have their inheritance disabled will inherit this configuration. You can do multiple configuration changes at once, but it is recommended to always do one after the other.


In the image above the group "hardware devices" has inherited its settings from group "All devices". The menus are greyed out but show the configuration. By pressing the orange "Edit settings" button this inheritance can be broken. Then hardware devices (and all its group below in the branch of the tree) will inherit the new configuration. Breaking inheritance and defining new settings will cause a green "save" button to appear. New configurations need to be saved. Then an information box pops up showing all impacted groups and devices.


Here you can cancel or save. Then the configuration is written. At this point in time the configuration is not yet committed.

Always check the list of devices that are in scope

Any time new configuration is committed the system generates a list of all devices that are impacted by this. Please check if this is as expected before you continue.


First when you press the orange commit button the configuration change gets active on the server and can be picked up by the relevant devices. A pop-up will allow you to add a short comment to this commit. Then it will propagate through the targeted devices with the defined connect interval of the devices. Progress can be followed in the log window, in the log tab for specific devices or in the audit menu. This configuration change has an entry that will track this specific change throughout the device park.

You need to SAVE and COMMIT

Make sure you save configuration AND commit it. Otherwise nothing will happen (only the respective config and the commit button turn orange).

Configuration change progress can be tracked

Follow the progress of your configuration change either in "Logs" or through the "Audit" view for the specific configuration change. In audit click on the time stamp and select "show reports". These will refresh automatically.

Changes will be applied after the next agent run

Configuration can only be active after having been committed and picked up by a device after the next qbee agent run.

It is possible to import and export configurations. Either to keep track of those or to migrate settings between different branches of the tree. Pressing "export" will export the json configuration to local download. An import is done by pasting the json into the form and then pressing "import". The inheritance part of the json should be disregarded when copying across the tree. It might make sense to work on the JSON for large changes (or if items need to be deleted). We will eventually rework the UI and make it more user friendly.


Some considerations around the state based concept

The qbee agent checks with each run if new configuration is available. If so the new configuration information is downloaded. Then the agent works on converging to the defined state issuing log messages if this was successful or not. This has some implications:

  • Devices joining later will still receive all current configuration information

    This is very useful if devices are kept as spares or might not be online all the time

  • qbee monitors and keeps its state

    If a password is defined as configuration in qbee and this is changed on the device qbee will change it back any time it runs. Also, if a file is played out and monitored by qbee on the target system and it is changed there it will be changed back.

  • bad configuration can make qbee work against you

    This is not a bad thing but it needs to be understood. If a file on a device is used to store device information and written by a process on the target device it should not be monitored directly. Then it should be transferred to the device as config_original.json and then copied with an after command to config.json. If this is written by the device qbee will not correct it as long as the config_original.json is not updated within the qbee file manager.

More information about this will be given for the specific configuration topics and it is also helpful to check out some of the examples to learn more about this. Below is an example configuration for a firewall setup for all devices. The group/device selector allows a very granular definition of which devices will receive the configuration.