DEVICE.FARM Generates Raspbian/Armbian Docker Images for about 100 Arm Linux SBCs

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 website

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.

device farm orange pi zero
Click to Enlarge

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.

device.farm docker image for SBCIt will take a few seconds or many a minute to generate the image, which you can then download, or flash with BalenaEtcher or other similar utility.

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.

DEVICE.FARM Docker Running Web Browser
Click to Enlarge

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.

Support CNX Software - Donate via PayPal or become a Patron on Patreon
Advertisements

5
Leave a Reply

avatar
1 Comment threads
4 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
4 Comment authors
zoobabwillyNone NeededPavel Burgr Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
willy
Guest
willy

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 without having to tell each and every identity providers what you’re doing when and why.

Pavel Burgr
Guest

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 image. That’s how it works.
To explain why it is need to log in: Linux image generator is only half of the story. The second part, even more advanced (and challenging in terms of security) is the VPN upstream link to DEVICE.FARM, which allows you to access your device even if it is behind firewall. You can expose services (web user interfaces, APIs) from your Docker containers under URL accessible from internet. DEVICE.FARM then acts as proxy with authentication mechanism, so you are asked to log in if you want to access your device remotely.

willy
Guest
willy

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 builds. It’s just that it definitely is not something I’d use.

zoobab
Guest

I stopped at the login box.

None Needed
Guest
None Needed

As usual, Balena needs analytics.
https://github.com/balena-io/etcher/issues/2497

Advertisements