NextBox: Warum wir uns für und gegen Ubuntu Core entschieden haben

Als wir mit der Entwicklung der NextBox begannen, entschieden wir uns für Ubuntu Core als Betriebssystem für die integrierte Software. Ubuntu Core scheint auf den ersten Blick zahlreiche Vorteile mitzubringen, welche sich aber leider Stück für Stück in Luft auflösten und sogar zu Problemen wurden. Daher haben wir diese Entscheidung revidieren müssen und haben das System auf Debian umgestellt. Dieser Artikel beschreibt die Gründe die dazu führten.

Anforderungen an das Betriebssystem

Die NextBox ist eine Hardware mit vorinstallierter Nextcloud, welche sich auch an Nutzer mit wenig bis keinem technischen Verständnis richtet, die aber trotzdem ein sicheres System unter ihrer Kontrolle betreiben möchten. Daraus ergeben sich die wesentlichen Anforderungen an das darin eingesetzte Betriebssystem:

• Open Source
• Automatische Updates und hohe Robustheit zwecks minimalem Administrationsaufwand
• Alleinige Kontrolle durch den Nutzer. Es sollte kein Fernzugriff durch uns nötig und möglich sein.
• Möglichst lange Sicherheitsupdates und idealerweise die Aktualisierbarkeit des gesamten Betriebssystems.
• Ein möglichst kleines System um eine minimale Angriffsfläche zu bieten
• Die Möglichkeit zum Einbringen weiterer Funktionen (z.B. Status-LED, Reset-Knopf, Secure Element)

Gleichzeitig wollen wir das Rad nicht neu erfinden in dem wir ein Betriebssystem (bzw. Distribution) von Grund auf neu entwickeln, sondern wir wollen ein existierendes Betriebssystem verwenden, welches die obigen Anforderungen erfüllt.

Warum wir uns für Ubuntu Core entschieden haben

Die Open-Source Landschaft für Betriebssysteme ist enorm vielfältig. Nicht ganz unbeeinflusst von eigenen positiven Erfahrungen mit Ubuntu als zuverlässiges, administrationsarmes Betriebssystem, erschien relativ früh Ubuntu Core auf dem Radar. Der Überblick zu Ubuntu Core listet genau die Leistungen auf, die wir für die NextBox brauchen: "Security first", "Tamper-resistant and hardened against corruption", "10 year security update commitment", "Minimal core, minimal risk, minimal bugs". Darüber hinaus Support für die Hardwareplatform unserer Wahl: Der Raspberry Pi 4.

Natürlich waren hier bereits auch die klassischen Kritikpunkte präsent, insbesondere die Tatsache, dass der Global Store die einzige Möglichkeit ist Snaps auf das Gerät zu bringen. Für die NextBox erschien die damit verbundenen Sicherheitsmechanismen sogar als Vorteil. Offensichtlich ist die Einschränkung von Ubuntu Core, exklusiv Snaps installieren zu dürfen, ein zweischneidiges Schwert; Für unser Anforderungsprofil aber grundsätzlich gut und wünschenswert im Bezug auf die Sicherheit und Robustheit.

An diesem Punkt war uns aber auch schon aufgefallen, dass ein sogenannter Brand Store eine (scheinbare) Option zur Nutzung von Ubuntu Core für ein derartiges Projekt ist. Die Dokumentation beschreibt einen Brand Store als zusätzliches Feature für größere Projekte und Softwarehersteller. Da wir die NextBox ohne Abonnement-Kosten anbieten, ist ein solcher Brand Store mit jährlichen Kosten von 30.000 $ für uns nicht wirtschaftlich und daher keine Option. Mittels Custom Images schienen wir auf den Brand Store verzichten zu können, und somit das Problem gelöst.

Natürlich hatten wir uns an dieser Stelle auch noch andere Optionen angeschaut, dazu aber später mehr...

Unsere Erfahrung mit Ubuntu Core

Kaum war die Entscheidung getroffen, begann sofort die Entwicklung eines Proof-of-Concepts. Dabei wurden zahlreiche Vorteile des Snap-Ökosystems schnell sichtbar:

• Es gab bereits ein Nextcloud Snap, sowie weitere Snaps, die wir benötigten
• Das Bauen eines Ubuntu Core Images ging gut von der Hand, inklusive der benötigten Snaps
• Images funktionieren problemlos auf unserer Zielhardware
• Ubuntu Builds von eigenen Snaps lassen sich auch auf anderen Plattformen nutzen

