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.

10.3.2021

Comments

Ich hätte es gut gefunden, wenn Ihr euch für eine eurpäische Distribution entschieden hättet, z.B. openSuSE. Klar habt Ihr einige valide spezielle Anforderungen, aber vll. kann man mit solchen Partnern besser arbeiten. Außerdem gibt es halt europäische Rechtssicherheit und europäische Software. Die Updatefähigkeit für die nächsten 10 Jahre halte ich Allgemein für unrealistisch. Besser wäre die Hardware nach 5 Jahren zurückzunehmen und zu recyclen und dann muss gegen neue Hardware und OS getauscht werden.
Welchem Staat ordnest du debian denn zu? Was ist „europäische Software“ im Kontext von freier Software? Sollte der Kernel (Linux) ausgetauscht werden, weil Torvalds (offizieller Hauptentwickler) in den USA lebt? Jetzt zu planen, alle NextClouds in 5 Jahren zu verschrotten, halte ich für mindestens fragwürdig. Klingt nicht besonders nachhaltig, direkt zu sagen „mehr als 5 Jahre überlebt es sowieso nicht“. Verschrottung und Ersetzung in 5 Jahren klingt auch sehr unökologisch.
Vielleicht war es etwas missverständlich ausgedrückt. Es geht um einen europäischen Geschäftspartner - nicht darum das alles in Europa entwickelt werden muss. Klar Debian und etwas eigenes machen ist auch vollkommen valide, wenn garantiert ist das es weiterhin aktualisiert wird. Es ist wie gesagt nichts gegen die Entscheidung selber, die sehr gut im Blog begründet wurde und auch vollkommen ok ist. Recyclen ist ebend nicht verschrotten, sondern wiederverwenden! Und alte Hardware ewig laufen zu lassen kann auch zu Nachhaltigkeitsproblemen führen. Ich finde man muss da nicht auf die 10 Jahre fixiert sein. Auch hier gilt, dass dies alles im Blog gut begründet wurde.
@Jörn: Den Aspekt eines Geschäftspartners konnte ich aus dem Text gar nicht erkennen. Viel mehr wurde ja auf die eigene Verantwortung verwiesen. Bei tatsächlich auftretenden Problemen könnte man sich ja immernoch an einen deutschen oder europäischen Partner wenden. Würde mich wundern, wenn es da nicht mindestens eine Hand voll Systemhäuser gibt, die das anbieten. Und beim Thema Nachhaltigkeit würde ich eine möglichst lange Nutzung einer Nachverwertung vorziehen. Es wurde in Studien mehrfach nachgewiesen, dass eine lange Lebensdauer fast immer nachhaltiger ist als eine Neuanschaffung. Grund dafür ist der hohe Energie und Ressourcenverbrauch bei der Herstellung. @nitrokey Ich finde, dass das ein schöner Artikel ist, weil ihr damit genau eure Hoffnungen und Schmerzpunkte beschreibt. Ich hoffe, dass ihr damit die richtigen Leute erreicht, die vor einer ähnlichen Entscheidung stehen.
Ich finde den Ansatz gut und danke für den ausführlichen Artikel. Evtl. könnte man sich im Docker-Umfeld auch noch einmal mit Podman auseinandersetzen. Hier gibt es auch die Möglichkeit einen Pod (wie in Kubernetes) allerdings im User-Mode laufen zu lassen. Eine Verwaltung könnte man z. B. mit Cockpit erreichen. Das Letztere würde das System allerdings ein wenig aufblähen, wobei man dem Nutzer die Installation auch selbst überlassen könnte. Als kleinere Schaltzentrale ist das ein nettes Werkzeug und man könnte die Installation neuer Anwendungen darüber ein wenig vereinheitlichen. So ließe sich z. B. auch die GPIO/I2C-Anwendung in Podman von NextBox getrennt entwickeln und bereitstellen. Wenn man dann noch alles im User-Mode z. B. unter dem nextbox-User laufen lassen könnte, wäre eine super Trennung vom restlichen OS-Umfeld erreicht.
Blos weil das udisks2 snap nicht mehr existiert, heisst das nicht dass man nicht selbst eins hochladen kann, siehe github.com/ogra1/automount ... bindet automatisch eingesteckte USB platten ein die dann in /media auftauchen wo nexcloud sie findet wenn das "removable-media" interface verbunden ist ... die gadget problematik ist meines wissens nach gelöst, nichtkommerzielle community projekte sollen nach prüfung ihre gadgets auch in den global store hochladen und so defaults und interface connections definieren können ...

