Linux für Unternehmen ist im Wandel begriffen, die Distributionen für Server und den Heimanwender ziehen nach. Wo führt die Entwicklung hin?

Die Frage, wie der Linux-Desktop in zehn Jahren wohl aussehen mag, lässt sich aktuell schwerer beantworten als jemals zuvor. Das liegt daran, dass Linux sich in einer Phase des Wandels befindet, wobei nicht klar ist, welche Distributionen die neuen Wege mitgehen. Das verunsichert zunehmend die Anwender, denn zumindest Fedora und OpenSuse werden in wenigen Jahren ganz anders funktionieren als heute. Das könnte die Kluft zwischen Enterprise-Linux und dem, was wir zu Hause nutzen, künftig vertiefen.

Bevor wir uns aber die Details näher ansehen, noch ein Hinweis: Wenn wir im Folgenden von Linux sprechen, meinen wir nicht den Kernel, sondern das gesamte Linux-Ökosystem.

Immutable

Einer, der den Wandel bereits seit vielen Jahren fordert und fördert, ist Systemd-Mastermind Lennart Poettering (Abbildung 1), der vor einigen Monaten von Red Hat zu Microsoft wechselte. LinuxUser berichtete bereits in Ausgabe 12/2014 über seine Forderung nach unveränderlichen Dateisystemen [1]. Gelegentlich werden diese Systeme auch als persistent bezeichnet. Das sorgt aber eher für Verwirrung, da dieser Begriff unter Linux bereits anders besetzt ist.

Abbildung 1: Lennart Poettering, ein Befürworter unveränderlicher Dateisysteme, wechselte im Sommer von Red Hat zu Microsoft. Das tut der Entwicklung von Systemd jedoch keinen Abbruch.

Der englische Fachbegriff dafür lautet “immutable”. Was es damit auf sich hat, erklärt der Kasten “Immutable File System”. In seinem Blog [2] breitete Poettering seine Ideen stets in langen Essays aus [3]. Darin finden sich viele Ideen, die heute die Vordenker der Linux-Zukunft wieder aufgreifen. Erst im Mai dieses Jahres erläuterte Poettering, wie die Werkzeuge für neue Distributionsmodelle aus seiner Sicht zusammenpassen [4].

Unveränderlicher Kern

In der Theorie soll nach den Plänen von Unternehmen wie Red Hat und Suse die Zukunft von Linux-Betriebssystemen aus einem unveränderlichen Kern bestehen, den atomare Updates aktuell halten. Atomar bedeutet in diesem Zusammenhang, dass eine Aktualisierung entweder komplett oder gar nicht stattfindet. Dabei wird ein komplettes Image gegen ein aktuelleres ausgetauscht. Gibt es Probleme mit dem neuen Image, steht es dem Anwender frei, auf das zuletzt als funktionierend bekannte Exemplar zurückzurollen. Das Image lässt sich temporär oder permanent einbinden.

Ein weiterer Vorteil für Administratoren: Alle Instanzen einer solchen Distribution sind im Kernsystem identisch. Die Anwendungssoftware liegt auf einer anderen Ebene mit Schreib- und Lesezugriff, wodurch sie sich mehr oder weniger wie heute üblich handhaben lässt. Dabei unterscheidet sich die Vorgehensweise der Entwickler hauptsächlich darin, wie die Pakete ins System gelangen.

Fedora Silverblue

Die von Red Hat unterstützte Distribution Fedora ist mit den Experimenten in Richtung Linux 2.0 vermutlich am weitesten fortgeschritten. Schon 2018 wurde erstmals das “Team Silverblue” (Abbildung 2) erwähnt, die Wurzeln liegen in der Fedora Atomic Workstation.

Abbildung 2: Oberflächlich betrachtet unterscheidet sich Fedora Silverblue kaum von der Fedora Workstation. Die Unterschiede liegen auf der Ebene des Dateisystems.

Ein Positionspapier klärt über das Vorhaben auf [5]. Dort steht zu lesen: “Das langfristige Ziel dieser Bemühungen ist die Umwandlung von Fedora Workstation in ein Image-basiertes System, bei dem die Anwendungen vom Betriebssystem getrennt und die Updates atomar sind”. Als Bestandteile nennt es Gnome, RPM-OSTree, Flatpak (Abbildung 3) und Flathub. Wie die Vision für Fedora Workstation im Detail aussieht, skizzierte Christian Schaller von Red Hat im Herbst 2021 in seinem Blog [6].

Abbildung 3: Die Flatpaks aktualisiert in Silverblue der Befehl flatpak update, während den Kern RPM-OSTree handhabt.

Seit Fedora 29 dient Silverblue (Abbildung 4) als ein eigenständiger Bestandteil des Fedora-Distributionsmodells. LinuxUser warf in Ausgabe 12/2019 bereits einen ersten Blick auf die Fortschritte [7]. Hauptakteur bei Silverblue ist OSTree [8].

Abbildung 4: Silverblue lässt sich sowohl über das Terminal als auch über die Anwendung Gnome Software aktualisieren. Die hier zum Update anstehenden Pakete lassen sich nicht wie üblich einzeln aktualisieren, sondern nur als Ganzes – inklusive Neustart.

