© Andrey Pavlov, 123RF

Einige Systemd-Entwickler um Lennart Poettering arbeiten emsig an einem System, das die Unterschiede der vielen Linux-Distributionen für Software-Anwender, -Entwickler und -Anbieter erträglich machen will. Eine zentrale Rolle in den hochgesteckten Plänen spielt das Dateisystem Btr-FS.

Will ein Hersteller heute sichergehen, dass seine Software auf den Rechnern der Linux-User läuft, entwickelt er in der Regel gegen eine LTS-Version von Ubuntu, Debian Stable oder RHEL. Doch schon die Zwischenversionen von Ubuntu lassen Hersteller mitunter links liegen, ganz zu schweigen von anderen Distributionen. Ihnen ist häufig der Aufwand zu hoch, mit den ABI- und API-Änderungen unter Linux Schritt zu halten.

Eine Distribution für alle

Lennart Poettering und einige Systemd-Entwickler haben Anfang September einen Vorschlag [1] skizziert, der die Kompatibilitätsprobleme beheben könnte und der zugleich Licht auf einige Neuerungen von Systemd wirft. Der Plan zielt darauf ab, bestimmte Teile einer Linux-Distribution für alle Nutzer, Admins, Entwickler und Software-Anbieter einheitlich zu gestalten. Das soll nicht nur die Softwareverteilung, sondern auch die Sicherheit verbessern. Insbesondere der Server-, Cloud- und Embedded-Bereich sollte von den Neuerungen profitieren. Deren Vorteile fasst Poettering folgendermaßen zusammen:

• Software-Anbieter müssen ihre Software nicht an die Bibliotheken der jeweiligen Distributionen anpassen, sondern wählen eine optimale Laufzeitumgebung aus und reichen diese dann an alle Distributionen weiter.
• Admins und User installieren Software ohne Rücksicht auf die eingesetzte Distribution.
• Updates erfolgen nach einem einheitlichen Schema und lassen sich für Betriebssysteme, OS-Container, Anwendungen und Programmier-ABIs gleichermaßen umsetzen.
• Eine Trustchain, die von der Firmware über den Bootloader bis hin zum Kernel reicht, soll in einer “Post-Snowden-Welt” für die nötige Sicherheit sorgen. Sie setzt den Aufbau eines Stateless-Systems voraus.

Um ihr Ziel zu erreichen, kombinieren Poettering & Co. verschiedene vorhandene Ansätze, wie sie Docker [2], Core OS [3] oder Gnomes OS-Tree [4] für ihre jeweiligen Einsatzbereiche verfolgen. Das neue Projekt soll hingegen für alle Distributionen und Workloads interessant sein und zugleich die Fähigkeiten von Systemd und K-Dbus nutzen.

Baumartig

Anders als ähnliche Projekte in der Vergangenheit, etwa Autopackage [5] und Zero Install [6], wollen die Entwickler ihr ehrgeiziges Konzept auf Dateisystemebene ansiedeln und dafür vor allem die Möglichkeiten von Btr-FS und Linux Filesystem Namespaces ausnutzen. Insbesondere von den Sub-Volumes und einem Feature namens Send-and-Receive will die Truppe laut Konzept intensiven Gebrauch machen.

Vereinfacht gesagt geht es darum, über die Sub-Volumes und schreibgeschützte »/usr« -Trees ein Nebeneinander mehrerer OS-Versionen, Runtimes, Frameworks, Anwendungen und Homeverzeichnisse auf demselben Btr-FS-Volume zu erlauben. Zugleich lassen sich die nur lesbar eingehängten »/usr« -Trees kryptographisch verifizieren.

Entwicklern ermöglicht es das Tree-Modell, einfach mehrere Runtime-Versionen parallel zu betreiben. Software-Anbieter können sichergehen, dass ihre Software in exakt der Umgebung beim User ankommt, in der sie diese entwickeln. Admins können mehrere Betriebssysteme nutzen, egal ob auf einem Bare-Metal-Rechner oder als Container.

Der Root-»/usr« -Tree soll zum Beispiel alle relevanten Dateien des Distributors enthalten und nach dem Schema

usr:vendorid:architecture:version

aufgebaut sein. In dem »/usr« -Tree darunter sind die Instanzen unterschiedlicher Betriebssysteme nach dem folgenden Schema angesiedelt:

root:name:vendorid:architecture

