Das Linux der Zukunft basiert nicht mehr auf Paketen, sondern auf virtuellen Containern, die Sie flexibel kombinieren. Das eröffnet viele Freiheiten und Möglichkeiten – sagt zumindest Systemd-Entwickler Lennart Poettering.

Geht es nach Lennart Poettering (Abbildung 1) und seinem Team, gehören alle heutigen Distributionen bald zum alten Eisen. Geht es nach Poettering, fügen sich künftig System, Applikationen und Benutzerdaten entsprechend den jeweiligen Anforderungen aus gespeicherten Zuständen wie von Geisterhand zu einem stimmigen Ganzen zusammen. Paketmanagement wäre dann Geschichte, Updates und Systempflege hätten ein vollkommen anderes Gesicht.

Abbildung 1: Systemd-Initiator Lennart Poettering hält mit seiner Meinung nicht hinter dem Berg. (Bild: Harald Hoyer, Wikipedia, CC-BY-SA 3.0)

Der Daemon Systemd dient in diesem Szenario als Unterbau. Andere Teile der Ansätze finden sich bereits in Docker und CoreOS. Die Systemd-Crew steht mit ihren Ideen also nicht alleine. NixOS mit seinem Paketmanager Nix [1] geht ebenso wie Bedrock Linux [2] oder OSTree [3] in eine ähnliche, stark von heutigen Standards abweichende Richtung.

Setzt sich Poetterings Vision durch, führt dies zu mehr Einheitlichkeit über Distributionsgrenzen hinweg, was tatsächlich vieles vereinfachen würde. Allerdings verlören viele Distributionen damit auch ihre Alleinstellungsmerkmale.

Heiße Diskussionen

Systemd steht nach wie vor unter heftigem Beschuss seitens der Anhänger der alten Unix-Schule, obwohl fast alle großen Distributionen den Umstieg bereits vollzogen oder fest geplant haben – nur Slackware und Gentoo bleiben bislang außen vor. Die Webseite “Boycott Systemd” [4] sammelt weiterhin Argumente gegen das Kernstück des Konzepts, was aber dessen Entwickler nicht davon abhält, viele Mechanismen in Linux zu entstauben.

Poettering und seine Mitstreiter gehen mit ihren Gedankenspielen schon jetzt über den dort diskutierten Status weit hinaus. So hat Poettering bereits früh in seinen Vorträgen zu Systemd betont, es sei ein Irrtum, die Software lediglich als Init-System zu betrachten. Vielmehr handele es sich dabei um einen “Satz von Komponenten, die man benötigt, um auf der Basis des Linux-Kernels ein Betriebssystem zu bauen.” Bereits 2010, im ersten Blog-Eintrag zu Systemd für Administratoren*[5], zeichnete sich ab, dass hier weit mehr zu erwarten war.

Dass das trotzdem lange nicht auffiel, mag daran gelegen haben, dass die Bestandteile des Konzepts in homöopathischen Dosen auftauchten: Zuerst war es eben lediglich ein neues Init-System, dann kamen immer mehr Komponenten hinzu, darunter eine Login-Verwaltung, ein Journal und ein Netzwerk-Management-Baustein (Abbildung 2). Nicht jede Distribution aktiviert alle Komponenten: Nur wenige nutzen bislang etwa das Bereitstellen zustandsloser Systeme, das mit Systemd 214 Einzug hielt.

Abbildung 2: Systemd zentralisiert viele Aufgaben in einem Daemon, dessen einzelne Bestandteile zum Teil fest mit dem Kernel verzahnt sind. (Bild: ScotXW, [6])

Eben jenes bildet jedoch den Auftakt zu einem tiefgreifenden Paradigmenwechsel, den Poettering kürzlich als Basis für künftige Distributionen genauer beschrieb [7]. Sein Beitrag wurde bisher nur vereinzelt in Diskussionen aufgenommen ([8],[9],[10],[11]).

Voraussetzungen

Poetterings Ansatz baut technisch unter anderem auf zustandslosen Systemen auf [12]. Diese speichern ihre Zustände nicht dauerhaft, sondern starten immer wieder in einen zuvor definierten Zustand. Darüber hinaus bezieht Poettering in den Ansatz Systeme ein, die Verzeichnisse wie /etc und /var erst beim Booten befüllen. Das setzt allerdings voraus, dass die Distributionen ihre Pakete anpassen.

