Unlike Enterprise Linux infrastructures which live on servers with modular components, IoT devices are single-board computers with all the functionality baked directly in. The have limited horsepower and connectivity in relative comparison. Hardware drivers, power & network connectivity present unique challenges as IoT devices can live in inaccessible, remote locations- which also imply they be engineered with ultimate reliability. IoT devices also present security challenges because they can live in locations which can’t be secured.
Networking:
Due to their remote placement, IoT devices frequently require wireless connectivity: WiFi and/or GSM. You’d be lucky if you don’t have driver issues with the radios. WiFi access is a double-edged problem: allow your devices to connect, but not unauthorized users. Then there’s the issue of potential signal interference by other wireless devices in the vicinity. Networking must be solid and absolutely reliable or the IoT device cannot upload its’ data, and you cannot remotely access it. GSM is an option, but undesirable due to cost and remotely access devices. IoT devices generally require some creative networking. So there’s the host networking on the Linux IoT device and the Wireless Router configuration. Being a Linux Engineer isn’t enough to deliver the required connectivity: network engineering skills are additionally required.
Power:
PoE could be an option, but if it’s not- and frequently it’s not– now the device has to be powered by a battery which is topped-up by solar power. No “A” and “B” power feeds like in a data centre. And the power must be ultimately reliable to preclude flapping- constantly rebooting due to power loss- which could corrupt data.
Security:
Frequently IoT devices live outside of our physical custody. If proprietary data- or certificates for EAP-TLS WiFi connectivity- live on the device, it’s a huge potential security problem. Then the data has to be protected in transit to preclude compromise. The IoT device itself could be stolen and anybody with physical access to a host can gain root access and see how it’s configured.
As you can see, there are a lot of issues developing IoT solutions that one does not encounter in Enterprise Linux infrastructures. Delivering a great solution requires strong overlapping Linux & Network Engineering experience. Read the case study to learn how F1Linux surmounted many unique & complex issues to deliver a great solution
IoT: Industrial Sensors
The Client’s project required translating complex network configuration requirements into an automated setup of a Linux router used by IoT sensors to push their raw data up to the Cloud for processing. It was impractical to expect equipment installers to adapt each router to site-specific connectivity conditions. Configuration was reduced to providing some basic information in a variables file and executing a single bash script “install.sh” which sourced the variables file.
Some of the functionality delivered by the system produced by F1Linux:
– Self-Configuring Interfaces: Serial, WAN & GSM connections auto configure w/out user input
– Default Route Toggling Between WAN & GSM Interfaces
– Access Point: Auto subnetting of IP pool & auth for AP clients and 802.11 connectivity configuration
– Security: Restriction by both Mac Address white-list and FW rules
– Package Mgmnt: Add/subtract packages to build via a simple list in a text file
– Hardware Reliability: Persistently disable Power Mgmnt on both USB interfaces & (WiFi) radios
– Power-Cycle USB Ports: Re-establish connectivity remotely to USB devices connected to gateway
– Centralized Config: A single file containing all variablized parameters sourced by all scripts
– Modular Design: Scripts organized by function and called in turn by install.sh
– Almost 100% Auto-Configuring: No deep knowledge of Linux or networking required by staff to config router
After each function was completed, 8Power’s lead developer would clone the GitHub repo to test it. After validating it worked correctly, reliably & performantly he’d sign-off on the function and I’d begin work on the next.
Worked under a huge time pressure to deliver the required automation for a demo Client was delivering in Europe.
www.F1Linux.com lives on an IoT device, although direct powered by mains and using Ethernet connectivity.
This website is actually (3) applications- MariaDB, WordPress & Nginx as a proxy- running as isolated Docker containers on a Raspberry Pi 4 with 8GB memory with a full 64bit Linux OS to access that additional memory. The picture on this page illustrates the solution.
Because all the libraries each application requires are containerized with it, Upgrading in-place posses less risks of versioning conflicts between libraries.
To create data persistence and avoid frequent writes trashing the Pi’s MicroSD card, on boot each Pi auto-mounts iSCSI LUNs exported from RAID 1 network storage and Docker in turn loads the chunks of iSCSI storage as Docker Volumes in each of the containers. All Ethernet networking is Gigabit speed and the radios WiFi networking have been disabled.
Each Pi running Docker is configured to route both IPv4 & IPv6 traffic to/from the containers and is connected directly to an Internet gateway which firewalls the traffic to the Pi Docker Hosts & DNATs the IPv4 traffic.
F1Linux believes that it’s right one eats their own dog food by publicly facing a solution to validate its’ performance & security before implementing for a Client. Agreed, one couldn’t host Google or Amazon on such configuration, but for this use-case it’s perfectly elegant.