Provided by: manpages-de_4.21.0-2_all bug

BEZEICHNUNG

       systemd-sysext, systemd-sysext.service, systemd-confext, systemd-confext.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 streng schreibgeschützt und die Hierarchien /usr/ und
       /opt/ des Rechners werden ebenfalls schreibgeschützt, solange sie aktiviert sind.

       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:

        1. Einfache Verzeichnisse oder Btrfs-Teildatenträger, die den Betriebssystembaum
           enthalten

        2. Plattenabbilder mit einer GPT-Festplattenbezeichnung gemäß der Spezifikation für
           auffindbare Partitionen[1]

        3. Plattenabbilder, denen eine Partitionstabelle fehlt, mit einem nackten
           Linux-Dateisystem (z.B. Erofs, Squashfs oder Ext4)

       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 Systemerweiterungsabbilder automatisch aktiviert, falls
       der systemd-sysext.service aktiviert ist. Beachten Sie, dass dieser Dienst erst ausgeführt
       wird, wenn die zugrundeliegenden Dateisysteme, auf denen Systemerweiterungen gefunden
       werden können, eingehängt wurden. Das bedeutet, dass sie nicht dazu geeignet sind,
       Ressourcen auszuliefern, die von Subsystemen verarbeitet werden, die in der frühsten
       Systemstartphase ausgeführt werden. Insbesondere sind Betriebssystemabbilder nicht dazu
       geeignet, System-Dienste oder systemd-sysusers(8)-Definitionen auszuliefern. Siehe die
       Seite Portierbare Dienste[2] für einen einfachen Mechanismus (ähnlich zu
       Betriebssystemabbildern) zum Ausliefern von Systemdiensten in Plattenabbildern. Beachten
       Sie die unterschiedlichen Isolationsmechanismen bei diesen zwei Varianten: Während
       Systemerweiterungen direkt das zugrundeliegende Betriebssystemabbild mit zusätzlichen
       Dateien erweitern, die auf eine ähnliche Art auftauchen, als wenn sie vom
       Betriebssystemabbild selbst ausgeliefert worden wären und daher keinerlei
       Sicherheitsisolationen implizieren, implizieren portierbare Dienste ein Sandboxing auf die
       eine oder andere Art auf Ebene des Dienstes. Es wird garantiert, dass der
       systemd-sysext.service sein Hochfahren beendet, bevor basic.target erreicht wird; d.h. zum
       Zeitpunkt, zu dem reguläre Dienste initialisieren (solche, die DefaultDependencies=no
       nicht verwenden), sind die Dateien und Verzeichnisse, die die Systemerweiterungen
       bereitstellen, in /usr/ und /opt/ für den Zugriff bereit.

       Beachten Sie, dass es kein Konzept zum Aktivieren/Deaktivieren installierter
       Systemerweiterungsabbilder gibt: alle installierten Erweiterungsabbilder werden beim
       Systemstart automatisch aktiviert. Sie können allerdings ein leeres Verzeichnis in
       /etc/extensions/ anlegen, das den entsprechenden Namen wie die Erweiterung (ohne .raw)
       hat, um eine Erweiterung mit dem gleichen Namen in einem Systemverzeichnis mit niedrigerer
       Priorität zu »maskieren«.

       A simple mechanism for version compatibility is enforced: a system extension image must
       carry a /usr/lib/extension-release.d/extension-release.NAME file, which must match its
       image name, that is compared with the host os-release file: the contained ID= fields have
       to match unless "_any" is set for the extension. If the extension ID= is not "_any", the
       SYSEXT_LEVEL= field (if defined) has to match. If the latter is not defined, the
       VERSION_ID= field has to match instead. If the extension defines the ARCHITECTURE= field
       and the value is not "_any" it has to match the kernel's architecture reported by uname(2)
       but the used architecture identifiers are the same as for ConditionArchitecture= described
       in systemd.unit(5). EXTENSION_RELOAD_MANAGER= can be set to 1 if the extension requires a
       service manager reload after application of the extension. Note that the for the reasons
       mentioned earlier: Portable Services[2] remain the recommended way to ship system
       services. System extensions should not ship a /usr/lib/os-release file (as that would be
       merged into the host /usr/ tree, overriding the host OS version data, which is not
       desirable). The extension-release file follows the same format and semantics, and carries
       the same content, as the os-release file of the OS, but it describes the resources carried
       in the extension image.

       Das Konzept systemd-confext folgt den gleichen Prinzipien wie die Funktionalität
       systemd-sysext(1), 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.

       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.

       Again, just like sysext images, the confext images will contain a
       /etc/extension-release.d/extension-release.NAME file, which must match the image name
       (with the usual escape hatch of the user.extension-release.strict xattr(7)), and again
       with content being one or more of ID=, VERSION_ID=, and CONFEXT_LEVEL. Confext images will
       then be checked and matched against the base OS layer.

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.

       Für den Confext-Fall zielt das Projekt OSConfig darauf, Laufzeit-Neukonfigurationen von
       Betriebssystemdiensten durchzufü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.