Entsprechend hatten wir in wenigen Tagen einen Proof-of-Concept entwickelt und erfolgreich getestet. Wir dachten: "Wow, das wird gut, 10 Jahre Sicherheitsaktualisierungen, schönes Ökosystem, Klasse!" Natürlich war auch schon an diesem Punkt sichtbar, dass wir uns an dieses Ökosystem anpassen müssen, was wir in Anbetracht des schnellen Fortschritts aber gerne akzeptierten.

Die Euphorie hielt nicht lange an und die ersten Rückschläge ließen nicht lange auf sich warten:

• Die NextBox muss die Möglichkeit haben externe Datenträger ins System einzubinden. Hierzu wurde bis mindestens Ende 2020 udisks2 als Lösung vorgeschlagen, was aber nicht problemlos funktionierte. (In der heutigen Ubuntu Core 20 Dokumentation wird udisks2 nicht mehr empfohlen.)
• Ein Snap ist verständlicherweise zahlreichen Einschränkungen bezüglich der Systemrechte unterlegen. Die Lösung hierzu sind sogenannte Interfaces welche auf den ersten Blick eine durchaus charmante Lösung darstellen: Ein Snap benennt die Interfaces, welche es benötigt und kann diese benutzen sobald sie verbunden sind. Dies haben wir an diesem Punkt nicht als echtes Problem wahrgenommen, sondern eher als typische Einschränkung eines derartigen Ökosystems.
• Das Ökosystem und die frei verfügbaren Werkzeuge erlaubten es nicht, ein auslieferungsfähiges Image zu erstellen. Das Verbinden der Interfaces stellte sich als ein größeres Problem heraus.

Der Plan war, mit den von Canonical bereitgestellten Werkzeugen ein Ubuntu Core NextBox Image zu erstellen, welches auf eine SD-Karte geschrieben wird und mit dem Raspberry Pi 4 in der NextBox ausgeliefert wird. Dazu war es nötig ein Gadget Snap in das Image einzubringen. Gesagt, getan: Das entsprechende Gadget Snap für den Raspberry Pi geforked, Anpassungen gemacht, zum Bauen in den Ubuntu Global Store eingestellt.

Das erwähnte Gadget-Snap wurde erfolgreich gebaut, aber es konnte nicht in den Global Store aufgenommen werden: "manual review required". Kurz darauf, kam es zum ersten Kontakt zwischen uns und Canonical. Zwei Verkäufer erklärten uns in einem Telefonat, dass dies nur mit einem kostenpflichtigen Brand Store möglich sei. Wir verwiesen darauf, dass wir, wie Canonical auch, eine Open-Source Firma sind und mit dem Produkt nicht ansatzweise genug Geld verdienen, um die Kosten für den Brand Store von jährlich 30.000 $ zu zahlen. Leider konnten wir keinen Kompromiss erwirken und wurden achselzuckend abgewiesen.

"Hey, das ist ein Rückschlag, aber das ist Open-Source, also lass uns eine Lösung finden!", hieß es während wir eine Lösung entwickelten, die wir als "Hack" bezeichneten. Im wesentlichen war die Idee, dass man unser Snap-Paket benutzt um die benötigten Funktionen ins System zu bringen. Das generierte Image wird daraufhin einmal gebootet und ein systemd-Dienst installiert, welcher die durch das Snap eingebrachten Funktionen als Root-Prozess ausführt. Das hebelt im wesentlichen die Snap Einschränkungen aus und erlaubt uns vollen Zugriff auf alles was man sonst nur mit einem "Brand Store" benutzen kann.

Im Prinzip war das lange unsere forcierte Lösung und wir hatten das Produkt damit vorangetrieben, nicht ganz wie gedacht, aber "Hey, wir kriegen 10 Jahre Updates" und wir haben unser Bestes getan um das Risiko des Hacks soweit möglich zu reduzieren. Mit diesem Ansatz konnten wir alle wesentlichen Funktionen wie z.B. DynDNS, USB-Zugriff, und Backups erfolgreich implementieren.

Canonical wird auf uns aufmerksam

Einige Wochen später war die NextBox ein erfolgreiches Kickstarter-Projekt. Canonical kontaktierte uns und wollte sich technisch mit uns über das Projekt austauschen. Natürlich willigten wir sofort ein, in der Hoffnung gemeinsam das Produkt zu verbessern und vielleicht kann sogar den Hack zu beseitigen.

Kurze Zeit später redeten wir mit zwei Software-Ingenieuren von Canonical. Die wesentlichen Erkenntnisse waren die folgenden:

• Die versprochenen 10 Jahre Support sind lediglich "gutes Marketing" und eigentlich gibt es nur 5 Jahre Support. Weitere 5 Jahre gibt es nur mit dem kostenpflichtigen Brand Store. Das würde bedeutet, dass wir von heute an lediglich 3 Jahre Sicherheitsaktualisierungen für Ubuntu Core problemlos bekommen könnten.
• Ubuntu Core 18 kann nicht auf Ubuntu Core 20 aktualisiert werden, ohne dieses bereits speziell vorzubereiten (undokumentiertes "Feature"). Wir könnten unsere Software noch vor Auslieferung auf Ubuntu Core 20 aktualisieren, aber das verwendete Nextcloud Snap Paket existiert lediglich für Ubuntu Core 18. Um später auf Ubuntu Core 20 zu aktualisieren müssten wir an einer komplizierten Aktualisierung der Geräte im Feld arbeiten.
• Canonical möchte uns unterstützen den Hack zu entfernen und motiviert uns auch dies zu tun
• Der Hack hat das zentrale Problem, dass alle Geräte im Global Store als das selbe Gerät identifiziert werden und "das kann zu Problemen führen".

Oha, das war ein harter Schlag für uns! Dennoch herrschte eine konstruktive "wir schaffen das"-Stimmung. Es wurden Informationen ausgetauscht und wir hatten das Gefühl es gibt einen Weg: Ohne Hack, mit Ubuntu Core 20 und einen Haufen Arbeit. Knietief im Ubuntu Core Ökosystem entschieden wir uns: "Ok, wir machen das jetzt richtig. Wird schon klappen, Support ist da, Let's go!"

Mit der neuen, von Canonical vorgesehenen Architektur, ließen die ersten Hürden nicht lange auf sich warten:

• Es gibt keine Möglichkeit eine externe Festplatte einzubinden (Deja Vu!)
• Interfaces können nur mit einem Gatekeeping-Prozess vielleicht automatisch verbunden werden. Oder man hat halt ein Gadget Snap, also einen kostenpflichtigen Brand Store.
• Interfaces wie GPIOs, I2C etc. können scheinbar nur in einem Brand Store überhaupt benutzt werden. Dies ist für uns relevant um zukünftig weitere Hardware-Features realisieren zu können.

Zum Glück antwortete uns Canonical, dass sie prüfen, ob wir kostenlos ein Gadget Snap im Global Store platzieren dürfen. Das würde die Probleme lösen.

Warum wir uns gegen Ubuntu Core entschieden haben

Seitdem haben wir von Canonical leider nichts mehr gehört. Natürlich hat uns Canonical zu keiner Zeit Versprechen oder belastbare Zusagen gemacht. Dennoch war der Tenor im Gespräch, dass Canonical uns unterstützen möchte die NextBox mit Ubuntu Core richtig zu machen. Bisher hat sich dies leider nicht bestätigt.

Schließlich blieb nur noch die eine Erkenntnis: Es geht nicht ohne Brand Store. Diese Paywall taucht immer wieder auf, an allen Ecken und Enden. Selbst wenn wir kostenlos ein Gadget Snap im Global Store bekommen hätten, würde Canonical uns sicherlich keine Zusicherung geben, wie lange sie dies erlauben. Entsprechend wäre das Risiko für NextBox Benutzer, dass uns Canonical irgendwann in der Zukunft dieses Privileg entziehen würde, und damit die NextBox vom einen auf den anderen Tag nicht mehr Aktualisierbar oder schlimmstenfalls unbrauchbar wäre.

Die Tatsache, dass die auf der Titelseite beworbenen 10 Jahre Sicherheitsaktualisierungen ein, vorsichtig gesagt, gut platziertes Marketing sind und ohne 30.000 $ pro Jahr einfach nicht der Wahrheit entsprechen, war die größte Enttäuschung. Das ist einfach nicht das, was wir von einem der Open-Source-Vorzeigeunternehmen erwarten. Selbst das Datasheet zu Ubuntu Core lässt diese Einschränkung lediglich mit "up to 10 years" erahnen.

Darüber hinaus zeigte sich, dass wir nicht ausreichend strikt nach Open-Source Kriterien ausgewählt hatten. Angenommen Canonical gäbe es irgendwann nicht mehr oder würde Ubuntu Core einstellen, dann wäre es mit Ubuntu Core nahezu unmöglich für die Open-Source Community dafür zu sorgen, dass die NextBox weiterhin sinnvoll benutzbar ist. Der restriktive Gedanke von Ubuntu Core zeigt hier seine Schattenseiten. Zusätzlich sei erwähnt, dass das Gatekeeping für den Global Store die inhärente Freiheit von Open-Source einschränkt. Selbst wenn wir einen Brand Store hätten, wäre es nahezu unmöglich die Geräte weiterhin aktuell zu halten oder durch die Community weiterzuentwickeln.

