© Kristian Kissling

Mit rund 100 Teilnehmern startete im November in Berlin die erste Konferenz rund um das Initsystem Systemd. Sie richtete sich vor allem an professionelle Init-Nutzer, also Admins und Entwickler.

Austragungsort war das in der Berliner IT-Szene bekannte Betahaus, das sich für die knapp hundert Teilnehmer vom Platz her als gute Wahl erwies. Drei Tage lang verfolgten sie Vorträge rund um Systemd und sein Ökosystem, legten aber auch in Hack-Sessions selbst Hand an das Initsystem. Organisiert hatten das Event [1] unter anderem die Macher des Linuxtags, zu den Hauptsponsoren gehörten Core OS und Red Hat. Videos der Veranstaltung finden sich auf der Heft-DVD, aber auch auf Youtube [2].

Github geht gut

Systemd-Hauptentwickler Lennart Poettering hatte es nicht weit zur Konferenz, lebt er doch in Berlin. Zum Auftakt lieferte er aktuelle Infos zum Status des Initsystems und den Plänen für die nahe Zukunft (Abbildung 1).

Abbildung 1: Auf der Konferenz sprach unter anderem Systemd-Chefentwickler Lennart Poettering ausführlich über die Pläne für das Initsystem.

Zunächst aber lobte er den Wechsel des Projekts auf Github [3]. Trotz einiger Mankos funktioniere Github wesentlich besser als die Zusammenarbeit über die Mailingliste, auf der mittlerweile 1300 Leute registriert seien. Über Github erhalte das Projekt durchschnittlich 127 Issue-Meldungen pro Monat sowie 180 Pull Requests. Mit Verweis auf RHEL 7 zeigte er sich erfreut, dass Systemd nun auch in kommerziellen Linux-Distributionen zum Einsatz komme.

Kdbus und Consoled

Schmerzhafte Erfahrungen wie die mit Kdbus erwähnte Poettering ebenfalls. Das Projekt sei nicht gerade eine Erfolgsstory: Man habe die IPC-Lösung vorerst wieder aus Fedora entfernt. Er halte sie aber weiterhin für eine notwendige Idee für den Kernel, das Projekt werde aber einige Komponenten aus dem Kernel- in den Userspace verlagern.

Wie Poettering erklärte, sei Kdbus nicht tot, die Entwickler dächten aber über einen Neuanfang nach. Vermutlich dauere es noch etwas, bis man den Pull Request erneuere. In einem weiteren Vortrag stellte Entwickler Djalal Harouni Kdbus nochmal aus der technischen Warte ausführlich vor und verglich es mit Androids IPC Binder [4].

Auch den Fans von Consoled überbrachte Lennart Poettering eher schlechte Nachrichten. Das Projekt sollte einst die vorhandene Linux-Konsole ersetzen. Die würde der Systemd-Entwickler am liebsten ganz abschaffen oder sie doch zumindest ersetzen. Die Systemd-Macher grübeln inzwischen über eine Lösung im Kernel via TTY nach.

Networkd und Container

Networkd komme hingegen bereits in Ubuntus Cloud Edition und in Fedora zum Einsatz, obwohl bislang ein vernünftiges Interface fehle. Auch Nspawn, mit dem sich Container starten lassen, sei bereits bei Core OS in Betrieb. Die Lösung bringe auf Anregung der Core-OS-Macher zwar bereits User-Namespace-Support mit, sei aber in Sachen Security noch nicht wirklich produktionsreif, weil sich Container-UIDs noch auf Host-UIDs mappen lassen.

Bus-API und Function-FS

Daneben kündigte Poettering an, dass in einigen Monaten das Bus-API fertig werde. Einem Hook-Interface für Shellskripte, wie es Distributionen gern verwenden, erteilte er allerdings eine Absage, solche Skripte halte er eher für einen Workaround. Interessiert zeigte er sich an einer Neuerung namens Function-FS [5] von Samsung. Die Funktion erlaube es, Dienste über USB zu aktivieren, ähnlich wie bei der Socket Activation.

