Systemd 260: TPM2, Sandboxing und neue Funktionen in Linux

Hardware-Leitfaden » Kaufberatungen » Systemd 260: TPM2, Sandboxing und neue Funktionen in Linux

Mit der Veröffentlichung von systemd 260 gehen Linux-Distributionen einen weiteren wichtigen Schritt hin zu einem moderneren, sichereren Ökosystem, das auf Cloud-Umgebungen, Virtualisierung und Automatisierung ausgerichtet ist. Diese Version optimiert nicht nur Details, sondern führt auch bedeutende Änderungen beim Bootvorgang, der Dienstverwaltung, der Netzwerkfunktionen, der Nutzung von TPM2 für Integrität und Verschlüsselung sowie bei Sandboxing-Funktionen auf Laufwerksebene ein.

Gleichzeitig verbessert das Projekt seine Dokumentation und seinen Ansatz für die Arbeit mit KI-Agenten und verdeutlicht damit, dass systemd eine zentrale Säule darstellt, an die immer mehr Entwicklungs- und Überwachungstools angebunden werden. Wenn Sie Linux-Systeme auf Servern, in der Cloud, auf Firmenrechnern oder in Laboren verwalten, sollten Sie sich die neuen Funktionen genauer ansehen, um Updates und Konfigurationsanpassungen zu planen.

Ein endgültiger Abschied von System V und der vollständigen Abhängigkeit von nativen Laufwerken.

Eine der auffälligsten Änderungen in systemd 260 ist die vollständige Entfernung der Unterstützung für System-V-Skripte . Der klassische Bootvorgang basierend auf /etc/init.d wurde bereits seit Jahren schrittweise abgeschafft, verschwindet nun aber endgültig aus dem systemd-Code.

Dies bedeutet, dass die Komponenten, die für die Verbindung zwischen SysV-Skripten und nativen Einheiten zuständig waren, entfernt wurden: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator und systemd-sysv-install existieren nicht mehr. Daher starten alle Dienste, die noch von diesen älteren Mechanismen abhängen, auf Systemen mit systemd 260 nicht mehr.

Im Zuge der Bereinigung wurden mehrere Meson-Build-Optionen als veraltet markiert oder entfernt. Die Flags `-Drc-local=`, `-Dsysvinit-path=` und `-Dsysvrcnd-path=` wurden in die Archive verschoben, während andere wie `-Dintegration-tests=` und `-Dcryptolib=` vollständig entfernt wurden. Dies verdeutlicht: Alles muss nun von nativen Units und der modernen Systemd-Infrastruktur verarbeitet werden.

Für viele europäische Infrastrukturen, die noch auf älteren Komponenten basieren, erfordert diese Umstellung eine Überprüfung interner Dienste, benutzerdefinierter Skripte und bestehender Installationen. Die Migration zu klar definierten Unit-Dateien ist nicht mehr nur empfehlenswert, sondern zwingend erforderlich, wenn Dienste weiterhin auf Distributionen mit systemd 260 ausgeführt werden sollen.

Höhere Kernel-Anforderungen und ein Fokus auf aktuelle Umgebungen

Die neue Version setzt höhere Anforderungen an den Kernel: Ab sofort ist Linux-Kernel 5.10 die minimal unterstützte Version , ältere Versionen wie 5.4 werden nicht mehr unterstützt. Das Projekt empfiehlt außerdem, idealerweise mit einem Kernel der Version 5.14 oder höher zu arbeiten und rät insbesondere zur Version 6.6 , um alle verfügbaren Funktionen voll auszuschöpfen.

Diese erhöhten Anforderungen stellen in modernen Distributionen in der Regel kein Problem dar, können aber in sehr konservativen Umgebungen oder seit vielen Jahren gewarteten Embedded-Systemen zu Komplikationen führen. Vor einem Upgrade auf systemd 260 empfiehlt es sich, den verwendeten Kernel zu überprüfen, insbesondere in europäischen Rechenzentren mit Langzeitbetrieb oder benutzerdefinierten Images.

Am anderen Ende des Spektrums stehen Rolling-Release-Distributionen wie Arch Linux oder openSUSE Tumbleweed, die bei Nutzern, die stets die neuesten Funktionen wünschen, sehr beliebt sind und neue Kernel und neue Zweige von systemd schnell integrieren. Andere Distributionen wie Fedora gewährleisten eine gewisse Stabilität der Hauptversion von systemd während des gesamten Lebenszyklus jeder Release, was etwas mehr Zeit für die Planung von Migrationen ermöglicht.

