BEZEICHNUNG¶

systemd-sysext, systemd-sysext.service, systemd-sysext-initrd.service, systemd-sysext-sysroot.service, systemd-confext, systemd-confext.service, systemd-confext-initrd.service, systemd-confext-sysroot.service - Aktivierung von Systemerweiterungsabbildern

ÜBERSICHT¶

systemd-sysext [OPTIONEN…] BEFEHL

systemd-sysext.service

systemd-confext [OPTIONEN…] BEFEHL

systemd-confext.service

BESCHREIBUNG¶

systemd-sysext (de)aktiviert Systemerweiterungsabbilder. Diese können die /usr/- und /opt/-Hierarchien dynamisch zur Laufzeit mit zusätzlichen Dateien erweitern. Dies ist besonders für unveränderbare Systemabbilder nützlich, bei der eine /usr/- und/oder /opt/-Hierarchie auf einem schreibgeschützten Dateisystem vorübergehend zur Laufzeit erweitert werden soll, ohne daran dauerhafte Veränderungen vorzunehmen.

Systemerweiterungsabbilder sollten Dateien und Verzeichnisse auf eine ähnliche Art wie bei einem normalen Betriebssystembaum enthalten. Werden eine oder mehrere Systemerweiterungsabbilder aktiviert, werden ihre /usr/- und /opt/-Hierarchien mittels »overlayfs« mit den gleichen Hierarchien auf dem Systembetriebssystem kombiniert und die /usr/ und /opt/ des Abbildes werden darüber eingehängt (»zusammengeführt«). Werden die Erweiterungen deaktiviert, wird der Einhängepunkt auseinandergenommen — dadurch wird die unveränderte Version der Hierarchie des Systems wieder sichtbar (»auseinandernehmen«). Durch das Zusammenführen werden die Ressourcen der Erweiterung plötzlich unterhalb der /usr/- und /opt/-Hierarchien auftauchen, als ob sie Teil des grundlegenden Betriebssystemabbildes selbst wären. Beim Auseinandernehmen werden die Ressourcen wieder verschwinden und an der Stelle verbleiben nur die Dateien, die mit dem zugrundeliegenden Betriebssystemabbild selbst ausgeliefert wurden.

Dateien und Verzeichnisse, die sich im Erweiterungsabbild außerhalb der /usr/- und /opt/-Hierarchien befinden, werden nicht zusammengeführt und haben daher keine Auswirkung, wenn sie in ein Systemerweiterungsabbild aufgenommen werden. Insbesondere werden Dateien, die in /etc/ und /var in einem Systemerweiterungsabbild enthalten sind, nicht in den entsprechenden Hierarchien nach der Aktivierung auftauchen.

Systemerweiterungsabbilder sind standardmäßig schreibgeschützt. Auf veränderlichen Dateisystemen auf dem Hauptsystem werden die Hierarchien /usr/ und /opt/ schreibgeschützt, während die Erweiterungen hinzugefügt werden, außer wenn die Veränderbarkeit aktiviert wurde. Die Veränderbarkeit kann über die Option --mutable= und die Option Mutable= in der Konfigurationsdatei aktiviert werden. Weitere Informationen in »Veränderbarkeit« weiter unten.

Über Konfigurationsdateien können verschiedene Optionen global konfiguriert werden. Details hierzu finden Sie in sysext.conf(5).

Systemerweiterungen sollen rein ergänzend sein, d.h. sie sollen nur Dateien enthalten, die im zugrundeliegenden Betriebssystemabbild nicht enthalten sind. Allerdings erlaubt der zugrundeliegende Mechanismus (Overlayfs) auch das Überdecken und Entfernen von Dateien, allerdings wird empfohlen, dies nicht zu verwenden.

Systemerweiterungsabbilder können in den folgenden Formaten bereitgestellt werden:

Diese Abbildformate sind die gleichen, die systemd-nspawn(1) mittels der Schalter --directory=/--image= und die der Diensteverwalter mittels RootDirectory=/RootImage= unterstützt. Ähnlich wie dort können sie optional Verity-Authentifizierungsinformationen tragen.

