Adding deployment options
On our BTS and BSC hardware products we are using a stripped down read-write GNU/Linux system. Like many GNU/Linux systems there is a package manager to install additional software and to manage upgrades.
This is a great way to start configuring and modelling the system. One can adjust the network configuration for VLANs or static IP addresses, install and run additional software on the BTS itself without requiring extra equipment. But how to replicate the setup when one is deploying many devices that have a very similar configuration? Some of our Customers have opted for other approaches and use read-only systems, different ways to manage the configuration and different upgrade mechanisms.
Earlier this year we have started a project with the goal to add a new mass deployment option for our products. The goal is to have full system updates (instead of package based) with a reliable rescue system to correct problems. The main design goals were:
Cryptographically sign the upgrade so it can be applied remotely.
Upgrade an entire system on an unused partition
The system itself should be read-only and not be modified.
A reboot should erase uncommitted changes
A factory reset should remove the user configuration
Easily manage the configuration of a specific system
The biggest benefits are that with a read-only system filesystem corruption (being accidentally by the user or the system itself) is less likely to occur and more easy to recover from, when managing many systems it is easier to verify that all of them run the same software and they can all be upgraded with the same command. This is easing mass deployment and administration of the system. Customers will be able to install their own cyrptographic keychain and continue to create the images they need. We have started to use an early version and will make the new system generally available throughout Q4.