systemd 259: Wichtigste Änderungen und Systemanforderungen

Informatec Digital » Ressourcen » systemd 259: Wichtigste Änderungen und Systemanforderungen

Die Veröffentlichung von systemd 259 als stabile Version markiert eine weitere Wendung in einem der umstrittensten und wichtigsten Bestandteile des Linux-Ökosystems. Es geht um das Framework zum Starten und Verwalten von Diensten, das bereits die meisten Distributionen dominiert. Diese Version verschärft die Anforderungen hinsichtlich technischer Details, Sicherheit und der Abkehr von veralteten Technologien.

Dieses Update ist das Ergebnis mehrmonatiger intensiver Entwicklungsarbeit und konzentriert sich auf drei Hauptbereiche: Kompatibilität mit neuen C-Bibliotheken, verbesserte Sicherheit und die Bereinigung von Altcode (SysV-Skripte, TPM 1.2, iptables usw.). Es führt außerdem wesentliche Änderungen an der Berechtigungsverwaltung mit run0, der Speicherverwaltung mit systemd-oomd, der Protokollspeicherung und dem internen Abhängigkeitsmodell von libsystemd ein.

systemd 259 und experimentelle Unterstützung für musl

Eine der meistdiskutierten Neuerungen dieser Version ist die erstmalige teilweise Unterstützung der C-Standardbibliothek musl durch systemd 259. Diese Bibliothek findet breite Anwendung in schlanken Systemen, minimalistischen Containern und eingebetteten Umgebungen, wo Einfachheit und geringerer Ressourcenverbrauch im Vergleich zu glibc erwünscht sind.

Die Unterstützung für musl wird aktiviert, indem die Option „libc“ des Meson-Buildsystems auf „musl“ gesetzt wird . Diese Integration ist jedoch noch lange nicht vollständig: musl implementiert den Name Service Switch (NSS)-Mechanismus nicht, was beim Kompilieren mit dieser Bibliothek die Deaktivierung mehrerer Teile von systemd erzwingt.

Konkret schließt die Erstellung von systemd 259 mit musl wichtige Komponenten wie nss-systemd, nss-resolve, systemd-homed, systemd-userdbd und systemd-nsresourced aus . Auch die Option DynamicUser und die Möglichkeit, systemd-nspawn ohne Administratorrechte auszuführen, sind nicht verfügbar, was insbesondere in Containerumgebungen relevant ist, die stark auf diese Funktionen angewiesen sind.

Die Entwickler selbst räumen ein, dass sie keine langfristige Unterstützung garantieren können . Die Fortführung hängt vom tatsächlichen Interesse der Community, der Reife der zusätzlichen Schichten, die die von musl fehlenden Funktionen bereitstellen, und von Fehlerberichten speziell zu dieser Bibliothek ab. Bei geringer Nachfrage oder zu komplexer Wartung wäre es nicht überraschend, wenn diese Unterstützung in zukünftigen Versionen überprüft würde.

Diese Öffnung für musl ist jedoch auch symbolisch bedeutsam: systemd wurde jahrelang für seine fast ausschließliche Abhängigkeit von glibc kritisiert , was es für alternative Distributionen und minimalistische Anwendungsfälle ungeeignet machte. Dieser Schritt löst zwar nicht alle Probleme, bricht aber mit dem Bild eines Systems, das anderen C-Bibliotheken völlig verschlossen ist.

run0 und das neue Berechtigungsmodell: eine Alternative zu sudo

Ein weiteres wichtiges Merkmal von systemd 259 ist das Dienstprogramm run0 wurde als moderner und sicherer Ersatz für sudo vorgeschlagen.Dieses Tool basierte bereits auf systemd-run, erhält nun aber eine wichtige Funktion: die Option --empower.