Es wird in den Verzeichnissen /etc/extensions/, /run/extensions/ und /var/lib/extensions/ nach Systemerweiterungen gesucht. Die ersten zwei aufgeführten Verzeichnisse sind nicht zum Überbringen von großen Binär-Abbildern geeignet, allerdings weiterhin zum Überbringen von Symlinks darauf. Der Hauptort zur Installation von Systemerweiterungen ist /var/lib/extensions/. Alle in diesen Suchverzeichnissen gefundenen Verzeichnisse werden als Verzeichnis-basierte Erweiterungsabbilder und alle Dateien mit der Endung .raw werden als plattenbasierte Erweiterungsabbilder betrachtet. Beim Aufruf in der Initrd wird das zusätzliche Verzeichnis /.extra/sysext/ in die nach Erweiterungsabbilder zu durchsuchenden Verzeichnisse eingeschlossen. Beachten Sie allerdings, dass standardmäßig eine striktere Abbildrichtline für dort gefundene Abbilder gilt, siehe unten. Dieses Verzeichnis wird durch systemd-stub(7) mit Erweiterungsabbildern gefüllt, die in der EFI-System-Partition des Systems gefunden wurden

Während des Systemstarts werden System- und Konfigurationserweiterungen automatisch aktiviert, falls systemd-sysext.service und systemd-confext.service services aktiviert sind. Beachten Sie, dass diese Dienste nur ausgeführt werden, nachdem die zugrundeliegenden Dateisysteme, auf denen sich die System- und Konfigurationserweiterungen befinden, eingehängt wurden. Um es zu ermöglichen, Ressourcen auszuliefern, die von Subsystemen als Teil der frühsten Systemstufen verarbeitet werden (beispielsweise Systemsdiensten oder systemd-sysusers(8)-Definitionen), werden die Initrd-Dienste systemd-sysext-sysroot.service and systemd-confext-sysroot.service bereitgestellt. Derzeit können diese Dienste nicht zum Zusammeführen von Systemerweiterungen aus /sysroot/var/lib/extensions/ und Konfigurationserweiterungen aus /sysroot/var/lib/confexts/ verwandt werden, wenn die /var/-Partition abgetrennt ist. Diese Erweiterungen werden später durch die Dienste systemd-sysext.service und systemd-confext.service zusammengeführt, wenn das Hauptbetriebssystem startet.

Lesen Sie auch die Seite Portable Dienste[2] für einen einfachen Mechanismus zur Auslieferung von Systemdiensten in Plattenabbildern, in einer ähnlichen Art wie Betriebssystemerweiterungen. Beachten Sie die Unterschiede in der Isolation bei den beiden Mechanismen: Während Systemerweiterungen direkt das zugrundeliegende Betriebssystemabbild mit zusätzlichen Dateien erweitern, die auftauchen, als ob sie im Betriebssystemabbild selbst ausgeliefert worden wären und damit keine Sicherheitsisolation bedeuten, bedeuten portable Dienste ein Sandboxing auf Diensteebene auf die eine oder andere Art. Programme, die in Systemerweiterungen ausgeliefert werden, können nur gegen Bibliotheken vom Hauptrechner gelinkt werden, falls die Erweiterung an die Betriebssystemversion des Hauptrechners gebunden ist (weitere Informationen weiter unten) oder müssen andernfalls statisch gelinkt sein. Portierbare Dienste sind allerdings vollständig vom Hauptsystem entkoppelt, da sie ihre eigenen Bibliotheksabhängigkeiten ausliefern.

Die Dienste systemd-sysext.service und systemd-confext.service beenden sich garantiert bevor basic.target erreicht wird; d.h. zum Zeitpunkt, zu dem sich reguläre Dienste initialisieren (solche, die DefaultDependencies=no nicht benutzen), die von System- und Konfigurationserweiterungen bereitgestellten Dateien und Verzeichnisse in /usr/, /opt/ und /etc/ verfügbar und möglicherweise zugreifbar sind.

System- und Konfigurationserweiterungen können auch zur Erweiterung der Initrd verwandt werden und die Initrd-Dienste systemd-sysext-initrd.service und systemd-confext-initrd.service werden bereitgestellt. Beachten Sie, dass es Einschränkungen gibt: Ressourcen, die in den frühsten Systemstartstufen der Initrd verwandt werden (z..B. Systemdienste) können nicht aktualisiert werden.