Dabei bleibt deren »/usr« -Verzeichnis zunächst leer. In ihm landen später die Runtimes und Frameworks, eine Etage darunter wiederum die Apps. Weitere Details zum geplanten Namensschema liefert [1].

In der Praxis soll beim Booten eine Instanz eines Betriebssystems hochfahren, in ihr leeres »/usr« -Verzeichnis kommt dann beispielsweise eine Java-Runtime, in der schließlich Libre Office läuft.

Btr bei die Fische

Erwartungsgemäß wurde der Blogpost auf Google Plus [7] und anderen Webseiten ausgiebig diskutiert. Einige der Befürchtungen zerstreut Lennart Poettering bereits im Blogeintrag. Nein, es werde nicht sehr viel mehr Speicherplatz kosten, wenn ein Admin mehrere Runtimes parallel installiert. Zum einen setzten viele User ohnehin nur eine begrenzte Zahl an Runtimes ein, zum anderen dedupliziere Btr-FS doppelte Dateien.

Betreibt ein Admin also fünf Betriebssysteme parallel, landen nicht fünf fast identische »/usr« -Trees auf der Festplatte. Aktualisiere der Admin eine Software, so Poettering, hole Btr-FS das binäre Delta, das lediglich die Unterschiede zwischen der alten und der neuen Version einer Software enthalte.

Zugleich kommt hier das anfangs erwähnte Send-and-Receive-Feature von Btr-FS ins Spiel, für das Poettering einen Doppelpuffer vorschlägt. Das Dateisystem kann die Deltas als Sub-Volumes auf andere Systeme übertragen. Auf diesem Weg lassen sich nicht nur Updates verteilen, beim Installieren entpackt der Admin ein Send-and-Receive-Delta einfach auf ein leeres Btr-FS-Volume. Zudem kann er Testsysteme in eigenen »/usr« -Trees bauen und diese als Diff verteilen. Das betrifft auch Embedded-Systeme, die auf TV-Geräten oder im In-Vehicle-Infotainment laufen.

Hindernisse

Warum Btr-FS? So lautet eine wiederkehrende Frage, die dem Dateisystem vorwirft, noch nicht bereit für den großen Auftritt zu sein. Poettering argumentiert zwar, dass die »/usr« -Trees ja nur lesbar seien, sieht aber auch, dass die Systemd-Entwickler versuchen, Userspace-Probleme in das noch junge Dateisystem zu drücken. Man müsse Btr-FS patchen, bis es den Anforderungen genüge, um nicht das Rad neu zu erfinden.

Wie der Admin denn die Runtime mit Securitypatches versorge, lautet eine weitere Frage. Poettering hofft, dass sich einige Standard-Runtimes herauskristallisieren, die Software aus den vorhandenen Distributionen verwenden – inklusive der Securitypatches. Ein offenes Problem seien hingegen Runtime-Dateien, die Hardwaresupport benötigen, etwa die Open-GL-Treiber. Es gebe keinen guten Ausweg aus der Situation, erklärt der Entwickler, aber wenn GL keine parallel installierten Userspace-Treiber erlaube, müsse man es wohl reparieren.

Erste Früchte

Bis alle Teile des Puzzles zusammenpassen, wird einige Zeit vergehen. Aktuell arbeiten die Entwickler an einem Stateless-Modus für Linux [8]. Der soll es ermöglichen, dass die Distributionsanbieter alle für sie relevanten Dateien in »/usr« lagern. Zugleich sollen diese Systeme auch bei leeren »/etc« – und »/var« -Verzeichnissen booten und dann über Systemd-Komponenten Default-Konfigurationen erhalten.

Dieser Schritt würde es zum Beispiel erlauben, einen »/usr« -Tree als verifizierten Golden Master in einem Netzwerk zu betreiben und die einzelnen Instanzen über »/etc« und »/var« mit individuellen Konfigurationen zu füttern. Auch Factory-Resets oder Stateless Reboots ermöglicht das Konzept, dessen erste Blüten sich bereits in Systemd 215 und 216 finden. Systemd-Entwickler Harald Hoyer arbeitet derweilen an Send-and-Receive-Images auf Fedora-Basis.

Wohlwissend, dass viele User dieser Art von Disruption eher kritisch gegenüberstehen und zahlreiche Admins weiterhin auf Linux mit klassischen Dateisystemen setzen werden, halten die Entwickler auch eine Alternative parat: Wer das neue Schema zum Beispiel auf traditionellen Ext-4-basierten Rechnern testen möchte, kann in »/var« Loopback-Images von Btr-FS anlegen.