Die benötigten Informationen erhalten diese zur Laufzeit. Das setzt voraus, dass alle von der Distribution mitgelieferten Daten unterhalb von /usr liegen, was letztendlich auf ein Vereinfachen des Verzeichnisbaums abzielt. Dieser trennt nicht mehr zwischen /bin und /usr/bin oder /sbin und /usr/sbin, /lib und /usr/lib sowie /lib64 und /usr/lib64 [13].

Einige Distributionen, darunter Fedora und CoreOS, haben diese Vorgabe bereits ganz oder teilweise umgesetzt. Das ermöglicht Systeme, die durch Zurücksetzen aller Konfigurationen in den Zustand nach der ersten Installation booten. Bei wirklich zustandslosen Systemen gilt das als Normalzustand: Sie booten in ein System, das einer Live-CD gleicht.

Aus diesem technischen Rahmen ergibt sich die Möglichkeit, Systeme zu konstruieren, die sich weitgehend selbst installieren und aktualisieren. Damit sollen sie Entwicklern, Administratoren und Distributoren die Arbeit erleichtern.

Finger auf die Wunde

Poettering identifiziert etliche verbesserungswürdige Punkte an der Art, wie Entwickler heute Linux-Distributionen erstellen und aktualisieren. Seine Hauptkritik betrifft das traditionell verwendete Paketmanagement sowie die Kluft zwischen Programmentwicklern und den Maintainern der Distributionen.

Das derzeit genutzte Schema beruht auf dem Entwickler, der Software programmiert und sie als Tarball bereitstellt (“Upstream”), und dem Maintainer, der aus diesen Archiven Binärpakete baut. Diese stehen für den Anwender in signierten Archiven bereit.

Für den Anwender, der der Distribution vertraut, scheint das auf den ersten Blick ein vernünftiger Weg. Für den Entwickler bringt es jedoch einige Probleme mit sich, die unter Umständen bis zum Endanwender durchschlagen: So wünschen sich viele Programmierer, dass die Maintainer ihre Software schnell veröffentlichen, sind dabei aber völlig auf den jeweiligen Paketbetreuer angewiesen, der über das Wie und Wann entscheidet.

Kommt es zu Verzögerungen, landen neue Funktionen verspätet beim Anwender, dem Entwickler fehlt wiederum das User-Feedback. Die Vielfalt an Distributionen macht dem Programmierer aussagekräftige, umfassende Tests nahezu unmöglich. Will er selbst testen, bleibt ihm nichts anderes übrig, als alle zu unterstützenden Distributionen zu installieren und seine Software jeweils darauf zu bauen.

Diesen Ablauf empfinden verständlicherweise viele Entwickler als zu umständlich. Das war kürzlich selbst von Linus Torvalds zu hören, der auf der Debian-Entwicklerkonferenz Debconf eine Frage-und-Antwort-Stunde abhielt [14] und dort seine Vorbehalte gegen das herkömmliche Design von Distributionen kundtat.

Torvalds entwickelt neben dem Kernel ein kleines Werkzeug für sein Hobby, das Tauchen. Das Tagebuch Subsurface steht für Windows und Mac OS X als Binärpaket bereit. Für Linux gibt es lediglich den Quellcode, da Torvalds nicht einsieht, Pakete für verschiedene Distributionen zu erstellen. Zudem kritisierte er das Modell der dynamischen Bibliotheken: Durch die Möglichkeit, mehrere Versionen einer Bibliothek zu installieren, komme es viel zu oft zu Brüchen im ABI.

Fehler im Design?

Die so identifizierten Defizite könnte man leicht als Meckern auf hohem Niveau beiseiteschieben, denn das Modell funktioniert ja größtenteils. Eine Alternative wäre, sie als Fehler im Design anzusehen, mit denen sich schlicht alle Beteiligten schon lange arrangiert haben.

Die Diskussion um das Design von Distributionen ist nicht neu, und teilweise finden sich bereits in einigen Distributionen und Projekten alternative Methoden. Poettering nennt Ubuntu Apps, Docker, Software Collections, ChromeOS und CoreOS als Beispiele. Dazu kommen die erwähnten NixOS, Bedrock Linux und OSTree mit teils komplett neuen Ansätzen.

Poettering und seinem Team schwebt allerdings ein generischer Ansatz vor, der im Rahmen von Systemd funktioniert, im Basissystem ansetzt und somit für Endanwender-Desktops ebenso funktioniert wie für Server oder eingebettete Systeme. Schließlich sei Linux gerade aufgrund der generischen Natur des Kernels so über die Maßen erfolgreich, vom Supercomputer bis hinab zu Kleinstsystemen, meint Poettering. Die gleiche Allgemeingültigkeit wünscht er sich für darauf basierende Betriebssysteme.