TPM2, Boot-Integrität und erweiterte SRK-Unterstützung

Einer der Bereiche, in denen sich systemd am stärksten weiterentwickelt, ist die Integration mit TPM2 (Trusted Platform Module 2.0) . Dieser Chip, der in modernen UEFI-Motherboards sowie in Mittelklasse- und High-End-Hardware immer häufiger zum Einsatz kommt, ermöglicht es, Geheimnisse im Systemzustand zu verankern, Bootphasen zu messen und verschlüsselte Volumes automatisch zu entsperren, sobald die Umgebung den Erwartungen entspricht.

Systemd 260 erweitert diese Integration durch zusätzliche Tools und Services, die verschiedene Phasen des Bootvorgangs abdecken. Eine Schlüsselkomponente ist systemd-tpm2-setup , das die Infrastruktur rund um den Storage Root Key (SRK) des TPM vorbereitet . Dieser Root Key dient als kryptografische Grundlage für die sichere Kommunikation mit dem Chip und die sichere Speicherung weiterer Geheimnisse.

Beim Systemstart werden zwei Phasen unterschieden: eine sehr frühe Phase in der Initrd und eine weitere im Root-System. In der ersten Phase prüft der Dienst „Early TPM SRK Setup“, ob das TPM bereits einen gespeicherten SRK besitzt. Falls nicht, erstellt er ihn und stellt ihn temporär unter /run/systemd/tpm2-srk-public-key.* bereit. Sobald das eigentliche Dateisystem eingebunden ist, konsolidiert der Dienst den SRK und überprüft, ob der in /var/lib/systemd/tpm2-srk-public-key.pem gespeicherte Schlüssel mit dem im TPM übereinstimmt.

In korrekt konfigurierten Umgebungen werden Journaleinträge wie „SRK ist bereits im TPM gespeichert“ und Meldungen angezeigt, die bestätigen, dass der SRK-Footprint dem erwarteten entspricht. Ist die Umgebung jedoch nicht korrekt konfiguriert (beispielsweise bei der Verwendung von Yocto oder auf Boards wie dem Raspberry Pi mit SPI-basiertem TPM und benutzerdefinierten Boot-Methoden wie U-Boot und Measured Boot), kann es vorkommen, dass systemd diese Dateien unter /var/lib/systemd nicht erstellt. Dies wirft Zweifel an der korrekten Konfiguration des SRK auf.

Wenn sich der TPM-Status geändert hat, Partitionen modifiziert oder die Bootreihenfolge angepasst wurde, ist die zugehörige Richtlinie möglicherweise nicht mehr gültig. In solchen Fällen empfehlen einige Administratoren, den TPM-Steckplatz bzw. die Richtlinie zu löschen und den Schlüssel neu zu registrieren . Die Vorgehensweise ähnelt der in Anleitungen zur Festplattenverschlüsselung mit TPM in Umgebungen wie openSUSE beschriebenen. Dort wird detailliert erklärt, wie die PCR-Richtlinie wiederhergestellt und die Datenträgerentsperrung neu verknüpft wird.

Neben dem SRK stellt die Einführung des internen Hilfsprogramms „tpm2_id“ in udev eine weitere praktische Verbesserung dar . Dieses integrierte Tool wird ausgeführt, sobald das System ein TPM2-Gerät erkennt, und extrahiert automatisch Hersteller und Modellkennung . Dies vereinfacht die Inventarisierung von Sicherheitshardware, was insbesondere in öffentlichen Verwaltungen, regulierten Unternehmen oder kritischen Infrastrukturen von großem Nutzen ist, da dort die genaue Kenntnis der eingesetzten TPM-Module unerlässlich ist.

Die Integration mit der Boot-Messinfrastruktur wird durch spezifische Einheiten wie systemd-pcrextend weiter gestärkt , die Ereignisse wie „enter-initrd“, „leave-initrd“, „sysinit“ und „ready“ in verschiedenen PCRs (z. B. PCR 11) protokollieren. Diese Erweiterungssequenz ermöglicht es dem TPM, einen kryptografisch verifizierbaren Datensatz des Bootvorgangs zu erstellen, der dann für Trusted-Boot-Richtlinien oder für UKI (Unified Kernel Images) verwendet werden kann , um den Zustand des Systems vor der Schlüsselfreigabe zu validieren.

Sicherheitsmaßnahmen und Sandboxing von Diensten mit systemd