Beachten Sie, dass es kein Konzept zu Aktivierung/Deaktivierung installierter Systemerweiterungsabbilder gibt: alle installierten Erweiterungsabbilder werden automatisch beim Systemstart aktiviert. Sie können allerdings ein leeres Verzeichnis mit dem Namen wie die Erweiterung (kein .raw) in /etc/extensions/ ablegen, um eine Erweiterung mit dem gleichen Namen in einem Systemverzeichnis mit niedriegerem Vorrang zu »maskieren«. Es ist auch möglich, das automatische Zusammenführen durch die Verwendung der Kernelbefehlszeilenoptionen rd.systemd.sysext=, rd.systemd.confext=, systemd.sysext= und systemd.confext= zu deaktivieren. Beachten Sie, dass systemd-sysext-sysroot.service und systemd-confext-sysroot.service durch die Optionen systemd.sysext= und systemd.confext= gesteuert werden, da diese Dienste System- und Konfigurationserweiterungen für das Hauptsystem und nicht für die Initrd zusammenführen.

Es wird ein einfacher Mechanismus zur Versionskompatibilität durchgesetzt: Ein Systemerweiterungsabbild muss eine Datei /usr/lib/extension-release.d/extension-release.NAME transportieren, die auf seinen Abbildnamen passen muss, die mit der Datei »os-release« verglichen wird: die enthaltenen Felder ID= müssen übereinstimmen, außer »_any« wurde für die Erweiterung gesetzt. Falls die ID= der Erweiterung nicht »_any« ist, muss das Feld SYSEXT_LEVEL= (falls definiert) passen. Falls Letzteres nicht definiert ist, müssen stattdessen die Felder VERSION_ID= übereinstimmen. Falls die Erweiterung das Feld ARCHITECTURE= definiert und der Wert nicht »_any« ist, muss er auf die Architektur des Kernels passen, wie diese von uname(2) berichtet wird, aber die verwandten Architekturkennzeichner sind die gleichen wie bei ConditionArchitecture= (in systemd.unit(5) beschrieben). EXTENSION_RELOAD_MANAGER= kann auf 1 gesetzt werden, falls die Erweiterung ein Neuladen des Diensteverwalters nach der Anwendung der Erweiterung benötigt. EXTENSION_RESTART_UNITS= und EXTENSION_RELOAD_OR_RESTART_UNITS= können auf eine Leerraum-getrennte Liste von Unit-Namen gesetzt werden (z.B. »EXTENSION_RESTART_UNITS="mein.service anderer.service"«) die systemd-sysext/systemd-confext neu starten bzw. neu laden (bzw. neustarten, falls die Unit kein Neuladen unterstützt) soll, nachdem die Erweiterung zusammengeführt oder aufgefrischt wurde und nach dem Auseinandertrennen. Verwenden Sie EXTENSION_RESTART_UNITS= für Units, deren Programme die Erweiterung ersetzt (ein Neuladen würde die neuen Programme nicht aufnehmen) und EXTENSION_RELOAD_OR_RESTART_UNITS= für Units, die die Erweiterung nur mit Konfigurations-Ergänzungen ergänzen (so dass neuladefähige Dienste nicht unnötigerweise unterbrochen werden). Sollte eine Unit verschwunden sein, z.B. bei einem Auseinandertrennen, da sie Teil einer Erweiterung war, wird sie stattdessen gestoppt. Falls die gleiche Unit in beiden Feldern aufgeführt ist, hat EXTENSION_RESTART_UNITS= Vorrang. Auflistung einer Unit in einem der beiden Felder impliziert EXTENSION_RELOAD_MANAGER=1, da der Dienstverwalter andernfalls noch nicht (oder nicht mehr) die von der Erweiterung ausgelieferten Unit-Dateien sehen würde. Beachten Sie, dass diese Einstellungen nicht wirksam werden, wenn diese Erweiterung für das System bereits aus der Initrd zusammengeführt ist und dass Erweiterungen weiterhin einen Symlink ».wants/« oder ».upholds/« vom Installationsziel ausliefern sollten, um sicherzustellen, dass die Unit beim Systemstart gestartet wird. Systemerweiterungsabbilder sollten keine Datei /usr/lib/os-release ausliefern (da diese in den /usr/-Baum des Rechners integriert würde und damit die Versionsdaten des Rechnerbetriebssystems außer Kraft setzen würde, was nicht wünschenswert ist). Die Datei extension-release folgt dem gleichen Format und der gleichen Semantik und transportiert den gleichen Inhalt wie die Datei os-release des Betriebssystems aber sie beschreibt die Ressourcen, die im Erweiterungsabbild transportiert werden.