BEFEHLE

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

       status
           Beim Aufruf ohne ein Befehlsverb oder wenn status angegeben ist, wird der derzeitige
           Zusammenführungsstatus angezeigt, separat (für sowohl /usr/ und /opt/ für Sysext und
           für /etc/ für Confext).

           Hinzugefügt in Version 248.

       merge
           Führt alle derzeit installierten Systemerweiterungsabbilder in /usr/ und /opt/
           zusammen, indem diese Hierarchien mit dem Dateisystem »overlayfs« übereinandergehängt
           werden und dadurch die zugrundeliegenden Hierarchien mit denen aus den
           Erweiterungsabbildern kombiniert werden. Dieser Befehl wird fehlschlagen, wenn die
           Hierarchien bereits zusammengeführt sind. Für Confext passiert die Zusammenführung
           stattdessen für das Verzeichnis /etc/.

           Hinzugefügt in Version 248.

       unmerge
           Trennt alle derzeit installierten Systemerweiterungsabbilder von /usr/ und /opt/ für
           Sysext und /etc/ für Confext auf, indem die vorher durch merge erstellten
           »overlayfs«-Dateisysteme ausgehängt werden.

           Hinzugefügt in Version 248.

       refresh
           Eine Kombination von unmerge und merge: Falls bereits eingehängt, wird die bestehende
           »overlayfs«-Instanz temporär ausgehängt und dann durch eine neue Version ersetzt.
           Dieser Befehl ist nach der Installation/Entfernung von Systemerweiterungsabbildern
           nützlich, um das »overlayfs«-Dateisystem entsprechend zu aktualisieren. Falls zum
           Zeitpunkt der Ausführung dieses Befehls keine Systemerweiterungen installiert sind,
           dann wird das Äquivalent von unmerge ausgeführt, ohne eine neue »overlayfs«-Instanz zu
           etablieren. Beachten Sie, dass es derzeit einen kurzen Moment gibt, zu dem weder das
           alte noch das neue »overlayfs«-Dateisystem eingehängt sind. Daraus folgt, dass alle
           durch eine Systemerweiterung bereitgestellten Ressourcen kurzzeitig verschwinden —
           selbst wenn sie dauerhaft während einer refresh-Aktion bestehen bleiben.

           Hinzugefügt in Version 248.

       list
           Zeigt eine kurze Liste der installierten Erweiterungsabilder an.

           Hinzugefügt in Version 248.

       -h, --help
           Zeigt einen kurzen Hilfetext an und beendet das Programm.

       --version
           Zeigt eine kurze Versionszeichenkette an und beendet das Programm.

OPTIONEN

       --root=
           Agiert relativ zu dem festgelegten Wurzelverzeichnis, d.h. richtet die
           »overlayfs«-Einhängung nicht auf den Hierarchien /usr/ und /opt/ für Sysext oder /etc/
           für Confext auf der obersten Stufe des Rechners ein, sondern unterhalb eines
           festgelegten Wurzelverzeichnisses.

           Hinzugefügt in Version 248.

       --force
           Bei der Zusammenführung von Systemerweiterungen in /usr/ und /opt/ für Sysext und
           /etc/ für Confext werden Versionsinkompatibilitäten ignoriert, d.h. das Zusammenführen
           wird erzwungen, unabhängig davon, ob die im Abbild enthaltenen Versionsinformationen
           zu denen des Rechners passen oder nicht.

           Hinzugefügt in Version 248.

       --image-policy=Richtlinie
           Akzeptiert gemäß systemd.image-policy(7) eine Abbildrichtlinienzeichenkette als
           Argument. Bei Aktionen auf Systemerweiterungsplattenabbildern wird diese Richtlinie
           durchgesetzt. Falls nicht angegeben ist die Vorgabe
           »root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent«
           für Systemerweiterungen, d.h. nur das Wurzel- und /usr/-Dateisystem im Abbild wird
           verwandt. Für Konfigurationserweiterungen ist die Vorgabe
           »root=verity+signed+encrypted+unprotected+absent«. Beim Betrieb in der Initrd und bei
           Aktionen auf einem im Verzeichnis /.extra/sysext/ gespeicherten
           Systemerweiterungsabbild wird standardmäßig eine leicht strengere Richtlinie verwandt:
           »root=signed+absent:usr=signed+absent«. Details hierzu finden Sie weiter oben.

           Hinzugefügt in Version 254.

       --noexec=LOGISCH
           Beim Zusammenführen von Konfigurationserweiterungen in /etc/ wird standardmäßig der
           Einhängeschalter »MS_NOEXEC« verwandt. Das kann mit dieser Option deaktiviert werden.

           Hinzugefügt in Version 254.

       --no-reload
           When used with merge, unmerge or refresh, do not reload daemon after executing the
           changes even if an extension that is applied requires a reload via the
           EXTENSION_RELOAD_MANAGER= set to 1.

           Hinzugefügt in Version 255.

       --no-pager
           Leitet die Ausgabe nicht an ein Textanzeigeprogramm weiter.

       --no-legend
           Gibt die Legende nicht aus, d.h. die Spaltenköpfe und die Fußzeile mit Hinweisen.

       --json=MODUS
           Zeigt die Ausgabe als JSON formatiert. Erwartet entweder »short« (für die kürzest
           mögliche Ausgabe ohne unnötigen Leerraum oder Zeilenumbrüche), »pretty« (für eine
           schönere Version der gleichen Ausgabe, mit Einzügen und Zeilenumbrüchen) oder »off«
           (um die standardmäßig aktivierte JSON-Ausgabe auszuschalten).

EXIT-STATUS

       Bei Erfolg wird 0 zurückgeliefert.

SIEHE AUCH

       systemd(1), systemd-nspawn(1), systemd-stub(7)

ANMERKUNGEN

        1. Spezifikation für auffindbare Partitionen
           https://uapi-group.org/specifications/specs/discoverable_partitions_specification

        2. Portable Dienste
           https://systemd.io/PORTABLE_SERVICES

Ü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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.