Das neue Argument `--empower` ermöglicht es Ihnen, eine Sitzung mit erhöhten Rechten zu starten, ohne Ihre Benutzerkennung (UID) in root zu ändern . Anstelle eines herkömmlichen Benutzerschalters nutzt `run0` Kernel-Funktionen (wie `CAP_SYS_ADMIN`), um genau die Berechtigungen zu erteilen, die für privilegierte Aktionen erforderlich sind, und reduziert so das Risiko, vollständig root zu werden.

Darüber hinaus werden mit diesem Ansatz initiierte Prozesse in einer logischen „Befähigungsgruppe“ zusammengefasst, die Zugriff auf eine breite Palette von Aktionen hat, die von Polkit verwaltet werden . Der Vorteil liegt in der fein abgestuften und kontrollierten Erhöhung der Berechtigungen, wodurch eine strengere Trennung als bei herkömmlichem sudo gewährleistet wird, wo der Zugriff oft zu weit gefasst ist.

Dieser Ansatz entspricht dem Trend, die direkte Nutzung des Root-Benutzers nach Möglichkeit zu vermeiden – ein hochgeschätztes Sicherheitsprinzip. Die tatsächliche Effektivität von run0 muss jedoch noch im Produktivbetrieb unter Beweis gestellt werden: Wir müssen beobachten, wie es sich in die Richtlinien der einzelnen Distributionen integriert, wie seine Funktionen in der Praxis konfiguriert werden und wie gut die Systemadministration den neuen Workflow anpasst.

Ende der Unterstützung für SysV-Init und Legacy-Bereinigung

Mit systemd 259 beginnt auch das endgültige Ende der Service-Skripte im System-V-Stil . Die Kompatibilität mit diesen klassischen Mechanismen galt schon seit Jahren als „im Verschwinden begriffen“, und nun wurde ein klarer Zeitplan für ihre Abschaffung festgelegt.

Diese Version kündigt mit Blick auf die nächste Hauptversion Folgendes an: Historische Komponenten wie systemd-sysv-generator, systemd-rc-local-generator und systemd-sysv-install werden entfernt.Das heißt, die Skripte in /etc/init.d/ Sie werden von systemd nicht mehr berücksichtigt, womit ein Übergang abgeschlossen wird, der fast ein Jahrzehnt gedauert hat.

Für Administratoren, die noch benutzerdefinierte Dienste auf Basis von SysV-Skripten betreiben , bedeutet dies: Es gilt, alle diese Skripte zu erfassen und in native systemd-Units (.service, .socket usw.) zu migrieren. Große Distributionen haben diesen Übergang bereits fast vollständig abgeschlossen, doch in benutzerdefinierten Umgebungen oder älteren Installationen laufen möglicherweise noch einige Überbleibsel im Hintergrund.

Dieser Legacy-Bereinigungsprozess beschränkt sich nicht auf SysV. Neuere Versionen von systemd haben bereits die Unterstützung für klassische Methoden wie `/forcefsck` und `/fastboot` entfernt und sie durch Kernelparameter und modernere Authentifizierungsmechanismen ersetzt. Mit Version 259 wird der Weg weiterverfolgt: weniger Abwärtskompatibilität zugunsten einer besser wartbaren und konsistenteren Codebasis.

Minimale Systemd-Anforderungen 259: Kernel, Bibliotheken und Umgebung

Eine der Änderungen, die sich am stärksten auf ältere Systeme auswirken kann, ist die Erhöhung der Mindestsoftwareanforderungen für die Ausführung von systemd 259. Diese Version berücksichtigt keine sehr alte Hardware oder Architektur mehr und zielt eindeutig auf moderne Plattformen ab.

Zu den wichtigsten Anforderungen, die in systemd 259 zusammengefasst wurden, gehören: ein Bekenntnis zu modernen Plattformen

