© Maksim Toome / 123RF.com

Systemd kommt ab Werk mit zwei Funktionen, um die Verwaltung von Containern zu erleichtern. Dabei geht es nicht um Container, wie Kubernetes sie will. Stattdessen lassen sich mit den Systemd-Features viele Programme durch Isolation sicherer betreiben.

Zugegeben: Existierte ein Publikumspreis der Open-Source-Szene, die Chancen für Lennart Poettering und sein Systemd stünden nicht sonderlich gut, ihn noch zu gewinnen. Zu kontrovers sind die teils leidenschaftlich geführten Diskussionen rund um die Software. Ursprünglich mit dem banalen Ziel angetreten, die uralten SysVinit-Skripte der meisten Linux-Distributionen durch eine zeitgemäße Lösung zu ersetzen, hat Systemd mittlerweile sogar dafür gesorgt, dass sich altehrwürdige Projekte wie Debian GNU/Linux in eine Pro-Systemd-Fraktion (Debian) und eine Anti-Systemd-Fraktion (Devuan) gespalten haben. Zweifelsohne gehört Systemd damit in die Gruppe der Software, die die größten Kontroversen auslöst.

Doch wie man es auch dreht und wendet: Der Erfolg gibt Poettering recht. Keine Major-Distribution käme heute noch ernsthaft auf die Idee, Systemd durch eine andere Lösung zu ersetzen. Und die Relevanz der genutzten Init-Systeme schwindet in Zeiten von Anwendungen, die als Container daherkommen, ohnehin. Wenn MariaDB nur noch ein Container ist, den es zu starten gilt, muss das Init-System dafür kaum noch irgendeine Magie beherrschen.

Klar ist auch, dass die Reise genau dorthin geht, zumindest wenn man Red Hat, Suse und Co. folgt. Bei allen Enterprise-Distributionen mit Ausnahme von Debian gilt mittlerweile ein Container-first-Prinzip. Sowohl aus Sicht der Anbieter als auch aus Sicht von Softwareherstellern sind Container schließlich eine bequeme Sache: Anders als früher muss die Distribution nur noch wenige Komponenten selbst bereitstellen – es genügen ein Kernel und eine Laufzeitumgebung für Container. Der Softwareanbieter wiederum braucht ebenfalls nur noch einen Container im Sortiment, weil dieser auf grundsätzlich jedem System mit funktionaler Container-Laufzeit läuft. Wo Red Hat und Co. früher also MariaDB, PostgreSQL und praktisch sämtliche relevanten Werkzeuge mehrmals in unterschiedlichen Versionen für die eigenen Distributionen pflegen mussten, stellen sie heute nur noch eine Hülle samt Kernel bereit. Der Anbieter der Software selbst springt in die Bresche und bietet exakt einen Container, der überall läuft. Schöne neue Welt – und so elegant.

Bestandssysteme bleiben

Die immer fantastischeren Erzählungen aus der Container-Welt lassen oft vergessen, dass es da draußen nicht nur grüne Wiesen gibt, auf denen Administratoren mit der Planung einer Umgebung bei null anfangen. So toll der hippe Kram auch sein mag: Der Bestand aktueller IT-Umgebungen wird den Admins dieser Republik noch eine Weile erhalten bleiben – und mit ihm die Frage, wie er sich sinnvoller und besser nutzen und verwalten lässt. Besonders ärgerlich: Von den vielfältigen Vorteilen, die Container zweifelsohne bieten – etwa die Separation von Berechtigungen, isolierter Zugriff auf eigene Dateisysteme oder überwachter Netzwerkverkehr – profitieren konventionelle Umgebungen praktisch gar nicht.

Ausgerechnet Systemd gehört zu jenen Lösungen, die hier ein paar Asse im Ärmel haben, von denen die meisten Admins allerdings gar nichts wissen – nicht zuletzt wegen der teils fast hysterisch geführten Kontroversen rund um das Produkt. Im Container-Kontext gehören zu diesen Funktionen Nspawnd und Portabled. Dass von diesen Tools viele Admins noch gar nichts gehört haben, ist schade: Richtig eingesetzt nutzen Nspawnd und Portabled nämlich Features aus der Container-Welt, um konventionelle Anwendungen sicherer zu machen. Wer Nspawnd klug einsetzt, erspart sich gegebenenfalls sogar den Einsatz von Docker oder Podman. Dieser Artikel geht darum auf beide Lösungen ein, stellt sie vor und erläutert, wie Admins mit ihnen das eigene Setup sinnvoll ergänzen.

