Software management

Manage software on edge devices

Software management is a simple and efficient way to remotely manage and control Debian software packages for fleets of IoT embedded Linux devices. Download from a defined repository or overlay packages / patches from the qbee file manager. Works also via REST API.

Software management is part of the qbee configuration engine. Define which Debian packages you want to deliver via OTA software update to the full fleet or any group or single device. Then qbee will handle the packages and install them on all embedded edge devices that are in scope the next time the qbee agent connects to the system. It will also start and maintain the service such that you can be ensured that the service is always running. Here you see an example that installs the Midnight commander file manager "mc" on "group_A".


Packages can come from two different sources:

  • It is possible to play out and maintain files from repositories and/or the qbee file manager. The system distinguishes between them by checking if there is a package ending. So a debian package with name "node-red" will be fetched from any of the repositories that are configured for the Linux system.

  • A package that has a debian compatible file name and a .deb package ending will be installed from qbee's internal file manager. For more information please see below. If the package defines a service qbee software management will automatically restart the service after any update.

Where do the Debian packages come from?

Debian packages defined by the service name and no ".deb" ending will be provided from the configured repository on the target device.

Packages that do have a debian compatible naming convention and a ".deb" ending will be provided by qbee from the file manager. Please use the full source path if directories are used in file manager.

If a service is defined it will be restarted after the update or after any key-value template changes. If the service name differs from the package name it can be provided.

For a specific version of a file the full package name can be used (with or without ".deb" depending if it is from a repository or file manager)

qbee works with strict Debian naming conventions

It is important to adhere to the debian naming convention for this to work.
A typical example is the chromium_83.0.4103.116-3.1_arm64.deb Chromium package. Or, in a more general notation: package_version_architecture.deb
Sometimes packages have a wrong name. They use for example name-0.0.3-all.deb. These need to be renamed or you will get an error. A very useful check for correct file name is to run dpkg -I package.deb. This will show the meta information for the package and this is how the file should be called. In the example below we run dpkg -I chromium_83.0.4103.116-3.1_arm64.deb and get the following output. Relevant name parts are highlighted in red: !finding-dpkg-meta-information

If you need to change your package name or meta description you can do this as described here.

Use your own packages and distribute them from qbee's file manager

qbee provides a file manager and storage to upload own files. Therefore you can easily distribute, install and run your software packages.

This is also helpful as a repository overlay. Imagine you use a standard Raspbian repository but want to provide your own software. Simply upload to the file manager and install from there. The same can be done if you need to patch a OS library from a standard repository. Just install the patched version from qbee and you don't need to worry about how to get this into the repository or operate your own repository.

Below is a more complex example that automatically installs a package for a Tinymesh sensor system remotely to handle the radio communication and cloud connection. This debian package tinymesh-agent_0.0.3_all.deb is installed from the file manager storage space "/tinymesh" and then moved to each edge device in scope of the "group_C" group. Also a template file called tinymesh-agent-conf.tmpl was uploaded to "/tinymesh". It gets resolved into the final configuration file for the tinymesh package with the following path on each of the target systems /etc/tinymesh-agent/tinymesh-agent.conf.


What happens here is that original config file tinymesh-agent.conf is transposed into a templating file. Any key-value pair that should be exposed is replaced by a mustache notation with the double curly brackets.

username = "my_username"
password = "my_password"
server = ""
port = 14819
tls = 0

[LPWAN system]
system-id = 12

Now it is possible to access one or all configuration options of this file remotely. Please rewrite this file into the template file tinymesh-agent-conf.tmpl. Then all configuration parameters that are in scope need to be exposed with {{your_key}} to expose them as key-value in the UI.

username = "{{username}}"
password = "{{password}}"
server = "{{server}}"
port = "{{port}}"
tls = 0

[LPWAN system]
system-id = {{system-id}}

Committing this configuration will then trigger all remote devices in the "group_C" group to install/upgrade the package (if this has not been installed yet) and then configure the new key-value pairs. It will also restart the service for any configuration change. In the case of the example above the audit trail shows that 2 devices have received this update already. They download the changed template file tinymesh-agent-conf.tmpl. Then the variables are applied to the real configuration file /etc/tinymesh-agent/tinymesh-agent.conf. As a last step the application * tinymesh-agent_0.0.3_all.deb* is restarted to apply the new configuration.