• Mindestens Linux-Kernel 5.10 (mit der Empfehlung, mindestens bis 5.14 zu gehen).
• glibc2.34 als Minimalversion der GNU-Standardbibliothek.
• OpenSSL 3.0.0 als zwingende Grundlage für die unterstützten Verschlüsselungsfunktionen.
• util-linux 2.37 als Voraussetzung für die grundlegenden Funktionen des Systems.
• libxcrypt 4.4.0 zur Verwaltung kryptografischer Funktionen im Zusammenhang mit Passwörtern.
• cryptsetup 2.4.0 und libseccomp 2.4.0 zur Volumenverschlüsselung und Systemaufruffilterung.
• Python 3.9.0 als Mindestvoraussetzung für Hilfsprogramme.
• Einige Notizen erwähnen auch Elfutils 0.177 als Teil des aktualisierten Abhängigkeitssatzes.

Diese Verschärfung bedeutet, dass sehr alte Systeme oder Distributionen, die noch Kernel-Versionen vor 5.10 verwenden, automatisch vom Support für diese Version ausgeschlossen werden, sofern sie ihre zugrundeliegende Technologie nicht aktualisieren. Im Gegenzug wird ein homogeneres Ökosystem mit weniger Sonderfällen und Kompromisslösungen erreicht.

Für die meisten gängigen Desktop- und Server-Distributionen sollten diese Anforderungen kein Problem darstellen: Moderne LTS-Kernel-Versionen übertreffen die 5.10-Grenze bereits deutlich , und die genannten Bibliotheken sind weit verbreitet. Die größten Schwierigkeiten können bei eingebetteten Systemen, Appliances oder sehr konservativen Installationen auftreten, die nicht regelmäßig aktualisiert werden.

Verbesserte Sicherheit: TPM 2.0, Verschlüsselung und Gerätebeschränkungen

Im Bereich Sicherheit beschleunigt systemd 259 seine Entwicklung durch mehrere wichtige Entscheidungen. Die auffälligste ist, dass systemd-boot und systemd-stub die Unterstützung für TPM 1.2 endgültig einstellen , sodass ab sofort nur noch TPM 2.0 als Referenzstandard gilt.

Diese Änderung bedeutet, dass Systeme, die bisher TPM 1.2 zur Verwaltung von Secure-Boot-Richtlinien oder Verschlüsselungsschlüsseln nutzten, ein Hardware-Upgrade (z. B. durch Austausch des Motherboards) benötigen, um diese Funktionen mit neueren Versionen von systemd-boot weiterhin nutzen zu können. Viele Linux-Desktop-Nutzer haben TPM und Secure Boot deaktiviert und bemerken die Änderung daher möglicherweise gar nicht. In Unternehmensumgebungen oder Umgebungen mit hohen Sicherheitsanforderungen könnte sie jedoch Auswirkungen haben.

In früheren Versionen, wie beispielsweise systemd 258, wurden in diesem Bereich bereits wesentliche Anpassungen vorgenommen: OpenSSL wurde zur einzigen von systemd-resolved und systemd-importd unterstützten Verschlüsselungsbibliothek , wodurch Alternativen wie GnuTLS und libgcrypt nicht mehr berücksichtigt wurden. All dies deutet auf eine Konsolidierung hin zu einem kleineren, besser kontrollierten Satz kryptografischer Werkzeuge.

Ebenfalls in Branch 258 wurden strengere Standardzugriffsbeschränkungen für tty/pts eingeführt : Knoten werden mit Berechtigungen von 0600 anstatt 0620 erstellt, wodurch verhindert wird, dass andere Benutzer auf unsere Terminals schreiben. Dies ist ein weiteres Beispiel dafür, wie systemd seit einiger Zeit Details auf niedriger Ebene optimiert, was in Kombination die Gesamtsicherheit des Systems stärkt.

libsystemd ist modularer und wird dynamisch geladen.

Um eine höhere Effizienz und eine geringere Abhängigkeitslast zu erreichen, führt systemd 259 grundlegende Änderungen an der Interaktion von libsystemd mit anderen Systembibliotheken ein . Ziel ist es, zu verhindern, dass alles von Anfang an geladen wird, sondern es nur bei Bedarf zu laden.