Das Konzept systemd-confext folgt den gleichen Prinzipien wie die Funktionalität systemd-sysext(8), statt aber auf /usr und /opt zu arbeiten, wird confext nur /etc erweitern. Im Confext-Abbild enthaltene Dateien und Verzeichnisse außerhalb der Hierarchie /etc/ werden nicht zusammengeführt und haben daher keine Auswirkung, wenn sie im Abbild aufgenommen werden. Die für diese Abbilder verwandten Formate sind identisch zu denen von Sysext-Abbildern. Die zusammengeführten Hierarchien werden mit »nosuid« und mit »noexec« (falls nicht über --noexec=false deaktiviert) eingehängt.

Genau wie Sysexts sind Confexts standardmäßig schreibgeschützt. Werden Confexts auf veränderbaren Dateisystemen auf dem Hauptsystem hinzugefügt, wird /etc/ schreibgeschützt werden. Wie bei Sysexts kann die Veränderbarkeit über die Option --mutable= aktiviert werden. Siehe »Veränderbarkeit« weiter unten für weitere Informationen.

Es wird in den Verzeichnissen /run/confexts/, /var/lib/confexts/, /usr/lib/confexts/ und /usr/local/lib/confexts/ nach Confexts geschaut. Das erste aufgeführte Verzeichnis ist nicht zum Überbringen von großen Binär-Abbildern geeignet, allerdings weiterhin zum Überbringen von Symlinks darauf. Der Hauptort zur Installation von Konfigurationserweiterungen ist /var/lib/confexts/. Alle in diesen Suchverzeichnissen gefundenen Verzeichnisse werden als Verzeichnis-basierte Confext-Abbilder und alle Dateien mit der Endung .raw werden als plattenbasierte Confext-Abbilder betrachtet.

Wie bei Sysext-Abbildern werden auch die Confext-Abbilder eine Datei /etc/extension-release.d/extension-release.NAME enthalten, die auf den Abbildnamen passen muss (mit dem normalen Notausstieg des user.extension-release.strict xattr(7)) und der Inhalt eines oder mehrere aus ID=, VERSION_ID= und CONFEXT_LEVEL sein muss. Confext-Abbilder werden dann überprüft und mit der grundlegenden Betriebssystemschicht verglichen.

VERWENDUNGEN¶

Der primäre Einsatzfall für Systemabbilder sind unveränderbare Umgebungen, bei denen optional Fehlersuch- und Entwicklungswerkzeuge verfügbar gemacht werden sollen, die aber nicht im unveränderbaren, grundlegenden Betriebssystemabbild enthalten sind (z.B. strace(1) und gdb(1) sollen eine optionale Ergänzung sein, um die Fehlersuche/Entwicklung zu vereinfachen). Systemerweiterungsabbilder sollten nicht als ein generisches Software-Paketierungs-Rahmenwerk missverstanden werden, da kein Abhängigkeitsschema verfügbar ist: Systemerweiterungen sollten alle Dateien transportieren, die sie selbst benötigen, außer denen, die bereits in dem zugrundeliegenden Betriebssystemabbild ausgeliefert sind. Typischerweise werden Systemerweiterungsabbilder zum gleichen Zeitpunkt gebaut, zu dem auch das zugrundeliegende Betriebssystemabbild gebaut wurde — innerhalb des gleichen Bausystems.