Lösungsansätze

Wie sieht nun der Lösungsansatz des Systemd-Teams aus? Mit ihm wären Entwickler und Distributoren in der Lage, Software – egal, ob Applikation oder Betriebssystem – für Endanwender zu packen und dabei genau zu kontrollieren, mit welchen Bibliotheken und anderen Teilen das Paket interagiert. Diese Pakete sollen, da sind sich Torvalds und Poettering einig, mit allen Systemen kompatibel sein, egal, welche Distribution darauf läuft.

Darüber hinaus wünschen sich die Systemd-Entwickler, neben Poettering namentlich Kay Sievers, Harald Hoyer, Daniel Mack, Tom Gundersen und David Herrmann, einen einheitlichen Ansatz für das automatisierte Aktualisieren von kompletten Systemen – vom Cluster bis hin zu OS-Containern, Endanwender-Applikationen, den ABIs und mehr. Dabei sollen dieses Systeme mindestens doppelt abgesichert sein, wie CoreOS das bereits mit einem zweifach vorhandenen Root-Dateisystem vormacht [15].

Aus Sicherheitsgründen sieht Poetterings Plan vor, Images von Betriebssystemen grundsätzlich vertrauenswürdig zu signieren. Von der Firmware über den Bootloader, den Kernel und die Initrd wäre so jede Komponente in der Lage, diese kryptografisch zu verifizieren. Das ist für Desktop-Systeme genauso interessant wie für Server oder für einzelne Apps – ChromeOS verfährt bereits nach dieser Maßgabe.

Technische Komponenten

Um diese Vision technisch umzusetzen, sehen die Entwickler neben Systemd in den Hauptrollen einerseits das Dateisystem Btrfs, andererseits die eng mit den Cgroups verwandten Kernel-Namensräume ([16],[17]). Diese helfen bereits, die Container von Docker abzuschotten, indem sie vereinfacht gesagt Objekte oder Ressourcen vor dem Rest des Systems verbergen.

Die in einem Namensraum verwendeten Namen stehen in einem anderen Namensraum oder dem Rest des Systems wieder bereit und dürfen dort andere Objekte bezeichnen. Systemd macht sich Namensräume bereits bei der Implementation von Systemd-Nspawn [18] zunutze, das in etwa einer Chroot gleicht (Abbildung 3).

Abbildung 3: Nspawn zeigt schon heute, in welche Richtung die Reise künftig geht: Applikationen laufen in abgeschotteten Containern, die sich die Ressource des Basissystems teilen. (Bild: ScotXW, [6])

Die zweite Komponente, das Dateisystem Btrfs, bietet einige Funktionen, die bei spezialisierten Betriebssystemen für bestimmte Aufgaben zum Einsatz kommen. Laut Poettering sind einige weitere in Arbeit, die den Plänen des Teams entgegenkommen. Btrfs bietet im jetzigen Entwicklungsstand Subvolumes, die prinzipiell Snapshots entsprechen. Bei Subvolumes handelt es sich um unabhängige Dateisysteme, die aber physisch auf dem gleichen Gerät innerhalb einer Instanz von Btrfs existieren und die das System einzeln einhängen darf.

Die Systemd-Macher wollen diese Subvolumes eng mit Namensräumen verknüpfen und auf diese Weise feste Namenszuordnungen wie etwa usr:Vendor-ID:Architektur:Version erstellen. Dieser Bezeichner steht für ein Verzeichnis /usr, wobei Vendor-ID den Distributor identifiziert, die jeweilige Architektur und Version stehen in den folgenden Feldern. Eine weitere Bezeichnung für ein Sub-Volume sähe so aus:

home:Benutzer:UID:GID

Weitere Subvolumes sieht das Konzept für das Root-Dateisystem, Frameworks, zur Laufzeit verwendete Dateien sowie für Apps oder Gruppen von Apps (etwa eine Office-Suite) vor. Um diese klarer gegen Btrfs-Partitionen abzugrenzen, die in den Subvolumes diesem Namensschema folgen, soll ein entsprechender GPT-Partitionstyp mit eigener ID entstehen.

Das Dateisystem