Daneben denke das Projekt über dienstabhängige Firewalls nach, wobei Dienste eigene Chains in IPtables erhalten könnten. Er merkte an dieser Stelle an, dass Systemd-Code für den Einsatz mit NFtables zwar bereitstehe, das Projekt aber noch abwarte, wie gut sich die neue Firewall-Technologie etabliere.

Stateless-Systeme

Qt-Mitarbeiter Tobias Hunger zeigte im Rahmen einer Live-Demo, wie sich ein Stateless-System in der Praxis aufsetzen lässt, das etwa Factory Resets beherrscht oder sich nicht löschen lässt. Es handle sich laut Hunger um ein Privatprojekt, an dem er bereits seit längerer Zeit arbeite. Auch das Systemd-Projekt denkt über die Möglichkeiten von Stateless-Linuxen nach [6].

Richard Maws Gedanken kreisten hingegen um Atomic Updates. Sie sollen verhindern, dass fehlgeschlagene Updates Systeme unbrauchbar machen. Allerdings erfordern sie Neustarts. Maw glaubt, mit Hilfe von Systemd solche erzwungenen Reboots künftig verhindern zu können, und stellte in seinem Vortrag seinen Ansatz vor.

Weniger enthusiastisch über Systemd äußerte sich Docker-Mitarbeiter Daniel Walsh. Er schilderte, wie Docker seine Probleme mit Systemd in den Griff bekommen will. So funktioniere »sd_notify« in Docker nicht und es fehle eine Socket Activation. Zudem wollen sowohl Docker als auch Systemd Cgroups kontrollieren.

Die Lösung heiße Runc und ist Teil der Container-Spezifikation der Open Container Initiative (OCI). Runc nutzt die Libcontainer und setzt Namespaces. Mit ihrer Hilfe lassen sich Docker-Container betreiben, während Systemd die Kontrolle über Cgroups behält.

Ein weiteres Problem sei, dass der Docker-Daemon Logs zwar im Json-Format speichert, diese Dateien aber verschwinden, sobald ein Entwickler den Container zerstört. Daher bringe Docker ab Version 1.9 über die Option »–log-driver=journald« Journald-Support mit, was in Fedora Rawhide zum Standardverhalten werden soll. Nicht zuletzt unterstütze auch das Base-Image nach einigen Experimenten mit abgespeckten Versionen Systemd mittlerweile vollständig, wobei Walsh seiner Hoffnung Ausdruck verlieh, das Projekt möge Systemd verkleinern und “einiges von dem Müll entsorgen”.

Systemd in den Distros

Schließlich kamen auch die Distributionen zu Wort. Entwickler Michael Biebl klärte unter Mitarbeit von Martin Pitt über den aktuellen Status von Systemd in Debian und Ubuntu auf. Die Welt sei nicht untergegangen, aber es habe einiger Anpassungen bedurft, beispielsweise im Umgang mit Udev. Auch hadere man noch ein wenig mit der Menge an Releases von Systemd und den vielen anvisierten Einsatzbereichen. Insgesamt, so Biebl, seien die Entwickler mit der Systemd-Integration jedoch recht zufrieden. Neben dem Debianer plauderten auch Vertreter von Core OS und Red Hat aus dem Systemd-Kästchen.

Den halben Freitag und am kompletten Samstag arbeiteten die versammelten Entwickler im Rahmen einer Hack-Session an Systemd. Ein paar Tage nach dem Event erschien Systemd 228, das bereits einige der auf der Konferenz besprochenen Punkte aufnahm [7].

Fazit

Den Konferenzbesuchern zeigte sich mitunter, dass die Vortragenden ähnliche Themen behandelten und sich inhaltlich zum Teil überschnitten. Einige Talks behandelten auch sehr spezielle Probleme. Insgesamt hinterließ die Veranstaltung aber einen guten Eindruck. Die Entwickler kamen ins Gespräch, die Vorträge waren überwiegend interessant und sparten auch sachliche Kritik an Systemd nicht aus. Die Vortrags-Slots waren gut gefüllt, die Clubmate ging nicht aus und der Ort passte zur Besucherzahl. Nächstes Jahr soll die Konferenz laut Poettering in eine weitere Runde gehen.