"Blos weil das udisks2 snap nicht mehr existiert, heisst das nicht dass man nicht selbst eins hochladen kann, siehe github.com/ogra1/automount ... bindet automatisch eingesteckte USB platten ein die dann in /media auftauchen wo nexcloud sie findet wenn das "removable-media" interface verbunden ist"

Ziemlich genau so haben wir das auch versucht (denke das ist auch im Artikel beschrieben, sorry wenn das nicht ganz klar wird, Stich-/Suchwort: "Deja Vu!"), aber u.a. geht der usdisks Service nicht ohne manual review in den Global Store, vielleicht hat sich das ja geändert verglichen zu dem "automount" Veröffentlichungsdatum?

"die gadget problematik ist meines wissens nach gelöst, nichtkommerzielle community projekte sollen nach prüfung ihre gadgets auch in den global store hochladen und so defaults und interface connections definieren können ..."

Gibt es dafür eine belastbare Quelle? Unsere Erfahrung war da nämlich gleich an zwei Canonical Kontaktpunkten (Sales & Engineering) leider eine andere. Wie im Artikel beschrieben haben wir explizit auf unsere Open-Source Wurzeln verwiesen, sind damit aber nicht wirklich vorangekommen. Mehr als ein "wir prüfen die Option, dass ihr ein Gadget Snap bekommt" kam leider nie zustande. Streng genommen sind wir halt auch kein "nichtkommerzielles community Projekt", vielleicht ist hier das Problem.

Noch eine persönliche Bemerkung hierzu: Meiner Meinung nach ist das Problem ist hier wirklich das Gatekeeping, "sollen nach Prüfung ihre Gadgets auch in den global store hochladen" ist einfach leider kein Open-Source, das ist ein gratis Bier, welches ich heute bekomme und morgen vielleicht nicht mehr. Open-Source sollte Freedom / Freiheit bedeuten. Generell halte ich das gesamte Snap-Ökosystem für wirklich gut, was fehlt ist einfach: Mach dir deinen eigenen Store, selbst gehostet, von mir aus mit beschnittenen Features. Dass dies nicht geht, gepaart mit der Tatsache, dass sich Canonical beim Global Store so restriktiv aufstellt, ist einfach eine nicht zu unterschätzende restriktive Interpretation von Open-Source.

Einen eigenen Snap Store kann man wohl recht einfach selbst hosten. Einfach mal nach "HOWTO: Host your own SNAP store!" suchen, da beschreibt Dustin Kirkland wie das funktioniert. Hattet Ihr das nicht in Betracht gezogen? Und wenn nein, warum nicht?
Interessanter Fund, der Artikel ist von Juni 2016, das Repository wurde im August 2017 geleert, enthält nur noch die neue Readme (https://github.com/noise/snapstore) im wesentlichen steht da: "Geht nicht mehr." Also zu den Fragen: Ja haben wir in Betracht gezogen, geht aber nicht.
Hi, You guys should check the English version of your KickStarter campaign page for NextBox - you still reference Ubuntu Core. I can see in the German version that you've updated this to Debian :) Good work, sounds like you made the right decision!
Thank you for the pointer. We fixed it now.

Es klingt etwas seltsam, wenn man schreibt, „ich bin froh, dass Ihr damit gescheitert seid“, aber ich bin es tatsächlich. Scheitern gehört bei der Entwicklung immer dazu und es ist wichtig, wie man mit dem Scheitern umgeht. Ich bin froh, wie es gelaufen ist und finde es positiv, dass Ihr das Scheitern sogar dokumentiert. Ihr habt Euch von „Es gibt Zweifel, wohin sich Nitrokey entwickeln wird“ hin zu „Der Ausflug ist beendet, man kann das Vertrauen wieder aufbauen” in meinen Augen gemausert.

Als ich von der NextBox laß, interessierten mich auch die Specs und als ich UbuntuCore laß, habe ich die Hände über dem Kopf zusammengeschlagen und mir nur gedacht, wie können die nur. Ich habe einen NitroKey(1) und hatte mich für diesen damals entschieden, da ich OpenSource wenn überhaupt unterstützen wollte und auf Sicherheit bedacht war. Mit UbuntuCore hätte ich dieses Produkt definitiv nicht gekauft und hätte es auch niemandem empfohlen.

UbuntuCore durch snap hat man ein Walled Garden, genauso wie mit Apple. Es gibt einen Gatekeeper und das ist Ubuntu und falls die plötlich keinen Bock mehr haben, dann drehen sie etwas eventuell ab. snap ist auch kein OpenSourceökosystem, denn es funktioniert nicht ohne Canonicals nicken. Es gibt jetzt schon nur NextCloud für UbuntuCore18, nicht 20. Wer sagt, dass es dies bald garnicht mehr gibt und wer garantiert für Updates? Canonical hat in der Vergangenheit schon sehr oft gezeigt, dass ihre Entwicklungen ein Griff ins Klo sind - upstart, mir, netplan, snap. upstart war davon am erfolgreichsten und verwendet inzwischen niemand mehr. mir wurde bei der Ankündigung bereits verrissen und netplan hat nichts neues beizutragen, im Gegenteil, man hat sofort Einschränkungen, die man zuvor (ifupdown) nicht hatte (VLAN-Support). Ubuntu war Canonicals einziger erfolgreicher Schritt, welcher wirklich OpenSource und den Menschen etwas positives gebracht hat. Somit hoffe ich sehr, dass snap keine Zukunft hat.

Wer nichts Zahlt, ist nicht Kunde, sondern Produkt. Ihr hättet Canonical nichts bezahlt, aber dafür hätte Canonical Euch einstellen können, wie sie es mit jedem Produkt hätten machen können. Mit einem Vertrag hättet Ihr eine vertragliche Zusicherung. Aber ich bin froh, dass Ihr Euch das nicht leisten konntet. ;)

