Artikel von: Mohamed BELOUARGA

Das Hinzufügen einer Funktion, das Beheben eines Fehlers oder das Schließen einer Sicherheitslücke gehören zum Lebenszyklus von Software, einer Bibliothek oder einer Firmware. Für Architekten und Entwickler ist die Durchführung dieser Aufgaben jedoch nach wie vor mit technischen Herausforderungen und einer Reihe potenzieller unerwünschter Folgen verbunden (weitere Fehler, Rollbacks usw.).

Bis heute schickt die Industrie, insbesondere die Embedded-System-Branche, ihre Techniker weiterhin vor Ort, um Updates an ihren Produkten durchzuführen. Diese Vorgänge sind zeitaufwendig, erfordern einen hohen logistischen Aufwand, sind kostspielig und werden daher oft vernachlässigt, was bei Kunden und Anwendern auf große Unzufriedenheit stößt.   

Fernaktualisierungen, auch als Over-the-Air-Updates (OTA) bezeichnet, sind besser auf die künftigen Anforderungen der meisten Industrieunternehmen, Hersteller und ihrer zukünftigen Produkte zugeschnitten.    

Im Embedded-Linux-Bereich sind OTA-Updates verfügbar

In diesem Artikel geht es um Fernaktualisierungen für eingebettete Linux-Systeme.

OTA-Updates ermöglichen es, Softwareänderungen an einem System vorzunehmen, ohne physischen Kontakt mit dem System herzustellen. Diese Updates können mithilfe verschiedener Open-Source-Lösungen durchgeführt werden, doch ihre Umsetzung ist nicht immer ganz einfach.

Wenn Hersteller nach Aktualisierungsmöglichkeiten suchen, ist die erste Lösung, die sie in Betracht ziehen, die Aktualisierung per Paket. Diese Lösung ist aus mehreren Gründen für eingebettete Systeme am wenigsten geeignet:

• Sollte die Aktualisierung nicht wie geplant verlaufen, ist ein Rollback nicht möglich.
• Jede Komponente muss entsprechend ihrer Abhängigkeiten verwaltet werden
• Versionskonflikte: In einem Desktop-System können wir es uns leisten, zwei Versionen derselben Bibliothek zu haben, doch in einem System mit begrenztem Speicherplatz ist das nicht der Fall.
• Die Validierung eines Updates ist eine sehr anspruchsvolle Aufgabe. Dies gilt umso mehr, je mehr Updates durchgeführt werden, da die Aktualisierung dadurch immer komplizierter und kostspieliger wird. Es ist notwendig, den Übergang von V1 zu V2, von V2 zu V3, aber auch von V1 zu V3 usw. zu planen.

👉 Beispiele hierfür sind Mender, Ostree, RAUC…

Dennoch gibt es andere Lösungen, mit denen sich all diese Nachteile vermeiden lassen, wie beispielsweise SWUpdate, Mender, OsTree, RAUC usw.

Jede Lösung hat ihre eigene Vorgehensweise beim Umgang mit Updates; in diesem Artikel werden wir uns ausschließlich mit Stefano Babics SWUpdate befassen.

#Swupdate ist eher ein Framework als eine andere Komplettlösung

Im Gegensatz zur End-to-End-Lösung Mender, die mit bestimmten Anforderungen, Einschränkungen und Grenzen verbunden ist, ermöglicht SWUpdate die Erstellung einer maßgeschneiderten Version von Mender, bei der Funktionen hinzugefügt oder entfernt werden können. So entsteht eine Update-Lösung, die perfekt auf die Bedürfnisse des Kunden zugeschnitten ist.

Der Nachteil ist, dass die Aktualisierungsdatei sehr groß sein kann, was die Netzwerkkosten in die Höhe treibt. Dieses Problem lässt sich jedoch vermeiden, indem man bei der Aktualisierung komprimierte Root-Dateisysteme verwendet oder auf Delta-Updates zurückgreift. Darauf werden wir später noch näher eingehen.

Festlegung einer Aktualisierungsstrategie

Bevor eine Update-Lösung implementiert wird, muss eine Update-Strategie festgelegt werden. Diese Strategie richtet sich nach der Lebensdauer eines Produkts und lässt sich nur sehr schwer ändern.

Beispiele für eine Aktualisierungsstrategie sind unter anderem: 

Doppelkopiermodus

• Der Doppelkopiermodus besteht darin, Elemente zu duplizieren, was Folgendes beinhaltet: zwei Root-Dateisysteme, zwei Kernel, zwei DT (Device Tree), zwei Bootloader-Umgebungen usw.

Der Aktualisierungsvorgang läuft wie folgt ab: Während das Produkt mit rootfs1 und kernel1 läuft, aktualisiert swupdate rootfs2 oder kernel2 und startet anschließend mit rootfs2 und kernel2 neu.

Wenn die Aktualisierung erfolgreich ist, bleibt das Produkt unverändert. Ist dies jedoch nicht der Fall (rootfs2 ist beschädigt oder kernel2 stürzt ab), führt U-Boot einen Rollback auf rootfs1 und kernel1 durch.

Einzige Rettungsstrategie

• Die Einzelrettungsstrategie benötigt weniger Speicherplatz als der Doppelkopiermodus, da sie mit einem Rettungs-Root-Dateisystem und einem Rettungskernel arbeitet.

Der Rettungs-Kernel beschränkt sich auf die erforderlichen Treiber, und das Rettungs-Rootfs beschränkt sich auf die erforderlichen Bibliotheken und „swupdate“. Das übrige Rootfs und der übrige Kernel stammen aus der Produktions-Firmware.

