Lennart Poettering: Wie alles zusammen passt

Lennart Poettering ist der Entwickler von Software wie Avahi-zeroconf, PulseAudio und nicht zuletzt systemd. Er arbeitet für Red Hat und macht sich des Öfteren öffentlich Gedanken darüber, wie wir künftig Distributionen zusammenstellen sollen. Bereits 2014 fasste ich seine Ideen aus dem Blogpost Revisiting How We Put Together Linux Systems in einem Artikel für die Zeitschrift LinuxUser zusammen.

Seitdem sind viele weitere Module in systemd eingeflossen. Poettering hat kürzlich in seinem Blog ein weiteres langes Essay unter dem Titel Fitting Everything Together veröffentlicht, der sich damit befasst, wie aus seiner Sicht Distributionen künftig zusammengestellt werden sollten. Er betont dabei ausdrücklich, dies seien seine Visionen und nicht die seines Arbeitgebers.

Die Ausgangslage von Poetterings Gedankenspielen bildet das traditionelle Distributionsmodell mit den etablierten Paketsystemen wie DEB und RPM. Ziel ist ein Desktop-System, weil damit die meisten Menschen täglich arbeiten und hier am meisten zu lernen sei. Das soll aber nicht heißen, dass die Erkenntnisse nicht auch auf Server, Container und Embedded Devices oder auf Systeme etwa im Automobilbereich übertragbar seien.

Die Ziele

Eine grundsätzliche Überlegung, wenn es um die Basis geht, ist, einen Image-basierten Ansatz dem gewohnten Paket-basierten Management vorzuziehen. Für Robustheit und Sicherheit ist es laut Poettering unerlässlich, mit reproduzierbaren, unveränderlichen Images zu arbeiten. Ziel ist »ein Maximum an bitgenauer Wiederverwendung und ein Minimum an lokalen Abweichungen«.

Dabei ist in Poetterings Gedankenwelt aber auch Platz für herkömmliche Paketsysteme, wie das auch Silverblue, Kinoite und andere fortschrittliche Distributionen handhaben. Er ist aber überzeugt, »sie sollten weniger ein Werkzeug zum Bereitstellen von Code sein, sondern eher ein Werkzeug zum Erstellen der bereitzustellenden Objekte«. Desktop-Systeme nur auf Image- und Container-Basis dürften es auch in meinen Augen schwer haben, denn ein Desktop, auf dem man nicht mal eben ein einzelnes Paket ohne anschließenden Reboot installieren kann, sind meines Erachtens nutzlos.

Einer der Vorteile von Images für die Kern-Distribution ist die Fähigkeit, tatsächlich zu überprüfen, dass sich die Dinge nicht geändert haben, wenn man das nicht möchte. Kehrseite ist, wenn man etwas ändern möchte, sollte es einfache Werkzeuge geben, die das ohne Neustart schaffen.

Vertrauenskette

Im grundsätzlichen Design ist für Poettering die Vertrauenskette vom Bootloader bis hin zu den Apps wichtig: »Dies bedeutet, dass der gesamte ausgeführte Code vor der Ausführung kryptografisch validiert werden muss. Alle Speicher müssen kryptografisch geschützt sein: öffentliche Daten müssen auf Integrität geprüft werden; private Daten müssen vertraulich bleiben.« Und dabei sieht er herkömmliche Distributionen derzeit scheitern.

Automatische Aktualisierung

Ein Punkt, den viele Linux-Nutzer ablehnen, sind automatische Aktualisierungen. Poettering ist dafür, das Betriebssystem ebenso wie Erweiterungen, Dienste und Apps einem automatisierten kontinuierlichen Update-Zyklus zu unterziehen. Dazu sieht er systemd-sysupdate als das geeignete Werkzeug an. Die Systeme müssten zudem robust gegen abgebrochenen OS-Operationen, Stromausfall und andere Unwägbarkeiten sein und zur Wiederinbetriebnahme keiner Benutzerinteraktion bedürfen. Außerdem muss jederzeit ein Factory Reset »in einen wohldefinierten, garantiert sicheren Zustand« möglich sein.

Abbilder sollten grundsätzlich live sein, per dd auf die Festplatte übertragen werden und »beim ersten Start instanziiert« werden anstatt davor. Die Systeme sollen zudem modular und »hackable« sein. Es sollte leicht sein, »ein Betriebssystem zu forken, ein Betriebssystem zu modifizieren und dennoch einen angemessenen kryptografischen Schutz zu erhalten«. Soweit die Ziele.

Der Entwurf