Schlussendlich blieb uns keine andere Möglichkeit als Ubuntu Core den Rücken zu kehren, um eine NextBox zu realisieren, die ihr Versprechen hält.

Der König ist tot, lang lebe der Debian

Also haben wir mit diesen neuen Erfahrungen erneut die verfügbaren Optionen analysiert und miteinander verglichen. Dabei galt es nach wie vor die eingangs beschriebenen Anforderungen zu erfüllen. Zusätzlich achteten wir darauf einen Gatekeeper zu vermeiden, der potentiell das System unbrauchbar (oder nicht mehr wartbar) machen könnte. Unter anderem betrachteten wir folgende Systeme:

Buildroot, Yocto, OpenEmbedded

Mittels Buildroot lässt sich ein speziell zugeschnittenes System bauen, welches folglich eine minimale Größe aufweist. Dies würde eine minimale Angriffsfläche bieten und somit ein sicheres System ermöglichen. Der Konfigurationsaufwand für ein Buildroot Image ist aber aus eben diesen Gründen alles andere als trivial. Ebenso ist die Flexibilität des resultierenden Systems begrenzt und ein Luxus wie einen Paket-Manager gibt es ganz bewusst nicht. Yocto, oder genereller OpenEmbedded, bieten zusätzlich einen Paket-Manager, aber die Vielfalt und schnelle Verfügbarkeit von Sicherheitsaktualisierungen bleiben hinter Debian (dazu später mehr) zurück. Daher sind sie ähnlich einzuordnen: Initial sehr gut adaptierbar, später aber Einbußen in der Flexibilität und bei Sicherheitsaktualisierungen. Die größte Herausforderung wäre aber, das Gesamtsystem zuverlässig zu aktualisieren. Da mit Buildroot wir die Verantwortung hätten, für jede eingesetzte Software-Komponente Sicherheitsaktualisierungen zu bewerten, einzuspielen und zu testen, wäre dies ein hoher Maintenance-Aufwand. Daher verwundert es nicht, dass viele Consumer-Produkte, die auf solchen kleinen Systemen basieren, nur unzureichend mit Sicherheitsaktualisierungen versorgt werden.

balenaOS

BalenaOS befindet sich bzgl. Flexibilität, Einfachheit und Kontrolle eindeutig auf der gegenüberliegenden Seite des Spektrums. Prinzipiell wird hier auf eine Container-Orchestrierung gesetzt, zusätzlich zu einem Supervisor-Container. Also ein ähnlicher Ansatz wie ihn Ubuntu Core mit Snap verfolgt. Das Ökosystem ist auch sehr umfangreich, insbesondere die breite Unterstützung von verschiedenster Hardware fällt sehr positiv auf. Zudem gibt es mit openbalena eine selbst betreibbare Alternative zur kommerziellen balenaCloud, welche zwar leicht eingeschränkt ist, aber schon die wichtigsten Funktionen als Open-Source Lösung bietet.

Hier zeigt sich am deutlichsten wieso die NextBox eben kein IoT Produkt ist, zumindest nicht in der Interpretation von Canonical oder Balena: openbalena erlaubt u.a. mittels SSH-Login die vollständige Kontrolle über die Geräte im Feld. Das ist eindeutig nicht das was wir unseren Kunden anbieten möchten. Am Ende soll die NextBox ein Gerät mit minimalem Administrationsaufwand sein, aber auf keinen Fall ein von uns kontrolliertes.

Debian

Debian bietet den Vorteil einer enorm großen Community und vollständiger Offenheit. Es hat hohe Ähnlichkeit mit Ubuntu Core und somit das was am nächsten der Benutzer-Erfahrung von Ubuntu Core entspricht, ohne die oben beschriebenen Einschränkungen. In Bezug auf Systemgröße und Flexibilität ordnen wir Debian ziemlich genau zwischen balenaOS und Buildroot ein: Wir können mittels Debian-Paketen und zusätzlicher Containerisierung sicherstellen, dass das Gerät robust und sicher ist. Gleichzeitig haben wir aber nicht die direkte Kontrolle über das Gerät. Dennoch ist es für den Benutzer möglich auf das Gerät zuzugreifen und zusätzliche Pakete zu installieren.

