Die All Systems Go! 2018 versammelte Ende September in Berlin namhafte Entwickler der Open-Source-Szene, die sich vor allem für die Schichten zwischen Kernel und Desktop interessieren. Thematisch kreiste sie um Werkzeuge rund ums Booten und den Start von Linux-Systemen – mit Ausflügen in die Containerwelt.

Die Location blieb unverändert, die Besucherzahl, trotz etwas höherer Ticketpreise, konstant: Die zweite All Systems Go! [1] übernahm den Themenmix der ersten weitgehend und steht wohl finanziell auf soliderem Boden. Laut Chris Kühl, einem der Hauptorganisatoren der Konferenz, werde das Event wohl schwarze Zahlen schreiben und sei damit auf dem Weg zur Nachhaltigkeit.

Die Userspace-Werkzeuge rund um den Bootprozess blieben ein zentraler Fokus der Veranstaltung. Rein Kernel-spezifische Themen will die Konferenz bewusst aussparen, es gehe eher um die so genannte Plumbing-Schicht. Die umfasse etwa die Prozesse vom Booten bis zum fertigen System, aber auch Kernel-nahe Werkzeuge wie Kexec und Kdump.

Daneben streifte die Konferenz auch ein paar etwas weiter abseits liegende Themengebiete. So zeigte Entwickler Zeeshan Ali, dass sich mit Mozillas Programmiersprache Rust inzwischen recht nützliche Dinge anfangen lassen. Konkret machte er die Vorteile von Rust an dem Multimedia-Framework Gstreamer fest, das mittlerweile Rust-Bindings im Gepäck hat. Darüber lassen sich einfacher sichere und zugleich performante Plugins für Gstreamer in Rust schreiben, weil der Compiler zur Übersetzungszeit auf Programmierfehler hinweist.

Ohne Container geht nix

Daneben legte die All Systems Go!, wie schon im letzten Jahr, einen Fokus auf Containertechnologien (Abbildung 1). Zu diesen gehörte unter anderem die Container-Runtime »systemd-nspawn«, die es erlaubt, ressourcensparend Namespace-Container auf Systemd-Systemen zu starten. Das Werkzeug unterstützt unter anderem die Container Interface Specification (CSI), weitere Neuerungen erwähnte Lennart Poettering in seinem Systemd-2018-Überblick.

Abbildung 1: Die All Systems Go! sparte auch in diesem Jahr Container nicht aus. Unter anderem stellte Ben Breard die Pläne für Fedora Core OS vor.

Auch bei Facebook kommen Container zum Einsatz. Mitarbeiter William Smith verwies auf ein neues Tool namens Capmon, für das Facebook demnächst die Quellen veröffentlichen will. Es sei in der Lage, die von den eingesetzten Containern benötigten Capabilities zu registrieren, um diese nach einer Weile angemessen zu beschränken. Es verwendet dazu BPF, Cgroups und Extended Attributes. Facebook benötige ein solches Tool offenbar, weil das soziale Netzwerk die Container bewusst mit Rootrechten laufen lasse, was unter Sicherheitsgesichtspunkten gewagt ist.

Vielleicht sollte das soziale Netzwerk einmal mit dem Red-Hat-Mitarbeiter und SE-Linux-Erfinder Dan Walsh reden. Dieser stellte mit Podman [2] eine alternative Verwaltung für Docker-Container vor. Podman erlaube es, Docker-Container ohne Rootrechte zu betreiben. In den Containern läuft Systemd als PID 1, Socket Activation und »sd-notify« würden ebenfalls funktionieren.

Auch Flatpak, das noch junge Paketformat aus dem Fedora-Gnome-Umfeld, basiert auf einer Containertechnologie und war Thema auf der Konferenz. Alexander Larsson und Philip Withnall gaben Einblicke in die Funktionsweise. Ersterer arbeitet an Flatpack selbst und sprach unter anderem über das Sandboxing und über die mit Flatpak verzahnten Technologien wie Bubblewrap und OS-Tree. Letzterer beschäftigte sich mit dem Linux-basierten Betriebssystem Endless OS, das ebenfalls Flatpak verwendet.

Verteilte Containerumgebungen wie Kubernetes werfen auch unter anderen Gesichtspunkten interessante Probleme auf. Eduardo Silva von Fluent Bit zeigte zum Beispiel, wie sich Logging in Umgebungen realisieren lässt, in denen der Admin mehrere und dynamisch operierende Datenquellen loggen muss.

Systemd-Updates

Lennart Poettering nutzte das Forum einmal mehr, um über die Neuerungen von Systemd seit seinem letzten Auftritt im Jahr 2017 zu sprechen. Dabei hob er als wichtigstes neues Feature die Portable Services [3] hervor. Ihnen widmete er einen eigenen Talk, sie seien mittlerweile produktionsreif.