Konkret verwendet libsystemd nun dlopen(), um Bibliotheken wie libacl, libblkid, libseccomp, libselinux und libmount dynamisch zu laden . Das bedeutet, dass diese Abhängigkeiten weder zur Kompilierzeit fest verknüpft noch immer in den Speicher geladen werden: Sie werden nur dann aktiviert, wenn eine bestimmte Funktion sie benötigt.

Dieser Mechanismus mit `dlopen()` findet auch Anwendung bei der Integration mit dem Linux-Audit-Subsystem und PAM . Dadurch können der Systemd-Start und der normale Betrieb in Umgebungen, die nicht alle diese Komponenten gleichzeitig benötigen, ressourcenschonender gestaltet werden.

Andererseits wurde die Funktionalität, die zuvor von der libcap-Bibliothek bereitgestellt wurde, direkt in libsystemd integriert . Dadurch entfällt eine weitere externe Abhängigkeit, was den Build-Prozess vereinfacht und potenzielle Fehlerquellen oder Inkompatibilitäten reduziert.

Im Allgemeinen bietet dieser Ansatz eine bessere Modularität und einen geringeren Speicher- und Festplattenbedarf , insbesondere in Systemen, in denen schnelle Startzeiten und eine kompakte Anordnung von Diensten erwünscht sind.

Netzwerk- und Containeränderungen: Tschüss iptables, hallo nftables

Auch der Bereich Netzwerk und Virtualisierung erfährt bedeutende Änderungen. Ab systemd 259 unterstützen systemd-networkd und systemd-nspawn die Erstellung von NAT-Regeln mit iptables/libiptc nicht mehr . Als einziges Firewall-Backend wird nun nftables unterstützt.

Dies betrifft unmittelbar Container, die mit systemd-nspawn verwaltet werden und auf NAT via iptables angewiesen sind , sowie Netzwerke, die in systemd-networkd definiert sind und Adressübersetzungsregeln mit dem klassischen Backend verwenden. In Tests mit Release Candidates traten unbemerkte Ausfälle der NAT-Funktionalität auf, bis die gesamte Konfiguration auf nftables migriert wurde.

Über die Übersetzung von Adressen hinaus, systemd-resolved erhält die Fähigkeit, lokale Hooks zu verwenden. en /run/systemd/resolve.hook/Diese Befehle werden jedes Mal ausgeführt, wenn eine lokale Namensauflösungsanfrage gestellt wird. Dies ermöglicht dem Administrator erweiterte DNS-Anpassungen und die Implementierung spezifischer Logik.

Im Bereich des Bildimports und der Bildverwaltung, systemd-importd enthält native Logik für die Arbeit mit TAR-DateienDabei wird libarchive aus dem GNU tar-Dienstprogramm verwendet. Außerdem können sowohl systemd-importd als auch systemd-machined nun im Benutzermodus ausgeführt werden und Systemabbilder verwalten, die in ~/.local/state/machines/.

Um diese Modi zu steuern, bietet das Dienstprogramm importctl die Optionen „--user“ und „--system“ , mit denen Sie einfach auswählen können, ob Sie im Benutzerkontext oder auf Systemebene arbeiten möchten. Dieser Ansatz ist nützlich für Entwicklungs- und Testumgebungen, in denen Sie die globale Konfiguration des Systems nicht ändern möchten.

Permanente Protokollierung als Standard und Festplattenverwaltung

Eine weitere Änderung mit praktischen Auswirkungen ist die Modifizierung der Standard-Journalspeichermodus, das Protokollierungssubsystem von systemd. Bisher hing das „automatische“ Verhalten von der Existenz oder Nichtexistenz des Verzeichnisses ab. /var/log/journal.