Das /usr/-Verzeichnis soll unveränderlich sein und alles enthalten »was erforderlich ist, um den minimalen Satz von Verzeichnissen und Dateien außerhalb von /usr/ einzurichten, damit das System funktioniert«. Dieses /usr/-Verzeichnis kann dann schreibgeschützt in das beschreibbare Root-Dateisystem eingehängt werden, das dann schließlich die lokale Konfiguration, den Status und die Benutzerdaten in /etc/, /var/und /home/wie gewohnt enthält. Hierzu ist Usrmerge unabdingbar, was aber die meisten Distributionen mittlerweile umgesetzt haben. Hinzu kommen Dienste wie systemd-sysusers und systemd-tmpfiles, die dafür sorgen, dass die Verzeichnisbäume außerhalb /usr/ beim Hochfahren automatisch nach Bedarf generiert werden, falls sie fehlen.

Aktualisierungen des Betriebssystems mit einem hermetischen /usr/-Verzeichnis sollen durch die Implementierung eines A/B-Aktualisierungsschemas atomar und robust vorgenommen werden können, während der Rest des Systems unberührt bleibt. Auch das Zurücksetzen auf die Werkseinstellungen profitiert davon: Nach Löschen des Root-Dateisystems und einem Neustart sorgt ein hermetisches /usr/-Verzeichnis für ein Neuaufsetzen des Systems.

Union-Mount-Dateisystem

Dieses Konzept verhindert allerdings das spontane Installieren von einzelnen Paketen. Hier schlägt Poettering deshalb einen Mittelweg vor, der einen unveränderlichen overlayfs-Mount nutzt, um etwa Binärdateien einzubinden. Dieses Konzept ist spätestens seit der Einführung von Live-Images durch Klaus Knoppper mit Knoppix populär. Um isolierte Systemdienste hinzuzufügen, denkt Poettering an Portable Services. Dabei handelt es sich um eine Auslieferungsmethode von systemd für Systemdienste, die zwei spezifische Eigenschaften des Container-Managements nutzt:

• Anwendungen werden gebündelt. Das bedeutet: mehrere Dienste, ihre Binärdateien und alle ihre Abhängigkeiten werden in ein Image gepackt und direkt von diesem ausgeführt.
• es gelten strengere Standardsicherheitsrichtlinien. So wird etwa Sandboxing von Anwendungen eingesetzt.

Ebenso wie bei den Betriebssystem-Images des Hauptsystems sowie den Systemerweiterungs-Images handelt es sich bei den Dienste-Images um GPT-Festplatten-Images mit einem unveränderlichen Dateisystem und zugehörigen Verity-Daten des Kernels. Für die Apps sieht Poettering Flatpak als das etablierte Format an, auch wenn er dessen Sicherheit bemängelt, da etwa Unveränderlichkeit im Konzept nicht vorgesehen ist.

Btrfs bevorzugt

Ansätze mit diesem Aufbau, die etwas mehr Flexibilität erfordern, könnten anstatt auf Bare Metal in Containern laufen, die mit systemd-nspawn aufgezogen werden. Was die Partitionen angeht, so sollte das von systemd-homed verwaltete /home laut Poettering auf jeden Fall btrfs verwenden, da hiermit Wachsen und Schrumpfen der Partitionen kein Problem sei. Der Vorteil von btrfs für das Root-FS in diesem Modell sei das Erstellen von Checksummen.

Bleibt noch die Frage, womit die Abbilder gebaut werden sollen. Hier kommt bei Poettering mkosi ins Spiel, ein Tool, von dem ich noch nie gehört habe. Laut GitHub ist es ein Wrapper um dnf --installroot, debootstrap, pacstrap und zypper.

Was wird sich davon durchsetzen?

Während sich beim herkömmlichen Ansatz Maintainer zusammen mit Upstream um die Pakete kümmern, die eine Distribution ausmachen und einzelne kaputte Teile reparieren, dreht sich in den Überlegungen von Poettering und anderen alles um Images und Container, die, wenn sie fehlerhaft sind, komplett entsorgt und neu erstellt werden.

Wer jetzt denkt, Fedora Silverblue oder Kinoite seien relativ nah an diesem Modell, der hat nicht ganz unrecht, aber Poettering geht viel weiter, was Robustheit, Verifizierbarkeit und Sicherheit angeht. Dort sieht er bei dem dort verwendeten OSTree gewisse Nachteile. Er erwartet auch nicht, dass sein Konzept von einer Mainstream-Distribution zu 100 % übernommen wird, würde sich aber über eine Zusammenarbeit mit Projekten, die an Teilen des Systems interessiert sind, freuen.