Unbekannte Container-Laufzeit

Auf das Thema Laufzeitumgebung für Container angesprochen, denken die meisten Admins intuitiv an einen von zwei Kandidaten: Docker oder Podman. Bei Docker ist das nur logisch – schließlich war es jene Firma, die Container unter Linux aus dem Dornröschenschlaf wachgeküsst und mit einem ordentlichen Geschäftsmodell versehen hat. Dass Container heute überhaupt als kommerziell attraktiv gelten, ist in großen Teilen der hartnäckigen Arbeit von Docker zu verdanken. Podman hingegen kennen die meisten Admins als das Anti-Docker, das existiert, weil die Docker-Entwickler sich einst mit Red Hat angelegt und erwartungsgemäß den Kürzeren gezogen haben.

Weil Podman als Eins-zu-eins-Ersatz für Docker funktionieren soll, übernimmt es dessen architektonische Annahmen allerdings zu weiten Teilen. Und die haben es in sich, denn die Docker-Vorstellung von Containern ist komplex (Abbildung 1). Eigentlich wären Container ja eine simple Sache: Alle Container-Implementierungen am Markt greifen letztlich auf eine relativ kleine Menge von Sicherheitsfunktionen zurück, die der Linux-Kernel selbst seit ein paar Jahren bietet.

Abbildung 1: Docker besteht aus einer Vielzahl von Diensten und Komponenten – wer nur simple Abschirmung will, fühlt sich von der Menge an Features rasch überfordert. Quelle: Docker

Keine Container-Umsetzung kommt beispielsweise ohne Namespaces (Abbildung 2) aus – zur Erinnerung: Ein Namespace dient in Linux der logischen Trennung einzelner Teile des Systems. Ein Network Namespace ermöglicht etwa das Anlegen virtueller Netzwerkkarten, ohne dass diese unmittelbaren Zugriff auf die physischen NICs des Hosts bekommen. Diesen Zugriff gilt es stattdessen per Brücke oder sonstwie herzustellen. Namespaces existieren nicht nur für Netzwerk-Stacks. Sie gelten auch für einzelne Punkte im Dateisystem, für die IDs der Prozesse sowie für die Vergabe von User-IDs in einem Linux-System. Immer funktionieren sie dabei nach demselben Prinzip: Sobald ein bestimmter Prozess in einem Namespace startet, funktioniert der wie ein Gefängnis, aus dem der Ausbruch unmöglich ist.

Abbildung 2: Namespaces sind eigentlich ein Kernel-Feature, das im Kontext von Containern vielfältig zur Anwendung kommt. Sie erlauben virtuelle, vom Hauptsystem isolierte Systembereiche. Quelle: Ivan Zahariev

Hinzu gesellen sich bei vielen Container-Umgebungen Cgroups: Auch diese sind tief im Linux-Kernel verankert. Die Abkürzung steht für Control Group, und stark vereinfacht ausgedrückt steuern Control Groups den Zugriff einzelner Prozesse auf die verfügbaren Ressourcen des Systems. Sie bilden eine gute Ergänzung zu Namespaces, weil sie es erlauben, Anwendungen und Prozesse in ein noch deutlich engeres Regelwerk zu zwingen, als es nur mit Namespaces allein möglich wäre.

Mehr als Runtimes

Wenn Nspawnd eine Laufzeitumgebung für Container ist, in Form von Docker und Podman aber schon mindestens zwei gut funktionierende Umgebungen existieren – wieso, mag sich mancher fragen, hat Poettering dann schon wieder seine Finger im Spiel? Die Antwort auf diese Frage ist verblüffend einfach: Nspawnd richtet sich an jene Admins, die wirklich nur grundlegende Kernel-Features nutzen wollen, um einzelne Prozesse voneinander zu isolieren.

