Edge-Computing etabliert sich in zunehmend mehr Branchen. Kassensysteme in Läden, Fleet-Management-Systeme in Lieferwägen oder Steuergeräte in der Industrie sind nur einige Beispiele, wo Standard-Hardware mit Standard-Linux-Betriebssystemen und containerisierten Applikationen zum Einsatz kommen. Die Volkswagen Gruppe beispielsweise entwickelt ihr eigenes "vw.os" auf Basis von Linux, das in einem Zentralrechner im Fahrzeug die Steuerung übernehmen, und damit bis zu 120 proprietäre Steuergeräte ersetzen soll.

Viele der Edge-Geräte arbeiten ohne oder mit nur sporadischen Verbindungen zu einem Netzwerk. Andere hingegen sind permanent online und am LAN angebunden – und um diese Geräte dreht sich unser Artikel. In der April-Ausgabe 2023 hatten wir im Artikel "Weit draußen" [1] darüber berichtet, wie Sie mit dem "Osbuild-Composer" maßgeschneiderte Images für Edge-Devices bauen. In der Regel landen diese Images dann auf Datenträgern innerhalb dieser Geräte. Je nach Einsatzgebiet kann das jedoch zu Problemen führen.

Die in Edge-Devices weit verbreiteten SD-Karten als Dateispeicher sind ursprünglich eigentlich nicht für einen derartigen Dauerbetrieb konzipiert. In Foto- und Videokameras leisten sie gute Dienste, weil sie dort gemächlich sequentiell bei angenehmen Temperaturen beschrieben und gelesen werden. Im Industrieumfeld ist das anders: Hier können höhere Temperaturen herrschen. Viele Random-Read-Write-IOs nagen zudem an der Lebenserwartung der SDs. Nicht umsonst offerieren führende Speicherhersteller mittlerweile teure, aber widerstandsfähige "Industrial"-SDs für genau diesen Zweck.

Und noch ein anderer Gedanke treibt Administratoren um, speziell bei Edge-Devices, auf die Nutzer direkt zugreifen können: Was, wenn Unbefugte das Gerät oder nur die darin enthaltene SD-Karte entwenden. Je nach verwendeter Softwarearchitektur könnten Diebe Zugriff zu unternehmenskritischen Daten wie Konstruktionsplänen oder CNC-Fertigungsdaten erhalten. Auch besteht die Gefahr, dass Netzwerk-Zugangsinformationen wie Schlüssel und Zertifikate auf der SD-Karte lagern.

Viele Admins in diesem Umfeld setzen daher Full-Disk-Encryption mit LUKS und Network Bound Disk Encryption (NBDE; siehe Artikel "Unter Verschluss", Ausgabe 10/2022 [2]) ein. Das verursacht einen großen Verwaltungsaufwand: OS-Image-Build, over-the-air-Update-Verteilung, Verschlüsselung, Tang-Server et cetera. Für machne Einsatzgebiete gibt es einen deutlich einfacheren Ansatz: Gar kein Datenträger im Edge-Device, weil dieses via LAN bootet und auch seine Root-Disk über das Netzwerk bezieht.

Gerade wenn auf Edge-Devices ohnehin Dienste arbeiten, die vollständig von der Verfügbarkeit des LANs abhängen, ergibt es durchaus Sinn, gleich das ganze Device über das Netzwerk zu starten. Eine SD-Karte lässt sich somit nicht mehr klauen und wer das komplette Gerät entwendet, findet darauf keine Daten. Auch das Management vereinfacht sich dramatisch, da dieses ausschließlich auf den Boot- und Storage-Servern läuft und keinen Zugriff zum eigentlichen Device benötigt.

Wie vergleichsweise simpel das Setup eines PXE-Servers für BIOS- und UEFI-LAN-Starts ist, haben wir bereits in der Ausgabe 02/2022 im Artikel "Fernzünder" [3] beschrieben. Eigentlich fehlen nur noch ein paar Parameter, um einem startenden Device ein Block- oder File-basiertes Netzwerk-Root-Laufwerk zuzuweisen. Das funktioniert mit modernen Linux-Distributionen aber nicht mehr ganz so einfach.