Das snap irgendwie zusätzliche Sicherheit brächte gegenüber debs ist definitiv nicht möglich, denn als Benutzer kann ich nicht einmal die Builds kontrollieren, ob diese wirklich aus den angegeben Sourcen erstellt worden sind. Reproduceable Builds sind bei debs kein Problem. Wenn Canonical will, kann es fremde Software einschleusen. Das Vertrauen ist somit für mich nicht vorhanden. Bei docker/podman sieht dies deutlich besser aus.

Aber auch zu den Images gibt es immer viel Potential für Kritik. Wer garantiert, dass es Updates für die Software gibt? Bei docker-Images gibt es einen Ersteller. Oft gibt es nur Updates für das Image, wenn eine neue Version der Software veröffentlicht wurde. Bugs im Betriebssystem werden hingegen vollkommen ignoriert. Wie die Updatepolitik der NextCloud-Images ist, weiß ich nicht, mir ist dies zuletzt bei MediaWiki aber aufgefallen. Fixes für Sicherheitslöcher des Webservers wurden nicht als Anlass genommen, ein neues Image zuerstellen, das Sicherheitsloch blieb offen.

Daher wäre von mir an die NextBox aus Sicherheitsgründen auf jeden Fall die Anforderung: Jegliche Software muss zeitnah mit Fixes bedacht werden und nicht nur die Software, dessen Name auf dem Image steht. Im Endeffekt ist dies eine Anforderung an Euch, denn Ihr wollt die NextBox anbieten. Der Kunde ist sonst von Euch enttäuscht, denn Ihr preist es mit Sicherheit an. Macht Euch daher vertraut mit den Images, die Ihr verwendet. Macht am Besten von Anfang an ein Fork vom eigentlichen Image, damit Ihr die Kontrolle darüber habt, welches Image zu Anfang installiert ist. Wenn das NextCloud-Image plötzlich freidreht, könnt Ihr den Kunden nicht sagen, „wir haben zwar gesagt, Ihr müsst nichts tun, aber leider müsst Ihr nun leider doch etwas tun und zwar bezieht nicht mehr NextCloud, sondern wechselt zu NextBox/NextCloud“. Die wichtigsten Images sollten von Euch bereits verwaltet werden. Reproduceable Builds sollten wohl klar sein. Eventuell baut einen eigenen Docker-Hub auf, um auch vom eventuellen freidrehenden Docker unabhängig zu sein. Der Kunde vertraut Euch und Ihr wollt nicht das Vertrauen der Kunden verlieren, nur weil Ihr Euch schlechte Partner ins Bett geholt habt. Falls der Kunde Euch irgendwann nicht mehr vertraut, weil Ihr Sch**** gebaut habt, dann ist das war ganz anderes. Der aufgeklärte Benutzer kann immer noch zum original NextCloud-Image wechseln, den anderen fällt dies erst garnicht auf.

Es wurde podman bereits erwähnt. Mit bullseye wird podman bei Debian dabei sein. Frische/junge Software unterliegt oft nervigen Fluktuationen. Bei Debian bleibt es aber stabil bei einer Version. Ich habe noch keine Erfahrung mit podman, aber es klingt „besser“ als docker. Da die selben Images bezogen werden können, sollte es auch kaum ein Risiko geben, dass sich Formate ändern. Besonders wenn Ihr einen eigenen Docker-Hub betreibt.

Wegen der finanziellen Risiken und den laufenden Kosten, kann ich es verstehen, wenn Ihr kein Docker-Hub betreiben werdet. Aber das eigene NextCloud-Image ist schon etwas, was Ihr Euch leisten könntet.