Das Problem mit Podman und Docker ist nämlich, dass der Admin hier niemals nur das jeweilige Programm bekommt. Stattdessen haben Docker und Podman einen riesigen Haufen an Annahmen und Voraussetzungen dafür im Schlepptau, wie man einen Container gut und sinnvoll betreibt. Mit Fakten wie Volumes, Software Defined Networking und anderem Pipapo mag sich ein Administrator vielleicht gar nicht befassen, wenn er lediglich einen Apache-Prozess in ein virtuelles Gefängnis stecken will. Und womöglich will der Admin auch nicht die etlichen Dutzende Megabyte an Zusatzsoftware für Docker oder Podman installieren, die den Wartungsaufwand erhöhen, funktional aber eigentlich gar nicht nötig wären. Wer sich von dieser Beschreibung angesprochen fühlt, gehört genau in die Zielgruppe, die Nspawnd anspricht. Einfache Container mit Bordmitteln ohne allzu viel Lametta sozusagen – auch wenn sich der Leistungsumfang von Nspawnd in den vergangenen Jahren naturgemäß erweitert hat.

Der Daemon gehört bereits seit 2015 zu Systemd, ist also eigentlich ein alter Bekannter. Das “N” im Namen steht, man ahnt es nach der Lektüre des Artikels bis hierhin, für “Namespaces”. Auf die wesentlichen Fakten reduziert handelt es sich bei Nspawnd also um ein Werkzeug, das die für den isolierten Betrieb von Anwendungen nötigen Namespaces einrichtet und die Anwendungen anschließend auch startet. Mancher Entwickler spricht scherzhaft von “Chroot auf Steroiden”, was als Metapher gut funktioniert. Im Kontext konkreter Technik allerdings hinkt der Vergleich.

Container, aber pronto

Bei den meisten Distributionen gehört Nspawnd mittlerweile zum Lieferumfang, sodass sich auf einem normalen Linux-System in kürzester Zeit ein Container aus dem Boden stampfen lässt. Die längste Zeit nimmt dabei das Erstellen eines brauchbaren Templates in Anspruch, im Docker- oder Podman-Sprech wäre von einem Image die Rede. Nspawnd benötigt lediglich ein funktionierendes Dateisystem einer Linux-Distribution. An dieses kommt der Admin auf unterschiedlichen Wegen.

Das folgende Beispiel nimmt als im Container genutzte Distribution Debian GNU/Linux 11 alias “Bullseye” an. Im ersten Schritt baut der Administrator sich auf einem Debian-System nach der Installation des Pakets debootstrap (Abbildung 3) einen leeren Ordner, der ein Bullseye-Grundsystem enthält:

# debootstrap --arch amd64 bullseye /mnt/containers/bullseye-1 https://debian.inf.tu-dresden.de/debian/

Abbildung 3: Ein für den Betrieb in Nspawnd oder Portabled geeigneter Container ist mit den typischen Debian-Werkzeugen wie Debootstrap schnell gebaut.

Wichtig: Damit der Login in den Container als Root später klappt, muss »pts/0« in »/etc/securetty« stehen. Das gelingt mittels des Kommandos »echo “pts/0” >> /mnt/containers/bullseye-1/etc/securetty«. Will der Admin nun einen laufenden Container aus dem gerade angelegten Verzeichnis heraus starten, erledigt er das mittels »systemd-nspawn -D /mnt/containers/bullseye-1«.

Hier kann er nun etwa mittels Passwd das Passwort des Systemadministrators Root im Container ändern oder neue Benutzer hinzufügen. Auch alle anderen Befehle, die der Administrator aus einem normalen Debian-System kennt, stehen ihm zur Verfügung. Daher empfiehlt es sich, zentrale Dateien wie die Paketquellen ebenfalls im Template zu hinterlegen und darin auch gleich mittels »apt update« eine Aktualisierung der Paketquellen zu veranlassen. Die Datei »/etc/hostname« löscht der Administrator im Template, damit der Container später den von Nspawnd zugewiesenen Namen verwendet.

Schließlich sollte im Container D-Bus installiert sein, weil das Userland-Werkzeug Machinectl (Abbildung 4), mit dem der Admin die Container vom Host aus steuert, sonst nicht mit dem jeweiligen Container kommunizieren kann. Ist das Template angelegt, kopiert der Admin es an einen Ort mit passendem Namen – etwa »/var/lib/machines/webserver-1« – und startet im nächsten Schritt mittels »systemd-nspawn -M webserver-1 -b -D webserver-1« den Container. Danach kann die Installation der Userland-Software erfolgen, die der Admin im Container betreiben möchte, also beispielsweise die eines Apache-Webservers.