Ein Linux-System benötigt für den Startvorgang in der Regel zwei Dateien: einen Systemkern (vmlinuz) und die initiale RAM-Disk (initrd.img). Läuft der Kernel, entpackt er die initrd-Datei und nutzt sie als initiales Root-Dateisystem. Dann ermittelt der Kernel die im System vorhandene Hardware und lädt aus initrd die benötigten Treiber dafür.

Nach dieser Phase kann der Systemkern auf das eigentliche Root-Dateisystem zugreifen und bindet es dann unter "/" anstelle der initrd ein und setzt den Startvorgang fort. Findet der Kern in der initrd-Datei keinen passenden Treiber für das Root-Dateisystem, bricht der Systemstart mit einem Fehler ab. In einem Rechner mit einem lokalen Datenträger lädt der Bootloader "grub" Kernel und inidrd aus dem Dateisystem "/boot", beim PXE-Start liegen die beiden Dateien auf einem Webserver.

In unserem Fall brauchen wir ein besonderes initrd-File, das den benötigten Treiber des LAN-Adapters wie auch die Client-Tools für das gewünschte Netzwerkdateisystem enthält. Für root auf NFS sind das die "nfs-utils", für iSCSI die "iscsi-initiator-utils". Theoretisch könnten Sie ein Root-Dateisystem auch mit SMB/CIFS, Ceph RBD, CephFS oder GlusterFS einbauen, solange Sie die passenden Treiber und Tools in die initrd einfügen. In diesem Artikel beschränken wir uns auf NFS und iSCSI.

Moderne Linux-Distributionen erstellen nach der Installation oder einem Systemupdate eine passende, schlanke initrd-Datei, die nur die nötigsten Treiber, jedoch keine der genannten Netzwerk-Tools enthält. Das File ist ja nur während des Systemstarts aktiv. Selbst wenn sie keine NFS-Tools enthält, kann Ihr System dennoch NFS-Freigaben einbauen, aber eben nicht während des Systemstarts, sondern erst, wenn ihr endgültiges root-Dateisystem gemounted wurde.

Theoretisch können Sie für den LAN-Start die initrd-Datei verwenden, die Sie auf der Installations-CD/DVD eines Enterprise-Linux (etwa RHEL, Rocky-, AlmaLinux, CentOS-Stream) im Verzeichnis "/images/pxeboot/initrd.img" finden. Diese enthält mehr Treiber und Tools als das initrd-File, das Ihr System nach einer regulären Installation oder einem Update erstellt. Wenn Sie jedoch das OS Ihrer LAN-Boot-Systeme updaten, sollten Sie dazu natürlich auch immer den Kernel und die initrd-Datei aktualisieren. Also passen Sie im System die Konfiguration von "dracut" an, dem Tool, das das File erstellt.

Ein simpler Weg zum LAN-Boot-fähigen Image führt über eine VM. Für ein Systemsetup mit einem späteren Root-Dateisystem auf NFS richten Sie dort zunächst das Basissetup Ihres gewünschten Systems mit den benötigten Werkzeugen ein. Dieses System passen Sie dann für Root auf NFS an. Für iSCSI nehmen wir einen leicht anderen Weg, mehr dazu später.

Planen Sie ein Netzwerk-Root-Laufwerk auf NFS (oder einem anderen Netzwerk-Dateisystem), legen Sie einfach in der virtuellen Maschine eine "/"- und die übliche "/boot"-Partition an. Die Größe der virtuellen Disk, die Sie der Template-VM geben, spielt hier keine Rolle. Legen Sie keine dezidierte Swap-Partition an. Für den Workshop erstellen wir eine Centos-Streams-9-VM in KVM. Nach dem Basissetup installieren Sie alle zusätzlichen Tools wie die oben erwähnten iSCSI- und NFS-Tools im System. Danach passen Sie die Konfiguration der initrd an. Im Verzeichnis /etc/dracut.conf.d erstellen Sie eine conf-Datei, beispielsweise "01-netboot.conf". Dort laden Sie die benötigten Module nach:

Achten Sie dabei auf die seltsame Syntax mit "+=" und den Leerzeichen vor und nach den Modulnamen. Eigentlich sollten Sie in dieser Datei auch Netzwerktreiber mit "add-Drivers+=" angeben können. Allerdings gibt es hier einen langjährigen Bug bei verschiedenen Distributionen, wobei das von dracut aufgerufene "mkinitrd"-Tool zwar die Module, nicht aber die Treiber berücksichtigt.