Dabei handelt es sich sowohl um eine gemeinsam genutzte Bibliothek (Libostree) als auch um eine Reihe von Kommandozeilenwerkzeugen. Man kann sich das Ganze wie ein Git für Betriebssystem-Binärdateien vorstellen. Wenn Sie unter OSTree ein Paket installieren, erstellt es zunächst einen Wiederherstellungspunkt. Dann folgt das Einrichten des Pakets. Die Änderungen am Dateisystem werden in einem Verzeichnis protokolliert und künftig weiterverfolgt. Weist das aufgefrischte Paket einen Fehler auf, kehren Sie einfach zum letzten Wiederherstellungspunkt zurück, und alles ist wie vorher (Abbildung 5).

Abbildung 5: Eine Statusabfrage nach einem Rollback zeigt oben die gerade aktive Version und darunter das Image, von dem aus zurückgerollt wurde.

Wie bei Android

Das damit erstellte Kernsystem wird schreibgeschützt eingebunden, womit es sich im Normalfall nicht verändern lässt, es sei denn, man tauscht das Image aus. Dieses Vorgehen kennt man bereits von Android und Chrome OS. Es ermöglicht eine Robustheit des Grundsystems, die sich mit herkömmlichen Paketsystemen nicht erreichen lässt. Eine Aktualisierung des Betriebssystems berührt die vorhandene Instanz zunächst nicht, da sie separat ausgerollt wird. Nach einem Reboot befindet man sich dann im aktualisierten System. Stellt sich das System als instabil heraus, kehrt man zur vorigen Version zurück. Das gleicht ein wenig den Snapshots von Btrfs.

Die Anwendungssoftware für ein solches System kommt bevorzugt als Flatpak aus dem zentralen Flathub-Repository. Die Installation von Paketen im RPM-Format ermöglicht OSTree in einer separaten Schicht außerhalb des Root-Dateisystems, wobei es jedoch wegen des bereits implementierten Sandboxings Flatpak favorisiert. Derart zusammengesetzte Betriebssysteme sollen die Stabilität eines LTS-Releases aufweisen, sind dabei aber deutlich aktueller.

Toolbox

Da sich Silverblue aber auch an Entwickler wendet, fehlt noch eine Möglichkeit, Kommandozeilenwerkzeuge und Entwicklungsumgebungen zu integrieren. Hier kommt Toolbox [9] ins Spiel. Das bei Fedora entwickelte Werkzeug erstellt eine containerisierte Kommandozeilenumgebung auf dem Fedora-Basissystem. Das auf der Spezifikation der Open Container Initiative (OCI) und auf Podman basierende Werkzeug benötigt keine Root-Rechte, um diese Container auszurollen. Im Toolbox-Container lassen sich mittels Yum oder Dnf die benötigten Tools installieren. Benötigt man sie nicht mehr, löscht man einfach den Container (Abbildung 6).

Abbildung 6: Mit Toolbox-Containern lassen sich per Dnf oder RPM Werkzeuge nachinstallieren, die das auf grafische Anwendungen zugeschnittene Flatpak-System nicht anbietet.

Ein weiteres Schmankerl steckt hinter dem Befehl rpm-ostree rebase. Er erlaubt es beispielsweise, ein Fedora Silverblue 37 in ein Fedora Workstation 35 umzuwandeln. Das Tool lädt die Wunschversion im Hintergrund herunter, danach steht sie zum Booten bereit. So gelingt auch der Wechsel von Silverblue zum experimentellen Rawhide oder zu Fedora Kinoite, der KDE-Variante von Silverblue. Auf Wunsch kehren Sie dann wieder zum Ausgangssystem zurück. Wie man sieht, vereinfacht das Prinzip, Up- oder Downgrades in Form von Images einzurichten, vieles.

Suse ALP

Weder steht derzeit fest, wann Silverblue den Platz von Fedora Workstation übernimmt, noch ob es die Workstation-Version weiter auf RPM-Paket-Basis geben wird. Ähnliche Fragen müssen sich mittlerweile auch die Nutzer von OpenSuse stellen, denn der Distributor aus Nürnberg strebt mit seiner Adaptable Linux Platform (ALP) prinzipiell in dieselbe Richtung wie Fedora und peilt ein unveränderliches Dateisystem an, mit davon abstrahierten Anwendungssoftware in Containern [10]. Bereits seit einiger Zeit liefert Suse mit MicroOS ein kleines Betriebssystem für Container, das als Basis OpenSuse Tumbleweed nutzt und ebenfalls dem Rolling-Release-Prinzip folgt.

Darauf aufbauend arbeiten die Entwickler derzeit an ALP, der künftigen Enterprise-Linux-Architektur von Suse. Mittlerweile erschien ein erster Prototyp [11]. Bei ALP stellt ein modifiziertes MicroOS das unveränderliche Kernsystem, containerisierte Anwendungen ergänzen es. Das Konzept geht dabei über Silverblue hinaus, denn das Projekt strebt ein selbstheilendes System an. Dafür sollen Werkzeuge wie Salt, Ansible und Zero Touch Provisioning (ZTP) sorgen, wobei nach Suses Vorstellungen der Anwender den Grad des Selbstmanagements bestimmt [12]. Darüber hinaus bleibt bei ALP noch vieles offen, auch wenn die Entwicklung stetig voranschreitet.