Im Vergleich zu Ubuntu Core ist Debian sogar sicherlich über einen längeren Zeitraum sehr stabil zu betreiben, inklusive automatischer Sicherheitsupdates. Konkret ist der Long-Term-Support für Debian Buster bis Juni 2024 angesetzt und in der Regel sind nochmal 2 zusätzliche Jahre bis 2026 für den Extended-Long-Term-Support zu erwarten. Entsprechend wird ohne unser Zutun die NextBox von heute rund 5 Jahre mit Sicherheitsupdates versorgt. Dies sind 2 Jahre mehr als mit Ubuntu Core 18. Unser Ziel ist es spätestens zum Ende des Long-Term-Supports eine weitestgehend automatisierte Möglichkeit anzubieten, auf die nächste Debian Version zu wechseln und somit weitere 5 Jahre Sicherheitsaktualisierungen zu erhalten. Mit Ubuntu Core wäre eine entsprechende Upgrade-Möglichkeit von Ubuntu Core 18 auf Ubuntu Core 20 unklar, da dies von Canonical nicht vorgesehen ist!

Als Kerntechnologie zum Deployment von Nextcloud und den Abhängigkeiten verwenden wir Docker, was uns eine ähnliche Kontrolle und Restriktion ermöglicht wie der Snap Ansatz von Ubuntu Core. Gleichzeitig sind wir wesentlich flexibler und es gibt keinen Gatekeeper um z.B. GPIOs zu benutzen.

Wir bauen ein ähnlich robustes System wie Ubuntu Core, indem wir ähnliche Konzepte verfolgen. Dabei profitiert der Benutzer von der mit Debian eingeführten Flexibilität:

• Nur minimale Schreibzugriffe auf die SD-Karte, indem schreibintensive Verzeichnisse auf die interne Festplatte bzw. SSD ausgelagert sind.
• Spezifische Versionskombinationen der verwendeten Container erlauben es, Versionssprünge vorab zu testen und diese als ganzes mit dem NextBox Debian Paket auszurollen.
• Verschiedene NextBox Pakete bilden verschiedene Stabilitätsstufen ab: stable, testing, unstable
• Unattended Upgrades sorgen für Security-Updates und aktualisieren das NextBox Debian Paket. Durch die gute Integrierbarkeit von apt, könnten wir zukünftig auch anbieten Systemsoftware direkt aus der Nextcloud NextBox App zu installieren.

Ubuntu Core wird mit "minimal core, minimal risk, minimal bugs" beworben. Ein Vergleich mit Debian ist schwierig, weil nicht eindeutig ist, welche Systembereiche miteinander vergleichbar sind. Trotzdem konnten wir mit Debian ein vergleichbar schlankes System bauen: Die Basissysteme sowohl von Ubuntu Core als auch von Debian haben jeweils eine Gesamtgröße von ca. 1 GB.

Die gesamte Funktionalität der NextBox kann nun durch ein Debian Paket bereitgestellt werden, was zahlreiche Vorteile mit sich bringt wie zum Beispiel Testbarkeit und Plattformunabhängigkeit. Zwar ist letztere auch mit einem Snap-basierten Ansatz möglich, aber halt nur mit einem Brand Store.

Aus Entwicklersicht ist es eine enorme Erleichterung sich nicht mehr in das Ubuntu Core Ökosystem zwängen zu müssen. Aber das bedeutet natürlich auch eine größere Verantwortung, da hier generell schon mehr Freiheiten existieren und diese natürlich richtig genutzt sein wollen.

Da unsere Systemarchitektur, der sog. Hack, üblichen Unix-Methoden folgt, dauerte die Umstellung auf Debian nur wenige Tage.

Zusammenfassung

Ubuntu Core und balenaOS scheinen sich eher an hochpreisige Systeme zu richten, bei denen der Hersteller (besser: Betreiber) die Kontrolle behält. Vermutlich eignet sich dies für Consumer Produkte nur ab einer hohen Stückzahl mit Abo-Preismodell. Besser passen diese Systeme beispielsweise zu Industrie-Systemen und -Maschinen.

Speziell zugeschnittene Systeme, die sich z.B. mittels Buildroot bauen lassen, erscheinen eher für kleine Hardware sinnvoll. Zudem ist der Maintenance-Aufwand nicht unerheblich. Auf einer relativ mächtigen Hardware wie dem Raspberry Pi (der NextBox) erscheint uns der Mehraufwand als unnötig.

Mit Debian haben wir ein System bei dem wir mit wenig Aufwand die von Ubuntu Core versprochenen Leistungen erhalten, die wir für die NextBox benötigen: kleine Systemgröße und hohe Sicherheit, Robustheit, langjährige Sicherheitsaktualisierungen, gute Hardwareunterstützung und volle Freiheit.