Artikel von: Mohamed BELOUARGA
Das Hinzufügen einer Funktion, das Beheben eines Fehlers oder das Korrigieren einer Sicherheitslücke sind Teil des Lebenszyklus einer Software, einer Bibliothek oder einer Firmware. Für Architekten und Entwickler ist die Durchführung dieser Aufgaben jedoch mit technischen Nachteilen und einer Reihe möglicher unerwünschter Folgen verbunden (mehr Fehler, Rollbacks usw.).
Bislang schickt die Industrie, insbesondere die Branche der eingebetteten Systeme, ihre Techniker immer noch vor Ort, um ihre Produkte zu aktualisieren. Diese Verfahren sind zeitaufwändig, erfordern eine aufwendige Logistik, sind teuer und werden daher oft übersehen, was bei Kunden und Anwendern große Verachtung hervorruft.
Remote-Updates, auch Over The Air (OTA)-Updates genannt, eignen sich besser für die künftigen Anforderungen der meisten Industrieunternehmen, Hersteller und ihrer künftigen Produkte.
Dieser Artikel befasst sich mit Remote-Updates für eingebettete Linux-Systeme.
OTA-Updates ermöglichen es, Softwareänderungen an einem System vorzunehmen, ohne mit dem System in Kontakt zu treten. Diese Aktualisierungen können mit verschiedenen Open-Source-Lösungen durchgeführt werden, aber ihre Implementierung ist nicht immer einfach.
Wenn Hersteller nach Aktualisierungsoptionen suchen, ist die erste Lösung, die sie in Betracht ziehen, die Aktualisierung per Paket. Diese Lösung ist für eingebettete Systeme aus mehreren Gründen am wenigsten geeignet:
👉 Beispiele sind Mender, Ostree, RAUC...
Es gibt jedoch auch andere Lösungen, die all diese Nachteile vermeiden können, z. B. SWUpdate, Mender, OsTree, RAUC, usw.
Jede Lösung hat ihre eigene Art und Weise, mit Updates umzugehen, wir werden in diesem Artikel nur auf Stefano Babics SWUpdate eingehen.
Im Gegensatz zur End-to-End-Lösung Mender, die ihre eigenen Anforderungen, Einschränkungen und Begrenzungen mitbringt, kann SWUpdate eine benutzerdefinierte Version von Mender erstellen, indem es Funktionen hinzufügt oder entfernt. So entsteht eine Update-Lösung, die perfekt auf die Bedürfnisse des Kunden abgestimmt ist.
Der Nachteil ist, dass die Aktualisierungsdatei sehr groß sein kann, was die Netzwerkkosten in die Höhe treibt. Dieses Problem kann jedoch auch durch die Verwendung von komprimierten Rootfs bei der Aktualisierung oder durch die Verwendung von Delta-Updates vermieden werden. Wir werden dies später entwickeln.
Vor der Implementierung einer Aktualisierungslösung muss eine Aktualisierungsstrategie festgelegt werden. Diese Strategie ist an die Lebensdauer eines Produkts gebunden und lässt sich nur sehr schwer ändern.
Einige Beispiele für die Aktualisierungsstrategie sind:
Der Aktualisierungsvorgang läuft wie folgt ab. Während das Produkt mit rootfs1 und kernel1 arbeitet, aktualisiert swupdate rootfs2 oder kernel2 und führt dann einen Neustart auf rootfs2 und kernel2 durch.
Wenn die Aktualisierung erfolgreich ist, bleibt das Produkt so, wie es ist. Wenn dies jedoch nicht der Fall ist (rootfs2 ist beschädigt oder Kernel2 gerät in Panik), führt u-boot eine Rollback-Operation zurück zu rootfs1 und Kernel1 durch.
Der Rescue-Kernel beschränkt sich auf die notwendigen Treiber und das Rescue-Rootfs auf die notwendigen Bibliotheken und swupdate. Das andere rootfs und der Kernel sind die Produktions-Firmware.
Wenn eine Aktualisierung bereit ist, wird das Image mit dem Rescue-Image neu gebootet, und vom Rescue-Image werden rootfs und Kernel aktualisiert. Nach der Aktualisierung wird das Image mit dem Produktionskernel und den rootfs neu gestartet.
Wenn die Aktualisierung fehlschlägt, dienen der Rettungskernel und rootfs in jedem Fall als Backups.
Wie bereits erwähnt, ist SWUpdate ein Framework, mit dem alles möglich ist. Die einzigen Grenzen sind die Phantasie der Benutzer.
SWUpdate muss mit dem Bootloader zusammenarbeiten, d. h. wenn das Gerät oder Produkt das rootfs ändern muss, ändert der Bootloader die Befehlszeile, die der Kernel erhält. Diese Verbindung ist für das Aktualisierungssystem von entscheidender Bedeutung.
Nachdem wir nun die Update-Strategien und die Bootloader-Schnittstelle kennengelernt haben, wollen wir uns nun die verschiedenen Tools ansehen, die SWUpdate zum Senden eines Updates bereitstellt.
Die Schnittstelle könnte wie folgt aussehen:
SWUpdate im Mangoose-Modus enthält einen eingebetteten Webserver, der es uns ermöglicht, die Aktualisierungsdatei über eine Weboberfläche zu senden.
Sobald SWUpdate korrekt konfiguriert ist, ermöglicht diese Schnittstelle dem Benutzer, eine Aktualisierungsdatei (.swu) an das Ziel zu senden. Die Schnittstelle zeigt auch Einblicke wie den Aktualisierungsstatus und Protokolle.
SWUpdate im Surricata-Modus fragt einen entfernten Server nach Updates, holt sie, installiert sie und meldet dann die Ergebnisse.
Meistens für große Mengen von Karten verwendet, Surricata Modus zentralisiert und überwacht die Kontrollen der Update-System. Auf der Serverseite können wir Eclipse hawkBit verwenden, um den Status eines Parks von Karten zu überwachen.
Derzeit wird nur Eclipse hawkBit unterstützt, aber dank des Open-Source-Charakters dieser Lösungen kann ein angepasster Server hinzugefügt werden und als Workaround dienen.
SWUpdate agiert wie ein Rahmenwerk und bietet dem Benutzer viele weitere Funktionen und Werkzeuge. Zum Beispiel, wenn ein Benutzer ein .swu-Update über eine andere Anwendung eingeben möchte. Die Datei kann mit dem Tool SWUpdate-client an den SWUpdate-Deamon gesendet werden. Außerdem kann dieselbe Anwendung mit SWUpdate-progress die Fortschrittsdaten der Aktualisierung abrufen, was eine externe Überwachung ermöglicht.
Es gibt noch viele andere Funktionen, und alle sind sehr gut dokumentiert.
Wenn Sie einen speziellen Bedarf haben, wie z.B. die Installation eines bestimmten Updates oder die Aktualisierung eines mit dem Ziel verbundenen Mikrocontrollers, können Sie mit SWUpdate Ihren eigenen Handler hinzufügen.
Sicherheit bleibt für SWUpdate wichtig. Die Fähigkeit, HTTPS mit dem Surricata-Modus zu verwenden, zeigt 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).
Der teuerste Teil eines Aktualisierungsvorgangs sind in den meisten Fällen die Kosten für die Bandbreite. Das Aktualisieren eines Rootfs für eine große Anzahl von Zielen erfordert ebenfalls eine große Menge an Bandbreite. Um dieses Problem zu lösen und die Kosten zu senken, ermöglicht SWUpdate die Verwendung komprimierter rootfs.
Der Preis für die Bandbreite bleibt auch nach der Komprimierung hoch, weshalb SWUpdate eine andere Lösung auf der Grundlage von Deltas vorschlägt.
Diese Lösung wird in einem späteren Artikel erörtert werden.
Zusammenfassend lässt sich sagen, dass SWUpdate ein umfangreiches Framework ist, das viele spezifische Situationen lösen kann. Wenn es gut konfiguriert ist, kann SWUpdate Ihre Aktualisierungskosten senken und gleichzeitig die Aktualisierung von Linux-basierten Systemen für alle wesentlich vereinfachen.
Fabien LAHOUDERE, T&S Linux Practice Leader
Martin COUSSERANS, Geschäftsleiter
Stellen Sie Ihre Fragen und finden Sie Lösungen für Ihre Produktentwicklung
Kontakt
Dieser Artikel beschreibt Indianas Werdegang bei T&S und hebt die Investitionen des Unternehmens in die Mitarbeiterentwicklung und interne Mobilitätsmöglichkeiten hervor. Erfahren Sie, wie Indiana ihre Fähigkeiten nutzte, um sich von der Verwaltungsassistentin zum HR Business Partner & Team Leader zu entwickeln.
READ MORE
Entdecken Sie Sophies bemerkenswerte Reise durch die Reihen von T&S , von einem 6-monatigen Praktikum bis zu einer Festanstellung in der Abteilung Employee Experience. Erfahren Sie mehr über ihr Durchhaltevermögen, ihre Anpassungsfähigkeit und wie sie Hindernisse überwunden hat, um beruflich erfolgreich zu sein.
READ MORE
Reduzieren Sie Ihre Auswirkungen! ♻️ Erfahren Sie, wie die Erstellung von CO2-Fußabdrücken Unternehmen bei der Bekämpfung des Klimawandels hilft.
READ MORE