Abbildung 4: Machinectl verwaltet Container in Nspawnd auf der Shell – auf Wunsch ist der Prozess per Unit-Datei aber auch automatisierbar.

Automation per Unit

Will der Admin den Container beim Systemstart automatisch zum Leben erwecken, lässt sich das mittels einer Systemd-Unit-Datei erreichen (Listing 1). In der kann der Admin auch gleich das Netzwerk für den Container konfigurieren; Systemd bietet hier grundsätzlich Shared Networking per Bridge oder eine Vielzahl anderer Optionen an. Die Shared-Variante ist allerdings die komfortabelste, wenn es nur um das Durchreichen einzelner Ports geht. Die Datei aus Listing 1 ist eine fertige Unit-Datei für einen “Bullseye”-Webserver-Container, den Nspawnd beim Boot mitstartet.

# /etc/systemd/nspawn/webserver-1.nspawn
[Exec]
PrivateUsers=pick
[Network]
Zone=web Port=tcp:443
[Files]
PrivateUsersChown=yes

Nach einem Systemd-Reload startet der Befehl »machinectl start webserver-1« den frisch angelegten Container. Konfiguriert der Admin das eben kopierte Verzeichnis nun so, dass darin ein Webserver läuft, agiert dieser anschließend autark und vom Rest des Systems entkoppelt. Selbst wenn also jemand in ein ungepflegtes Joomla oder Typo3 im Webserver einbricht, erhält er dadurch nicht automatisch Zugriff auf die Ressourcen anderer Nutzer oder des Hosts – und zwar völlig ohne Docker, Podman oder anderes hippes Gedöns.

Mini-Container zum Umziehen

Um zu verstehen, was der zweite Dienst in diesem Artikel – Systemd-portable – tut, ist es notwendig, sich die Funktionalität von Systemd-nspawn nochmals vor Augen zu führen. Praktisch stößt Systemd-portable in ein sehr ähnliches Horn, und unter der Haube nutzt es viel Funktionalität, die auch Nspawnd einsetzt.

Portabled gehört seit Systemd 239 zum Lieferumfang von Systemd, sollte auf aktuellen Distributionen also durchaus vorhanden sein. Zwar werden die Fraktionen der Podman- und Docker-Fans es ungern hören, aber Portabled bietet im Wesentlichen genau jene Funktionen, die Red Hat, Suse und Co. vorschweben, wenn sie von “Rumpfsystemen” reden und ihre Software bevorzugt per Container ausliefern möchten. Dabei kommt es jedoch ohne den größten Teil der Komplexität aus, die Podman und Co. implementieren.

Zugegeben, im Gegenzug fehlen im Container und um ihn herum anschließend auch ein paar Features, die bei Docker und Co. vorhanden wären. Doch wenn es um die bloße Isolation von Diensten geht und darum, diese portabel zu ermöglichen, bietet sich Portabled als hilfreiches Werkzeug an. Das gilt besonders für Bestandssysteme, die der Administrator sicherer gestalten möchte, ohne gleich einen kompletten Umstieg auf Docker oder Podman zu vollziehen.

Die Grundidee hinter Portabled besteht darin, kleine Container-Images zu bauen, die einen oder mehrere Dienste samt einer passenden Konfiguration enthalten. Sobald auf einem Linux-System ein aktueller Kernel mit Namespaces-Support sowie eine aktuelle Systemd-Umgebung existieren, so die Theorie, lässt sich das Container-Abbild auf diesem Host ausrollen und dort betreiben. Der Clou: Das funktioniert völlig unabhängig von der genutzten Paketverwaltung.

Wo ein Abbild herkommt

Damit sich ein Abbild mit Portabled nutzen lässt, muss es nur wenige Anforderungen erfüllen. Wie im Beispiel zuvor empfiehlt es sich, auch hier mit Tools wie Debootstrap zu Werke zu gehen, um ein grundlegendes Dateisystem zu erstellen. Wie im Fall von Nspawnd brauchen auch Portabled-Abbilder weder einen eigenen Kernel noch einen eigenen Bootloader. Soll ein RAW-Abbild zum Einsatz kommen, muss man es aber mit einer passenden Partitionstabelle ausstatten, die der Linux-Kernel des Host-Systems versteht. Systemd im Image muss zudem eine funktionierende Unit-Datei für den Dienst oder die Dienste haben, die der Container betreiben soll.