Mit systemd 259 wird der Standardmodus auf „persistent “ gesetzt, unabhängig davon, ob der Ordner zuvor existierte. Das bedeutet, dass das Journal standardmäßig dauerhaft auf der Festplatte gespeichert wird, anstatt im flüchtigen Arbeitsspeicher (RAM) abgelegt zu werden.

Diese Entscheidung hat Vor- und Nachteile. Einerseits vereinfacht sie die Fehlersuche erheblich , da die Protokolle auch nach Neustarts erhalten bleiben, ohne dass der Administrator eingreifen muss. Andererseits kann sie in eingebetteten Systemen, schlanken Containern oder Umgebungen mit sehr begrenztem Speicherplatz zu einem deutlichen Anstieg der Festplattennutzung führen.

In solchen Fällen ist es wichtiger denn je, die Richtlinien für Journalrotation und -größe anzupassen oder sogar einen anderen Speichermodus zu erzwingen, wenn man übermäßigen Verschleiß vermeiden will (zum Beispiel bei Flash-Speichern mit begrenzter Anzahl an Schreibzyklen).

systemd-oomd, OOM-Tracking und Ressourcenkontrolle

Das Speichermanagement und die Behandlung von Speichermangelszenarien wurden ebenfalls deutlich verbessert. Die Komponente systemd-oomd, die für die Reaktion auf Speichermangel zuständig ist , verfügt nun über neue Eigenschaften, die eine bessere Übersichtlichkeit ermöglichen.

Die Eigenschaften OOMKills und ManagedOOMKills sind nun für Dienste verfügbar und protokollieren die Anzahl der Prozesse, die vom Kernel oder von systemd-oomd aufgrund von Speichermangel beendet wurden. Diese Informationen können direkt mit systemd-Tools abgerufen werden, was die nachfolgende Vorfallsanalyse erleichtert.

Wenn ein Prozess außer Kontrolle gerät und so viel RAM verbraucht, dass das System gefährdet wird , ermöglichen Ihnen diese Metriken, auf einen Blick zu erkennen, welche Einheiten betroffen sind, wie oft der OOM-Mechanismus ausgelöst wurde und welche Komponenten den größten Speicherdruck verursachen.

Für Administratoren von Umgebungen mit hoher Auslastung oder Systemen mit sehr knappen Ressourcen ist diese verbesserte Möglichkeit, den Speicherverbrauch zu beobachten , besonders nützlich, da sie dabei hilft, schlecht dimensionierte Dienste oder Speicherlecks zu identifizieren, die zuvor möglicherweise unbemerkt geblieben wären.

Weitere bemerkenswerte Verbesserungen in systemd 259

Neben den oben genannten Hauptänderungen enthält systemd 259 zahlreiche Verbesserungen und kleinere Optimierungen im gesamten Ökosystem . Viele davon sind recht technischer Natur, aber es lohnt sich, sie genauer anzusehen, da sie zusammengenommen eine bedeutende Veränderung bewirken.

Zu den neuen Funktionen der API gehören: Die auf dem Varlink-Protokoll basierende Schnittstelle wird erweitert um den Zugriff auf die Dienstkonfiguration zu ermöglichen und IPC-Aufrufe wie z. B. Reload() y Reexecute()Zusätzlich wurden spezifische Aufrufe hinzugefügt, um die Funktionalitäten von systemd-repart, systemd-resolved und systemd-networkd zu handhaben.

Im Bereich Konfiguration und Einheiten wurde die Option `ExecReloadPost` eingeführt , mit der Befehle unmittelbar nach dem Neuladen der Dienstkonfiguration ausgeführt werden können. Außerdem werden Konfigurationsdateien mit der Endung `.ignore` nun automatisch verworfen – ein einfacher Trick, um Dateien zu deaktivieren, ohne sie löschen oder umbenennen zu müssen.