Systemd startet nicht nur Prozesse, sondern bietet auch umfassende Sandboxing-Direktiven , um Dienste zu isolieren und den Schaden im Falle einer Kompromittierung zu begrenzen. Dieser mehrschichtige Verteidigungsansatz basiert auf Cgroups, Namensräumen, Kernel-Funktionen und Systemaufruffiltern (seccomp).

Um die Sicherheit eines bestimmten Dienstes zu bewerten, stellt systemd das Sicherheitstool systemd-analyze bereit . Dessen Ausführung generiert einen Bericht mit einem Gefährdungsindex auf einer Skala von 0 bis 10, wobei ein niedrigerer Wert eine bessere Sicherheit bedeutet. Der Bericht zeigt detailliert an, welche Schutzmechanismen aktiviert oder deaktiviert sind (Netzwerkisolation, Dateisystemzugriff, Gerätezugriff usw.). Dadurch lassen sich fehlende Einstellungen leicht identifizieren und überprüfen, ob Änderungen den Indexwert tatsächlich verbessern.

Anstatt die Originaleinheit zu bearbeiten – die bei zukünftigen Paketaktualisierungen verloren ginge – wird empfohlen, eine zu erstellen Override en /etc/systemd/system/mi-servicio.service.d/ mit einer Datei, zum Beispiel sandbox.confNach der Änderung laden Sie die Konfiguration einfach neu mit Systemctl-Daemon-Reload und starten Sie den Dienst neu, damit die neuen Einschränkungen in Kraft treten.

Auf Dateisystemebene ist eine der wichtigsten Optionen ProtectSystem=Werte wie zum Beispiel strict, full o true Sie binden verschiedene Teile des Baums im schreibgeschützten Modus ein. Üblicherweise wird, wenn möglich, Folgendes verwendet: ProtectSystem=strictDadurch werden die Verzeichnisse /usr, /boot, /efi und /etc für den Dienst schreibgeschützt. Falls eine Anwendung in bestimmte Verzeichnisse schreiben muss, kann sie dies mit folgendem Befehl tun: ReadWritePaths=/path in der Einheit.

Um den Datenschutz weiter zu verbessern, wird empfohlen, den Zugriff auf Benutzerverzeichnisse mit `ProtectHome=true` einzuschränken . Dadurch wird verhindert, dass der Dienst `/home`, `/root` oder `/run/user` liest. Zusätzlich erstellt `PrivateTmp=true` isolierte `/tmp`- und `/var/tmp`-Bereiche, wodurch die Sichtbarkeit temporärer Dateien zwischen Prozessen unterbunden wird.

Bei Geräten blendet `PrivateDevices=true` den eigentlichen `/dev`-Baum aus und ersetzt ihn durch eine minimale Menge sicherer Pseudo-Geräte (null, zero, random usw.). Benötigt ein Laufwerk ein bestimmtes Gerät (z. B. eine serielle Schnittstelle oder einen Festplattenblock), kann dies mit `DeviceAllow=/dev/xxx rw` oder im Nur-Lese-Modus gewährt werden.

Das Netzwerk ist ebenfalls ein wichtiger Vektor. PrivateNetwork=true Es wird ein isolierter Netzwerk-Namensraum erstellt, der nur die Loopback-Schnittstelle übrig lässt; der Dienst sieht keine physischen Schnittstellen und kann nicht mit der Außenwelt kommunizieren. Alternativ können Sie die Adressfamilien einschränken, die er verwenden darf, indem Sie RestrictAddressFamilies=nur AF_INET und AF_INET6 für IPv4/IPv6, AF_UNIX für lokale Sockets oder sogar none um die Netzwerkfähigkeiten vollständig zu japanisieren.

Bezüglich der Berechtigungen ist die Direktive `NoNewPrivileges=true` eine der wirksamsten: Sie verhindert, dass der Prozess über Setuid-Binärdateien oder Capability-Änderungen neue Berechtigungen erlangt. Kurz gesagt: Selbst wenn der Dienst anfälligen Code ausführt, sollte er nicht in der Lage sein, über herkömmliche Mechanismen Root-Rechte zu erlangen. In Kombination mit `CapabilityBoundingSet=` , das die genaue Liste der zulässigen Capabilities definiert (z. B. nur `CAP_NET_BIND_SERVICE` zum Abhören niedriger Ports), wird die Angriffsfläche minimiert.