Für diesen Workshop setzen wir ein Edge-Device "fitlet 2" [4] ein. Das integriert zwei Intel-LAN-Adapter vom Typ "I211", die den Kerneltreiber "igb" benötigen. In der Standard-initrd-Datei ist bei Centos-Streams-9 aber nur der e1000-Treiber enthalten. Für die LAN-bootfähige initrd mit Root auf NFS brauchen wir daher zwei dracut-Aufrufe. Mit dem ersten erstellen wir zunächst eine neue initrd mit dem gewünschten NFS-Modul:

In einem zweiten Aufruf fügen wir dieser initrd-Datei dann den LAN-Treiber hinzu:

Sie können das initrd-File natürlich benennen, wie Sie möchten. Im Beispiel folgen wir der üblichen Namensgebung mit Kernel-Version, OS-Version und Architektur. Wenn Sie übrigens prüfen möchten, was tatsächlich in einer initrd-Datei steckt, lassen Sie sich den Inhalt mit dem Kommando "lsinitrd" <Dateiname> auflisten.

In unserem Setup kommen zwei getrennte Server zum Einsatz: Der Fileserver mit den NFS-Freigaben und dem iSCSI-Target läuft auf 192.168.2.8. Der DHCP/PXE-Server, der auch via HTTP den Kernel und die initrd aus einem Unterverzeichnis unter "/var/www/html" bereitstellt, läuft auf 192.168.2.12. Daher müssen wir an dieser Stelle den Kernel und die neu erstellte initrd aus dem /boot-Dateisystem der virtuellen Maschine jetzt in das Verzeichnis "/var/www/html/nfsroot/" des PXE/DHCP-Servers kopieren.

Für den NFS-Start binden wir die zuvor erstellte NFS-Freigabe in die virtuelle Maschine ein. Unser NFS-Server läuft auf der IP-Adresse 192.168.2.8 und die Freigabe für das NFS-Root befindet sich unter "/nfs/01":

Dann kopieren wir das komplette Dateisystem aus der VM auf den NFS-Server:

und fahren die VM herunter. Nachdem Sie das Dateisystem aus der VM kopiert haben, müssen Sie auf dem NFS-Server einige Änderungen daran vornehmen: In der fstab-Datei unter "/nfs/01/etc/fstab" auf dem NFS-Server entfernen Sie die Mount-Points für "/" und "/boot", die auf die UUIDs der VM-Disk verweisen, und tragen stattdessen den NFS-Serverpfad ein. Passend zu unserem Beispiel lautet dieser "192.168.2.8:/nfs/01 / nfs rw,hard,intr 1 1". Nach der Vorbereitung des Systems folgt die Anpassung im dnsmasq-Server.

Im Verzeicnis "/var/lib/tftpboot" legen sie eine individuelle "grub.cfg" für ihren Client an. Diese erhält den Namen nach dem Schema: "grub.cfg-01-<MAC-Adresse>", beispielsweise "grub.cfg-01-00-01-02-03-04-05". Nach dem üblich verdächtigen Header der Grub-Datei

folgt der eigentliche Eintrag für den NFS-Boot-Vorgang:

Für den ersten Start des Systems geben wir hier den Kernel-Parameter "enforcing=0" mit, der das SELinux der Maschine in den "Permissive"-Modus zwingt. So können Sie prüfen, ob die SELinux-Labels auf ihrem NFS-Root stimmen oder erst über ein "Relabel" korrigiert werden müssen. Sollte es zu Problemen mit Labeln auf ihrer NFS-Freigabe kommen, müssen Sie das SELinux mit dem Kernel-Paramter "selinux=0" ganz abschalten.

Ein Netzwerk-Dateisystem wie NFS erlaubt keinen Schreibcache. Daher ist NFS bei Aufgaben mit Schreib-IOPS des Clients langsamer als ein iSCSI-Root. Der Nachteil ist zugleich auch ein Vorteil, denn das NFS-Dateisystem kann bei einem Absturz des Clients nicht als Ganzes crashen. Geht der angebundene Client unbeabsichtigt down – beispielsweise durch den Not-Aus-Schalter einer Fabrikationsmaschine –, könnten zwar einzelne Dateien des NFS-Dateisystems beschädigt werden, nicht aber das Dateisystem als Ganzes.