Ein anderer Anwendungsfall für das Konzept der Systemerweiterung ist das temporäre Außerkraftsetzen von Ressourcen, die vom Betriebssystem bereitgestellt werden, durch neuere, beispielsweise um eine lokal kompilierte Entwicklungsversion einer systemnahen Komponenten über das unveränderbare Betriebssystemabbild zu installieren, ohne das Betriebssystem komplett neu zu bauen oder das dem Namen nach unveränderbare Abbild zu verändern (z.B. ein lokal gebautes Paket mit DESTDIR=/var/lib/extensions/mytest make install && systemd-sysext refresh zu »installieren« und es unter /usr/ bereitzustellen, als ob es im Betriebssystemabbild selbst installiert wäre). Dieser Fall funktioniert unabhängig davon, ob das /usr/ des Rechners als unveränderbares Plattenabbild verwaltet wird oder ein traditionell durch einen Paketverwalter gesteuerter (d.h. schreibbarer) Baum ist.

Mit systemd-confext können Sie Laufzeit-Neukonfigurationen von Betriebssystemdiensten durchführen. Manchmal ist es notwendig, bestimmte Konfigurationsparameter auszutauschen oder nur einen bestimmten Dienst neuzustarten, ohne neuen Code oder ein komplettes Betriebssystem auszurollen. Anders formuliert sollen die am meisten konfigurierten Optionen an zur Laufzeit aktualisierbare Schalter geknüpft werden, die dann ohne einen Systemneustart geändert werden können. Dies hilft bei der Reduktion von Service-Zeiten, wenn die Notwendigkeit besteht, die Betriebssystemkonfiguration zu ändern. Es bietet auche ein verlässliches Werkzeug für die Verwaltung von Konfiguration an, da alle alten Konfigurationsdateien verschwinden, wenn das systemd-confext-Abbild entfernt wird.

VERÄNDERBARKEIT¶

Standardmäßig wird das Hinzufügen von Systemerweiterungen auf veränderbaren Dateisystemen des Hauptsystems dazu führen, dass die Hierarchien /usr/ und /opt/ schreibgeschützt werden. Das Hinzufügen von Konfigurationserweiterungen hat die gleiche Auswirkung auf /etc/. Der Veränderbarkeitsmodus erlaubt das Schreiben an diese Orte, bei denen Erweiterungen hinzugefügt werden.

Die folgenden Modi werden unterstützt:

Siehe nachfolgende »Optionen« zur Angabe der Modi mittels der Befehlszeilenoption --mutable=.

Mit der Ausnahme des Modus »ephemeral«, schreiben die veränderbaren Modusweiterleitungen in Unterverzeichnisse in /var/lib/extensions.mutable/.

Falls usr/, opt/ oder etc/ in /var/lib/extensions.mutable/ Symlinks sind, dann werden Schreibaktionen zu den Zielen der Symlinks gelenkt. Um Veränderbarkeit eines Dateisystems des Hauptsystems zu erhalten, erstellen Sie konsequenterweise Symlinks

Alternativ kann ein temporäres Dateisystem auf /var/lib/extensions.mutable/ eingehängt werden oder Symlinks in /var/lib/extensions.mutable/ können auf Unterverzeichnisse eines temporären Dateisystems zeigen (z.B. unterhalb /tmp/), um nur kurzlebige Änderungen zu erlauben. Beachten Sie, dass dies nicht mit dem Modus »ephemeral« identisch ist, da temporäre Dateisysteme nach dem Auftrennen weiterhin existieren.

Hinzugefügt in Version 256.

BEFEHLE¶

Die folgenden Befehle werden sowohl vom Sysext- als auch Confext-Konzept verstanden:

status

merge

unmerge

refresh

list

-h, --help

--version

OPTIONEN¶

--root=

--force

--always-refresh=yes|no

--image-policy=Richtlinie

--mutable=LOGISCH|auto|import|ephemeral|ephemeral-import|help

--noexec=LOGISCH

--no-reload

--no-pager

--no-legend

--json=MODUS

EXIT-STATUS¶

Bei Erfolg wird 0 zurückgeliefert.

SIEHE AUCH¶

systemd(1), sysext.conf(5), systemd-nspawn(1), systemd-stub(7), importctl(1)

ANMERKUNGEN¶

1.

UAPI.2-Spezifikation für auffindbare Partitionen

2.

Portable Dienste

ÜBERSETZUNG¶

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.