New features in Remote Device Fleet Manager: Web GUI, single-file updates and cloud setup guide

Based on a number of exciting use cases for new and existing customers, we’ve been steadily expanding the functionality of Remote Device Fleet Manager (RDFM) - our open source Over-the-Air update and fleet management framework.

Recent additions improve RDFM on many fronts: new fleet management capabilities, granular updates allowing for individual file updates (such as AI models or configuration files) and enhanc⁠⁠ed permission levels and mechanisms allowing to specify precisely what users can update in the system, as well as which devices can be updated by a specified user.

On top of all those changes, we have also introduced a Web frontend providing easy access to devices, packages and groups assigned to the RDFM Management Server in a friendly graphical environment.

Below, we describe the new functionalities and the scenarios they enable in more detail as well as walk you through setting up the RDFM Management Server for cloud-based use along with additional open source services for update management, database management and user management with an easy-to-configure Docker Compose flow.

Single-file artifact support

The ability to send minimal updates to your devices helps in use cases including configuration adjustments, updating model weights for AI tasks or images for containers. RDFM now allows you to create such update packages that contain a single file and a path to it, introducing single-file changes either on rootfs partitions or other partitions.

You can perform this type of update by simply running:

rdfm-artifact write single-file \
	--file "my-file.txt" \
	--artifact-name "my-artifact-name" \
	--device-type "my-device-type" \
	--output-path "path-to-output.rdfm" \
	--dest-dir "/destination/device/directory" \
	--rollback-support

Single file updates take two new parameters, compared to rootfs updates. --dest-dir describes the path to the destination on the target device and the optional (and disabled by default) --rollback-support determines whether a backup .tmp file for rollback purposes should be stored in addition to the updated file.

You can find more details in the Single-file artifact section in the documentation.

Extended permission mechanisms

Permissions to methods in RDFM’s API were so far available on two levels:

• rdfm_admin_ro - allow only reading data from RDFM
• rdfm_admin_rw - allow reading and writing to RDFM

Now we added two more levels:

• rdfm_upload_rootfs_image - allow uploading rootfs images
• rdfm_upload_single_file - allow uploading single-file updates except rootfs

On top of the permissions listed above, you can also assign specific permissions for users in relation to particular resources:

• read - lets users list devices and device groups as well as list and download packages
• update - lets users modify, add and update groups and packages
• delete - lets users delete groups and packages

These permissions are mutually non-exclusive and non-hierarchical.

For more details, follow contents of the RDFM Management Server chapter.

RDFM Management Server Web GUI

We have created a lightweight frontend that exposes most of RDFM’s Management Server’s endpoints. The resulting GUI lets users:

• List devices - show device ID, current software version, etc.
• Register new devices
• List, upload and download packages
• Create device groups
• Assign devices and packages to groups
• Assign updates to specific groups

The frontend can be easily integrated with authentication and authorization services, such as Keycloak (used in the demo in the section below).

The screenshots below present several of the main views available through the RDFM GUI.

Device list view

Device view

Device group view

Package view

RDFM cloud setup

RDFM Management Server requires a set of services in order to be fully functional, in particular:

• Authentication services for users and applications surrounding the RDFM Management Server
• A database for storing RDFM’s data regarding authentication, devices, groups, revisions, permissions and more
• A bucket for storing RDFM updates
• A server for hosting the frontend for the management server

In RDFM’s server/deploy you can find various Docker Compose recipes for integration with third-party services. These recipes and their usage is described in more detail in the RDFM Management Server documentation. One of the more complete examples can be found in docker-compose.full.yml, a recipe that relies fully on open source services:

• Keycloak - an authentication service
• MinIO - a S3-compatible storage
• PostgreSQL used by RDFM Management Server and Keycloak as a database
• nginx used as a frontend server, providing endpoints for RDFM GUI, RDFM Management API, and Keycloak authentication

The configuration for the services is stored in a single environment file - docker-compose.full.env. For testing purposes only, you can change the PUBLIC_ADDRESS to the host name of running PC, and then proceed with simply running the services (from the root directory of the repository):

# Generate sample certificates for the services
./server/tests/certgen.sh ./server/deploy/certs/ DNS.1:$HOST DEVICE no MINIO DNS.1:minio KEYCLOAK DNS.1:keycloak FRONTEND DNS.1:$HOST
openssl ec -in ./server/deploy/certs/MINIO.key -out ./server/deploy/certs/MINIO.key

# Build and download all images needed for the demo
docker-compose --env-file ./server/deploy/docker-compose.full.env -f ./server/deploy/docker-compose.full.yml build

# Run the services
docker-compose --env-file ./server/deploy/docker-compose.full.env -f ./server/deploy/docker-compose.full.yml up

Then, the RDFM GUI will be available at https://<hostname>/, where <hostname> is the name of the PC. The GUI will have two pre-defined users - rdfm-admin_ro and rdfm_admin_rw, with the same passwords and same permissions as their names. This should allow basic tests of the frontend. To test integration with devices as well, you can refer to the Testing server-device integration with a demo Linux device client section in the documentation.

When finished testing, to stop and clean up all services, run:

docker-compose --env-file server/deploy/docker-compose.full.env -f server/deploy/docker-compose.full.yml down -v

For actual deployment, all variables in the docker-compose.full.env need to be fully reviewed and adjusted - especially the ones defined within the Variables requiring modification section. This applies to variables like RDFM_OAUTH_CLIENT_SEC, RDFM_JWT_SECRET, RDFM_S3_ACCESS_SECRET_KEY, DB_PASSWORD, since they directly affect the security of the setup.

Find more details in A more advanced example of production deployment in the RDFM documentation.

RDFM Management Server is not limited to the services provided above - some (or all) of them can be easily replaced by their (e.g. AWS or GCP) alternatives:

• AWS S3 buckets can be used for update storage
• AWS Aurora can be used as a database
• AWS Load Balancers can be used to expose services and provide HTTPS

Switching to alternative services is a matter of changing the environment file and removing the no-longer-used services from the Docker compose recipe.

Set up secure, customizable cloud-based fleet management solutions with RDFM and Antmicro

The additions of a lightweight Web-based graphical interface and new permission mechanisms extend RDFM’s use cases to cater for more roles within a project. On top of this, single-file update support provides a convenient solution for minimal updates typical for edge AI scenarios.

To find out more about other features RDFM offers for fleet management, take a look at our previous blog articles describing managing and deploying updates, including delta packages in multi-OS fleets, on MCUs running Zephyr and for NVIDIA BSP updates for edge AI.

If you would like to adopt the framework to your existing AWS, GCP or other infrastructure or develop software and hardware solutions complete with post-rollout management, feel free to reach out to us at contact@antmicro.com to discuss how we can help.