Um noch einen Schritt weiter zu gehen, ermöglicht systemd das Filtern von Systemaufrufen mit SystemCallFilter=Anstatt eine manuelle Liste von Systemaufrufen zu pflegen, werden vordefinierte Gruppen verwendet, wie zum Beispiel @system-service, @network-io, @basic-io oder Gruppen wie ~@privileged. Mit systemd-analyze syscall-filter Es ist möglich zu überprüfen, welche spezifischen Aufrufe zu welcher Gruppe gehören. Dies ermöglicht die Erstellung eines sehr eingeschränkten Ausführungsprofils, ähnlich dem, was eine dedizierte Sandbox bieten würde.

Weitere relevante Einstellungen sind `ProtectKernelTunables=true` , wodurch Änderungen an Kernelparametern in `/proc/sys` und `/sys` verhindert werden; `ProtectKernelModules=true` , wodurch das Laden und Entladen von Modulen unterbunden wird; `ProtectKernelLogs=true` , wodurch das Lesen von Kernelprotokollen verhindert wird; und `ProtectControlGroups=true` , wodurch Schreibvorgänge in die Cgroups-Hierarchie blockiert werden. All dies funktioniert nahtlos mit neuen Funktionen zur Benutzerisolation wie ` PrivateUsers=full` , das in Version 260 aktualisiert wurde, um den gesamten Bereich der Benutzer-IDs abzubilden und somit die bisherigen Workarounds für verschachtelte systemd-Umgebungen zu eliminieren.

PrivateUsers, xaccess und neue Gerätezugriffskontrollen

Der Mechanismus PrivateUsers , der es Diensten ermöglicht, in einem isolierten Benutzer-ID-Bereich zu laufen, wurde in systemd 260 konsolidiert. Die Option PrivateUsers=full ordnet nun den gesamten Bereich der Kennungen zu, was die Verwendung in Containern und auf Systemen mit verschachtelten systemd-Instanzen älterer Versionen (vor 257) vereinfacht. Diese Verbesserung beseitigt die zuvor verwendeten Workarounds zur Erkennung dieser älteren Instanzen.

Parallel dazu führten Komponenten wie systemd-logind und systemd-udevd das Konzept von xaccess ein . Dieser Mechanismus ergänzt die klassische Logik von uaccess , die Benutzern mit aktiven Grafiksitzungen auf dem lokalen Rechner Zugriff auf bestimmte Geräte (z. B. Audio oder Video) gewährt. Mit xaccess lassen sich Berechtigungen an entfernte Benutzer mit speziell gekennzeichneten Sitzungen delegieren , sodass beispielsweise ein Benutzer, der über Remote Desktop verbunden ist, auf lokale GPU-Rendering-Geräte zugreifen kann, ohne dem gesamten System umfassende Berechtigungen erteilen zu müssen.

Die Konfiguration dieser Sitzungen erfolgt über Umgebungsvariablen, die über PAM bereitgestellt werden, insbesondere PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , wodurch definiert werden kann, welche spezifischen Geräte in diese Logik einbezogen werden. Dieser Ansatz entspricht weitgehend den regulatorischen Anforderungen und Datenschutzbestimmungen der Europäischen Union, die Granularität und Nachverfolgbarkeit für den Zugriff auf sensible Hardware fordern.

mstack, systemd-mstack und neue Container-Tools

Im Bereich der Containerisierung führt systemd 260 die Funktionalität ein. mstack und ein zugehöriger Befehl, systemd-mstackDie Idee hinter mstack besteht darin, die Definition eines OverlayFS basierend auf der Struktur eines speziellen Verzeichnisses namens .mstack/, das einer spezifischen Spezifikation für die Organisation seiner Ebenen folgt.

Das neue Kommandozeilentool systemd-mstack vereinfacht die interaktive Arbeit mit diesen Dateisystem-Stacks und bietet mehr Flexibilität beim Einrichten von mehrschichtigen Umgebungen für Container oder hochgradig isolierte Dienste. Diese Funktionalität ist auch mit Verbesserungen in systemd-importd verknüpft, das die Unterstützung für das Herunterladen und Verwalten von OCI-Images erweitert und damit die Rolle von systemd als Containerisierungs- und Sandboxing-Engine stärkt – eine weit verbreitete Anwendung bei europäischen Cloud-Anbietern und modernen Hosting-Plattformen.

Netzwerk: Integration mit ModemManager und neue Leistungsoptionen