Temporäre Einheiten erlangen Eigentum RootDirectoryFileDescriptor, wodurch der Dateideskriptor definiert wird, der dem Stammverzeichnis entspricht, und eine neue Option wird hinzugefügt Benutzernamespacepfad, wodurch Sie ein Laufwerk mit einem Benutzer-Namespace verknüpfen können, indem Sie einen Pfad angeben in /procIn systemd-nspawn erscheint die Direktive NamespacePath im Abschnitt aus den .nspawn-Dateien, um den zu verwendenden Netzwerk-Namespace anzugeben.

Weitere Komponenten wie z systemd-sysext und systemd-confext enthalten dedizierte Konfigurationsdateien en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.confUmgebungsvariablen SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS Sie ermöglichen es Ihnen, die Montageoptionen für Overlays anzupassen.

In der udev-Welt wird die Option hinzugefügt. OPTIONS=»dump-json» to systemd-udevd Um den aktuellen Status eines Ereignisses im JSON-Format anzuzeigen, dient die Funktion net_id Es generiert vorhersagbare Namen für drahtlose Schnittstellen auf Systemen mit DeviceTree und erstellt symbolische Verknüpfungen. /dev/gpio/by-id/... für GPIO-Geräte.

Der Benutzer- und Kontobereich wird ebenfalls verbessert: Die Benutzerdatenbank enthält ein UUID-Feld.Das Dienstprogramm userdbctl unterstützt die Option "-uuid", um anhand dieser Kennung zu suchen, und homectl update Es unterstützt nun die Option "--recovery-key", um bestehenden Konten Wiederherstellungsschlüssel hinzuzufügen.

In systemd-homed werden die Optionen "--prompt-shell" und "--prompt-groups" beim ersten Systemstart mithilfe von systemd-homed-firstboot.service eingebunden , und in systemd-firstboot scheint "--prompt-keymap-auto" beim ersten Systemstart nach der Tastaturbelegung zu fragen, wenn die lokale Konsole verwendet wird.

El Der Bootmanager systemd-boot bietet die Möglichkeit, den Detaillierungsgrad des Protokolls festzulegen. mit Parameter log-level en loader.conf oder mit dem SMBIOS-Feld io.systemd.boot.loglevelDarüber hinaus werden strengere Anforderungen an Partitionen wie XBOOTLDR konsolidiert, die nun im VFAT-Format vorliegen müssen, analog zu den Anforderungen an die ESP in modernen UEFI-Systemen.

Auf der Ebene erweitert systemd-networkd die Netzwerkfunktionen und fügt dem DHCP-Server die Optionen EmitDomain und Domain hinzu. Zudem implementiert es einen Controller, der die per DHCP vergebenen Hostnamen mithilfe der DNS-Auflösung ermittelt. Gleichzeitig lädt systemd-modules-load Kernelmodule parallel , wodurch die Bootzeiten auf Systemen mit vielen Treibern verkürzt werden.

Schließlich fügt systemd-integrity-setup im Abschnitt zur Integrität Unterstützung für die Algorithmen HMAC-SHA256, PHMAC-SHA256 und PHMAC-SHA512 hinzu und erweitert damit die Palette der kryptografischen Optionen zum Schutz der Systemintegrität.

Mit all diesen Änderungen festigt systemd 259 seine Position als technisch anspruchsvolle, zukunftsorientierte Version . Es fordert Benutzer auf, veraltete Technologien wie SysV init, iptables und TPM 1.2 aufzugeben, stärkt die Sicherheit und Ressourcenkontrolle, verbessert die interne Modularität und ermöglicht neue Konfigurationen mit musl, wenn auch nur teilweise und unter bestimmten Bedingungen. Für Endbenutzer von Point-Release-Distributionen werden viele dieser neuen Funktionen kaum spürbar sein; Administratoren und Projekte, die stets die neueste Version verwenden, sollten jedoch Skripte, Units und Hardwareanforderungen sorgfältig überprüfen, bevor sie umsteigen.