Die Datei »/etc/machine-id« muss ebenso vorhanden sein wie »/usr/lib/os-release«. Auch eine »resolv.conf« brauchen die Dienste im Container. Um alles andere kümmern sich Werkzeuge wie Debootstrap automatisch. Das Beispiel geht im Folgenden davon aus, dass der Admin sich ein »lamp.raw« angelegt hat, das ein basales Debian GNU/Linux 11 enthält und in dem Apache 2, MariaDB sowie PHP vorhanden sind. Wichtig: Die Systemd-Unit-Dateien müssen, damit Portabled sie später erkennt, im Abbild unter »/usr/lib/systemd/system/lamp-apache.service« sowie »/usr/lib/systemd/system/lamp-mariadb.service« liegen. Wenn Portabled den Container später auf dem Zielsystem startet, kopiert es diese Dateien auf dem Host und ergänzt sie um diverse eigene Einstellungen. Diese betreffen etwas das Logging oder das Handling von Ausgaben auf Stdout generell. Hier wird gut deutlich, dass die Systemd-Entwickler dem Admin mit portablen Images so wenig Aufwand wie möglich verursachen wollten.

Basis- und Overlay-Abbilder

Apropos wenig Aufwand: Der beschriebene Workflow suggeriert, dass der Admin das am Anfang erstellte Standardabbild für jeden Container kopieren muss, der einen Dienst oder mehrere Dienste enthalten soll. Das stimmt aber nicht, denn Portabled bietet auch die Möglichkeit, mehrere Teilabbilder per OverlayFS in ein vollständiges Abbild zu kombinieren. Damit das funktioniert, müssen die Erweiterungsabbilder im Verzeichnis »/usr/lib/extension-release.d/« eine Datei beliebigen Namens enthalten, die zumindest die Zeilen »ID=« mit der ID des Erweiterungsabbilds sowie »SYSEXT_LEVEL=« und »VERSION_ID«-Einträge mit den Daten des Erweiterungsabbilds enthält, die das ursprüngliche Abbild erweitert.

Wie Nspawnd hat auch Portabled ein eigenes CLI für die Manipulation von Containern, nämlich Portablectl. Der Befehl »portablectl attach –extension lamp_1.raw debian-bullseye_1.raw lamp« hängt beispielsweise die Erweiterung »lamp« an das Abbild für Debian GNU/Linux “Bullseye” an. Im nächsten Schritt lässt sich der Container, den Portabled wie beschrieben per OverlayFS zusammenflickt, dann behandeln, als sei er ein eigenständiger, vollständiger Container. Mittels des beschriebenen Workflows ist es insofern recht leicht möglich, ein Basis-Abbild zu pflegen und es mittels vieler kleiner Erweiterungen zu variieren.

Mkosi hilft weiter

Wer sich mit den Werkzeugen der Distributoren zum Anlegen eines Abbilds nicht anfreunden kann, findet in Mkosi möglicherweise eine funktionale Alternative. Der Name des Werkzeugs ist offensichtlich eine Anspielung auf ISO, das Dateiformat, das bei CDs und ähnlichen Datenträgern zum Einsatz kommt. Bei Mkosi steht es jedoch für Operating System Image. Bei Mkosi handelt es sich vereinfacht ausgedrückt also um ein kleines Tool, das einen Ordner mit dem kompletten Dateisystem einer Linux-Distribution aus dem Boden stampft, der sich in Systemd anschließend mit Nspawnd oder Portabled wie ein normaler Container verwenden lässt.

Das Programm findet sich im GitHub-Verzeichnis von Systemd; seine Verwendung ist fast schon trivial. Um ein Debian-Abbild zu erstellen, das den beschriebenen Details entspricht, genügt etwa folgender Befehl:

$ mkosi -d debian -r bullseye -t gpt_ext4 -b --checksum --password geheim --package openssh-client,vim -o image.raw

In »image.raw« findet sich anschließend ein “Bullseye”-Abbild, das neben der Standardauswahl an Paketen auch Openssh-client und Vim enthält. Wer kein Freund von Parametern auf der Kommandozeile ist, gibt Mkosi alternativ eine Konfigurationsdatei mit auf den Weg. Das Beispiel aus Listing 2 erzielt denselben Effekt wie der CLI-Befehl oben.

[Distribution] Distribution=debian
Release=bullseye
[Output]
Format=gpt_ext4 Bootable=yes Output=image.raw
[Packages]
Packages=         openssh-client          vim
[Validation]
Password=geheim

