PIMOD: A Tool for Configuring Single-Board Computer Operating System Images
Jonas Höchst, Alvar Penning, Patrick Lampe, Bernd Freisleben
PPIMOD: A Tool for Configuring Single-BoardComputer Operating System Images
Jonas Höchst ∗† , Alvar Penning ∗ , Patrick Lampe ∗† , Bernd Freisleben ∗†∗ Department of Mathematics & Computer Science, University of Marburg, Germany{hoechst, penning, lampep, freisleb}@informatik.uni-marburg.de † Department of Computer Science / Electrical Engineering & Information Technology, TU Darmstadt, Germany{jonas.hoechst, patrick.lampe, bernd.freisleben}@maki.tu-darmstadt.de
Abstract —Computer systems used in the field of humanitariantechnology are often based on general-purpose single-boardcomputers, such as Raspberry Pis. While these systems offergreat flexibility for developers and users, configuration anddeployment either introduces overhead by executing scripts onmultiple devices or requires deeper technical understanding whenbuilding operating system images for such small computers fromscratch. In this paper, we present PIMOD, a software tool forconfiguring operating system images for single-board computersystems. We propose a simple yet comprehensive configurationlanguage. In a configuration profile, called Pifile, a small set ofcommands is used to describe the configuration of an operatingsystem image. Virtualization techniques are used during theexecution of the profile in order to be distribution and platformindependent. Commands can be issued in the guest operatingsystem, providing access to the distribution specific tools, e.g., toconfigure hardware parameters. The implementation of PIMODis made public under a free and open source license. PIMOD isevaluated in terms of user benefits, performance compared to on-system configuration, and applicability across different hardwareplatforms and operating systems.
Index Terms —Single-Board Computer, Operating System Im-age, System Provisioning
I. I
NTRODUCTION
When applying technology in the humanitarian field, it isparticularly important that the equipment used is availableand that the installations are traceable and maintainable bythe user groups. For this reason and for reasons of low cost,single-board computers (SBCs), such as the Raspberry Pi, areoften used as the basis for research and especially for practicalapplications. Various use cases have been posted, where suchdevices are key enablers for the proposed solutions, be it tech-nical or general education [24], [27], monitoring of technology[25] or monitoring in the health care sector [16], or variouscommunication technologies [1], [2], [20].When dealing with single-board computers, either for soft-ware development or when deploying hardware based onthese boards, there is a lack of support for creating operatingsystem (OS) images. There are several cases in which readilyconfigured images and use case specific distributions need tobe distributed to users or operators. Devices like a RaspberryPi are used at home, in applications for multimedia centersor smart homes, but also in challenging applications such as emergency response, environmental monitoring, Internet-of-Things (IoT), and smart city infrastructures.Single-board platforms that do rely on an operating systemregularly use images provided by vendors or third parties.Typically, an image is flashed to an SD card and then bootedin a system. Since there is no installation process, the OSesheavily depend on defaults, e.g., username, password, installedsoftware, or on scripts executed on the first boot, e.g., cryp-tographic parameters or partition size adjustments. Softwarecan then be installed and configurations can be adapted in therunning system. While this seems to be convenient for singledeployments and fast progress compared classical installationroutines, it is not suitable for larger deployments.When custom software and additional configurations needto be added to an OS image, this can either be achievedby a) creating an OS image from scratch, b) adding scriptsto be run on the first boot, or c) create an image from apreviously configured system. However, these methods eachhave their individual drawbacks. Bootstrapping images fromscratch requires deep technical understanding. When using firstboot scripts, a network connection is required on this firstboot. Creating an image from a configured system requiresadditional steps to revert OS specific first boot configurations.In this paper, we present PIMOD, a tool for modifyingan existing operating system image by executing commandsdescribed in a configuration file. In the proposed line-basedconfiguration, a
Pifile , i.e., a small set of commands, canbe used to describe how an image will be created. Thesecommands are then interpreted by PIMOD and executedaccordingly. In our approach, the target image is based onan existing image, it then can be resized, and files from thehost system can be included in the image. The special
RUN command allows running commands inside the image, so thatguest OS specific packet managers and configuration tools canbe used. Our approach can easily be used with continuousintegration (CI) systems and enable reproducible builds ofsingle-board computer operating system images. The softwareas described in this paper is released under the free and opensource GPL-3.0 license and is available online . https://github.com/nature40/pimod/ a r X i v : . [ c s . O S ] O c t o summarize, we make the following contributions: • We propose a novel method of configuring single-boardcomputer operating system images. • We present a simple yet comprehensive operating systemimage configuration language. • We provide a free and open source implementation ofPIMOD. • We conduct an evaluation of PIMOD in terms of userbenefits, performance, and language flexibility.The paper is organized as follows. Section II discussesrelated work. In Section III, we present requirements anddesigns decisions. Section IV discusses implementation issues.Section V presents experimental results. Section VI concludesthe paper and outlines areas of future work.II. R
ELATED W ORK
In general, single-board computers (SBCs) use operatingsystem images provided by a) the hardware vendor, b) a thirdparty operating system distributor, or c) a software provider,bundling up its software and dependencies to create a software-specific distribution. The images are flashed to a SD card andthen booted on a SBC. Since there is no installation process,the OSes heavily depend on defaults and can only be adaptedby running them and changing software or configurations.As a first option, use case specific images can be created byusing the tools provided by the SBC vendor, such as pi-genprovided by the Raspberry Pi Foundation [23] or alternativeapproaches [15]. The tool is designed to create images fromscratch and highly adjusted to the specific use case. The opensource wireless router distribution OpenWRT features its ownbuild system [8]. This build system is created modularly,and own packages can easily be integrated into the buildprocess. In addition to build images from scratch, the authorscreated an image builder, specifically targeted for OpenWRT,which installs precompiled packages to an image. However,the image builder is targeted specifically for their operatingsystem and does not work for others. These tools often resultin long execution times, since all components are installed oreven cross-compiled from scratch.The second available option consists of tools that addcustom scripts to be executed on the devices itself. WithPiBakery, a graphical configuration interface for Raspbian isprovided, which then creates scripts that are executed on thefirst boot or on every boot accordingly [9]. Some distributionsuse the first boot for configuration, e.g., ssh keys in the caseof Raspbian, which need to be taken care of manually [22].These tools have the drawback that, e.g., requested softwareneeds to be installed on every device independently, whichresults in multiple identical installation processes that maylead to high network overheads. The approach also lacks thepossibility of being integrated into Continuous Integration (CI)build systems.The third widely available option is to use an existingSD card with installed software and a finished configuration.While this is a straightforward approach, it can hardly be automated. To be storage efficient, the copied image, includingthe partition table and file system, would need to be shrinked,which requires additional tools, such as PiShrink [6].When dealing with configuration of systems, Docker is awell known virtualization system, designed for dependencymanagement and containerization of applications [18]. Dockerfeatures a simple imperative configuration language. A newimage is built based on an old image and extended by copy-ing files, altering a Docker specific configuration or runningcommands inside the container. When using Docker to provideand install software, it is necessary to install Docker and thecorresponding software images on the live system. Therefore,this approach does not overcome the problem of multipleinstallations on individual devices and does not offer a fulloperating system image.For configuration management tools like Ansible [12], Salt-stack [13], and Puppet [17], the main concept is to have acentral server that ships a configuration to every node. Thenode then adapts the installed system in the manner definedin the configuration. This method has the drawback that ituses more network resources because every single node hasto download updates and the installer for itself. Also, the nodeshave to be booted so that the first boot scripts are executed.The possibility of configuring and reconfiguring a runningsystem is quite helpful, but we focus on the creation of fullOS system images with preinstalled and configured software.Furthermore, the client part has to be installed on every singlenode, and the master node has to run when a new node shouldbe configured. III. PIMOD D
ESIGN
The goal of PIMOD is to facilitate the creation of single-board computer operating system images with custom soft-ware in an easy and reproducible manner and simplify thedeployment of such devices. To reach this goal, a simple yetcomprehensive configuration language is provided, which isinterpreted to modify a system image. The language should bemanageable through versioning systems to support the over-all goal of reproducibility. A generic configuration languagecannot rely on distribution-specific configuration parametersand thus should provide an interface to the distribution’sconfiguration mechanisms. With PIMOD we target Linux-based operating systems, which are widespread in severalcommunities using SBCs [3], [14].
A. The PIMOD Language
In this section, the PIMOD language used in a Pifile ispresented. To reach the goal of easy learnability, the languagewas inspired by the Dockerfile language, which is alreadywidely known. A Pifile is a line-based document where eachline may either contain a) an empty line that may containwhite space, b) a comment indicated by a hash symbol, c) aPIMOD command written in caps followed by parameters. a) FROM
The required sourceparameter declares a base image to be found in the local filesystem, a block device to create an image from, or an URL toe downloaded and extracted. Optionally, the partition numberresized and mounted in the further process can be declared. Itdefaults to the second partition, since most operating systemsuse one boot as one system partition. b) TO
When a Pifile is executed,the resulting image is written next to the Pifile and named afterthe respective Pifile. The image destination can be changed byrunning the TO command. When a block device is specified,the defined source is written to the respective device andfurther commands are executed directly on the device. c) INPLACE
INPLACE command,an image can be specified on which the commands areexecuted. d) PUMP
Using the
PUMP command, theimage is increased by the given amount of bytes, SI prefixessuch as k, M, G or, T are supported. e) PATH
By default, the local
PATH vari-able of the host system is used inside the guest system. Withthis command, it can be extended by another location. f) RUN
Commands specified using the
RUN command are executed inside of the operating system image.Note that the operating system of the image is not started, butthe run time environment of the target system is modeled. g) INSTALL [mode]
Installingcustom files from the host system is especially useful whencustom software is used, or for configuration purposes. Thesource parameter relates to a file in the host file system, thedestination describes a path in the file system of the targetsystem. The optional mode parameter can be useful wheninstalling executables, e.g., cross-compiled software. h) HOST
When a command is specified usingthe HOST command, it is executed on the local system ratherthan inside the image. Issuing a local command can especiallybe useful for preparing configuration files or cross-compilingsoftware, which later is installed to the guest system.In Listing 1, a Pifile is presented that features all commandsof the PIMOD language. Line 1 defines a source image to befound in the local file system and the partition to be resized andmounted as the primary system partition. In Line 2, we declarethat the file should be written to an alternative location. Line5,
PUMP 100M , causes the image and the second partitionto be increased by 100 mebibytes. In Line 8, a distribution-specific configuration tool is used to enable the serial consoleavailable at the target hardware. Line 11 and 12 are used toupgrade the operating system by first updating the sourcesof the packet manager and then running a distribution update.Note that in Line 12 an environment variable is set by runningthe command inside a bash shell. Finally, in Line 15, a sshpublic key is copied to allow remote login.
B. Linux Support
The Pifile language is designed to be a simple yet com-prehensive operating system image configuration language.To reach this goal, some assumptions were made during thedesign phase. First, to enable fast execution of Pifiles, we donot want to use full system emulation, which would result FROM TO raspbian-buster-upgraded.img PUMP RUN raspi-config nonint do_serial 0 RUN apt-get update RUN bash -c ’DEBIAN_FRONTEND=noninteractive apt-get -y dist-upgrade’ INSTALL id_rsa.pub /home/pi/.ssh/authorized_keys
Listing 1: PIMOD example 1: upgrade Raspbian and enable the serial console. in booting the guest system kernel. This would have thedisadvantage that, e.g., the first boot scripts of the distributionwould be executed and other parameters would be initialized,such as cryptographic keys, as discussed in the introduction.We decided to use a QEMU-based system emulation, whichallows us to execute Linux ELF binaries across multipledifferent instruction set architectures [4]. Second, especiallymounting the partitions of the image according to the distribu-tion requires specific knowledge, which is hard to generalize.Therefore, we decided to use the file system table definedby the Filesystem Hierarchy Standard, /etc/fstab , whichitself is used by many Linux operating systems. Third, theexecuted binaries are searched according to a path variable,which itself is distribution specific. In PIMOD, this variableis initialized from the host system and can be extended byusing the
PATH command in a Pifile.
C. Continuous Integration Support
Continuous Integration (CI) is a technique used to overcomeintegration problems in the development cycle during softwareengineering. It has been shown that continuous integrationimproves the productivity of project teams and boosts theintegration of external contributions without a reduction incode quality [26]. When combining version management andmodern CI systems, every commit of a software under devel-opment is automatically integrated into a larger context andtested. PIMOD is designed to be used in combination withCI to create software-specific operating system images in areproducible and easy manner.
D. Host System Support
Another goal of our approach is extensibility, such that itcan be integrated into workflows of the communities using
S Image ———————————————————+ FROM, TO, INPLACE——————————————————— copy image ———————————————————+ PUMP——————————————————— increase image spaceenlarge partitionexpand file systemloop mount, bind mount, chroot ———————————————————————+ PATH, RUN, INSTALL———————————————————————
Stage 1: Setup Stage 2: PrepareStage 3: Chroot
Fig. 1: Stages of PIMOD: preparation, commands, and post-processing.
PIMOD. Thus, the configuration language should provideoptions to interface the host system. One option to enableinterfacing in this manner is the already described
HOST command. In addition, users should be able to use environmentvariables defined in the host system and program a controlflow. IV. I
MPLEMENTATION
The target of modifying system images and executing codeinside of a system image can be achieved best by using systemtools. GNU/Linux ships several helpful tools for the individualtasks implemented by PIMOD. To make use of and integrateexisting tools in a simple manner, PIMOD was implementedusing the Bash programming language [21].The interpretation of a Pifile is implemented in severalstages, since some commands can only be executed afterothers, as shown in Fig. 1. We define three stages to whichthe commands are assigned: First, setup , managing the
FROM , TO and INPLACE configuration. Second, prepare , handlingchanges of the image itself, currently only depicting
PUMP .Third, chroot , covering all commands interacting with thefile system of an image, namely
RUN , PATH and
INSTALL .During the execution of a Pifile, it is actually executed onetime for each stage, only executing the commands belongingto the individual stage. This mechanism insures that sourceand target are defined before resizing an image, which itselfneeds to happen before modifying content on the guest.
A. Stage 1: Setup
In the setup stage, the
FROM , TO , and INPLACE commandsare executed, checking and setting source and destinationsystem images.
FROM is not only able to handle local images,but can also download images from a remote location byspecifying an HTTP(s) or FTP URL. A local cache minimizesnetwork load and timely overhead. When no destination isdefined via TO , it is derived from the name of the Pifile.The stage is concluded by copying the source image tothe destination location. In the special case of an identicalsource and destination path and when using INPLACE , themodifications are executed in place.
B. Stage 2: Prepare
The stage implements the
PUMP command. Enlarging animage requires to a) increase the image file size, b) enlargea partition inside the image, and c) expand the file systemsto the size defined by the partition. These subtasks are im-plemented using the GNU/Linux utilities dd , fdisk , and resize2fs . C. Stage 3: Chroot
Before executing the
RUN and
INSTALL commands imple-mented by this stage, some preparations need to be taken: first,the system image file is associated with a loop device of thehost system. Then, the main partition’s file system is mountedinside the host system. A working chroot environment requiressystem interaction, which can easily achieved by importing /dev , /sys , /proc and /dev/pts using a bind mount.The network interfaces are available through the host systemkernel, the domain name system configuration is done bybind mounting /etc/resolv.conf . After this step, thestatically linked QEMU binaries for the supported platformsare also bind mounted in the chroot environment. Ultimately,additional partitions defined in the file system table of the guestsystem are mounted. INSTALL is implemented by copying therequested files to the target file system and optionally adjustingthe permissions. Running a command inside the target imageis easily achievable using chroot: a command is executed ina specified root directory and thus using all binaries, librariesand resources of the mounted image.
D. Continuous Integration
PIMOD is designed to work in combination with continuousintegration services. We provide an example integration fortwo different CI services. Travis CI is a free and open sourceCI service, which has been shown to be used by a widevariety of software projects [5]. GitHub Actions is a CI serviceintegrated with GitHub, a software hosting platform, widelyused for Open Source projects [7]. In both integrations, first thedependencies need to be installed, then the resources, such as abase image are downloaded, and finally the Pifile is executed.The output of PIMOD is presented inside the web interfacesof the individual service. Also, both implementations offerthe possibility to release the created image in the form ofa downloadable image. Hence, the developers of a use casespecific distribution can test their progress locally and tag aspecific git commit. This indeed triggers a cloud build usingthe discussed CI integration and uploads an image to thecorresponding releases web page. Our example integration isalso available free and open source in a separate repository and can easily be forked and adapted. https://linux.die.net/man/8/resize2fs https://github.com/nature40/pimod-ci/ . E VALUATION
In this section, we evaluate PIMOD. First, the benefits ofusing PIMOD from the view of a sensor network operator arediscussed. Then, the performance of the approach is evaluatedby comparing execution times of exemplary commands. Third,the generalization of PIMOD is investigated by testing thesoftware with Linux OS images of different distributions andmade for different hardware.
A. PIMOD vs. Manual Integration
The first goal of PIMOD is to facilitate the modification ofsingle-board computer operating system images and therebysimplify deployment. We evaluate this goal by discussing theuse case of deploying nodes in a sensor network scenario.The deployment of such sensor nodes can be done in differentways. A straightforward approach would be to repeat thedeployment on each node manually. First, a chosen operatingsystem is installed, then the operator connects to each node,installs dependencies and software, and configures the system.A more complex yet more efficient way would be to installonly one system by the steps presented above and clone thisinstallation to the other systems. In some cases, the operatorwould need to manually alter some configurations, done duringthe first boot. This, however, requires the appliance to beconnected to a fast Internet connection and checks on everydevice that the initial scripts did run correctly. The thirdalternative for the operator would be to build the systemimage by him- or herself and execute the required steps in theprocess. This would, however, require a deep understandingof the build process of an operating system, which can taketime to understand and which itself takes a certain time toexecute. In addition, some software build systems require vastamounts of resources, e.g., TensorFlow, a machine learningtoolkit. Building the software requires certain tricks, e.g., swappartitions to allow for larger amounts of memory, which canbe circumvented using more powerful hardware. With PIMOD,the operators can create a configuration file in which all therequired steps can be described. The resulting Pifile can thenbe executed either locally resulting in an image to be flashedor integrated into a CI system, e.g., to build and upload animage to a certain online location. The approach can also beused to write the resulting image to a SD card, e.g., to writedevice-specific configuration files.
B. Performance Evaluation
To evaluate the performance of PIMOD, multiple examplecommands are executed on a single-board computer andusing PIMOD. The experiments presented in Table I wereexecuted on a Raspberry Pi 3 Model B V1.2 that consistsof an ARM-Cortex-A53 with 4 cores of 1,2 GHz and 1 GBRAM. For storage, a Samsung EVO Plus 32 GB microSD ofUltra High Speed (UHS) class U1 was used, which allowsread speeds of 95 MB/s and write speeds of 20 MB/s. Theexperiments of PIMOD were conducted on a x86_64-basedserver featuring two Intel Xeon E5-2698 CPUs, a total of256 GB RAM. Storage was realized using a NVMe-based T i m e ( s ) o p k g u pd a t e o p k g i n s t a ll h tt p h tt p s a p t - g e t u pd a t ea p t - g e t i n s t a ll o f = / d e v / nu ll o f = m . b i n A E S Raspberry Pi PIMOD
Fig. 2: Example executions times of different commands using a RaspberryPi compared to PIMOD.
Intel SSDPEKKW512G7, with 512 GB storage and a readand write speed of up to 1775 MB/s and 560 MB/s. All testswere repeated 5 times and averaged. Although the systemsthemselves are quite different in terms of performance, we tryto mimic a build server that might be running in a continuousintegration pipeline.In Table I, the runtimes of various commands on dif-ferent operating systems are presented, namely OpenWRTand Raspbian Buster. With opkg update and apt-getupdate , the individual packet managers update the list ofavailable packages. The OpenWRT packet manager introducesa small overhead using PIMOD compared to native execu-tion. Updating the package list consists of downloading thecompressed lists and verifying the signature, especially thelatter requires many ARM instructions to be simulated onthe x86_64 hardware and therefore introduces some overhead.Installing software using opkg is faster on the native hardwarecompared to PIMOD, which is mostly related to the used gzip compression executed through qemu .When looking at Raspbian Buster’s packet manager apt ,PIMOD achieves better runtimes compared to native execu-tion, for both updating the package. One reason for this isthe much faster write speed of the desktop system comparedto the microSD card of the Raspberry Pi. Since OpenWRTis designed for low footprint systems, such as routers, thepackages are relatively small compared to the respectiveRaspbian packages, based on Debian and designed for desktopclass computers. For the wget examples, the downloaded datais not written to disk, and thus only shows the performanceof the networking stack. Downloading the file using HTTPshows the superiority of the build server, only requiring atenth of the time compared to native execution. Since mostbuild servers do have larger than 1 GBit/s Internet connections,
ABLE I: Example executions times of different commands using a Raspberry Pi compared to PIMOD.
Operating System Command t RasPi t PIMOD
Overhead
OpenWRT opkg update opkg install python wget -O /dev/null http://host/100m.bin wget -O /dev/null https://host/100m.bin apt-get update apt-get install -y python3 dd if=/dev/urandom of=/dev/null dd if=/dev/urandom of=100m.bin openssl enc -aes-256-cbc the runtimes can be up to 10 times as fast compared to aRaspberry Pi limited to 100 MBit/s. However, when using thesame protocol with TLS encryption, the cost of encryptionand decryption adds an overhead of 13.6%. In the examplesusing dd , 100 MB of random data is read using the com-mand dd if=/dev/urandom bs=1M count=100 . Thecomputations needed to generate the data happen in the kerneland thus natively on both systems. When discarding the datausing of=/dev/null , no heavy computation is required andPIMOD performs better, because the main load happens in thekernel of the host. From the runtimes of the second examplepresented in the table it becomes evident that for read/writeintensive tasks, the disk is the bottleneck; the overhead gainof 91.24% is comparable to the download task. In the lastexample, data is read from /dev/urandom and encryptedusing the OpenSSL AES encryption. The speed advantage ofPIMOD fades, since the computationally intensive encryptionis performed through the QEMU emulation layer. Neverthe-less, our approach is still around 30% faster compared to nativeexecution. C. Testing Linux Distributions
To test the generalization properties of our approach, twodirections are important: hardware and operating system vari-ety. In our tests using the well known Raspberry Pi, we wereable to use PIMOD for the widespread Debian-based operatingsystems, such as Raspbian and Ubuntu Server, as well asOpenWRT, CentOS, Fedora, Kali, and OpenSUSE. Androidas well as NixOS did not implement the Filesystem HierarchyStandard and therefore do not satisfy our assumptions. PIMODcan be adapted to work with both distributions, but a general-ization is not easily feasible. In addition, we evaluated differenthardware platforms using the operating system recommendedand distributed by the vendor. In our tests, we found thatPIMOD can be used with the Libre Computer boards ALL-H3-CC, AML-S805X-AC and ROC-RK3328-CC, BananaPi M4,Nvidia Jetson Nano (AI development board), ODROID C2 andN2, OrangePi 3, all models of RaspberryPi, and the RockPi 4.Most of the operating systems distributed by the vendors areDebian-based and include specific changes for the individualboards.
D. PIMOD Language Flexibility
One secondary design goal was to support flexibility for theusers of PIMOD. The presented tool is written in the Bashscripting language, a Pifile itself is a script sourced in theindividual stages. Thus, in a Pifile all features available inBash scripts can be used. PIMOD’s flexibility features willbe discussed by the examples presented in Listing 2, therespective output log is shown in Listing 3. FROM http://downloads.openwrt.org/releases/18.06.5/targets/brcm2708/bcm2710/openwrt-18.06.5-brcm2708-bcm2710-rpi-3-ext4-factory.img.gz TO $DEVICE source modules/wifi.Pifile RUN tee -a /etc/dropbear/authorized_keys < $HOME/.ssh/id_rsa.pub RUN tee -a /etc/config/network << EOF config interface ’lan’ option type ’bridge’ option ifname ’eth0’ option proto ’dhcp’ EOF HOST
GOOS=linux GOARCH=arm GOARM=5 gobuild -o dtn7d ./dtn7-go/cmd/dtnd INSTALL
755 dtn7d /usr/bin/dtn7d
Listing 2: PIMOD example 2: advanced scripting with Bash features. Using cache: / var /cache/pimod/downloads.openwrt.org/ releases/18.06.5/ targets /brcm2708/bcm2710/openwrt−18.06.5−brcm2708−bcm2710−rpi−3−ext4−factory.img.gz Moving temporary /tmp/tmp.sv3nxlM9qS to sd.img add map loop0p1 (253:0): 0 40960 linear 7:0 8192 add map loop0p2 (253:1): 0 524288 linear 7:0 57344 ssh−rsa AAAA.... hoechst@ds config interface ’lan’ option type ’bridge’ option ifname ’eth0’ option proto ’dhcp’ / storage / hoechst /pimod−example/dtn7−go /storage/hoechst /pimod−example / storage / hoechst /pimod−example umount: /tmp/tmp.ampfPoR8rz/dev/pts unmounted umount: /tmp/tmp.ampfPoR8rz/dev unmounted umount: /tmp/tmp.ampfPoR8rz/sys unmounted umount: /tmp/tmp.ampfPoR8rz/proc unmounted umount: /tmp/tmp.ampfPoR8rz unmounted del devmap : loop0p2 del devmap : loop0p1Listing 3: PIMOD example 2 (Listing 2) execution log.
1) Environment Variables:
Environment variables can behelpful to adjust the build to the runtime. In the examplepresented in Line 5 of Listing 2, a block device to work oncan be specified through the environment variable
DEVICE .In Line 11, another example is shown, where the ssh publickey from the local user is added to the guest system.
2) Redirections:
Redirections of input and output streamsare a key feature in shell programming and can be helpful inour use cases. The task of adding an ssh key from the hostsystem, presented in Line 11, is implemented by appendingto a file and redirecting the input stream to a file in thehost system. The
HOME variable provides the location ofthe host system user’s home directory. A second example ispresented in Lines 14–19, where a network configuration file iswritten by using a here document . When using documents, theconfiguration resides inside of the Pifile itself, and is easily un-derstandable. Environment variables are also evaluated insideof here documents , such that device-specific configuration,e.g., a hostname, can be set using this mechanism.
3) Cross-Compilation:
For some cases, it is beneficial tocompile software on the host system, rather than running thevirtualized compiler of the guest system, especially for largersoftware projects. In the above example of Line 22, the delay-tolerant routing software DTN7 [19] is cross-compiled on thehost system by using the
HOST command and installed to theguest system afterwards.
4) Modularization:
Individual parts of a Pifile can be ex-tracted into modules, represented as independent files, that can
SSH InterfaceNetworking ToolsWireguard VPNWebserverMesh Networking
Base Sensorbox
I2C BusI2S Mic DriversCameraReal-Time ClockSensor Software
Sensorbox
MariaDBRTL SDRSignal Detection
RadioTracking
SPI BusRadioHead LibraryGPS DriversLoRa Gateway
LoRaRaspbian Buster
Fig. 3: Raspberry Pi Image configurations used for the Nature 4.0 Project be reused afterwards. In the example presented above, the Wi-Fi configuration is included from another Pifile, as presentedin Line 8. The file is included by using the source command,which executes the commands from the file in the currentscript. Thus, PIMOD offers a wide variety of interactions withthe host systems and can thereby be integrated into user’sworkflows well.
E. Applications of PIMOD
The goal of the Nature 4.0 project is to develop a modularenvironmental monitoring system for high-resolution obser-vation of species, habitats, and processes relevant to natureconservation [10]. For this use case, a set of sensor boxes hasbeen designed, each dedicated to sightly different use cases,following the same principal networking functionalities andthe same software basis, each based on a Raspberry Pi. InFig. 3, the hierarchy derived from the requirements of theproject are presented. The first box is the rather generic
Sen-sorbox , which comes in different configurations, distinguishedby the wired sensor set. It includes a camera, a microphone viathe I2S bus, sensors for temperature, humidity, atmosphericpressure, air quality, spectral brightness, and various others.The second box is the
RadioTracking configuration. Thisbox is dedicated to read and analyze data flows of foursoftware-defined radio devices per box, which point to thefour directions of the compass in order to record signals frombats tagged with special senders [11]. The last configurationis a
LoRa gateway receiving and forwarding messages ofother sensor applications via the well known long range
LoRa protocol. All images are derived from the
Raspbian
OS, in its
Buster version, which is the de facto standard for Raspberry PiSBCs. The
Base Sensorbox image contains all shared softwareand configuration, e.g., an access option via a VPN and aSSH remote shell, a web server for convenient data retrievaland management in the field, as well as a mesh networkconfiguration for sensor box interconnection.IMOD is used in the project Nature 4.0 for over a yearat the date of writing, and integrates well into the workflow .A software or system developer can get a copy of the projectusing the git versioning system, including all sub modules, andcan build am image from scratch in the matter of minutes. Ad-ditional software as well as adjustments can be implementedand a new image can be built and tested locally. After asuccessful test, the changes are committed, and a new releaseis built and using the CI integration mentioned above.VI. C ONCLUSION
In this paper. we presented PIMOD, a tool for configuringsingle-board computer operating system images. A simple yetcomprehensive language for configuring these images wasproposed, which offers an interface to operating system spe-cific configuration tools. The implementation of the proposedlanguage was presented and the staged execution of a Pifilewas explained. PIMOD was evaluated by first discussing thebenefits for operators of a sensor network. The performance ofthe proposed approach was evaluated by comparing runtimesof exemplary commands providing an overview of the over-head. Furthermore, it was demonstrated that PIMOD supportsa wide variety of hardware platforms and operating systems.An interesting area of future work is to extend PIMODto enable reproducible image builds. However, some of theunique characteristics of PIMOD’s implementation preventhash identical builds. Several commands executed in the guestsystems have non-deterministic side effects, such as creatingtemporary and logging files. Another example are the timestamps contained in the image file system, which would alsoneed to be adjusted accordingly.VII. A
CKNOWLEDGEMENTS
This work is funded by the Hessian State Ministry forHigher Education, Research and the Arts (HMWK) (LOEWENatur 4.0 and LOEWE emergenCITY), and the DeutscheForschungsgemeinschaft (DFG, SFB 1053).R
EFERENCES[1] L. Baumgärtner, A. Penning, P. Lampe, B. Richerzhagen, R. Steinmetz,and B. Freisleben, “Environmental monitoring using low-cost hardwareand infrastructureless wireless communication,” in . IEEE, 2018, pp. 1–8.[2] L. Baumgärtner, J. Höchst, P. Lampe, R. Mogk, A. Sterz, P. Weisen-burger, M. Mezini, and B. Freisleben, “Smart street lights and mobilecitizen apps for resilient communication in a digital city,” in , 2019, pp. 1–8.[3] C. Baun, “Mobile clusters of single board computers: an option forproviding resources to student projects and researchers,”
SpringerPlus ,vol. 5, no. 1, p. 360, 2016.[4] F. Bellard, “QEMU, a fast and portable dynamic translator.” in
USENIXAnnual Technical Conference, FREENIX Track , vol. 41, 2005, p. 46.[5] M. Beller, G. Gousios, and A. Zaidman, “Oops, my tests broke the build:An explorative analysis of Travis CI with GitHub,” in .IEEE, 2017, pp. 356–367.[6] D. Bonasera. (2016) PiShrink: Make your Pi images smaller! [Online].Available: https://github.com/Drewsif/PiShrink https://github.com/nature40/sensorboxes-images/ [7] K. Daigle. (2018, October) GitHub Actions: built by you, run by us.GitHub.[8] F. Fainelli, “The OpenWRT embedded development framework,” in Proceedings of the Free and Open Source Software Developers EuropeanMeeting et al. , “IntroducingNature 4.0: A sensor network for environmental monitoring in theMarburg Open Forest,”
Biodiversity Information Science and Standards ,2019.[11] J. Gottwald, R. Zeidler, N. Friess, M. Ludwig, C. Reudenbach, andT. Nauss, “Introduction of an automatic and open-source radio-trackingsystem for small animals,”
Methods in Ecology and Evolution , vol. 10,no. 12, pp. 2163–2172, 2019.[12] L. Hochstein and R. Moser,
Ansible: Up and Running: Automatingconfiguration management and deployment the easy way . O’ReillyMedia, Inc., 2017.[13] B. Hosmer, “Getting started with Salt Stack - the other configurationmanagement system built with Python,”
Linux journal , vol. 2012, no.223, p. 3, 2012.[14] S. J. Johnston, P. J. Basford, C. S. Perkins, H. Herry, F. P. Tso,D. Pezaros, R. D. Mullins, E. Yoneki, S. J. Cox, and J. Singer,“Commodity single board computer clusters and their applications,”
Future Generation Computer Systems , vol. 89, pp. 201–212, 2018.[15] A. Kairiukstis. (2012) BuildRaspbianImage: Build (and cross-compile)your own image for Raspberry Pi. [Online]. Available: https://github.com/andrius/build-raspbian-image/[16] R. Kumar and M. P. Rajasekaran, “An IoT based patient monitoringsystem using Raspberry Pi,” in .IEEE, 2016, pp. 1–4.[17] J. Loope,
Managing infrastructure with puppet: Configuration manage-ment at scale . O’Reilly Media, Inc., 2011.[18] D. Merkel, “Docker: Lightweight Linux containers for consistent de-velopment and deployment,”
Linux Journal , vol. 2014, no. 239, p. 2,2014.[19] A. Penning, L. Baumgärtner, J. Höchst, A. Sterz, M. Mezini, andB. Freisleben, “DTN7: An open-Source disruption-tolerant networkingimplementation of Bundle Protocol 7,” in
International Conference onAd-Hoc Networks and Wireless (AdHoc-Now 2019) . Luxembourg,Luxembourg: Springer, 2019, pp. 196–209.[20] C. P. Quitevis and C. D. Ambatali, “Feasibility of an amateur radiotransmitter implementation using Raspberry Pi for a low cost andportable emergency communications device,” in . IEEE, 2018, pp. 1–6.[21] C. Ramey, “What’s GNU: Bash - The GNU Shell,”
Linux Journal et al. , “GreenEduComp: Low cost green computing systemfor education in Rural India: A scheme for sustainable developmentthrough education,” in . IEEE, 2013, pp. 102–107.[25] S. Truitt, T. D. Gage, B. E. Vincent, and S. Chun, “Low-cost remotemonitoring system for small-Scale UPS installations in developingcountries,” in , 2019, pp. 1–6.[26] B. Vasilescu, Y. Yu, H. Wang, P. Devanbu, and V. Filkov, “Quality andproductivity outcomes relating to continuous integration in GitHub,” in
Proceedings of the 2015 10th Joint Meeting on Foundations of SoftwareEngineering , 2015, pp. 805–816.[27] N. S. Yamanoor and S. Yamanoor, “High quality, low cost educationwith the Raspberry Pi,” in2017 IEEE Global Humanitarian TechnologyConference (GHTC)