Last year, I reviewed BalenaOS and BalenaCloud on Raspberry Pi CM3L based BalenaFin hardware. The solution generates OS images with docker support in order to easily manage and update a fleet of devices remotely over a web interface or client program.
Balena.io supports over 60 boards either officially, or thanks to the work of the community, but Pavel Burgr is developing an alternative with DEVICE.FARM supporting close to 100 Arm SBC’s including Raspberry Pi boards, and most Armbian supported Arm SBC’s.
DEVICE.FARM is still beta, but the MVP (Minimum Viable Product) version of the website provides:
- Customized images for supported boards (currently 94 boards)
- Preinstalled docker
- Secure remote access to the device’s docker end-point
- Secure remote access to the device’s services exposed by containers
This is functional, but bugs are likely, and documentation still needs to be finalized. I don’t have a board with me, but I tried to generate an image for Orange Pi Zero SBC.
Once you click on any of the board from the list, you’ll be asked to login with Facebook, Google, Github, or via SSH key.
After login, I could get to the Linux image configuration page, where I gave a name for the device, set a root password (one is also automatically generated), select whether you want to connect through Ethernet or/and WiFi with fields to enter the access point credential. You can also overwrite files from the root file system. Note that Raspberry Pi relies on Raspbian Buster Lite and other SBCs on Armbian headless images. Click on the “Register device and build the image” button for the next step.
You’ll also be provided a list of CLI commands to perform several actions including:
- Deploy your first container (busybox httpd webserver)
- Install DEVICE.FARM command-line utility (written with node.js)
- Drop to shell with proxy to docker endpoint
- Local SSH access via root user using mDNS
[Update: here’s a screenshot showing several ONLINE/OFFLINE devices and how easy it is to access a container’s service from the internet since once the container is tagged with “farm.device.services” label, DEVICE.FARM creates a HTTP proxy link from URL in form https://<service-name>-<device-id>.device.farm to the container.
This is achieved by a VPN link (openconnect) initiated by the device. and explains why user authentication is required. This way users can securely access devices remotely such as home automation system, 3D printer’s Octoprint UI, or disk storage…]
Check out the website to give it a try.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
The principle looks interesting, but I’m seriously wondering how we can be sure the entered information are *NEVER* stored on their side so they cannot be stolen ? I mean, you have to give a root password for a device that will be attached to a WiFi network whose password you also give. If this service gains in popularity, this may constitute a very interesting target for some dataleak attacks. Also I don’t understand why you have to log in to perform such operations there. You could also just get a download link just like others such as nodemcu-build.com do… Read more »
Willy I can understand your concern about security of entered credentials. Unfortunately the service is not open source yet (but most likely will be in future), so only I can tell is, that the builder keeps credentials on server side for minimum possible time, which is few tens of seconds of Linux image customization (or more if there are other builds in queue). Then credentials are removed, but they still exists in the built image, waiting for download. Once the image is downloaded, it gets deleted from server storage – you can test it by second attempt to download the… Read more »
I understand the challenge posed by the way images are built, but I think you instead should do like most SBC vendors, and use a default simple password that must be changed on first boot. If you ask the user a password, you can be certain they’ll put the definitive one to simplify their deployment. Also I was not aware of the “other part of the story”, which can definitely make sense for this use case. Still for those who only want an image it’s overkill. But I can also understand why you would avoid seeing anonymous users triggering heavy… Read more »
I stopped at the login box.
As usual, Balena needs analytics.
https://github.com/balena-io/etcher/issues/2497