Mauerblümchen

Die Bestrebungen der großen Distributoren wie Red Hat und Suse nach neuen Architekturen für ihre Enterprise-Distributionen sind aber beileibe nicht die einzigen Entwicklungen in diesem Sektor. Es gibt bereits mehrere weitere unveränderliche Distributionen, die bisher eher im Verborgenen blühen. Dazu zählen Flatcar Linux [13], Bottlerocket [14] und Talos Linux [15]. Alle drei sind für den Einsatz auf Servern mit Containern optimiert.

Flatcar Linux stellt das Kubernetes-Startup Kinfolk (mittlerweile von Microsoft aufgekauft) zusammen. Die Distribution hängt zwar das Verzeichnis /usr nur lesend ein, erlaubt aber allgemeine Laufzeitänderungen wie das dynamische Laden von Kernel-Modulen und das Überschreiben von Systemd-Konfigurationen.

Bottlerocket stammt von Amazon, seine Verwendung beschränkt sich auf die Amazon Web Services (AWS). Es weist eine nur lesbare Root-Partition auf, deaktiviert standardmäßig den SSH-Zugriff und lässt nur Kernel-Module zu, die mit dem Bottlerocket-Image-Schlüssel signiert wurden.

Talos Linux entstammt den Sidero Labs, bezeichnet sich als Kubernetes Operating System und führt das Konzept der Unveränderlichkeit noch weiter, in Form eines vollständig unveränderlichen Dateisystems. Neben dem Deaktivieren von SSH verzichtet es vollständig auf den Konsolenzugriff. Es läuft überall dort, wo sich Kubernetes ausführen lässt.

Für den Desktop

Aber auch beim Desktop gibt es Zuwachs bei den unveränderlichen Distributionen. Das recht junge, noch in der Alpha-Phase befindliche CarbonOS besteht mit Ausnahme von /usr/local/ ebenfalls aus einem unveränderlichen Dateisystem [16]. Es wird von Grund auf neu gebaut, basiert also nicht auf einer anderen Distribution. Als Grundbausteine fungieren OSTree und Gnome 43, ansonsten gilt: Container für das Grundsystem, Flatpaks für die Anwendungen. Ein herkömmlicher Paketmanager fehlt der Distribution. Secure Boot, TPM und Systemd-homed [17] sollen die Integrität beim Booten und zur Laufzeit gewährleisten.

Eine Aktualisierung ist entweder vollständig erfolgreich oder schlägt vollständig fehl. Dann rollt das System auf den vorherigen Stand zurück. Der Anwender wählt zwischen read only und read/write. Während für Desktop-Anwendungen Flatpak als Mittel der Wahl gilt, steht für fortgeschrittene Arbeitsabläufe der Container-Manager Nsbox bereit [18]. In dessen Containern lassen sich dank eigenem Init herkömmliche Distributionen wie Arch Linux oder Debian starten und somit in CarbonOS integrieren. Damit gleicht das System eher der Toolbox-Erweiterung Distrobox [19].

Das Ziel von CarbonOS besteht darin, dem Anwender nicht im Weg zu stehen. Er soll das System nutzen können, ohne sich um die technischen Details hinter den Kulissen kümmern zu müssen. Die dazu gewählten Mittel versprechen ein interessantes System, das LinuxUser näher unter die Lupe nehmen wird, sobald das Projekt etwas mehr Stabilität erlangt. Distributionen mit ähnlicher Zielsetzung sind rlxOS und AshOS.

Fazit und Ausblick

Fest steht: Linux wird in einigen Jahren anders funktionieren als heute. Wie viel dabei von den Enterprise-Linuxen, für die die neue Architektur entwickelt wird, nach unten durchrutscht, bleibt abzuwarten. Distributionen wie Fedora Linux oder OpenSuse werden zwangsläufig mitziehen, denn sonst verlieren sie ihre Daseinsberechtigung als die Hexenküchen von Red Hat und Suse. Zudem findet die Entwicklung und Erprobung dort statt.

Inwieweit Distributionen wie Debian oder Arch Linux auf den Zug aufspringen, steht noch keineswegs fest. Wenn überhaupt, wird das mit einiger Verzögerung passieren, wobei vermutlich einige Derivate schneller reagieren. Auf jeden Fall ist diese Architekturanpassung die größte Verwerfung seit der Einführung von Systemd. Ob unveränderliche Systeme das Zeug dazu haben, sich so nachhaltig durchzusetzen wie Systemd, bleibt allerdings fraglich.

Auf alle Fälle liegt hier Potenzial, Linux sicherer und einfacher zu machen und somit zur weiteren Verbreitung des freien Betriebssystems beizutragen. Eine umfassende Zusammenstellung von Informationen und Ressourcen zu diesem Thema finden Sie bei Interesse auf Github [20]. (tle)