Sobald ein Update bereitsteht, wird das Image auf das Rettungs-Image neu gestartet, und von diesem aus werden das Root-Dateisystem und der Kernel aktualisiert. Nach der Aktualisierung wird das Image mit dem Produktions-Kernel und dem Produktions-Root-Dateisystem neu gestartet.

Sollte das Update fehlschlagen, dienen der Rettungskernel und das Root-Dateisystem als Backup.

Wie bereits erwähnt, ist SWUpdate ein Framework, mit dem alles möglich ist. Seine einzigen Grenzen sind die Vorstellungskraft seiner Nutzer.

Bootloader-Schnittstelle

SWUpdate muss mit dem Bootloader zusammenarbeiten, was bedeutet, dass der Bootloader die Befehlszeile, die der Kernel erhält, anpasst, wenn das Gerät oder Produkt das Root-Dateisystem ändern muss. Dadurch ist diese Zusammenarbeit für das Update-System von entscheidender Bedeutung.

Nachdem wir uns nun die Update-Strategien und die Bootloader-Schnittstelle angesehen haben, wollen wir uns die verschiedenen Tools ansehen, die SWUpdate zum Versenden eines eigentlichen Updates bereitstellt. 

Mangoose-Modus

Die Benutzeroberfläche könnte so aussehen:

SWUpdate im Mangoose-Modus verfügt über einen integrierten Webserver, über den wir die Aktualisierungsdatei über eine Weboberfläche versenden können.

Sobald SWUpdate korrekt konfiguriert ist, ermöglicht diese Schnittstelle dem Benutzer, eine Aktualisierungsdatei (.swu) an das Zielgerät zu senden. Die Schnittstelle zeigt außerdem Informationen wie den Aktualisierungsstatus und Protokolle an.

Erdmännchen-Modus

SWUpdate im Surricata-Modus fragt einen Remote-Server nach Updates ab, lädt diese herunter, installiert sie und meldet anschließend die Ergebnisse.

Der Surricata-Modus wird vor allem bei großen Kartenbeständen eingesetzt und dient der Zentralisierung und Überwachung der Steuerung des Aktualisierungssystems. Auf der Serverseite können wir Eclipse hawkBit nutzen, um den Status eines Kartenbestands zu überwachen.

Derzeit wird nur Eclipse hawkBit unterstützt, doch dank des Open-Source-Charakters dieser Lösungen kann ein individuell angepasster Server hinzugefügt werden, der als Ausweichlösung dient.

SWupdate zu einem festen Bestandteil Ihrer Geschäftsprozesse machen

Da SWUpdate als Framework fungiert, stehen den Benutzern weitaus mehr Funktionen und Werkzeuge zur Verfügung. Ein Beispiel hierfür ist der Fall, dass ein Benutzer ein .swu-Update über eine andere Anwendung einspeisen möchte. Die Datei kann mithilfe des Tools „SWUpdate-client“ an den SWUpdate-Daemon gesendet werden. Darüber hinaus kann dieselbe Anwendung mit „SWUpdate-progress“ die Daten zum Fortschritt des Updates abrufen, wodurch eine externe Überwachung möglich wird.

Es stehen noch viele weitere Funktionen zur Verfügung, die alle sehr gut dokumentiert sind. 

Handler

Wenn Sie einen bestimmten Bedarf haben, beispielsweise wie man ein bestimmtes Update installiert oder einen mit dem Zielgerät verbundenen Mikrocontroller aktualisiert, können Sie mit SWUpdate einen eigenen Handler hinzufügen.

Signierte Updates

Sicherheit hat für SWUpdate weiterhin hohe Priorität. Die Möglichkeit, im Surricata-Modus HTTPS zu nutzen, unterstreicht dies bereits, aber wir können auch .swu-Dateien signieren. SWUpdate ist dann in der Lage zu überprüfen, ob die empfangenen Updates von einer autorisierten Quelle stammen (privater Schlüssel/öffentlicher Schlüssel).  

Das Problem der Datenmenge und Bandbreite lösen

👉 Zusammengefasste Updates

Der teuerste Teil eines Update-Vorgangs sind in den meisten Fällen die Kosten für die Bandbreite. Die Aktualisierung eines Root-Dateisystems für eine große Anzahl von Zielsystemen erfordert zudem eine hohe Bandbreite. Um dieses Problem zu lösen und die Kosten zu senken, ermöglicht SWUpdate die Verwendung komprimierter Root-Dateisysteme.

👉 Neuigkeiten von Delta

Die Bandbreitenkosten bleiben auch nach der Komprimierung hoch, weshalb SWUpdate eine weitere Lösung auf Basis von Deltas vorschlägt.

Diese Lösung wird in einem späteren Artikel behandelt.

Zusammenfassend lässt sich sagen, dass SWUpdate ein leistungsstarkes Framework ist, das sich für viele spezifische Anwendungsfälle eignet. Bei richtiger Konfiguration kann SWUpdate Ihre Update-Kosten senken und gleichzeitig die Aktualisierung von Linux-basierten Systemen für alle Beteiligten erheblich vereinfachen.

Wenn Sie mehr über SWUpdate erfahren möchten und darüber, wie es Ihrem Unternehmen helfen kann, wenden Sie sich bitte an: 

Fabien LAHOUDERE, Leiter des T&S-Linux-Bereichs
Martin COUSSERANS, Geschäftsleiter

Kontaktieren Sie uns