Auf der Netzwerkschicht gewinnt systemd-networkd weiterhin an Bedeutung. Eine der bemerkenswertesten Neuerungen ist die Integration mit ModemManager über das „simple connect“-Protokoll , wodurch Modems und Mobilfunkverbindungen direkt von networkd aus verwaltet werden können, ohne auf externe Tools angewiesen zu sein.

Um diesen Ablauf zu unterstützen, wird ein neuer Abschnitt hinzugefügt. zu den Konfigurationsdateien, mit Parametern wie APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Dies erleichtert die Bereitstellung in ländliche Gebiete oder Umgebungen mit Konnektivität basierend auf Mobilfunknetzen, sehr verbreitet in bestimmten Gebieten Europas, wo es nicht immer Glasfaseranschlüsse oder qualitativ hochwertige Festnetzanschlüsse gibt.

Die systemd-networkd .link -Dateien bieten hinsichtlich der Leistung neue Optionen speziell für Ethernet-Geräte. Dazu gehören ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList und GenericReceiveOffloadUDPForwarding . Diese Optionen ermöglichen die Feinabstimmung der Lastverteilung auf Hardware und Treiber, was in Unternehmensnetzwerken, Rechenzentren und bei Serviceprovidern, die jede Millisekunde Latenz minimieren müssen, von entscheidender Bedeutung ist.

Darüber hinaus können die Varlink- und JSON- Schnittstellen von systemd-networkd IP-Adressen nun in einem lesbaren Format (Zeichenketten) ausgeben, wobei die Darstellung als Integer-Array erhalten bleibt. Dies vereinfacht die Integration in Monitoring-Dashboards, Management-Skripte oder Drittanbieter-Tools, die nicht mit unintuitiven numerischen Formaten arbeiten möchten.

Dienstportabilität, kurzlebige virtuelle Maschinen und unprivilegierte Dienste

Die Komponente systemd-portabled , die für die Verwaltung portabler Dienste in Images zuständig ist, erhält eine interessante neue Funktion: Sie kann nun als Benutzerdienst ausgeführt werden . Das bedeutet, dass Benutzer ohne Administratorrechte in ihrer normalen Sitzung portable Dienste in ihrem eigenen Bereich starten und verwalten können, ohne auf sudo oder erhöhte Berechtigungen zurückgreifen zu müssen.

Darüber hinaus kann portabled ab dieser Version Richtlinien generieren und das mit einem portablen Dienst verknüpfte Image sperren , sodass dieses Image nur durch erneutes Anhängen verändert werden kann. Dies ermöglicht es Benutzern, in sich geschlossene Umgebungen mit zusätzlichen Unveränderlichkeitsgarantien einzurichten – ein besonders attraktives Merkmal für Labore, Entwicklungsumgebungen und Testumgebungen.

Andererseits erweitert systemd-vmspawn – das Tool zum Starten virtueller Maschinen in Verbindung mit systemd – seine Funktionalität, um sich innerhalb der Benutzersitzung bei systemd-machined zu registrieren. Es führt außerdem die Option `-ephemeral` ein, um kurzlebige Maschinen zu erstellen, die nach Beendigung ihrer Nutzung gelöscht werden. Dies eignet sich ideal für CI/CD-Pipelines, virtuelle Klassenzimmer oder europäische Bildungsplattformen, die die schnelle und kontrollierte Erstellung und Löschung virtueller Maschinen erfordern.

Feinabgestimmte Steuerung von CPU, Speicher und Scheduling mit SCHED_EXT und THP

Systemd 260 befasst sich mit neuen Richtlinien auch mit der Leistungssteuerung. Die Serviceoption CPUSchedulingPolicy= Akzeptieren Sie nun den Wert extwodurch der Zeitplaner aktiviert wird SCHED_EXTDieser alternative Planer öffnet die Tür zu Experimente mit unterschiedlichen Planungspolitiken den Kernel-Standards entsprechend, was in Forschungs- und Entwicklungslaboren oder bei hochspezialisierten Anwendungen von Interesse sein könnte.

Im Speicherbereich finden Sie `MemoryTHP=` , mit dem Sie die Verwendung von Transparent Huge Pages (THP) dienstspezifisch steuern können. Anstatt einer systemweiten Einstellung können Sie festlegen, ob eine bestimmte Einheit THP nutzen, deaktivieren oder Zwischenmodi verwenden soll. Für kritische Anwendungen im Bankwesen, Versicherungswesen oder in Behörden kann diese detaillierte Steuerung Latenz, Speicherverbrauch und Leistung erheblich verbessern.