Ein Nachteil von Mkosi: Es kümmert sich nicht um die Installation der Pakete, die es beim Anlegen von Abbildern benötigt. Auf Debian-Systemen fällt dem Admin vor dem Aufruf von Mkosi daher die Aufgabe zu, die Pakete debootstrap und debian-archive-keyring händisch zu installieren (Abbildung 5).

Abbildung 5: Mkosi erleichtert das Bauen von Abbildern deutlich, doch die distributionsspezifischen Werkzeuge muss der Admin vorab selbst installieren.

Zugriff auf Systemressourcen

Eine letzte Frage bleibt im Rahmen dieses Artikels noch zu klären, weil sonst die Container-Freude eventuell ein jähes Ende findet: Wie macht der Admin Ressourcen des Host-Systems in Containern verfügbar? Gemeint ist damit gar nicht so sehr spezifische Hardware: Weil Container keinen eigenen Kernel brauchen, greifen sie durch den Kernel des Host-Systems ohnehin unmittelbar auf die Hardware zu – wenn auch durch Namespaces hindurch, also in einer gesteuerten Art und Weise. Gemeint sind viel eher Programme, die den Zugriff auf Teile des »/sys«-Baums brauchen oder aus »/proc« Informationen beziehen. Gelegentlich kommt es auch vor, dass eine Anwendung in einem Container auf den Unix-Socket einer Anwendung in einem anderen Container zugreifen muss.

Die Antwort auf die Frage, wie das funktioniert, ist denkbar einfach: Der Admin sorgt dafür, dass das jeweilige Verzeichnis auf dem Host existiert. Er bringt Systemd mittels der Direktiven »BindPaths=« und »BindReadOnlyPaths=« in den Systemd-Unit-Dateien der Container dazu, die Ordner als Bind-Mount im Container zur Verfügung zu stellen. Dabei gilt es jedoch, im Hinterkopf zu behalten, dass das ein bewusstes, gewolltes Verwischen der Sicherheitsgrenzen ist. Der Admin sollte diese Option darum nur wählen, wenn es absolut keine Alternative gibt.

Fazit

Die zwei Systemd-Komponenten Nspawnd und Portabled kennt kaum ein Admins – sehr zu Unrecht. Man mag zu Systemd stehen, wie man mag: Wer eine der großen Distributionen der Gegenwart nutzt, hat mit hoher Wahrscheinlichkeit ein Setup mit Systemd. Ist es schon einmal vorhanden, sollte man es auch nutzen.

Beide vorgestellten Werkzeuge bieten tatsächlichen Mehrwert. Chroot gilt aus guten Gründen mittlerweile als unsicher; es gibt mehrere dokumentierte Szenarien, aus einer Chroot-Umgebung auszubrechen. Namespaces im Linux-Kernel sind nicht nur moderner, sondern auch viel stärker auf das Thema Security ausgelegt, sodass sie ein beachtliches Plus an Sicherheit bieten. Wer Anwendungen also voneinander oder vom Rest des Systems isolieren möchte, ohne sich gleich die Komplexität von Docker oder Podman ins Haus zu holen, sollte sich die Systemd-Beigabe Nspawnd dringend genauer ansehen.

Ähnliches gilt für Portabled. Streng genommen ist die Idee dahinter ja nichts anderes als eben jene, die die großen Anbieter mit ihren Strategien im Hinblick auf Container derzeit verfolgen. An die Stelle der Abhängigkeitshölle der gängigen Paketmanager treten sauber definierte Container-Abbilder, die genau die nötigen Teile enthalten und ansonsten keine externen Abhängigkeiten aufweisen. Dass Portabled dabei nicht dem Container-Mantra “eine Mikroarchitekturanwendung in einem Container” folgt, lässt sich verschmerzen – gerade vor dem Hintergrund, dass Portabled in den meisten Fällen ohnehin eher in klassischen Umgebungen zum Einsatz kommen dürfte. Im Gegenzug erhält der Administrator auch hier mehr Komfort, höhere Sicherheit und bessere Administrierbarkeit.

Wer sich über die Isolation von Diensten und das Absichern seiner Systeme Gedanken macht, sollte die beiden Standardfunktionen von Systemd also durchaus auf dem Schirm haben. (jcb)