Grob vereinfacht sind das simple Festplattenimages mit integriertem Verzeichnisbaum. Sie versammeln alle zum Service gehörigen Dateien. Das mache den Dienst portabel und einfacher zu verwalten. Admins ergänzen die Dienste in bestehenden Systemen oder entfernen sie aus diesen. Neben nativen Systemd-Diensten und solchen mit Sysvinit-Support handele es sich quasi um einen dritten Modus für Systemd-Dienste.

Neben der besseren Portierbarkeit sorgt ein standardmäßig aktiviertes Sandboxing für mehr Sicherheit bei den Anwendungen. Als Steuerprogramm dient das Kommandozeilentool »portablectl«, das sich an »systemctl« anlehnt.

Neben diesem Hauptfeature bringt Systemd inzwischen weitere Neuerungen mit. Boot Counting hilft dabei, gezielter auf Reboots von Systemen zu reagieren. Eine System-Call-Whitelist erlaubt Sandboxing und beschränkt Dienste auf eine bestimmte Auswahl an verfügbaren Systemaufrufen.

Memory Accounting ist für die Systemd-Dienste neuerdings standardmäßig aktiviert, weil der Kernel es fast ohne Kosten erledigt. Weitere Accounting-Typen sollen folgen, sobald der Kernel auch diese ohne größeren Overhead implementiert.

Ordnungsversuche

Am zweite Tag versuchte Vincent Batts Ordnung ins Chaos der zahlreichen Container-Runtimes und -Technologien zu bringen. Er stellte in diesem Zusammenhang gefühlt alle in den letzten Jahren entstandenen Projekte und ihre Ziele vor – und das sind nicht wenige.

Einen zweiten Talk hängte der Entwickler gleich nahtlos an seinen ersten. Darin beschäftigte er sich mit den Möglichkeiten und Stolpersteinen beim Verifizieren von Dateien auf Dateisystemen. Er zeigte, wie schwierig es oft ist, sicher festzustellen, ob sich wirklich die gewünschten Dateien auf dem Dateisystem befinden. Das liege unter anderem daran, dass klassische Software oft nicht reproduzierbar arbeite. Als Gegenmittel empfahl Batts daher M-Tree-Implementierungen, aus dem Publikum kam der Hinweis auf FS-Verity [4].

Ein bekannter Benchmark-Spruch lautet: “Wer misst, misst Mist”. Amazon-Web-Services-Mitarbeiter Frank Becker wollte das so nicht stehen lassen und zeigte in einem Vortrag, wie sich die Performance von Systemen sinnvoll bestimmen lässt. Becker stellte nicht nur für diverse Mess-Szenarien hilfreiche Tools vor, sondern wies auch auf Fallen hin, die lauern, wenn Messdiener Caches nicht leeren oder das arithmetische Mittel nicht vom Median unterscheiden.

Freies Booten

Nicht zuletzt versuchten Google-Mitarbeiter Chris Koch und der Max-Planck-Forscher Paul Menzel in ihren Vorträgen den Anwesenden die Freuden eines freien Bootsystems näher zu bringen. Googles Chromebooks verwenden Coreboot. Im Serverbereich arbeitet die Firma daran, die zahlreichen Hardware-Blobs auf Intel-Systemen und die UEFI-Treiber (DXEs, Dixie gesprochen) loszuwerden oder zumindest zu umgehen. Als Ersatz könnte künftig ein Linux als UEFI-Payload dienen. Tatsächlich bieten die UEFI-Bausteine mittlerweile genügend Platz für solche Komplettsysteme.

Linux als Auswechselspieler einzusetzen würde gleich einige Vorteile mit sich bringen: Nicht nur gibt es auf der Welt deutlich mehr Linux- als UEFI-Entwickler. Ein solches Projekt hätte also potenziell eine größere Zahl an Mitarbeitern und Code-Prüfern. Die wiederum könnten größere Mengen an Bugs entfernen. Vor allem aber würden solche Systeme nach Ansicht der Redner deutlich flotter anlaufen, weil die DXE-Initialisierung viel Zeit benötige.

Im Großen und Ganzen lieferte die Konferenz also einen interessanten Themenmix, wobei nur Teile des Publikums aus Berlin oder Deutschland kamen. Die Sponsoren Facebook und Red Hat hatten einige Entwickler aus den USA einfliegen lassen, viele weitere reisten laut Chris Kühl aus verschiedenen Teilen Europas an. Geht es nach ihm, wird die Veranstaltung im nächsten Jahr ohne große Änderungen erneut stattfinden.