Neue Befehle in systemctl und erweiterte Nutzung von Varlink

Der bekannte systemctl- Befehl erhält eine neue Funktion: enqueue-marked . Diese ruft intern die D-Bus-Methode EnqueueMarkedJobs() auf und ermöglicht die Arbeit mit Warteschlangen von vorab markierten Jobs und Diensten. Auch wenn dies wie ein kleines Detail erscheinen mag, ist es für Betriebsteams, die große Serverfarmen verwalten, ein weiteres Werkzeug zur Optimierung von Bereitstellungs- und Automatisierungs-Workflows.

Parallel dazu wird im Projekt die Nutzung von Varlink als Kommunikationsmechanismus zwischen Komponenten weiter ausgebaut . Viele Teile von systemd stellen stabile Varlink-Schnittstellen bereit, die die Integration mit externen Tools, benutzerdefinierten Dashboards oder Überwachungsagenten erleichtern, welche einen strukturierten Zugriff auf Systeminformationen benötigen.

Systemidentifikationsfelder und Benutzererfahrung

Eine kuriose, aber nützliche Neuerung für einige Distributionen ist die Einführung des Feldes FANCY_NAME= im Archiv /etc/os-releaseDieses Feld ähnelt PRETTY_NAME, erlaubt aber Folgendes: ANSI-Sequenzen und komplexere Unicode-ZeichenDank dieser Möglichkeit können bestimmte Vertriebsformen und Editionen mit einprägsameren oder unverwechselbareren Namen präsentiert werden.

Der Wert von FANCY_NAME kann über den Systemd-Manager mit systemd-hostnamed oder durch Abfrage von hostnamectl angezeigt werden . Auch wenn es sich um eine kleine Änderung handelt, kann sie in Desktop-Umgebungen und grafischen Administrationsoberflächen hilfreich sein, um das verwaltete System schnell zu identifizieren , insbesondere bei der Verwaltung vieler abgeleiteter Varianten.

Spezifische Dokumentation für KI-Agenten und den Workflow für die unterstützte Überprüfung

Eines der interessantesten Anzeichen für die Entwicklungsrichtung von systemd ist die Verfügbarkeit von Dokumentation speziell für KI-Agenten . Das Repository enthält eine AGENTS.md- Datei , die Code-Analyse-Tools und Programmierassistenten helfen soll, sowie einige Technologie-Leitfäden , um die Architektur, den Stil, den Entwicklungsablauf und die Richtlinien für Mitarbeitende des Projekts besser zu verstehen.

Dieses Dokument beschreibt Komponenten, Build-Pfade, die Durchführung von Tests und Integrationen sowie Richtlinien für die Erstellung akzeptabler Patches. Ziel ist es, KI-Agenten, die Code überprüfen oder Änderungen vornehmen, ein fundiertes Verständnis der Systemd-Architektur zu vermitteln , um Fehler und unpassende Vorschläge zu reduzieren.

Neben der Datei AGENTS.md existiert die Datei CLAUDE.md , die explizit auf AGENTS.md verweist und als Steuerung für das Tool Claude Code dient, einen der am weitesten verbreiteten KI-basierten Entwicklungsassistenten. Dadurch integriert das Projekt KI explizit in seinen Entwicklungszyklus.

Zusätzlich ist eine Konfigurationsdatei enthalten. claude-review.ymlDort wird definiert, wie der Prozess der Analyse von Änderungsanforderungen (Pull Requests) mithilfe von Claude Code überprüft werden soll. In diesem Zusammenhang müssen Beiträge, die KI verwendet haben, diese berücksichtigen. Offenlegungsetiketten als Co-developed-by in den Patches, was darauf hindeutet, dass ein automatisiertes Tool an der Erstellung des Codes beteiligt war.

Mit diesem umfassenden Änderungspaket – Bereinigung der Unterstützung für ältere Systeme, Optimierung des Sandboxings, Verbesserung von TPM2 und SRK, erweiterte Netzwerkintegration, neue Portabilitätsfunktionen und Dokumentation für intelligente Agenten – festigt systemd 260 seine zentrale Rolle im modernen Linux-Ökosystem. Für Administratoren und Entwickler in Spanien und Europa besteht die unmittelbare Herausforderung darin, Kernel zu überprüfen, Bootkonfigurationen und Dienste anzupassen und diese Funktionen zu nutzen, um sicherere, automatisierte Infrastrukturen zu schaffen, die der aktuellen Systemnutzung entsprechen.