Zudem können andere System auf die Freigabe zugreifen und somit Dateien aus dem laufenden System kopieren (Backup) oder Dateien an das Device übertragen.

Um ein System via iSCSI zu starten, sind mehr Modifikationen am System, der inird und den Boot-Parametern erforderlich. Zum Glück müssen Sie hier nicht selbst Hand anlegen, denn mit einem simplen Trick überlassen Sie diese Konfigurationsarbeit dem Enterprise-Linux-Installer Anaconda. Das Prinzip ist simpel: Sie richten wiederum ein neues System in einer VM ein und veranlassen Anaconda, das Root-Dateisystem direkt auf einem iSCSI-Laufwerk abzulegen. Das erlaubt der Installer jedoch nur, wenn Sie zudem eine lokale Disk für das "/boot"-Dateisystem angeben.

Das Vorgehen ist daher wie folgt: Erstellen Sie zuerst ein leeres iSCSI-Laufwerk auf Ihrem iSCSI-Server. Im Beispiel nutzen wir dazu einfach das reguläre iSCSI-Target von Linux mit dem targetcli-Kommando. Für jedes zu bootende System legen wir hier ein eigenes iSCSI-Target mit dem passenden LUN-Mapping an. Ein Zugriffschutz über chap-Authentisierung wäre möglich. Der Einfachheit halber genügt für unser Beispiel jedoch die Autorisierung über den Initiatornamen des Clients.

Legen Sie eine virtuelle Maschine in KVM an und geben Sie dieser eine kleine virtuelle Disk mit 1 oder 2 GByte Größe. Packen Sie das ISO-Abbild der gewünschten EL-Distribution als Bootlaufwerk dazu – in unserem Fall CentOS-Stream-9 – und starten Sie die VM.

Aus dem Hauptmenü der Installation wechseln Sie in das Untermenü "Installations-Ziel". Dort finden Sie die kleine Boot-Platte vor. Wechseln Sie auf "Angepasste Installation" und klicken Sie auf den Button "Festplatte hinzufügen". Nun wählen Sie den Punkt "iSCSI-Ziel hinzufügen" und tragen im folgenden Dialog die IP-Adresse des iSCSI-Targets sowie den Namen für den Initiator ein, so wie Sie ihn bei der Targetkonfiguration festgelegt haben. Wenn Sie jetzt die "Erkennung starten", zeigt Ihnen Anaconda im nächsten Menü die gefundenen iSCSI-Targets an. Je nach Konfiguration kann das eine längere Liste sein. Wählen Sie in dieser Liste nur das Target aus, das Sie für dieses Setup erstellt haben, und klicken dann auf "Anmelden". Im folgenden Dialog zeigt der Installer die gefundenen Laufwerke an. Hier sollte lediglich die zuvor angelegte LUN erscheinen.

Wenn Sie auf "Fertig" klicken, kehrt Anaconda zum Dialog "Installationsziel" zurück und hat nun sowohl die kleine virtuelle Platte als auch das iSCSI-Laufwerk ausgewählt. In der folgenden Partitionierung wählen Sie "Standardpartition" aus und legen auf der VM-Disk lediglich das "/boot"-Dateisystem mit ext4 an. Die komplette iSCSI-Disk weisen Sie dem "/"-Laufwerk zu und formatieren es mit xfs. Dann setzen Sie die OS-Installation mit den gewünschten Einstellungen fort. Die Warnung, dass Ihr System über kein "Swap"-Laufwerk verfügt, können Sie ignorieren. Am Ende der Installation starten Sie die VM neu. Je nach Wunsch installieren Sie nun weitere Programme für das künftige Edge-Device und spielen Updates ein.

Anaconda hat bei der Installation ein passendes initrd-Image kreiert und auch im System die iSCSI-Konfiguration angepasst. Falls Sie weitere Treiber in der initrd benötigen, können Sie diese nun nachträglich einfügen. In unserem Beispiel rüsten wir für das Fitlet2-Edge-Device wie beschrieben den igb-Treiber nach. Nach eventuellen Änderungen kopieren Sie den Kernel und das initrd-File aus dem Verzeichnis "/boot" der VM auf den DHCP-Server und platzieren beide Dateien dort innerhalb des HTTP-Verzeichnisses, in unserem Fall unter "/var/ www/html/iscsiroot/".