Habt Ihr bedacht, dass NextCloud seine Architektur umstellen will? Wie wollt Ihr damit umgehen?

Ich wünsche Euch viel Erfolg mit der NextBox und dass es für Euch und den Kunden eine Bereicherung wird.

Danke das produktive Feedback, kurz zu den zentralen Punkten: Die Docker Images sind auf eine Version festgenagelt, in voller Konsequenz müsste man auch Images wie MariaDB und Redis forken, momentan sehen wir das nicht als nötig an, da wir aber über unser Debian NextBox Paket die ausgerollten Images & Versionen voll in der Hand haben, werden wir das genau beobachten und eventuell doch noch forken. NextCloud 21 bringt bereits das neue Rust File Backend, das läuft bereits bei uns im Testbetrieb, für die Architekturanpassungen machen wir uns auch wenig Sorgen, dass die zu Problemen führt, die wir nicht unter Kontrolle haben.
With all that you mention, I wonder why you didn't pick Debian as the first choice. You'd have saved everyone's time.
Auf Kickstarter in den FAQ: How to make sure... wird auch noch Ubuntu Core erwaehnt (Und ich bin hier um zu sehen ob Nextbox die Nachfolge meiner Nextcloud.box mit UbuntuCore ersetzen kann)
Danke für den Hinweis. Wir können jetzt ohne Weiteres die FAQ nicht mehr ändern. Haben eine Anfrage an Kickstarter gestellt...
Fedora IOT mag keine Turnkey Lösung sein, ist aber flexibel genug um fast jede mögliche Konfiguration umzusetzten. Vor allem hat Fedora IOT natürlich mit RPM OSTree einen extrem stabilen update Mechanismus.
very good article very nice to read the full story, about the development, and the decisions that had to be taken, to make sure the Nextbox vision was fulfilled. i hope you guys have other kickstarters coming in the future. Future kickstarter ideas: selfhosted email server on a Raspberry pi or a raspberry pi tor vpn router or something like this :)
Good read. It provides context to your rationale. Other providers can learn from this openness. Suggestion, add the OS of you choice, Debian in this case, to the Specification list on the product page. It may give potential end-users instant clarity on this topic.
Debian ist eine gute Wahl aber viel zu fett. Schon mal über OpenBSD arm nachgedacht? Läuft auch mit 350MB Platz und sehr wenig Ram sehr gut auf einem Raspi 4. Sauberes, sicheres UNIX, Open Source, gut zu pflegen (syspatch), einfach upzugraden (sysupgrade). Lediglich das direkte Booten auf dem Raspi (nicht von SD Card) ist etwas komplizierter.
"viel zu fett" ist sehr subjektiv. Es gibt natürlich dutzende von Alternativen wie z.B. OpenBSD. Ohne Grund werden wir nicht wechseln und bisher sind wir mit Debian sehr zufrieden.
Nice story. Thanks for sharing. I think you made the right choice and hope you will give back to Debian, they deserve it.
Thanks a lot for the article, I think is very important to document these kind of processes, where you eventually find the solution after walking over your first assumptions. One question only, why "standard" Ubuntu was not an option?
Once we did the step away from a very specialized (IoT) distribution, the field of possible distribution is very wide. One reason for Debian instead of Ubuntu was clearly the "uncompromised open source" approach Debian goes, which is also stated in the article. But likely heavier weights the fact that we have more experience and know-how in Debian, which for us was a not to be underestimated factor, too.
Have you considered using the Super Long Term Support Debian from the Linux Foundation Project "Civil Infrastructure Platform"? It is based on Debian and comes with real 10 years support backed by funding from international companies.
The arguments are roughly the same as for the "Why not Ubuntu?" question just before. In summary: We have quite some Debian experience and we consider this an important factor. But admittedly we did not look into the "Civil Infrastructure Platform" in detail as the (Extended) Long-Term-Support provided by Debian itself is already pretty long.
Specifically, how do you handle kernel updates/rollback and factory restores? Does the user install a new SD card if the system breaks or do you have recovery partitions that can be booted? I like the idea of the base snap/docker that installs the base system services.
System level (security) updates (including the nextbox package) are delivered via unattended-updates. Factory-Reset is essentially a script (triggered via the hardware button) which is executed and cleans up any user-data on the system, there is no 2nd (recovery) partition.
Thank you for the article. Now if anyone tell me he wants to use Ubuntu Core for IoT I will link him this. All in all, Canonical has been always eager to monetise linux and their idea is Snap. At first, I had high hopes for Ubuntu Core as I wanted to use it for our IoT fleet but now I think there is are lots of better options out there. For IoT Canonical still leagues behind, a skilled engineer can offer better.

Add new comment

Fill in the blank.