Das Gesamtkonzept ermöglicht, in einer Btrfs-Instanz multiple Betriebssysteme, Home-Verzeichnisse, Frameworks und Apps in verschiedensten Versionen zu betreiben. Damit besteht die Möglichkeit, ein Root-Dateisystem mit passendem Verzeichnis /usr zu booten, ein passendes Home-Verzeichnis auszuwählen und benötigte Apps einzubinden.

Konkret erstellt das System nun für die Apps einen Laufzeit-Namespace und lädt die App-Volumes nach /opt/Vendor-ID. Die passenden Laufzeit-Dateien kopiert es nach /usr und hängt das gewünschte Home-Verzeichnis an die richtige Stelle ein.

Programmierern bietet den Vorteil, Software ohne großen Aufwand auf verschiedenen Architekturen, mit unterschiedlichen Runtimes und Frameworks zu entwickeln. Anwender profitieren von der Möglichkeit, ohne große Umstände verschiedene Versionen einer Software zu nutzen oder deren Verhalten unter verschiedenen Betriebssystemen zu testen. Obendrein kann das System von einer nicht funktionierenden Variante automatisch zu einer betriebsfähigen Version wechseln.

Das geschilderte Szenario setzt freilich voraus, dass Distributoren, Desktop-Umgebungen, Framework-Projekte und App-Entwickler unisono das vorgeschlagene Schema umsetzen. Halten sich alle strikt an das Paradigma der Namensräume, ist es laut Poettering kein Problem, verschiedene Distributionen in unterschiedlichen Versionen mit mehreren Versionen verschiedener Desktops samt Apps in unterschiedlichen Versionen zu kombinieren. Um dabei nicht zu viele Daten mehrfach zu speichern, kommt die Daten-Deduplikation [19] von Btrfs zum Zug.

Status quo

Der derzeitige Stand der Entwicklung umfasst bereits eine Menge Arbeit an den Grundlagen, deren Ergebnisse aber wiederum außerhalb des großen Ganzen Anwendung finden (Abbildung 4). Der wichtigste Punkt des gesamten Plans ist jedoch das bereits beschriebene Zusammenfassen der Ressourcen im Verzeichnis /usr. Zudem setzt der Ansatz ein starkes Sandbox-System voraus, dessen Grundlagen derzeit in Kdbus entstehen. Das ermöglicht es den Apps, abgesichert per Interprozesskommunikation (IPC [20]) zu kommunizieren.

Abbildung 4: Systemd everywhere: Geht es nach den Vorstellungen der Maintainer, übernimmt Systemd in weiten Teilen die Kontrolle im System. (Bild: StarQuake, [21])

Dazu gesellt sich eine noch in der Erprobung befindliche Funktion von Btrfs namens Send and Receive, die es erlaubt, einen Vergleich zwischen zwei Dateisystemen zu erzeugen, dessen Differenz in einer binären Delta-Datei landet. Ein solches Delta dient unter anderem zum Übertragen der Subvolumes von einer Maschine der Entwickler auf die Rechner der Endanwender.

Fazit

Geht es nach den Systemd-Entwicklern, erzeugen die Maintainer beim Aufsetzen und Aktualisieren von Betriebssystemen, Frameworks und Apps künftig für jede Komponente ein Delta, das als neues Subvolume mit neuem Namensraum ins System kommt. Ganz ähnlich, allerdings mit einem Device-Mapper anstelle von Btrfs, klappt das bereits jetzt mit Docker-Images. Dabei besticht die Tatsache, dass aus Perspektive der Technik kaum mehr Unterschiede im Umgang mit Betriebssystem, Framework, Runtime und Apps bestehen.

Dass die Idee vom System, das sich mit anderen Betriebssystemen und weiteren Komponenten ein Dateisystem teilt und sich automatisiert aktualisiert, bei Desktop-Distributionen Einzug hält, setzt voraus, dass viele Entwickler und Distributoren ihre Systeme umstellen. So könnte es letztendlich auch kommen, denn der überwiegende Teil der Distributionen hat aller Bedenken und Kritik zum Trotz die Möglichkeiten von Systemd bereits erkannt und – mit nicht geringem Aufwand – integriert. Trotzdem gehen bis zum Abschluss voraussichtlich noch einige Jahre ins Land.

Das bahnbrechend Neue an Lennart Poetterings Ideen stellen nicht die Einzelteile dar, sondern das Ganze mit der Kernkomponente Systemd. Technisch gesehen lassen sich die Hürden durchaus überwinden, immerhin ist das meiste davon bereits in einzelnen Teilaspekten bei anderen Projekten umgesetzt.