Das Installationsprogramm hat auch gleich die benötigten Kernel-Parameter für den iSCSI-Boot erstellt und diese in die Datei "/boot/grub2/grub.cfg" eingetragen. Suchen Sie dort nach einer Zeile, die mit "set kernelopts" beginnt. Sie enthält die genauen Parameter für den iSCSI-Boot und die UUID des Root-Dateisystems. Kurz bevor Sie die VM abschalten, passen Sie noch die Datei "/etc/fstab" an und kommentieren darin den Eintrag für das "boot"-Dateisystem aus, da wir diesen beim PXE-Boot nicht benötigen.

Auf dem DHCP-Server erstellen/ändern Sie die Datei "grub.cfg-01-<MAC-Adresse>" für Ihr Edge-Device und tragen dort die Parameter für den iSCSI-Boot ein. Aus der "grub.cfg" der virtuellen Maschine übernehmen Sie die Einträge für "root=UUID" und "netroot=iscsi". Allerdings lassen Sie das "ro" weg und passen ebenfalls den "ip"-Paramter an. In der "grub.cfg" der VM enthält der IP-Parameter unter Umständen den vollständigen Namen des IP-Interfaces. Dieser kann auf dem physischen Edge-Device jedoch abweichen, daher tragen Sie in der PXE-Boot-Konfiguration lediglich "ip=dhcp" ein, ohne einen Interface-Namen zu nennen. In unserem Beispiel sieht "grub.cfg" so aus:

Damit startet unser Fitlet2-Edge-Device via PXE und mit der iSCSI-Disk als Root-Laufwerk.

Auf dem iSCSI-Laufwerk arbeitet das reguläre XFS-Dateisystem. Daher gibt es hier Schreibcache und damit auch schnellere Zugriffe bei Schreib-IOs. Zudem funktioniert SELinux ohne Probleme. Der Nachteil gegenüber Root auf NFS ist dann aber, dass das XFS-Dateisystem Schaden nehmen kann, sollte das Edge-Dive abstürzen oder einfach im laufenden Betrieb abschalten. Um das zu vermeiden, lässt sich der iSCSI-Boot natürlich auch mit einem Ostree-Image ausführen, das das Root-Dateisystem im RO-Modus betreibt.

Um weitere Edge-Devices via iSCSI zu starten, können Sie das Laufwerk des zuerst erstellten Setups als Vorlage verwenden und klonen. Sie müssen dabei jedoch im Dateisystem der Klone Änderungen einbringen. Zwar bleibt die UUID der geklonten Disks identisch, aber die Konfiguration des iSCSI-Initiators weicht ab.

Sie müssen bei geklonten Disks die Datei "/etc/iscsi/initiatorname.iscsi" anpassen und dort den Initiatornamen des neuen Clients einfügen, den Sie dann auch in die passende "grub.cfg-01"-Datei für den PXE-Boot eintragen. Zudem löschen Sie die Konfiguration des iSCSI-Initiators, in dem Sie die kompletten Inhalte der Verzeichnisse "/var/lib/iscsi/nodes/*" und "/var/lib/iscsi/sendtargets/*" löschen.

Systeme mit dem Root-Laufwerk auf dem LAN müssen bei Updates leider noch einen Extraschritt einlegen. Sollten Sie eine neue Kernel-Version einrichten, müssen Sie diese samt initrd nach dem Update und der eventuell nötigen Anpassung durch dracut vom Edge-Device an den DHCP-Server übertragen und die zugehörige grub.cfg-Konfiguration anpassen.

Das Setup von Systemen mit dem Root-Dateisystem im LAN mag anfangs etwas komplex erscheinen. Verglichen mit dem Aufwand für voll verschlüsselte SD-Karten und automatische Unlocks via Tang-Server hält sich das PXE-Setup aber in Grenzen. Es ist sicher keine Lösung für alle Edge-Devices, aber in vielen Anwendungen mit einer stabilen LAN-Anbindung eine gute Option. Da Disks und PXE-Konfiguration im Backend liegen, lässt sich das Setup vollautomatisch anpassen, ohne die Edge-Devices selbst ansprechen zu müssen.