Ubuntu Manpage: systemd-nspawn - Erzeugt einen Befehl oder ein Betriebssystem in einem leichtgewichtigen Container

BEZEICHNUNG

       systemd-nspawn - Erzeugt einen Befehl oder ein Betriebssystem in einem leichtgewichtigen Container

ÜBERSICHT


       systemd-nspawn [OPTIONEN…] [BEFEHL [ARG…]]

       systemd-nspawn --boot [OPTIONEN…] [ARG…]

BESCHREIBUNG

systemd-nspawn kann zur Ausführung eines Befehls oder Betriebssystems (OS) in einem leichtgewichtigen
Namensraum-Container verwandt werden. In vielerlei Art ist es zu chroot(1) ähnlich, aber
leistungsfähiger, da es die Dateisystemhierarchie sowie den Prozessbaum, die verschiedenen
IPC-Untersysteme und die Rechner- und Domain-Namen virtualisiert.

systemd-nspawn kann in jedem Verzeichnisbaum, der einen Betriebssystembaum enthält, mittels der
Befehlszeilenoption --directory= aufgerufen werden. Durch Verwendung der Option --machine= wird der
OS-Baum automatisch nach einer Reihe von Orten durchsucht, am wichtigsten dabei ist /var/lib/machines/,
das bevorzugte Verzeichnis, um auf dem System installierte OS-Container-Abbilder abzulegen.

Im Gegensatz zu chroot(1) kann systemd-nspawn zum Starten kompletter, Linux-basierter Betriebssysteme in
einem Container verwandt werden.

systemd-nspawn begrenzt den Zugriff auf verschiedene Kernelschnittstellen, wie /sys/, /proc/sys/ oder
/sys/fs/selinux/, im Container auf nur-lesbar. Die Netzwerkschnittstelle des Wirts und die Systemuhr
können aus dem Container heraus nicht geändert werden. Geräteknoten können nicht erstellt werden. Das
Wirtssystem kann nicht neu gestartet werden und Kernelmodule dürfen von innerhalb des Containers nicht
geladen werden. Diese Sandbox kann leicht aus dem Container heraus umgangen werden, falls keine
Namensräume verwandt werden. Das bedeutet, dass nicht vertrauenswürdiger Code immer innerhalb eines
Benutzernamensraums ausgeführt werden muss, siehe die nachfolgende Diskussion der Option
--private-users=.

Verwenden Sie Werkzeuge wie dnf(8), debootstrap(8) oder pacman(8), um eine geeignete
OS-Verzeichnisbaumhierarchie für systemd-nspawn einzurichten. Lesen Sie den nachfolgenden Abschnitt
»Beispiele« für geeignete Aufrufe dieser Befehle.

Als Sicherheitsprüfung wird systemd-nspawn die Existenz von /usr/lib/os-release oder /etc/os-release im
Container-Baum überprüfen, bevor der Systemstart des Containers durchgeführt wird (siehe os-release(5)).
Es könnte notwendig sein, diese Datei manuell zum Container-Baum hinzuzufügen, falls das OS des
Containers zu alt ist, um diese Datei bereits mitgeliefert zu haben.

systemd-nspawn kann direkt von der interaktiven Befehlszeile aus oder als Systemdienst im Hintergrund
aufgerufen werden. In diesem Modus betreibt jede Container-Instanz seine eigene Dienste-Instanz; eine
Standard-Vorlagen-Unit-Datei systemd-nspawn@.service wird bereitgestellt, um dies leicht zu ermöglichen;
sie akzeptiert den Container-Namen als Instanzen-Kennzeichner. Beachten Sie, dass andere Vorgabeoptionen
gelten, wenn systemd-nspawn durch die Vorlagen-Unit-Datei als wenn es interaktiv auf der Befehlszeile
aufgerufen wird. Der wichtigste Unterschied bei den Vorgaben ist, dass die Vorlagen-Unit-Datei die Option
--boot verwendet, während dies beim Aufruf von systemd-nspawn auf der Befehlszeile nicht der Fall ist.
Weitere Unterschiede in den Vorgaben sind zusammen mit den verschiedenen unterstützten Optionen weiter
unten dokumentiert.

Das Werkzeug machinectl(1) kann zur Ausführung einer Reihe von Aktionen an Containern verwandt werden. Es
stellt insbesondere leicht zu benutzende Befehle bereit, um Container als Systemdienste mittels der
Vorlagen-Unit-Datei systemd-nspawn@.service auszuführen.

Neben jedem Container kann eine Einstellungsdatei mit der Endung .nspawn existieren, die zusätzliche, bei
der Ausführung des Containers anzuwendende Einstellungen enthält. Siehe systemd.nspawn(5) für Details.
Einstellungsdateien setzen die von der Vorlagen-Unit-Datei systemd-nspawn@.service verwandten
Vorgabeoptionen außer Kraft, wodurch es im Allgemeinen unnötig wird, diese Vorlagendatei direkt zu
ändern.

Beachten Sie, dass systemd-nspawn Dateisysteme privat für den Container nach /dev/, /run/ und ähnlichem
einhängen wird. Diese werden außerhalb des Containers nicht sichtbar sein und ihre Inhalte gehen
verloren, wenn sich der Container beendet.

Beachten Sie, dass die Ausführung von zwei systemd-nspawn-Containern aus dem gleichen Verzeichnis nicht
dazu führt, dass sich die Prozesse in beiden gegenseitig sehen. Die PID-Namensraumtrennung der zwei
Container ist vollständig und die Container nutzen sehr wenige Laufzeitobjekte gemeinsam, außer das
unterliegende Dateisystem. Verwenden Sie eher die Befehle login oder shell von machinectl(1), um
zusätzliche Anmeldesitzungen in einem laufenden Container zu erbitten.

systemd-nspawn implementiert die Spezifikation Container-Schnittstelle[1].

Während des Betriebs werden mittels systemd-nspawn aufgerufene Container mit dem Dienst
systemd-machined(8) registriert. Dieser verfolgt die laufenden Container nach und stellt
Programmierschnittstellen bereit, um mit ihnen zu interagieren.

NICHT PRIVILEGIERTE OPERATIONEN

       systemd-nspawn kann mit oder ohne Privilegien aufgerufen werden. Die vollständige Funktionalität ist
       derzeit nur beim Aufruf mit Privilegien verfügbar. Beim Aufruf ohne Privilegien gelten verschiedene
       Einschränkungen, einschließlich, aber nicht beschränkt auf:

       •   Es werden nur Platten-basierte Container unterstützt (d.h. --image=). Verzeichnis-basierte
           (d.h.--directory=) werden nicht unterstützt.

       •   Maschinenregistrierung mittels --machine= wird nicht unterstützt.

       •   Es werden nur die Netzwerkmodi --private-network und --network-veth unterstützt.

       Beim Betrieb im nicht privilegierten Modus wird ein Teil der benötigten Funktionalität mittels
       systemd-mountfsd.service(8) und systemd-nsresourced.service(8) bereitgestellt.

OPTIONEN

Falls die Option -boot angegeben ist, werden die Argumente als Argumente für das Init-Programm verwandt.
Andernfalls gibt BEFEHL das zu startende Programm in dem Container an und die verbleibenden Argumente
werden als Argumente für dieses Programm benutzt. Falls --boot nicht verwandt wird und keine Argumente
angegeben sind, wird eine Shell in dem Container gestartet.

Die folgenden Optionen werden verstanden:

-q, --quiet
Schaltet sämtliche Statusausgaben des Werkzeuges selbst aus. Wird dieser Schalter verwandt, wird die
einzige Ausgabe von Nspawn die Ausgabe der Konsole des Container-Betriebssystems selbst sein.

Hinzugefügt in Version 209.

--settings=MODUS
Steuert, ob systemd-nspawn nach Container-bezogenen Einstellungen aus .nspawn-Dateien suchen und
diese verwenden soll. Akzeptiert einen logischen oder die besonderen Werte override oder trusted.

Falls aktiviert (die Vorgabe), wird eine Einstellungsdatei, die nach der Maschine (wie mit der
Einstellung --machine= angegeben oder aus dem Verzeichnis oder Abbildnamen abgeleitet) mit der
Endung.nspawn benannt ist, in /etc/systemd/nspawn/ und /run/systemd/nspawn/ gesucht. Falls sie dort
gefunden wird, werden deren Einstellungen gelesen und verwandt. Falls sie dort nicht gefunden wird,
wird sie nachfolgend in dem gleichen Verzeichnis wie die Abbilddatei oder in dem Verzeichnis direkt
über dem Wurzelverzeichnis des Containers gesucht. Falls die Datei in diesem Fall gefunden wird,
werden ihre Einstellungen auch gelesen und verwandt, aber möglicherweise unsichere Einstellungen
werden ignoriert. Beachten Sie, dass in beiden Fällen die Einstellungen auf der Befehlszeile Vorrang
gegenüber den entsprechenden Einstellungen aus geladenen .nspawn-Dateien haben, falls beide angegeben
sind. Alle Einstellungen, die die Privilegien des Containers erhöhen oder Zugriff auf zusätzliche
Ressourcen wie Dateien oder Verzeichnissen auf der Wirtsmaschine geben können, werden als unsichere
Einstellungen betrachtet. Für Details über das Format und die Inhalte von .nspawn-Dateien lesen Sie
bitte systemd.nspawn(5).

Falls diese Option auf override gesetzt ist, wird die Datei durchsucht, gelesen und auf die gleiche
Art verwandt, allerdings ist die Vorrangreihenfolge umgedreht: Einstellungen aus den .nspawn-Dateien
haben Vorrang vor den entsprechenden Einstellungen der Befehlszeilenoptionen, falls beide angegeben
sind.

Falls diese Option auf trusted gesetzt ist, wird die Datei durchsucht, gelesen und auf die gleiche
Art verwandt, unabhängig davon, wo sie in /etc/systemd/nspawn/, /run/systemd/nspawn/ oder neben der
Abbild-Datei oder dem Wurzelverzeichnis des Containers gefunden wurde, alle Einstellungen werden
wirksam, allerdings haben Befehlszeilenoptionen weiterhin Vorrang vor den entsprechenden
Einstellungen.

Falls deaktiviert, werden keine .nspawn-Dateien gelesen und keine Einstellungen außer denen auf der
Befehlszeile werden wirksam.

Hinzugefügt in Version 226.

Abbildoptionen
-D, --directory=
Verzeichnis, das als Dateisystemwurzel für den Container verwandt werden soll.

Falls weder --directory= noch --image= angegeben sind, wird das Verzeichnis ermittelt, indem nach
einem Verzeichnis, dessen Namen mit einem mittels --machine= übergebenen Maschinennamen
übereinstimmt, gesucht wird. Siehe den Abschnitt »Dateien und Verzeichnisse« in machinectl(1) für den
genauen Suchpfad.

Anstelle des Verzeichnispfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
systemd.v(7) zu Details.

Falls weder --directory=, --image= noch --machine= angegeben sind, wird das aktuelle Verzeichnis
verwandt. Darf nicht zusammen mit --image= angegeben werden.

--template=
Verzeichnis oder »btrfs«-Teildatenträger, das/der als Vorlage für das Wurzelverzeichnis des
Containers verwandt werden soll. Falls dies angegeben ist und das Wurzelverzeichnis des Containers
(wie mit --directory= konfiguriert) noch nicht existiert, wird es als »btrfs«-Schnappschuss (falls
unterstützt) oder als einfaches Verzeichnis (andernfalls) erstellt und von diesem Vorlagenbaum
befüllt. Idealerweise bezieht sich der angegebene Vorlagenpfad auf das Wurzelverzeichnis eines
»btrfs«-Teildatenträgers, wodurch in diesem Fall ein einfacher
»Kopieren-beim-Schreiben«-Schnappschuss gemacht wird und das Befüllen des Wurzelverzeichnisses
instantan erfolgt. Falls sich der angegebene Vorlagenpfad nicht auf die Wurzel eines
»btrfs«-Teildatenträgers bezieht (oder noch nicht einmal auf einem »btrfs«-Dateisystem liegt), wird
der Verzeichnisbaum kopiert (möglicherweise allerdings in einem
»reflink«-»Kopieren-beim-Schreiben«-Schema — falls das Dateisystem dies unterstützt), was deutlich
mehr Zeit benötigen kann. Beachten Sie, dass der Schnappschuss von dem angegebenen Verzeichnis oder
Teildatenträger vorgenommen wird, einschließlich aller Unterverzeichnisse und Teildatenträger, aber
ausschließlich aller Untereinhängungen. Darf nicht zusammen mit --image= oder --ephemeral angegeben
werden.

Beachten Sie, dass dieser Schalter den Rechnernamen, die Maschinenkennung und alle anderen
Einstellungen, die die Instanz identifizieren könnten, unverändert lässt.

Hinzugefügt in Version 219.

-x, --ephemeral
Führt den Container mit einem temporären Schnappschuss seines Dateisystems aus, falls angegeben.
Dieser wird direkt nach Beenden des Containers entfernt. Darf nicht zusammen mit --template=
angegeben werden.

Beachten Sie, dass dieser Schalter den Rechnernamen, die Maschinenkennung und alle anderen
Einstellungen, die die Instanz identifizieren könnten, unverändert lässt. Beachten Sie, dass wie bei
--template= das Vornehmen eines temporären Schnappschusses auf Dateisystemen, die Teildatenträger
oder nativ »reflinks« unterstützen (»btrfs« oder neues »xfs«), effizienter als auf traditionelleren
Dateisystemen, die das nicht tun (»ext4«), ist. Beachten Sie, dass der aufgenommene Schnappschuss das
gesamte angegebene Verzeichnis oder Teildatenträger umfasst, einschließlich aller Unterverzeichnisse
und Teildatenträger darunter, aber ausschließlich aller Untereinhängungen.

Mit dieser Option werden keine Änderungen am Container-Abbild erhalten. Verwenden Sie (das
nachfolgend beschriebene) --volatile= als weiteren Mechanismus, um die Dauerhaftigkeit von
Container-Abbildern zur Laufzeit zu begrenzen.

Hinzugefügt in Version 219.

-i, --image=
Plattenabbild, aus dem das Wurzelverzeichnis für den Container geladen werden soll. Akzeptiert einen
Pfad zu einer regulären Datei oder zu einem Blockgeräteknoten. Die Datei oder das Blockgerät muss
eines der Folgenden enthalten:

• Eine MBR-Partitionstabelle mit einer einzelnen Partition vom Typ 0x83, der startfähig markiert
ist.

• Eine GUID-Partitionstablle (GPT) mit einer einzelnen Partition vom Typ
0fc63daf-8483-4772-8e79-3d69d8477de4.

• Eine GUID-Partitionstabelle (GPT) mit einer markierten Wurzelpartition, die als Wurzelverzeichnis
des Containers eingehängt ist. Optional dürfen GPT-Abbilder auch eine Home- oder
Serverdatenpartition enthalten, die an den geeigneten Stellen im Container eingehängt sind. Alle
diese Partitionen müssen durch die in Spezifikation auffindbarer Partitionen[2] definierten
Partitionstypen identifiziert werden.

• Keine Partitionstabelle und eine einzelne Datei, die sich über das gesamte Abbild erstreckt.

Falls eine EFI-Systempartition (ESP) auf GPT-Abbildern entdeckt wird, wird diese automatisch nach
/efi (oder /boot als Rückfall) eingehängt, falls ein Verzeichnis dieses Namens existiert und leer
ist.

Mit LUKS verschlüsselte Partitionen werden automatisch entschlüsselt. Auf GPT-Abbildern prüft
dm-verity auch, ob die Datenintegritäts-Hash-Partitionen eingerichtet sind, falls der Wurzel-Hash für
sie mit der Option --root-hash= angegeben wurde.

Einzelne Dateisystemabbilder (d.h. Dateisysteme ohne eine umgebende Partitionstabelle) können mittels
Dm-verity geöffnet werden, falls die Integritätsdaten mittels der Optionen --root-hash= und
--verity-data= (und optional --root-hash-sig=) übergeben werden.

Alle anderen Partitionen, wie fremde Partitionen oder Auslagerungspartitionen, werden nicht
eingehängt. Darf nicht zusammen mit --directory=, --template= angegeben werden.

Anstelle des Abbildpfades kann ein versioniertes Verzeichnis ».v/« angegeben werden, siehe
systemd.v(7) zu Details.

Hinzugefügt in Version 211.

--image-policy=Richtlinie
Akzeptiert eine Abbild-Richtlinienzeichenkette als Argument, eine pro systemd.image-policy(7). Die
Richtlinie wird bei Aktionen auf dem mittels --image= festgelegten Plattenabbild durchgesetzt, siehe
oben. Falls nicht angegeben, ist die Vorgabe
»root=verity+signed+encrypted+unprotected+absent:usr=verity+signed+encrypted+unprotected+absent:home=encrypted+unprotected+absent:srv=encrypted+unprotected+absent:esp=unprotected+absent:xbootldr=unprotected+absent:tmp=encrypted+unprotected+absent:var=encrypted+unprotected+absent«,
d.h. alle erkannten Dateisysteme in dem Abbild werden verwandt, aber nicht die Auslagerungspartition.

Hinzugefügt in Version 254.

--oci-bundle=
Akzeptiert einen Pfad zu einem aufzurufenden OCI-Laufzeitbündel, wie in der
OCI-Laufzeit-Spezifikation[3] spezifiziert ist. In diesem Fall wird keine .nspawn-Datei geladen und
das Wurzelverzeichnis und verschiedene Einstellungen werden aus den OCI-Laufzeit-JSON-Daten
eingelesen (allerdings haben auf der Befehlszeile übergebene Daten Vorrang).

Hinzugefügt in Version 242.

--read-only
Hängt das Wurzeldateisystem des Containers (und alle anderen Dateisysteme, die in dem
Container-Abbild enthalten sind) nur-lesbar ein. Dies hat für zusätzliche Einhängungen mit --bind=,
--tmpfs= und ähnlichen Optionen keine Wirkung. Dieser Modus ist impliziert, falls das
Container-Abbild oder Verzeichnis als nur-lesbar markiert wurde. Beim Einsatz von --volatile= wird
dies auch impliziert. In diesem Fall ist das Container-Abbild auf Platte streng nur-lesbar, wobei
Änderungen erlaubt sind, aber nur nicht dauerhaft im Arbeitsspeicher gehalten werden. Weitere Details
finden Sie nachfolgend.

--volatile, --volatile=MODUS
Startet den Container im flüchtigen Mouds. Wird kein Modusparameter übergeben oder der Modus als yes
angegeben, dann wird der vollständige flüchtige Modus aktiviert. Dies bedeutet, dass das
Wurzelverzeichnis eine größtenteils leere »tmpfs«-Instanz ist und /usr/ aus dem Betriebssystembaum
dort nur-lesbar hineingehängt ist (das System startet daher mit einem nur-lesbaren
Betriebssystemabbild aber einem jungfräulichen Zustand und jungfräulicher Konfiguration und sämtliche
Änderungen an Letzterem gehen beim Herunterfahren verloren). Falls der Modusparameter als overlay
angegeben ist, wird das nur-lesbare Wurzeldateisystem mit einer schreibbaren Tmpfs-Instanz mittels
»overlayfs« kombiniert, so dass es sich wie normalerweise verhält, aber sämtliche Änderungen nur an
dem temporären Dateisystem vorgenommen werden und daher bei der Beendigung des Containers verloren
gehen. Falls der Modusparameter als no angegeben ist (die Vorgabe), dann wird der gesamte
Betriebssystembaum schreibbar zur Verfügung gestellt (außer --read-only ist angegeben, siehe oben).

Beachten Sie, dass bei der Auswahl einer der flüchtigen Modi die Auswirkung auf das Wurzeldateisystem
(oder im Falle von state /var/) begrenzt wird und jede andere, in der Hierarchie angeordnete
Einhängung davon unbetroffen ist, unabhängig davon, ob sie automatisch (z.B. die EFI-Systempartition,
die nach /efi/ oder /boot/ eingehängt sein könnte) oder explizit (z..B. durch eine zusätzliche
Befehlszeilenoption wie --bind=, siehe unten) etabliert wurden. Dies bedeutet, dass Änderungen an
/efi/ oder /boot/ verboten sind, selbst falls --volatile=overlay verwandt wurde und eine solche
Partition im betroffenen Container-Abbild existiert und selbst falls --volatile=state verwandt wird,
wird die hypothetische Datei /etc/foobar möglicherweise schreibbar, falls --bind=/etc/foobar zum
Einhängen von außerhalb des nur lesbaren Container-/etc/-Verzeichnisses verwandt wird.

Die Option --ephemeral hat einen engen Bezug zu dieser Einstellung und stellt ähnliches Verhalten
bereit, bei dem eine temporäre und vergängliche Kopie des gesamten Betriebssystemabbildes erfolgt und
diese dann ausgeführt wird. Weitere Details finden Sie weiter oben.

Die Option --tmpfs= und --overlay= stellen ähnliche Funktionalität bereit, allerdings nur für
bestimmte Unterverzeichnisse des Betriebssystemabbildes. Details finden Sie nachfolgend.

Diese Option stellt ähnliche Funktionalität für Container bereit, wie der Befehlszeilenschalter
»systemd.volatile=« dies für Rechner selbst darstellt. Siehe kernel-command-line(7) für Details.

Beachten Sie, dass das Setzen dieser Option auf yes oder state nur funktioniert, falls das
Betriebssystem des Containers einen Systemstart mit ausschließlich eingehängtem /usr/ durchführen und
dann selbständig /var/ bevölkern (und im Falle von »--volatile=yes« auch /etc/) kann. Dies bedeutet
insbesondere, dass Betriebssysteme, die der historischen Aufteilung von /bin/ und /lib/ (und
zugehörigen Verzeichnissen) von /usr/ folgen (d.h. bei denen Erstere keine Symlinks in Letztere
sind), bei »--volatile=yes« nicht als Container-Inhalt unterstützt werden. Die Option overlay
verlangt keine besonderen Vorbereitungen von dem Betriebssystem, aber beachten Sie, dass sich das
Verhalten von »overlayfs« von dem regulärer Dateisysteme in einer Reihe von Punkten unterscheidet und
somit die Kompatibilität eingeschränkt ist.

Hinzugefügt in Version 216.

--root-hash=
Akzeptiert einen hexadezimalen Dateiintegritäts-Wurzel-Hash (dm-verity). Diese Option aktiviert
Datenintegritätsüberprüfungen mittels dm-verity, falls das verwandte Abbild die notwendigen
Integritätsdaten enthält (siehe oben). Der angegebene Hash muss auf den Wurzel-Hash der
Integritätsdaten passen und ist normalerweise mindestens 256 Bit (und damit 64 formatierte
hexadezimale Zeichen) lang (im beispielhaften Fall von SHA256). Falls diese Option nicht angegeben
ist, aber das Abbild das erweiterte Attribut »user.verity.roothash« trägt (siehe xattr(7)), dann wird
der Wurzel-Hash und auch die formatierten hexadezimalen Zeichen daraus gelesen. Falls das erweiterte
Dateiattribut nicht gefunden wird (oder von dem zugrundeliegenden Dateisystem nicht unterstützt
wird), aber eine Datei mit der Endung .roothash neben dem Abbild gefunden wird, das ansonsten den
gleichen Namen trägt (außer falls das Abbild die Endung .raw enthält, dann darf die Root-Hash-Datei
dies nicht in ihrem Namen enthalten), dann wird der Wurzel-Hash und auch die formatierten
hexadezimalen Zeichen daraus gelesen und automatisch verwandt.

Beachten Sie, dass dies den Wurzel-Hash für das Wurzeldateisystem konfiguriert. Plattenabbilder
können auch separate Dateiystem für die /usr/-Hierarchie enthalten, die auch Verity-geschützt sein
kann. Der Wurzel-Hash für diesen Schutz kann mit dem erweiterten Dateiattribut »user.verity.usrhash«
oder mittels einer .usrhash-Datei neben dem Plattenabbild konfiguriert werden. Dies folgt dem
gleichen Format und der gleichen Logik wie für den hier beschriebenen Wurzel-Hash für das
Wurzeldateisystem. Beachten Sie, dass es derzeit keinen Schalter gibt, um den Wurzel-Hash für /usr/
von der Befehlszeile aus zu konfigurieren.

Siehe auch die Option RootHash= in systemd.exec(5).

Hinzugefügt in Version 233.

--root-hash-sig=
Akzeptiert eine PKCS7-Signatur der Option --root-hash=. Die Semantik ist zur Option
RootHashSignature= identisch, siehe systemd.exec(5).

Hinzugefügt in Version 246.

--verity-data=
Akzeptiert einen Pfad zu einer Datenintegritätsdatei (dm-verity). Diese Option aktiviert
Datenintegritätsüberprüfungen mittels Dm-verity, falls ein Wurzel-Hash übergeben wird und falls das
verwandte Abbild selbst keine Integritätsdaten enthält. Die Integritätsdaten müssen mit dem
Wurzel-Hash übereinstimmen. Falls diese Option nicht angegeben ist, aber eine Datei mit der Endung
».verity« neben der Abbild-Datei gefunden wird, die ansonsten den gleichen Namen trägt (außer falls
das Abbild die Endung ».raw« hat, in welchem Falle die Verity-Datendatei dies nicht in ihrem Namen
haben darf), dann werden die Verity-Daten daraus gelesen und automatisch verwandt.

Hinzugefügt in Version 246.

--pivot-root=
Schwenkt in das angegebene Verzeichnis als / innerhalb des Containers um und hängt entweder die alte
Wurzel des Containers aus oder schwenkt sie auf ein anderes angegebenes Verzeichnis um. Akzeptiert
entweder ein Pfadargument (in diesem Fall wird der angegebene Pfad zu / verschwenkt und die alte
Wurzel ausgehängt) oder ein Doppelpunkt-getrenntes Paar aus neuem Wurzelpfad und Schwenkziel für die
alte Wurzel. Der neue Wurzelpfad wird auf / verschwenkt und die alte / wird auf das andere
Verzeichnis verschwenkt. Beide Pfade müssen absolut und im Dateisystemnamensraum des Containers
auflösbar sein.

Dies ist für Container, die mehrere startfähige Verzeichnisse enthalten, beispielweise mehrere
OSTree[4]-Einsätze. Sie emuliert das Verhalten eines Systemstartprogrammes und einer Initrd, die
normalerweise auswählt, welches Verzeichnis als Wurzel eingehängt und darin PID 1 des Containers
gestartet wird.

Hinzugefügt in Version 233.

Ausführungsoptionen
-a, --as-pid2
Ruft die Shell oder das angegebene Programm als Prozesskennung (PID) 2 statt als PID 1 (Init) auf.
Standardmäßig wird das ausgewählte Programm als Prozess mit PID 1 ausgeführt, falls weder diese noch
die Option --boot verwandt wird. Dieser Modus ist nur für Programme geeignet, die sich der besonderen
Semantik, die Prozesse mit der PID 1 unter UNIX haben, bewusst sind. Beispielsweise muss er alle
(Zombie-)Prozesse beseitigen, deren Elternprozess er geworden ist, und sollte sysvinit-kompatible
Signalhandhabung implementieren (insbesondere muss sie bei SIGINT das System neu starten, bei SIGTERM
sich selbst neu ausführen, ihre Konfiguration bei SIGHUP neu einlesen und so weiter). Mit --as-pid2
wird ein minimaler Init-Prozess als PID 1 und das ausgewählte Programm wird als PID 2 ausgeführt (und
muss daher keine besonderen Semantiken implementieren). Der minimale Init-Prozess wird
(Zombie-)Prozesse wie nötig beseitigen und geeignet auf Signale reagieren. Es wird empfohlen, diesen
Modus zum Aufruf von beliebigen Befehlen in Containern zu verwenden, außer diese wurden zum Betrieb
als PID 1 angepasst. Mit anderen Worten: dieser Schalter sollte für so ziemlich alle Befehle
verwendet werden, außer der Befehl bezieht sich auf eine Init- oder Shell-Implementierung, da diese
im Allgemeinen in der Lage sind, korrekt als PID 1 zu laufen. Diese Option darf nicht mit --boot
kombiniert werden.

Hinzugefügt in Version 229.

-b, --boot
Sucht automatisch nach einem Init-Programm und ruft es als PID 1 statt einer Shell oder eines
benutzerdefinierten Programms auf. Falls diese Option verwandt wird, werden auf der Befehlszeile
übergebene Argumente als Argumente für das Init-Programm verwandt. Diese Option darf nicht mit
--as-pid2 kombiniert werden.

Die nachfolgende Tabelle erklärt die verschiedenen Aufrufmodi und die Beziehung zu --as-pid2 (siehe
oben):

Tabelle 1. Aufrufmodus
┌───────────────────────────────────────┬──────────────────────────────────────┐
│ Schalter │ Erklärung │
├───────────────────────────────────────┼──────────────────────────────────────┤
│ Weder --as-pid2 noch --boot angegeben │ Die übergebenen Parameter werden als │
│ │ Befehlszeile interpretiert, die als │
│ │ PID 1 im Container ausgeführt wird. │
├───────────────────────────────────────┼──────────────────────────────────────┤
│ --as-pid2 angegeben │ Die übergebenen Parameter werden als │
│ │ Befehlszeile interpretiert, die als │
│ │ PID 2 im Container ausgeführt wird. │
│ │ Ein minimaler Init-Prozess wird als │
│ │ PID 1 ausgeführt. │
├───────────────────────────────────────┼──────────────────────────────────────┤
│ --boot angegeben │ Im Container wird automatisch nach │
│ │ einem Init-Programm gesucht und │
│ │ dieses als PID 1 ausgeführt. Die │
│ │ übergebenen Parameter werden als │
│ │ Aufrufparameter für diesen Prozess │
│ │ verwandt. │
└───────────────────────────────────────┴──────────────────────────────────────┘

Beachten Sie, dass --boot der Standardaktionsmodus ist, falls die Vorlagen-Unit-Datei
systemd-nspawn@.service verwandt wird.

--chdir=
Wechselt vor Aufruf des Prozesses im Container zu dem angegebenen Arbeitsverzeichnis. Erwartet einen
absoluten Pfad in dem Dateisystemnamensraum des Containers.

Hinzugefügt in Version 229.

-E NAME[=WERT], --setenv=NAME[=WERT]
Gibt die Umgebungsvariablen an, die an den Init-Prozess im Container übergeben werden soll. Dies kann
zum Außerkraftsetzen der Vorgabenvariablen oder zum Setzen zusätzlicher Variablen verwandt werden. Es
kann mehr als einmal benutzt werden, um mehrere Variablen zu setzen. Wenn »=« und WERT nicht
angegeben sind, dann wird der Wert der Variablen mit dem gleichen Namen in der Programmumgebung
verwandt.

Hinzugefügt in Version 209.

-u, --user=
Wechselt nach Übergang in den Container zu dem angegebenen Benutzer, wie er in der Benutzerdatenbank
im Container definiert ist. Wie alle anderen Systemd-nspawn-Funktionalitäten ist dies keine
Sicherheitsfunktionalität und stellt nur einen Schutz gegen versehentliche zerstörerische Aktionen
dar.

Beachten Sie, dass bei der Verwendung von Zugangsberechtigungen in Kombination mit einem von Root
verschiedenen --user= (d.h.: --set-credential=, --load-credential= oder --import-credential=)
--no-new-privileges=yes verwandt werden muss und --boot oder --as-pid2 nicht verwandt werden darf, da
die Zugangsberechtigungen ansonsten für den Container aufgrund fehlender Privilegien nach dem
Umschalten auf den angegebenen Benutzer nicht lesbar wären.

--kill-signal=
Gibt das an PID 1 des Containers zu sendende Prozesssignal an, wenn Nspawn selbst SIGTERM empfängt,
um ein geordnetes Herunterfahren des Containers auszulösen. Standardmäßig SIGRTMIN+3, falls --boot
verwandt wird (auf Systemd-kompatiblen Init-Systemen löst SIGRTMIN+3 ein geordnetes Herunterfahren
aus). Falls --boot nicht verwandt wird und diese Option nicht angegeben ist, dann werden die Prozesse
im Container abrupt mit SIGKILL beendet. Siehe signal(7) für eine Liste gültiger Signale.

Hinzugefügt in Version 220.

--notify-ready=
Konfiguriert Unterstützung für Benachrichtigungen von dem Init-Prozess des Containers.
--notify-ready= akzeptiert einen logischen Wert (no und yes). Mit der Option no benachrichtigt
Systemd-nspawn Systemd mit einer »READY=1«-Meldung, wenn der Init-Prozess erstellt wurde. Mit der
Option yes wartet Systemd-nspawn auf die Meldung »READY=1« vom Init-Prozess im Container, bevor er
seine eigene an Systemd sendet. Weitere Details über Benachrichtigungen finden Sie in sd_notify(3).

Hinzugefügt in Version 231.

--suppress-sync=
Erwartet ein logisches Argument. Falls true, wird für den Inhalt des Containers jegliche Form von
plattengebundener Dateisynchronisation ausgeschaltet. Das bedeutet, dass alle Dateisystemaufrufe wie
sync(2), fsync(), syncfs(), … nichts ausführen werden und die Schalter O_SYNC/O_DSYNC von open(2) und
verwandten Aufrufen nicht verfügbar sein werden. Dies ist möglicherweise gefährlich, da angenommene
Datenintegritätsgarantien für den Inhalt des Containers nicht tatsächlich durchgesetzt werden (dh.
Daten, von den Schreiben auf Platte angenommen wurden, könnten verlorengehen, falls das System
ungewöhnlich heruntergefahren wird). Allerdings kann es die Laufzeitleistung des Containers massiv
erhöhen – solange diese Garantien weder benötigt noch gewünscht werden, beispielsweise da sämtliche
vom Container geschriebenen Daten temporärer, redundanter Art sind oder nur ein Zwischenartefakt, das
weiterverarbeitet wird und in einem späteren Schritt in dem Verarbeitungssystem finalisiert wird.
Standardmäßig false.

Hinzugefügt in Version 250.

Systemidentitätsoptionen
-M, --machine=
Setzt den Maschinennamen für diesen Container. Dieser Name kann zur Identifizierung des Containers
während der Laufzeit verwandt werden (beispielsweise in Werkzeugen wie machinectl(1) und ähnlichen).
Er wird zur Initialisierung des Rechnernamens des Containers verwandt (der im Container allerdings
außer Kraft gesetzt werden kann). Falls nicht angegeben, wird die letzte Komponente des
Wurzelverzeichnispfades des Containers verwandt, wobei möglicherweise eine zufällige Kennzeichnung
angehängt wird, falls der Modus --ephemeral ausgewählt ist. Falls das ausgewählte Wurzelverzeichnis
mit dem Wurzelverzeichnis des Rechners übereinstimmt, wird der eigene Rechnername stattdessen als
Vorgabe im Container verwandt.

Hinzugefügt in Version 202.

--hostname=
Steuert den innerhalb des Containers zu setzenden Rechnernamen, falls vom Maschinennamen verschieden.
Erwartet einen gültigen Rechnernamen als Argument. Falls diese Option verwandt wird, wird der
Kernel-Rechnername des Containers auf diesen Wert gesetzt, andernfalls wird dieser auf den
Maschinennamen, wie mit der oben beschrieben Option --machine= gesteuert, gesetzt. Der Maschinenname
wird für verschiedene Identifikationsaspekte des Containers von außerhalb verwandt, der mit dieser
Option konfigurierbare Kernel-Rechnername ist für die Identifikation des Containers von innen
nützlich. Normalerweise ist es eine gute Idee, beide Identifikationsformen synchronisiert zu halten,
um Verwirrung zu vermeiden. Es wird daher empfohlen, die Verwendung dieser Option zu vermeiden und
ausschließlich --machine= zu verwenden. Beachten Sie, dass der Container später seinen
Kernel-Rechnernamen selbst frei außer Kraft setzen kann, unabhängig davon, ob der Name mit der Option
--hostname= oder über die Option --machine= initialisiert wurde.

Hinzugefügt in Version 239.

--uuid=
Setzt die angegebene UUID für den Container. Das Init-System wird /etc/machine-id daraus
initialisieren, falls diese Datei noch nicht gesetzt ist. Beachten Sie, dass diese Option nur wirksam
wird, falls /etc/machine-id im Container noch leer ist.

Eigenschaftsoptionen
-S, --slice=
Fügt den Container als Teil der angegebenen Scheibe hinzu, statt der Vorgabe machine.slice. Dies gilt
nur, falls die Maschine in ihrer eigenen Bereichs-Unit ausgeführt wird, d.h. falls --keep-unit nicht
verwandt wird.

Hinzugefügt in Version 206.

--property=
Setzt eine Unit-Eigenschaft der für diese Maschine zu registrierenden Bereichs-Unit. Dies gilt nur,
falls die Maschine in ihrer eigenen Bereichs-Unit ausgeführt wird, d.h. falls --keep-unit nicht
verwandt wird. Akzeptiert eine Unit-Eigenschaftszuweisung im gleichen Format wie systemctl
set-property. Dies ist zum Setzen von Speicherbeschränkungen und Ähnlichem für den Container
nützlich.

Hinzugefügt in Version 220.

--register=
Steuert, ob der Container mit systemd-machined(8) registriert wird. Akzeptiert ein logisches
Argument, standardmäßig »yes«. Diese Option sollte aktiviert werden, wenn der Container ein
vollständiges Betriebssystem ausführt (genauer: ein System- und Diensteverwalter als PID 1). Sie ist
nützlich, um sicherzustellen, dass auf den Container mit machinectl(1) zugegriffen und dieser durch
Werkzeuge wie ps(1) angezeigt werden kann. Falls der Container keinen Diensteverwalter ausführt, wird
empfohlen, diese Option auf »no« zu setzen.

Hinzugefügt in Version 209.

--keep-unit
Verwendet einfach die Dienste- oder Bereichs-Unit, in der systemd-nspawn aufgerufen wurde, anstatt
eine flüchtige Bereichs-Unit, in der der Container ausgeführt wird, zu erstellen. Falls
--register=yes gesetzt ist, wird diese Unit mit systemd-machined(8) registriert. Dieser Schalter
sollte verwandt werden, falls systemd-nspawn aus einer Dienste-Unit heraus aufgerufen wurde und der
einzige Zweck der Dienste-Unit die Ausführung eines einzelnen systemd-nspawn-Containers ist. Diese
Option ist bei der Ausführung aus einer Benutzersitzung heraus nicht verfügbar.

Beachten Sie, dass die Verwendung von --keep-unit die Wirkung von --slice= und --property=
deaktiviert. Verwenden Sie --keep-unit und --register=no in Kombination, um jegliche Art von
Unit-Zuweisung oder -Registrierung mit systemd-machined zu deaktivieren.

Hinzugefügt in Version 209.

Benutzer-Namensraum-Optionen
--private-users=
Steuert Benutzernamensräume. Falls aktiviert, wird der Container in seiner eigenen privaten Gruppe an
UNIX-Benutzer- und Gruppenkennungen (UIDs und GIDs) ausgeführt. Dazu gehört die Zuordnung der im
Container verwandten privaten UIDs/GIDs (beginnend mit dem Benutzer root mit 0 und höher) auf den
Bereich von UIDs/GIDs auf dem Rechner, die noch nicht für andere Zwecke verwandt sind (normalerweise
im Bereich höher als UID/GID 65536 auf dem Rechner), abgebildet. Dieser Parameter kann wie folgt
angegeben werden:

1. Falls eine oder zwei Doppelpunkt-getrennte Zahlen angegeben sind, werden Benutzernamensräume
eingeschaltet. Der erste Parameter gibt die erste UID/GID des Rechners an, die dem Container
zugewiesen werden soll, der zweite Parameter gibt die Anzahl an UIDs/GIDs an, die dem Container
zugewiesen werden soll. Falls der zweite Parameter fehlt, werden 65536 UIDs/GIDs zugewiesen.

2. Falls der Parameter »yes« ist, werden Benutzernamensräume eingeschaltet. Der zu verwendende
UID-/GID-Bereich wird automatisch aus der Dateieigentümerschaft des Wurzelverzeichnisses des
Verzeichnisbaums des Containers bestimmt. Um diese Option zu verwenden, muss der Verzeichnisbaum
vorher vorbereitet werden, um sicherzustellen, dass alle Dateien und Verzeichnisse UIDs/GIDs in
dem von Ihnen gewünschten Bereich gehören. Auch müssen alle Datei-ACLs ausschließlich UIDs/GIDs
im gewünschten Bereich referenzieren. In diesem Modus ist die Anzahl der dem Container
zugewiesenen UIDs/GIDS 65536, und die Eigentümer-UID/GID des Wurzelverzeichnisses muss ein
Vielfaches von 65536 sein.

3. Der besondere Wert »pick« schaltet Benutzernamensräume ein. In diesem Fall wird der
UID/GID-Bereich automatisch ausgewählt. Im ersten Schritt wird die Eigentümer-UID/GID des
Wurzelverzeichnisses des Verzeichnisbaums des Containers eingelesen und überprüft, dass ihn
derzeit kein anderer Container verwendet. Falls die Überprüfung erfolgreich ist, wird der auf
diesem Weg ermittelte UID/GID-Bereich verwandt, ähnlich wie bei der Angabe von »yes«. Falls die
Überprüfung nicht erfolgreich ist (und daher der durch den Eigentümer des Wurzelverzeichnis
angezeigte UID/GID-Bereich bereits woanders verwandt wird), wird ein neuer, derzeit nicht
verwendeter, UID/GID-Bereich von 65536 UIDs/GIDs aus dem Bereich 524288 bis 1878982656 auf dem
Rechner zufällig ausgewählt, wobei immer bei Vielfachen von 65536 begonnen und, falls möglich,
konsistent vom Maschinennamen gehasht wird. Diese Einstellung impliziert
--private-users-ownership=auto (siehe unten), was möglicherweise bewirkt, dass die Dateien und
Verzeichnisse im Verzeichnisbaum des Containers den passenden Benutzern in dem ausgewählten
Bereich gehören. Mit dieser Option wird das Verhalten von Benutzernamensräumen vollständig
automatisiert. Beachten Sie, dass der erste Aufruf eines bisher nicht verwandten Containers zur
Auswahl eines neuen UID/GID-Bereichs dafür führen könnte und daher eine (möglicherweise
aufwändige) Anpassungsaktion für Dateieigentümerschaften erfolgen könnte. Der Aufwand für
nachfolgende Ausführungen des Containers wird allerdings gering sein (außer natürlich der
ausgewählte UID/GID-Bereich wird zu diesem Zeitpunkt anders verwandt).

4. Falls der Parameter »no« lautet, werden Benutzernamensräume ausgeschaltet. Diese ist die Vorgabe,
wenn systemd-nspawn direkt aufgerufen wird. (Beachten Sie, dass die Unit systemd-nspawn@.service
private Benutzer aktiviert.) Diese Option ist nicht sicher und darf nicht zur Ausführung
unvertrauenswürdigem Code angewandt werden.

5. Falls dieser Parameter »identity« ist, werden Benutzer-Namensräume mit einer identischen
Zuordnung für die ersten 65536 UIDs/GIDs eingesetzt. Dies ist größtenteils äquivalent zu
--private-users=0:65536. Während es keine UID/GID-Isolierung bereitstellt, da alle Rechner- und
Container-UIDs/GIDs identisch ausgewählt werden, bietet es dennoch Isolation der
Prozess-Capabilitys und könnte daher nützlich sein, falls ein ordentlicher Benutzernamensraum mit
unterschiedlichen UID-Zuordnungen nicht möglich ist. Diese Option ist nicht sicher und darf nicht
zur Ausführung unvertrauenswürdigen Codes verwandt werden.

Es wird empfohlen, jedem Container mindestens 65536 UIDs/GIDs zuzuweisen, so dass der verwendbare
Bereich an UIDs/GIDs im Container 16 Bit überdeckt. Für größtmögliche Sicherheit sollten sich die
UID/GID-Bereiche je zweier Container nicht überlappen. Daher ist es eine gute Idee, die oberen 16 Bit
der 32-Bit-UIDs/GIDs des Rechners als Container-Kennzeichner und die unteren 16-Bit zur Kodierung der
im Container verwandten UID/GIDs zu verwenden. Dies ist tatsächlich das Verhalten, das die Option
--private-users=pick erzwingt.

Werden Benutzernamensräume verwandt, wird der jedem Container zugewiesene GID-Bereich immer identisch
zu dem UID-Bereich ausgewählt.

In den meisten Fällen ist --private-users=pick die empfohlene Option, da Benutzer-Namensräume aus
Sicherheitsgründen benötigt werden und diese Option die Container-Sicherheit massiv erhöht und
gleichzeitig in den meisten Fällen vollautomatisch funktioniert.

Beachten Sie, dass der ausgewählte UID/GID-Bereich nicht in /etc/passwd oder /etc/group geschrieben
wird. Tatsächlich wird die Zuweisung des Bereiches nicht dauerhaft gespeichert, außer in den
Dateieigentümerschaften der Dateien und Verzeichnisse des Containers.

Beachten Sie, dass sich dies bei der Verwendung von Benutzernamensräumen in den
Dateieigentümerschaften auf der Platte widerspiegelt und alle Dateien und Verzeichnisse des
Containers den effektiven Benutzer- und Gruppenkennungen des Containers gehören. Dies bedeutet, dass
das Kopieren von Dateien in und aus dem Container heraus die Anpassung der numerischen UID/GID-Werte
verlangt, je nach angewandter UID/GID-Verschiebung.

Hinzugefügt in Version 220.

--private-users-ownership=
Steuert, wie die UIDs und GIDs des Containers angepasst werden, um auf den mit --private-users=
gewählten UID/GID-Bereich zu passen, siehe oben. Akzeptiert entweder »off« (um das Abbild unverändert
zu lassen), »chown« (um den Verzeichnisbaum des Containers nach Notwendigkeit rekursiv mit chown()
anzupassen), »map« (um Einhängungen mit transparenter Zuordnung der Kennungen zu verwenden) oder
»auto«, um automatisch »map« wo verfügbar zu verwenden und »chown« wo nicht.

Passt, falls »chown« ausgewählt ist, alle Dateien und Verzeichnisse im Verzeichnisbaum des Containers
an, so dass sie den passenden, für den Container ausgewählten UIDs/GIDs gehören (siehe oben). Diese
Aktion ist möglicherweise aufwändig, da sie den vollen Durchlauf durch den Verzeichnisbaum des
Containers verlangt. Neben der eigentlichen Dateieigentümerschaft werden auch ACLs angepasst.

Normalerweise ist »map« die beste Wahl, da es transparent die UIDs/GIDs im Speicher wie notwendig
ohne Veränderung des Abbilds abbildet und auch keine teure rekursive Anpassungsaktion benötigt.
Allerdings ist sie derzeit nicht für alle Dateisysteme verfügbar.

Die Option --private-users-ownership=auto wird impliziert, falls --private-users=pick verwandt wird.
Diese Option hat nur eine Auswirkung, falls Benutzernamensräume verwandt werden.

Hinzugefügt in Version 230.

-U
Falls der Kernel die Benutzernamensraumfunktionalität unterstützt, ist dies äquivalent zu
--private-users=pick --private-users-ownership=auto, ansonsten zu --private-users=no.

Beachten Sie, dass -U die Vorgabe ist, falls die Vorlagendatei systemd-nspawn@.service verwandt wird.

Hinweis: Das Ergebnis von --private-users-ownership=chown (oder -U) auf das Dateisystem kann
rückgängig gemacht werden, indem die Aktion mit der ersten UID 0 erneut durchgeführt wird:

systemd-nspawn … --private-users=0 --private-users-ownership=chown

Hinzugefügt in Version 230.

Vernetzungsoptionen
--private-network
Trennt die Vernetzung zwischen Containers und Rechner. Damit werden alle Netzwerkschnittstellen im
Container nicht mehr verfügbar, Ausnahmen sind nur das Loopback-Gerät und die mit
--network-interface= angegebenen und mit --network-veth konfigurierten Schnittstellen. Falls diese
Option angegeben ist, wird die Capability CAP_NET_ADMIN zu der Gruppe der Capabilities hinzugefügt,
die der Container behält. Letzteres kann mit --drop-capability= deaktiviert werden. Falls diese
Option nicht angegeben (oder durch eine der nachfolgend aufgeführten Optionen impliziert) ist, hat
der Container vollen Zugriff auf das Netzwerk des Rechners.

--network-interface=
Weist die angegebene Netzwerkschnittstelle dem Container zu. Akzeptiert entweder einen einzelnen
Schnittstellennamen, der den Namen auf dem Wirtsystem referenziert, oder ein Doppelpunkt-getrenntes
Paar an Schnittstellen, bei denen der erste den Namen auf dem Wirtrechner referenziert und der zweite
den Namen in dem Container. Wenn der Container sich beendet, wird die Schnittstelle zum aufrufenden
Namensraum zurückverschoben und wieder auf seinen ursprünglichen Namen zurückbenannt. Beachten Sie,
dass --network-interface= --private-network impliziert. Diese Option kann mehr als einmal verwandt
werden, um mehrere Netzwerkschnittstellen in dem Container hinzuzufügen.

Beachten Sie, dass alle auf diese Art festgelegten Schnittstellen zum Zeitpunkt des Startens des
Containers bereits existieren müssen. Falls der Container automatisch beim Systemstart mittels der
Unit-Dateiinstanz systemd-nspawn@.service gestartet werden soll, kann es daher sinnvoll sein, eine
Unit-Dateiergänzung für die Diensteinstanz hinzuzufügen (z.B.
/etc/systemd/system/systemd-nspawn@foobar.service.d/50-network.conf), die Inhalte folgender Art
enthält:

[Unit]
Wants=sys-subsystem-net-devices-ens1.device
After=sys-subsystem-net-devices-ens1.device

Dies stellt sicher, dass die Aktivierung des Container-Dienstes verzögert wird, bis die
Netzwerkschnittstelle »ens1« aufgetaucht ist. Dies ist notwendig, da Hardwareermittlung vollständig
asynchron erfolgt und Netzwerkschnittstellen erst später während des Systemstartprozesses erkannt
werden könnten, nachdem der Container normalerweise ohne diese expliziten Abhängigkeiten gestartet
worden wäre.

Hinzugefügt in Version 209.

--network-macvlan=
Erstellt eine »macvlan«-Schnittstelle auf der angegebenen Ethernet-Netzwerkschnittstelle und fügt sie
dem Container hinzu. Akzeptiert entweder einen einzelnen Schnittstellennamen, der den Namen auf dem
Wirtsystem referenziert, oder ein Doppelpunkt-getrenntes Paar an Schnittstellen, bei denen der erste
den Namen auf dem Wirtrechner referenziert und der zweite den Namen in dem Container. Eine
»macvlan«-Schnittstelle ist eine virtuelle Schnittstelle, die eine zweite MAC-Adresse zu einer
bestehenden physischen Ethernet-Verbindung hinzufügt. Falls der Container-Schnittstellenname nicht
definiert ist, wird die Adresse im Container nach der Schnittstelle auf dem Rechner benannt, wobei
»mv-« vorangestellt wird. Beachten Sie, dass --network-ipvlan= --private-network impliziert. Diese
Option kann mehr als einmal verwandt werden, um mehrere Netzwerkschnittstellen in dem Container
hinzuzufügen.

Wie bei --network-interface= muss die zugrundeliegende Ethernet-Netzwerkschnittstelle zum Zeitpunkt
des Startens des Containers bereits existieren und daher könnten ähnliche Unit-Dateiergänzungen wie
oben beschrieben nützlich sein.

Hinzugefügt in Version 211.

--network-ipvlan=
Erstellt eine »ipvlan«-Schnittstelle auf der angegebenen Ethernet-Netzwerkschnittstelle und fügt sie
dem Container hinzu. Akzeptiert entweder einen einzelnen Schnittstellennamen, der den Namen auf dem
Wirtsystem referenziert, oder ein Doppelpunkt-getrenntes Paar an Schnittstellen, bei denen der erste
den Namen auf dem Wirtrechner referenziert und der zweite den Namen in dem Container. Eine
»ipvlan«-Schnittstelle ist eine virtuelle Schnittstelle, ähnlich einer »macvlan«-Schnittstelle, die
die gleiche MAC-Adresse wie die zugrundeliegende Schnittstelle auf dem Rechner verwendet. Falls der
Container-Schnittstellenname nicht definiert ist, wird die Adresse im Container nach der
Schnittstelle auf dem Rechner benannt, wobei »iv-« vorangestellt wird. Beachten Sie, dass
--network-ipvlan= --private-network impliziert. Diese Option kann mehr als einmal verwandt werden, um
mehrere Netzwerkschnittstellen in dem Container hinzuzufügen.

Hinzugefügt in Version 219.

-n, --network-veth
Erstellt eine virtuelle Ethernet-Verbindung (»veth«) zwischen dem Rechner und dem Container. Die
Rechnerseite der Ethernet-Verbindung wird als Netzwerkschnittstelle verfügbar sein, die nach dem
Namen der Maschine (wie mit --machine= angegeben) benannt ist, der »ve-« vorangestellt ist. Die
Container-Seite der Ethernetverbindung wird »host0« heißen. Die Option --network-veth impliziert
--private-network.

Beachten Sie, dass systemd-networkd.service(8) eine Vorgabe-Netzwerkdatei
/usr/lib/systemd/network/80-container-ve.network enthält, die auf die auf diese Art erstellte
Schnittstelle im Rechner passt und die Einstellungen enthält, um die automatische
Adressbereitstellung auf der erstellten virtuellen Verbindung mittels DHCP sowie das automatische
IP-Routen auf der externen Netzwerkschnittstelle des Rechners aktiviert. Sie enthält auch
/usr/lib/systemd/network/80-container-host0.network, die auf die auf diese Art erstellte
Schnittstelle im Container passt und die Einstellung zur Aktivierung der Adresszuweisung mittels DHCP
für den Client enthält. Wenn Systemd-networkd sowohl im Rechner als auch im Container läuft, ist
daher automatische IP-Kommunikation vom Container zum Rechner verfügbar, mit weiterer Verbindung zum
externen Netz.

Beachten Sie, dass --network-veth die Vorgabe ist, falls die Vorlagen-Unit-Datei
systemd-nspawn@.service verwandt wird.

Beachten Sie, dass Netzwerkschnittstellennamen unter Linux eine maximale Länge von 15 Zeichen haben
dürfen, während Container-Namen 64 Zeichen lang sein dürfen. Da diese Option den Schnittstellennamen
auf der Rechnerseite vom Container-Namen ableitet, ist der Name möglicherweise abgeschnitten. Daher
muss in diesem Falle aufgepasst werden, dass die Schnittstellennamen eindeutig bleiben; besser noch,
Container-Namen sollten im Allgemeinen so ausgewählt werden, dass sie nicht länger als 12 Zeichen
sind, um das Abschneiden zu vermeiden. Falls der Name abgeschnitten ist, wird systemd-nspawn
automatisch einen 4-ziffrigen Hash-Wert an den Namen anhängen, um die Möglichkeit von Kollisionen zu
verringern. Allerdings ist der Hash-Algorithmus nicht kollisionsfrei. (Siehe
systemd.net-naming-scheme(7) für Details über ältere Benennungsalgorithmen für diese Schnittstelle).
Alternativ kann die Option --network-veth-extra= verwandt werden. Sie erlaubt die freie Konfiguration
des Schnittstellennamens auf der Rechnerseite unabhängig vom Container-Namen — könnte aber ein
bisschen mehr an Konfiguration benötigen, falls Bridging im Stile von --network-bridge= erwünscht
ist.

Hinzugefügt in Version 209.

--network-veth-extra=
Fügt eine zusätzliche virtuelle Ethernet-Vebindung zwischen dem Rechner und dem Container hinzu.
Akzeptiert ein Doppelpunkt-getrenntes Paar von Schnittstellennamen (auf dem Rechner und in dem
Container). Letzerer kann entfallen; dann wird auf Seiten des Containers und des Rechners der gleiche
Name zugewiesen. Dieser Schalter ist unabhängig von --network-veth und kann im Gegensatz zu diesem
mehrfach verwandt werden und erlaubt die Konfiguration von Netzwerkschnittstellennamen. Beachten Sie,
dass --network-bridge= auf mit --network-veth-extra= erstellten Schnittstellen keine Auswirkung hat.

Hinzugefügt in Version 228.

--network-bridge=
Fügt die Rechnerseite der mit --network-veth erstellten Ethernet-Verbindung zu der angegebenen
Ethernet-Bridge-Schnittstelle hinzu. Erwartet als Argument einen gültigen Netzwerkschnittstellennamen
für das Bridge-Gerät. Beachten Sie, dass --network-bridge= --network-veth impliziert. Falls diese
Option verwandt wird, verwendet die Rechnerseite des Ethernet-Links das Präfix »vb-« anstelle von
»ve-«. Unabhängig vom verwandten Benennungschema gelten die gleichen Längenbeschränkungen von Linux
für Netzwerkschnittstellennamen, zusammen mit den hierdurch entstehenden Komplikationen (siehe oben
für Details).

Wie bei --network-interface= muss die zugrundeliegende Bridge-Netzwerkschnittstelle zum Zeitpunkt des
Startens des Containers bereits existieren und daher könnten ähnliche Unit-Dateiergänzungen wie oben
beschrieben nützlich sein.

Hinzugefügt in Version 209.

--network-zone=
Erstellt eine virtuelle Ethernet-Verbindung (»veth«) für den Container und fügt ihn zu den
automatisch verwalteten Ethernet-Bridge-Schnittstellen hinzu. Die Bridge-Schnittstelle wird nach dem
übergebenen Argument benannt, dem »vz-« vorangestellt wird. Die Bridge-Schnittstelle wird automatisch
erstellt, wenn der erste für diesen Namen konfigurierte Container gestartet wird und automatisch
entfernt, wenn der letzte für diesen Namen konfigurierte Container sich beendet. Daher existiert jede
auf diese Art erstellte Bridge-Schnittstelle nur so lange mindestens ein Container läuft, der sie
referenziert. Diese Option ist sehr ähnlich zu --network-bridge=, abgesehen von der automatischen
Erstellung/Entfernung des Bridge-Gerätes.

Diese Einstellung macht es leicht, mehrere zusammengehörige Container in eine gemeinsame, virtuelle,
Ethernet-basierte Broadcast-Domäne zu legen, die hier »Zone« genannt wird. Jeder Container darf nur
Teil einer Zone sein, aber jede Zone kann eine beliebige Anzahl an Containern enthalten. Auf jede
Zone kann mit ihrem Namen Bezug genommen werden. Namen können frei ausgewählt werden (solange sie
einen gültigen Netzwerkschnittstellenamen bilden, denen »vz-« vorangestellt ist) und es reicht aus,
den gleichen Namen an den Schalter --network-zone= für die verschiedenen, gleichzeitig laufenden
Container zu übergeben, um sie in eine Zone aufzunehmen.

Beachten Sie, dass systemd-networkd.service(8) standardmäßig eine Netzwerkdatei
/usr/lib/systemd/network/80-container-vz.network enthält, die auf die auf diese Art erstellte
Bridge-Schnittstelle passt und die Einstellungen enthält, die die automatische Bereitstellung von
Adressen mittels DHCP im erstellten virtuellen Netzwerk sowie das automatische IP-Routen auf den
externen Netzwerkschnittstellen des Rechners aktivieren. Die Verwendung von --network-zone= ist daher
in den meisten Fällen vollautomatisch und ausreichend, um mehrere lokale Container in einer
vereinigten Broadcast-Domäne mit dem Rechner zu verbinden, einschließlich weiterer Verbindung zum
externen Netzwerk.

Hinzugefügt in Version 230.

--network-namespace-path=
Akzeptiert einen Pfad zu einer Datei, die einen Netzwerk-Namensraum darstellt, in dem der Container
ausgeführt werden soll. Der angegebene Pfad sollte sich auf eine (möglicherweise »bind«-eingehängte)
Netzwerk-Namensraum-Datei beziehen, wie diese durch den Kernel unterhalb von /proc/$PID/ns/net
offengelegt wird. Dies führt dazu, dass der Container in den durch ip-netns(8) unter /run/netns
erstellten angegebenen Netzwerk-Namensraum eintritt. Beispiel:
--network-namespace-path=/run/netns/foo. Beachten Sie, dass diese Option nicht zusammen mit anderen
Netzwerk-bezogenen Optionen verwandt werden kann, wie --private-network oder --network-interface=.

Hinzugefügt in Version 236.

-p, --port=
Bildet einen IP-Port auf dem Rechner auf einen IP-Port im Container ab, falls private Netzwerke
aktiviert sind. Akzeptiert einen Protokollkennzeichner (entweder »tcp« oder »udp«), getrennt durch
einen Doppelpunkt von der Port-Nummer des Rechners im Bereich 1 bis 65535, getrennt durch einen
Doppelpunkt von der Container-Port-Nummer im Bereich 1 bis 65535. Der Protokollkennzeichner und sein
trennender Doppelpunkt kann entfallen, wodurch »tcp« angenommen wird. Die Container-Port-Nummer und
ihr Doppelpunkt kann entfallen, wodurch der gleiche Port wie auf dem Rechner impliziert wird. Diese
Option wird nur unterstützt, falls private Netzwerke verwandt werden, wie mit --network-veth,
--network-zone= --network-bridge= ausgewählt.

Hinzugefügt in Version 219.

Sicherheitsoptionen
--capability=
Listet eine oder mehrere zusätzliche Capabilities auf, die dem Container gewährt werden sollen.
Akzeptiert eine Kommata-getrennte Liste von Capability-Namen, siehe capabilities(7) für weitere
Informationen. Beachten Sie, dass die folgenden Capabilities auf jeden Fall gewährt werden:
CAP_AUDIT_CONTROL, CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER,
CAP_FSETID, CAP_IPC_OWNER, CAP_KILL, CAP_LEASE, CAP_LINUX_IMMUTABLE, CAP_MKNOD, CAP_NET_BIND_SERVICE,
CAP_NET_BROADCAST, CAP_NET_RAW, CAP_SETFCAP, CAP_SETGID, CAP_SETPCAP, CAP_SETUID, CAP_SYS_ADMIN,
CAP_SYS_BOOT, CAP_SYS_CHROOT, CAP_SYS_NICE, CAP_SYS_PTRACE, CAP_SYS_RESOURCE, CAP_SYS_TTY_CONFIG.
Auch wird CAP_NET_ADMIN behalten, falls --private-network angegeben ist. Falls der besondere Wert
»all« übergeben wird, werden alle Capabilities behalten.

Falls der besondere Wert »help« übergeben wird, wird das Programm die bekannten Capability-Namen
ausgeben und sich beenden.

Diese Option setzt die Begrenzungsmenge der Capabilities, die auch die Umgebungs-Capabilities, wie
sie mit --ambient-capability= übergeben werden, begrenzt.

Hinzugefügt in Version 186.

--drop-capability=
Gibt eine oder mehrere zusätzliche Capabilities an, die für den Container entfernt werden sollen.
Dies erlaubt den Betrieb des Containers mit weniger als den Standard-Capabilities (siehe oben).

Falls der besondere Wert »help« übergeben wird, wird das Programm die bekannten Capability-Namen
ausgeben und sich beenden.

Diese Option setzt die Begrenzungsmenge der Capabilities, die auch die Umgebungs-Capabilities, wie
sie mit --ambient-capability= übergeben werden, begrenzt.

Hinzugefügt in Version 209.

--ambient-capability=
Gibt eine oder mehrere zusätzliche Capabilities an, die an die vererbare und Umgebungsmenge von
Programmen, die im Container gestartet werden, übergeben werden sollen. Der Wert »all« wird für diese
Einstellung nicht unterstützt.

Alle hier angegebenen Capabilities müssen in der mit den Optionen --capability= und
--drop-capability= erlaubten Menge sein. Andernfalls wird eine Fehlermeldung angezeigt.

Diese Option kann nicht mit dem Systemstartmodus des Containers (wie mit --boot erbeten) kombiniert
werden.

Falls der besondere Wert »help« übergeben wird, wird das Programm die bekannten Capability-Namen
ausgeben und sich beenden.

Hinzugefügt in Version 248.

--no-new-privileges=
Akzeptiert ein logisches Argument. Gibt den Wert des Schalters PR_SET_NO_NEW_PRIVS für den
Container-Inhalt an. Standardmäßig »off«. Wenn eingeschaltet, kann der Inhaltscode des Containers
keine neuen Privilegien erlangen, d.h. das Datei-Bit »setuid« und Dateisystem-Capabilities haben
keine Wirkung mehr. Siehe prctl(2) für Details über diesen Schalter.

Hinzugefügt in Version 239.

--system-call-filter=
Ändert den auf Container angewandten Systemaufruffilter. Akzeptiert eine Leerzeichen-getrennte Liste
von Systemaufrufnamen oder -gruppennamen (Letzteren wird »@« vorangestellt, wie dies durch den Befehl
syscall-filter von systemd-analyze(1) aufgeführt wird). Der Liste kann optional »~« vorangestellt
werden, wodurch alle aufgeführten Systemaufrufe verboten sind. Falls diese Befehlszeilenoption
mehrfach verwandt wird, werden die konfigurierten Listen kombiniert. Falls sowohl eine positive als
auch eine negative Liste (das bedeutet, eine Liste ohne und eine Liste mit vorangestelltem »~«)
konfiguriert werden, hat die negative Liste Vorrang vor der positiven Liste. Beachten Sie, dass
systemd-nspawn immer eine Erlaubnisliste von Systemaufrufen implementiert (im Gegensatz zu einer
Ausschlussliste), und dieser Befehl daher Einträge zu dieser Vorgabeerlaubnisliste hinzufügt oder aus
ihr entfernt, abhängig, ob »~« vorangestellt ist. Beachten Sie, dass der angewandte
Systemaufruffilter auch implizit geändert wird, falls mittels --capabilities= zusätzliche
Capabilities übergeben werden.

Hinzugefügt in Version 235.

-Z, --selinux-context=
Setzt den für die Markierung von Prozessen in dem Container zu verwendenden Sicherheitskontext.

Hinzugefügt in Version 209.

-L, --selinux-apifs-context=
Setzt den für die Markierung von Dateien in dem virtuellen API-Dateisystem im Container zu
verwendenden Sicherheitskontext.

Hinzugefügt in Version 209.

Ressourcenoptionen
--rlimit=
Setzt die angegebene POSIX-Ressourcenbeschränkung für den Container-Inhalt. Erwartet eine Zuweisung
der Form »BESCHRÄNKUNG=WEICH:HART« oder »BESCHRÄNKUNG=WERT«, wobei sich BESCHRÄNKUNG auf einen
Ressourcenbeschränkungstyp wie RLIMIT_NOFILE oder RLIMIT_NICE beziehen sollte. Die Felder WEICH und
HART sollten sich auf die numerischen weichen und harten Ressourcenbeschränkungswerte beziehen. Falls
die zweite Form verwandt wird, kann WERT einen Wert angeben, der sowohl als weiche als auch als harte
Beschränkung verwandt wird. Anstelle eines numerischen Wertes kann die besondere Zeichenkette
»infinity« verwandt werden, die zum Abschalten der Beschränkung für den angegebenen Ressourcentyp
eingesetzt werden kann. Diese Befehlszeilenoption kann mehrfach verwandt werden, um die
Beschränkungen für mehrere Beschränkungstypen zu steuern. Falls sie mehrfach für den gleichen
Beschränkungstyp verwandt wird, gewinnt die letzte Verwendung. Für Details über
Ressourcenbeschränkungen siehe setrlimit(2). Standardmäßig werden Ressourcenbeschränkungen für den
Init-Prozess (PID 1) des Containers auf die gleichen Werte gesetzt, die der Linux-Kernel ursprünglich
an das Init-System des Rechners übergeben hat. Beachten Sie, dass einige Ressourcenbeschränkungen
benutzerbezogen erzwungen werden, insbesondere RLIMIT_NPROC. Dies bedeutet, dass sämtliche
Beschränkungen auf die Ressourcenverwendung des gleichen Benutzers auf allen lokalen Containern sowie
dem Rechner angewandt werden, außer es werden Benutzer-Namensräume eingesetzt (d.h. --private-users=
verwandt wird, siehe oben). Dies bedeutet, dass besondere Vorsicht mit diesen Beschränkungen walten
gelassen werden muss, da sie von möglicherweise weniger vertrauenswürdigem Code ausgelöst werden
könnten. Beispiel: »--rlimit=RLIMIT_NOFILE=8192:16384«.

Hinzugefügt in Version 239.

--oom-score-adjust=
Ändert den OOM (»Speichererknappheits«)-Anpassungsbewertungswert für den Container-Inhalt. Dies
steuert /proc/self/oom_score_adj, das die Rangfolge beeinflusst, mit dem einzelne Container beendet
werden, wenn der Speicher rar wird. Für Details siehe proc(5). Akzeptiert eine Ganzzahl im Bereich
-1000…1000.

Hinzugefügt in Version 239.

--cpu-affinity=
Steuert die CPU-Affinität für den Inhalt des Containers. Akzeptiert eine Kommata-getrennte Liste von
CPU-Nummern oder Nummern-Bereichen (bei diesen trennen Sie Start- und Endwert durch Bindestriche).
Siehe sched_setaffinity(2) für Details.

Hinzugefügt in Version 239.

--personality=
Steuert die durch uname(2) im Container gemeldete Architektur (»Personalität«). Derzeit werden nur
»x86« und »x86-64« unterstützt. Dies ist zum Betrieb von 32-Bit-Containern auf 64-Bit-Rechnern
nützlich. Falls diese Einstellung nicht verwandt wird, ist die im Container gemeldete Personalität
identisch zu der auf dem Rechner gemeldeten.

Hinzugefügt in Version 209.

Integrationsoptionen
--resolv-conf=
Konfiguriert, wie /etc/resolv.conf innerhalb des Containers gehandhabt werden soll (d.h. die
DNS-Synchronisierung vom Rechner zum Container). Akzeptiert entweder »off«, »copy-host«,
»copy-static«, »copy-uplink«, »copy-stub«, »replace-host«, »replace-static«, »replace-uplink«,
»replace-stub«, »bind-host«, »bind-static«, »bind-uplink«, »bind-stub«, »delete« oder »auto«.

Falls auf »off« gesetzt, dann wird die Datei /etc/resolv.conf im Container so belassen, wie sie im
Abbild enthalten ist und weder verändert noch eine Bind-Einhängung darüber durchgeführt.

Falls auf »copy-host« gesetzt, wird die Datei /etc/resolv.conf vom Rechner in den Container kopiert,
außer die Datei existiert bereits und ist keine reguläre Datei (z.B. ein Symlink). Ähnlich wird beim
Einsatz von »replace-host« die Datei kopiert und jede existierende Inode ersetzt, einschließlich
Symlinks. Ähnlich wird beim Einsatz von »bind-host« die Datei vom Rechner in den Container
Bind-eingehängt.

Falls auf »copy-static«, »replace-static« oder »bind-static« gesetzt, wird die durch
systemd-resolved.service(8) bereitgestellte statische resolv.conf-Datei (konkret:
/usr/lib/systemd/resolv.conf) in den Container kopiert oder Bind-eingehängt.

Falls auf »copy-uplink«, »replace-uplink« oder »bind-uplink« gesetzt, wird die durch
Systemd-resolved.service verwaltete Uplink-resolv.conf-Datei (konkret:
/run/systemd/resolve/resolv.conf) in den Container kopiert oder Bind-eingehängt.

Falls auf »copy-stub«, »replace-stub« oder »bind-stub« gesetzt, wird die durch
Systemd-resolved.service verwaltete Rumpf-resolv.conf-Datei (konkret:
/run/systemd/resolve/stub-resolv.conf) in den Container kopiert oder Bind-eingehängt.

Falls auf »delete« gesetzt, wird die Datei /etc/resolv.conf gelöscht, falls sie existiert.

Falls schließlich auf »auto« gesetzt, wird die Datei so belassen, wie sie ist, falls privates
Netzwerken aktiviert ist (siehe --private-network). Falls andernfalls Systemd-resolved.service läuft,
wird dessen Rumpf-resolv.conf-Datei verwandt und falls nicht, die Datei /etc/resolv.conf des
Rechners. In letzterem Fall wird die Datei kopiert, falls das Abbild beschreibbar ist und andernfalls
Bind-eingehängt.

Es wird empfohlen, »copy-…« oder »replace-…« zu verwenden, falls der Container in der Lage sein soll,
selbst an seiner DNS-Einstellung Änderungen vorzunehmen, die sich von denen des Rechners
unterscheiden. Andernfalls ist »bind« zu bevorzugen, da dies bedeutet, dass direkte Änderungen an
/etc/resolv.conf im Container nicht erlaubt sind, da es eine schreibgeschützte Bind-Einhängung ist
(beachten Sie aber, dass der Container einfach die Bind-Einhängung aushängen könnte, falls er über
genug Privilegien verfügt). Beachten Sie, dass in beiden Fällen (Bind-Einhängen und Kopieren der
Datei) im Allgemeinen keine weitere Weitergabe der Konfiguration nach dieser einmaligen
Initialisierung erfolgt (dies kommt daher, da die Datei normalerweise durch Kopieren und Umbenennen
aktualisiert wird). Standardmäßig »auto«.

Hinzugefügt in Version 239.

--timezone=
Steuert, wie mit /etc/localtime innerhalb des Containers (d.h. der Zeitsynchronisation vom Rechner
zum Container) umgegangen werden soll. Akzeptiert entweder »off«, »copy«, »bind«, »symlink«, »delete«
oder »auto«. Falls auf »off« gesetzt, verbleibt die Datei /etc/localtime im Container, wie sie im
Abbild enthalten ist; sie wird weder verändert noch erfolgt darüber eine bind-Einhängung. Falls auf
»copy« gesetzt, wird die Datei /etc/localtime vom Rechner in den Container kopiert. Ähnlich wird bei
der Verwendung von »bind« die Datei vom Rechner in den Container bind-eingehängt. Falls auf »symlink«
gesetzt, wird ein Symlink erstellt, der von /etc/localtime im Container auf die Zeitzonendatei im
Container, die auf die Zeitzoneneinstellung im Rechner passt, zeigt. Falls auf »delete« gesetzt, wird
die Datei im Container gelöscht, falls sie existiert. Falls auf »auto« gesetzt und die Datei
/etc/localtime des Rechners ein Symlink ist, dann wird der »symlink«-Modus verwandt, ansonsten
»copy«, falls das Abbild schreibbar ist und andernfalls »bind«. Standardmäßig »auto«.

Hinzugefügt in Version 239.

--link-journal=
Steuert, ob das Journal des Containers für den Rechner sichtbar sein soll. Falls aktiviert, erlaubt
dies das Betrachten der Journal-Dateien des Containers vom Rechner aus (aber nicht andersherum).
Akzeptiert entweder »no«, »host«, »try-host«, »guest«, »try-guest« oder »auto«. Falls »no«, wird das
Journal nicht verlinkt. Falls »host«, werden die Journal-Dateien auf dem Dateisystem des Rechners
gespeichert (unterhalb von /var/log/journal/Maschinenkennung) und das Unterverzeichnis wird im
Container am gleichen Ort bind-eingehängt. Falls »guest«, werden die Journal-Dateien im
Gast-Dateisystem (unterhalb von /var/log/journal/Maschinenkennung) gespeichert und das
Unterverzeichnis wird im Rechner am gleichen Ort verlinkt. »try-host« und »try-guest« machen das
gleiche, schlagen aber nicht fehl, falls der Rechner kein dauerhaftes Journal aktiviert hat oder der
Container im Modus --ephemeral ist. Falls »auto« (die Vorgabe) und das richtige Unterverzeichnis von
/var/log/journal existiert, wird es in den Container bind-eingehängt. Falls das Unterverzeichnis
nicht existiert, erfolgt keine Verlinkung. Effektiv führt einmaliges Starten eines Containers mit
»guest« oder »host« dazu, dass das Journal dauerhaft verlinkt wird, falls zukünftig die Vorgabe
»auto« verwandt wird.

Beachten Sie, dass --link-journal=try-guest die Vorgabe ist, falls die Unit-Vorlagendatei
systemd-nspawn@.service verwandt wird.

Hinzugefügt in Version 187.

-j
Äquivalent zu --link-journal=try-guest.

Hinzugefügt in Version 187.

Einhänge-Optionen
--bind=, --bind-ro=
Hängt eine Datei oder ein Verzeichnis vom Rechner in den Container mit bind ein. Akzeptiert entweder
ein Pfad-Argument (dann wird der angegebene Pfad vom Rechner zum gleichen Pfad im Container
eingehängt), ein durch Doppelpunkt getrenntes Paar von Pfaden (dann wird der zuerst angegebene Pfad
als Quelle auf dem Rechner und der zweite Pfad als Ziel im Container verwandt) oder ein
Doppelpunkt-getrenntes Tripel von Quellpfad, Zielpfad und Einhängeoptionen. Dem Quellpfad darf
optional ein »+«-Zeichen vorangestellt werden. In diesem Fall wird der Quellpfad relativ zum
Wurzelverzeichnis des Containers betrachtet. Damit wird die Einrichtung von bind-Einhängungen
innerhalb des Container-Abbildes ermöglicht. Der Quellpfad kann als leere Zeichenkette angegeben
werden. Dann wird ein temporäres Verzeichnis unterhalb von /var/tmp/ im Rechner verwandt. Dieses wird
beim Herunterfahren des Containers automatisch entfernt. Falls der Quellpfad nicht absolut ist, wird
er relativ zum aktuellen Arbeitsverzeichnis aufgelöst. Die Option --bind-ro= erstellt nur-lesbare
Bind-Einhängungen. Maskierungen durch Rückwärtsschrägstriche werden interpretiert, so kann »\:«
verwandt werden, um Doppelpunkte in Pfade einzubetten. Diese Option kann mehrfach verwandt werden, um
mehrere unabhängige bind-Einhängepunkte zu erzeugen.

Einhängeoptionen werden durch Kommata getrennt. rbind und norbind steuern, ob eine rekursive oder
eine reguläre Bind-Einhängung erstellt wird. Standardmäßig rbind. noidmap, idmap, rootidmap und
owneridmap steuern die Kennungszuordnung.

Die Verwendung von idmap, rootidmap oder owneridmap benötigt Unterstützung durch das Quelldateisystem
für die Benutzer-/Gruppen-Zuordnung-Einhängungen. Standardmäßig noidmap. Ist x der
UID-Bereichsversatz des Containers, y die Länge des UID-Bereichs des Containers und p die
Eigentümer-UID der Bind-Einhängungs-Inode auf dem Rechner:

• Falls noidmap verwandt wird, wird jeder Benutzer z im Bereich 0 … y (von innerhalb des Containers
betrachtet) auf x + z im Bereich x … x + y auf dem Rechner abgebildet. Andere Benutzer des
Rechners werden auf nobody innerhalb des Containers abgebildet.

• Falls idmap verwandt wird, wird jeder Benutzer z im UID-Bereich 0 … y (von innerhalb des
Containers betrachtet) auf die gleiche z im gleichen Bereich 0 … y auf dem Rechner abgebildet.
Andere Benutzer des Rechners werden auf nobody innerhalb des Containers abgebildet.

• Falls rootidmap verwandt wird, wird der Benutzer 0 (von innerhalb des Containers betrachtet) auf
p auf dem Rechner abgebildet. Andere Benutzer des Rechners werden auf nobody innerhalb des
Containers abgebildet.

• Falls owneridmap verwandt wird, wird der Eigentümer des Zielverzeichnisses (von innerhalb des
Containers betrachtet) auf p auf dem Rechner abgebildet. Andere Benutzer des Rechners werden auf
nobody innerhalb des Containers abgebildet.

Unabhängig von der gewählten Kennungs-Zuordnungsfunktion wird die gleiche Zuordnung für Benutzer und
Gruppen verwandt. Falls rootidmap oder owneridmap verwandt werden, hat die Gruppe, der das
Bind-Einhängungsverzeichnis gehört, keine Auswirkung.

Beachten Sie, dass die entstehenden Einhängepunkte dem Benutzer nobody gehören werden, falls dies in
Kombination mit --private-users verwandt wird. Dies ist der Fall, da die Einhängung und deren Dateien
und Verzeichnisse weiterhin dem relevanten Benutzer und der relevanten Gruppe des Rechners gehören,
die im Container nicht existieren, und daher unter der Joker-UID 65534 (nobody) erscheinen. Falls
solche bind-Einhängungen erstellt werden, wird empfohlen, diese mit --bind-ro= nur-lesbar zu machen.
Alternativ können Sie die Einhängeoption »idmap« verwenden, um die Dateisystemkennungen abzubilden.

Hinzugefügt in Version 198.

--bind-user=
Bindet das Home-Verzeichnis des angegebenen Benutzers auf dem Rechner in den Container. Akzeptiert
den Namen eines bestehenden Benutzers auf dem Rechner als Argument. Kann mehrfach verwandt werden, um
mehrere Benutzer in den Container zu binden. Dies macht drei Dinge:

1. Das Home-Verzeichnis des Benutzers wird vom Rechner in /run/host/home/ bind-eingehängt.

2. Eine zusätzliche UID/GID-Zuordnung wird hinzugefügt, die die UID/GID des Benutzers des Rechners
auf die UID/GID des Containers abbildet, ausgewählt aus dem Bereich 60514…...60577.

3. Ein JSON-Benutzer- und -Gruppendatensatz wird in /run/userdb/ erstellt, der die abgebildeten
Benutzer beschreibt. Er enthält eine minimale Darstellung des Benutzerdatensatzes des Rechners,
angepasst auf die UID/GID und den Home-Verzeichnispfad, der dem Benutzer in dem Container
zugeordnet ist. Das Glibc-NSS-Modul nss-systemd(8) wird diese Datensätze dort aufnehmen und sie
in den Benutzer-/Gruppendatenbanken des Containers zur Verfügung stellen.

Die Kombination der obigen drei Aktionen stellt sicher, dass es möglich ist, sich an dem Container
mit den gleichen Konto-Informationen wie auf dem Rechner anzumelden. Der Benutzer wird nur flüchtig
während der Container betrieben wird abgebildet und die Zuordnung selbst führt nicht zu dauerhaften
Änderungen im Container (außer vielleicht für erstellte Protokollmeldungen zum Anmeldezeitpunkt und
ähnlichem). Beachten Sie, dass insbesondere die UID/GID-Zuweisung im Container nicht dauerhaft
erfolgt. Falls der Benutzer flüchtig abgebildet wird, ist es am besten, dem Benutzer keine Änderungen
an dem Container zu erlauben. Falls der Benutzer Dateien oder Verzeichnisse, die ihm gehören, in dem
Container zurücklässt und diese UIDs/GIDs während späterer Container-Aufrufe erneut verwandt werden
(möglicherweise mit einer anderen --bind-user=-Zuordnung), dann kann der »neu« Benutzer nicht auf
diese Dateien und Verzeichnisse zugreifen.

Die Benutzer-/Gruppen-Datensatz-Zuordnung funktioniert nur, falls der Container Systemd 249 oder
neuer enthält und nss-systemd korrekt in nsswitch.conf konfiguriert ist. Siehe nss-systemd(8) für
Details.

Beachten Sie, dass der vom Rechner in den Container ausgebreitete Benutzerdatensatz den
UNIX-Passwort-Hash des Benutzers enthalten wird, so dass nahtlose Anmeldungen in dem Container
möglich sind. Falls dem Container weniger als dem Rechner vertraut wird, ist es daher wichtig, eine
starke UNIX-Passwort-Hash-Funktion zu verwenden (z.B. yescrypt oder ähnlich, mit dem Hash
vorangestelltem »$y$«).

Beim Anbinden eines Benutzers vom Rechner in den Container werden Überprüfungen ausgeführt, um
sicherzustellen, dass der Benutzername im Container noch nicht bekannt ist. Desweiteren wird
überprüft, dass die zugewiesenen UID/GID derzeit in der Benutzer-/Gruppendatenbank des Containers
nicht definiert ist. Beide Überprüfungen greifen direkt auf die /etc/passwd und /etc/group im
Container zu und könnten daher bestehende Konten in anderen Datenbanken nicht erkennen.

Diese Aktion wird nur in Kombination mit --private-users=/-U unterstützt.

Hinzugefügt in Version 249.

--inaccessible=
Macht den angegebenen Pfad im Container nicht zugreifbar. Damit wird über den angegebenen Pfad (der
im Container existieren muss) ein leerer Dateiknoten des gleichen Typs eingehängt, der so restriktive
Zugriffsmodi wie möglich hat. Dies ist eine wirksame Methode, Dateien, Verzeichnisse und andere
Dateisystemobjekte vom Container-Inhalt zu maskieren. Diese Option kann mehr als einmal verwandt
werden, wodurch alle angegebenen Pfade maskiert werden.

Hinzugefügt in Version 242.

--tmpfs=
Hängt ein Tmpfs-Dateisystem in den Container ein. Akzeptiert ein einzelnes, absolutes Pfadargument,
das angibt, wohin die Tmpfs-Instanz eingehängt wird (in diesem Fall ist der Verzeichniszugriffsmodus
als 0755 und der Eigentümer root/root ausgewählt) oder optional ein Doppelpunkt-getrenntes Paar von
Pfad- und Einhängeoptionszeichenkette, die zum Einhängen verwandt wird (in diesem Fall werden die
Kernelvorgaben für Zugriffsmodus und Eigentümer ausgewählt, falls nicht anderweitig angegeben).
Maskierungen durch Rückwärtsschrägstriche werden im Pfad interpretiert, so kann »\:« verwandt werden,
um Doppelpunkte in Pfade einzubetten.

Beachten Sie, dass diese Option nicht zur Ersetzung des Wurzeldateisystems des Containers durch ein
temporäres Dateisystem verwandt werden kann. Die nachfolgend beschriebene Option --volatile= stellt
allerdings eine ähnliche Funktionalität bereit, wobei der Fokus auf zustandslosen
Betriebssystemabbildern liegt.

Hinzugefügt in Version 214.

--overlay=, --overlay-ro=
Kombiniert mehrere Verzeichnisbäume in ein Überlagerungsdateisystem und hängt es im Container ein.
Akzeptiert eine Liste von Doppelpunkt-getrennten Pfaden zu den zu kombinierenden Verzeichnisbäumen
und dem Zieleinhängepunkt.

Maskierungen durch Rückwärtsschrägstriche werden im Pfad interpretiert; so kann »\:« verwandt werden,
um Doppelpunkte in Pfade einzubetten.

Falls drei oder mehr Pfade angegeben werden, dann ist der letzte angegebene Pfad der
Zieleinhängepunkt im Container; alle vorher angegebenen Pfade beziehen sich auf Verzeichnisbäume im
Rechner und werden in der angegebenen Reihenfolge in das Überlagerungsdateisystem kombiniert. Der am
weitesten links stehende Pfad ist daher der niedrigste Verzeichnisbaum, der vorletzte Pfad der
höchste Verzeichnisbaum in der Stapelreihenfolge. Falls --overlay-ro= anstelle von --overlay=
verwandt wird, dann wird ein nur-lesbares Überlagerungsdateisystem erstellt. Falls ein schreibbares
Überlagerungsdateisystem erstellt wird, werden alle an ihm vorgenommenen Änderungen zum höchsten
Verzeichnisbaum in der Stapelreihenfolge geschrieben, d.h. im vorletzten angegebenen.

Falls nur zwei Pfade angegeben werden, dann wird der zweite angegebene Pfad sowohl als oberstes
Verzeichnis in der Stapelreihenfolge (wie vom Rechner gesehen) betrachtet, sowie auch als
Einhängepunkt für das Überlagerungsdateisystem im Container. Es müssen mindestens zwei Pfade
angegeben werden.

Den Quellpfaden darf optional das Zeichen »+« vorangestellt werden. In diesem Falle werden die Pfade
relativ zum Wurzelverzeichnis des Abbildes behandelt. Der oberste Quellpfad kann auch als eine leere
Zeichenkette angegeben werden, dann wird ein temporäres Verzeichnis unterhalb von /var/tmp/ auf dem
Rechner verwandt. Das Verzeichnis wird automatisch entfernt, wenn der Container heruntergefahren
wird. Dieses Verhalten ist nützlich, um nur-lesbare Container-Verzeichnisse schreibbar zu machen,
während der Container läuft. Verwenden Sie beispielweise »--overlay=+/var::/var«, um automatisch ein
temporäres schreibbares Verzeichnis über ein nur-lesbares /var/-Verzeichnis zu legen. Falls ein
Quellpfad nicht absolut ist, wird er relativ zum aktuellen Arbeitsverzeichnis aufgelöst.

Für Details zu Überlagerungsdateisystemen, siehe Überlagerungsdateisystem[5]. Beachten Sie, dass sich
die Semantiken eines Überlagerungsdateisystems deutlich von denen normaler Dateisysteme
unterscheiden, insbesondere im Hinblick auf die gemeldeten Geräte- und Inode-Informationen. Geräte-
und Inode-Informationen einer Datei können sich während des Hineinschreibens ändern und zeitweilig
könnten Prozesse veraltete Versionen von Dateien sehen. Beachten Sie, dass dieser Schalter
automatisch die Einhängeoption »workdir=« für das Überlagerungsdateisystem vom obersten
Verzeichnisbaum ableitet und damit zum Geschwisterverzeichnis wird. Es ist damit wesentlich, dass das
Verzeichnis oberster Ebene selbst kein Einhängepunkt ist (da das Arbeitsverzeichnis auf dem gleichen
Dateisystem wie der oberste Verzeichnisbaum sein muss). Beachten Sie auch, dass die Einhängeoption
»lowerdir=« die zu stapelnden Pfade in der umgekehrten Reihenfolge wie bei diesem Schalter erhält.

Beachten Sie, dass diese Option nicht zur Ersetzung des Wurzeldateisystems eines Containers durch ein
Überlagerungsdateisystem verwandt werden kann. Allerdings stellt die oben beschriebene Option
--volatile= eine ähnliche Funktionalität bereit, wobei der Fokus auf zustandslosen
Betriebssystemabbildern liegt.

Hinzugefügt in Version 220.

Ein-/Ausgabe-Optionen
--console=MODUS
Konfiguriert, wie die Standardeingabe, -ausgabe und die Fehlerausgabe für den Container-Inhalt
konfiguriert wird, sowie /dev/console-Geräte für den Container. Akzeptiert entweder interactive,
read-only, passive, pipe oder autopipe. Falls interactive, wird ein Pseudo-TTY reserviert und als
/dev/console im Container verfügbar gemacht. Es wird dann bidirektional mit der Standardeingabe
verbunden; die Standardausgabe wird an systemd-nspawn übergeben. read-only ist ähnlich, aber nur die
Ausgabe des Containers wird weitergeleitet und keine Eingaben vom Aufrufenden werden gelesen. Falls
passive, wird ein Pseudo-TTY-Gerät reserviert, aber es wird mit nichts verbunden. Im pipe-Modus wird
kein Pseudo-TTY reserviert, aber die an systemd-nspawn übergebenen Standardeingabedeskriptoren,
-ausgabedeskriptoren und die Fehlerausgabedeskriptoren werden — so wie sie sind — an den
Container-Inhalt weitergegeben, siehe dazu den nächsten Absatz. autopipe agiert schießlich wie
interactive wenn systemd-nspawn auf einem Terminal gestartet wird und andernfalls wie pipe.
Standardmäßig interactive, falls systemd-nspawn von einem Terminal aus aufgerufen wird, und ansonsten
read-only.

Im Modus pipe existiert /dev/console im Container nicht. Das bedeutet, dass der Container-Inhalt im
Allgemeinen kein vollständiges Init-System sein kann, da Init-Systeme dazu neigen, /dev/console zu
benötigen. Auf der anderen Seite können in diesem Modus Container-Aufrufe innerhalb von
Shell-Weiterleitungen verwandt werden. Dies liegt daran, dass zwischengeschaltete Pseudo-TTYs keine
unabhängige, bidirektionale Weiterleitung der Dateiendebedingung (EOF) erlauben, was allerdings für
den korrekten Betrieb von Shell-Weiterleitungen benötigt wird. Beachten Sie, dass der Modus pipe
vorsichtig verwandt werden sollte, da die Übergabe beliebiger Dateideskriptoren an weniger
vertrauenswürdige Container-Inhalte unerwünschte Schnittstellen für Zugriffe des Container-Inhaltes
öffnen könnten. Falls sich ein übergebener Dateideskriptor beispielsweise auf ein TTY in irgendeiner
Weise bezieht, können APIs wie TIOCSTI dazu verwandt werden, Eingaben künstlich zu erzeugen, die zum
Ausbruch aus dem Container verwandt werden können. Daher sollte der Modus pipe nur verwandt werden,
wenn dem Inhalt hinreichend vertraut wird oder wenn die Dateideskriptoren der Standardeingabe,
-ausgabe und Fehlerausgabe bekanntermaßen sicher sind, zum Beispiel Pipes.

Hinzugefügt in Version 242.

--pipe, -P
Äquivalent zu --console=pipe.

Hinzugefügt in Version 242.

--background=FARBE
Ändert während der Laufzeit des Containers die Terminal-Hintergrundfarbe auf die angegebene
ANSI-Farbe. Die Farbspezifikation sollte eine ANSI-X3.64-SGR-Hintergrundfarbe sein, d.h.
Zeichenketten wie »40«, »41«, …, »47«, »48;2;…«, »48;5;…«. Siehe ANSI-Maskier-Code (Wikipedia)[6] zu
Details. Weisen Sie eine leere Zeichenkette zu, um jede Einfärbung zu deaktivieren.

Hinzugefügt in Version 256.

Zugangsdaten
--load-credential=KENNUNG:PFAD, --set-credential=KENNUNG:WERT
Gibt ein Zugangsdatum an den Container. Diese zwei Optionen entsprechend den Einstellungen
LoadCredential= und SetCredential= in Unit-Dateien. Siehe systemd.exec(5) zu Details über diese
Konzepte, sowie die Syntax der Argumente der Optionen.

Beachten Sie: Wenn systemd-nspawn als Systemd-Systemdienst ausgeführt wird, kann es die mittels
LoadCredential=/SetCredential= empfangenen Zugangsdaten an den Nutzinhalt des Containers
weiterleiten. Ein Systemd-Diensteverwalter, der als PID 1 im Container ausgeführt wird, kann sie noch
weiter zu den Diensten, die er selber startet, weiterleiten. Es ist daher möglich, Zugangsdaten
leicht vom übergeordneten Diensteverwalter zu einem Container-Verwalterdienst und von dort in seine
Nutzlast weiterzuleiten. Das kann sogar rekursiv erfolgen.

Um Binärdaten in die Zugangsdaten für --set-credential= einzubetten, verwenden Sie C-artige
Maskierung (d.h. »\n« für einen eingebetteten Zeilenumbruch oder »\x00«, um ein Nullbyte (NUL)
einzubetten). Beachten Sie, dass die aufrufende Shell die Maskierungen bereits einmal entfernt haben
könnte, daher könnte eine doppelte Maskierung notwendig sein!

Die Dienste systemd-sysusers.service(8) und systemd-firstboot(1) lesen die auf diese Art
konfigurierten Anmeldedaten zum Zweck der Konfiguration des Passworts und der Shell des Benutzers
root des Containers, sowie der Locale, der Tastaturzuordnung und der Zeitzone des Systems während des
ersten Systemstartprozesses des Containers. Dies ist insbesondere in Kombination mit --volatile=yes
nützlich, wo jeder einzelne Systemstart wie der erste Systemstart aussieht, da die in /etc/
angewandte Konfiguration verloren geht, wenn der Container einen Neustart durchführt. Siehe die
entsprechenden Handbuchseiten für Details. Beispiel:

# systemd-nspawn -i image.raw \
--volatile=yes \
--set-credential=firstboot.locale:de_DE.UTF-8 \
--set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' \
-b

Der obige Befehl wird die angegebene Abbilddatei image.raw im flüchtigen Modus aufrufen, d.h. mit
leerem /etc/ und /var/. Die Nutzlast des Containers wird dies als ersten Systemstart erkennen und den
Dienst systemd-firstboot.service startet, der dann die zwei übergebenen Anmeldedaten einliest, um die
anfängliche Locale und das Passwort von Root des Systems zu konfigurieren.

Hinzugefügt in Version 247.

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

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

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

UMGEBUNGSVARIABLEN

$SYSTEMD_LOG_LEVEL
Die maximale Protokollierstufe für ausgegebene Meldungen (Meldungen mit einer höheren
Protokollierstufe, d.h. weniger wichtige, werden unterdrückt). Akzeptiert eine Kommata-getrennte
Liste von Werten. Ein Wert kann einer der folgenden sein (in Reihenfolge absteigender Bedeutung):
emerg, alert, crit, err, warning, notice, info, debug oder eine Ganzzahl im Bereich 0…7. Siehe
syslog(3) für weitere Informationen. Jedem Wert kann optional eine Zeichenkette aus console, syslog,
kmsg oder journal gefolgt von einem Doppelpunkt vorangestellt werden, um die maximale
Protokollierstufe für dieses spezielle Protokollierziel zu setzen (d.h.
SYSTEMD_LOG_LEVEL=debug,console:info legt fest, dass auf der Stufe »debug« protokolliert werden soll,
außer beim Protokollieren auf die Konsole, die auf Stufe »info« erfolgen soll). Beachten Sie, dass
die globale maximale Protokollierstufe Priorität gegenüber jeder zielbezogenen maximalen
Protokollierstufe hat.

$SYSTEMD_LOG_COLOR
Ein logischer Wert. Falls true, werden auf das TTY geschriebene Nachrichten gemäß ihrer Priorität
eingefärbt.

Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal geschrieben werden,
da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbständig Nachrichten gemäß ihrer
Protokollierungsstufe einfärben.

$SYSTEMD_LOG_TIME
Ein logischer Wert. Falls true, wird den Protokollnachrichten der Konsole ein Zeitstempel
vorangestellt.

Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal oder in eine Datei
geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbständig
Zeitstempel basierend auf ihren Metadaten den Nachrichten anhängen.

$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls true, wird den Protokollnachrichten ein Dateiname und eine Zeilenummer in
dem Quellcode, aus dem die Nachrichten stammen, vorangestellt.

Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den Journal-Einträgen angehängt
ist. Die Aufnahme in den Nachrichtentext kann bei der Fehlersuche in Programmen dennoch praktisch
sein.

$SYSTEMD_LOG_TID
Ein logischer Wert. Falls true, wird den Nachrichten die aktuelle numerische Thread-Kennung (TID)
vorangestellt.

Beachten Sie, dass diese Informationen sowieso als Metadaten an Journal-Einträge angehängt wird. Die
Aufnahme direkt im Nachrichtentext kann aber trotzdem bei der Fehlersuche in Programmen praktisch
sein.

$SYSTEMD_LOG_TARGET
Das Ziel für Protokolliernachrichten. Entweder console (auf das angehängte TTY protokollieren),
console-prefixed (auf das angehängte TTY protokollieren, aber die Protokollierstufe und »Einrichtung«
voranstellen, siehe syslog(3)), kmsg (in den zirkulären Kernel-Protokollpuffer protokollieren),
journal (in das Journal protokollieren), journal-or-kmsg (in das Journal protokollieren, falls
verfügbar, und andernfalls nach Kmsg), auto (das geeignete Protokollierziel automatisch ermitteln,
die Vorgabe) oder null (die Protokollierung deaktivieren).

$SYSTEMD_LOG_RATELIMIT_KMSG
Ob Kmsg ratenlimitiert werden soll oder nicht. Akzeptiert einen logischen Wert. Standardmäßig »true«.
Falls deaktiviert, wird Systemd die nach Kmsg geschriebenen Meldungen nicht ratenlimitieren.

$SYSTEMD_PAGER, $PAGER
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist. Falls gesetzt, wird
$SYSTEMD_PAGER verwandt, andernfalls $PAGER. setzt $PAGER außer Kraft. Falls weder $SYSTEMD_PAGER
noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter Implementierungen von Textanzeigeprogrammen
der Reihe nach ausprobiert, einschließlich less(1) und more(1), bis eines gefunden wird. Falls keine
Implementierung eines Textanzeigeprogramms gefunden wird, wird keines aufgerufen. Setzen dieser
Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist äquivalent zur Übergabe von
--no-pager.

Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, können $SYSTEMD_PAGER und $PAGER nur zum
Deaktivieren des Seitenanzeigeprogramms (mit »cat« oder »«) verwandt werden und werden ansonsten
ignoriert.

$SYSTEMD_LESS
Setzt die an less übergebenen Optionen (standardmäßig »FRSXMK«) außer Kraft.

Benutzer könnten insbesondere zwei Optionen ändern wollen:

K
Diese Option weist das Textanzeigeprogramm an, sich sofort beim Druck von Strg-C zu beenden. Um
less die Handhabung von Strg-C selbst zum Umschalten auf die Eingabeaufforderung zu erlauben,
setzen Sie diese Option zurück.

Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene Textanzeigeprogramm
ist, wird Strg+C durch das Programm ignoriert und muss durch das Textanzeigeprogramm selbst
gehandhabt werden.

X
Diese Option weist das Textanzeigeprogramm an, keine Termcap-Initialisierungs- und
-Deinitalisierungszeichenketten an das Terminal zu senden. Dies ist standardmäßig gesetzt, damit
die Darstellung von Befehlen selbst nach dem Beenden des Textanzeigeprogramms sichtbar bleibt.
Allerdings stehen dadurch einige Funktionen des Textanzeigeprogramms nicht zur Verfügung;
insbesondere ist das Scrollen in der Ausgabe mit der Maus nicht möglich.

Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESS keine Auswirkungen auf die
Ausführung von less(1) durch systemd(1)-Werkzeuge hat.

Siehe less(1) für weitere Ausführungen.

$SYSTEMD_LESSCHARSET
Setzt den an less zu übergebenden Zeichensatz (standardmäßig »utf-8«, falls das aufrufende Terminal
als UTF-8-kompatibel erkannt wurde) außer Kraft.

Beachten Sie, dass das Setzen der regulären Umgebungsvariablen $LESSCHARSET keine Auswirkungen auf
die Ausführungen von less(1) durch systemd(1)-Werkzeuge hat.

$SYSTEMD_PAGERSECURE
Typische Seitenanzeigeprogramme wie less(1) unterstützen nebem dem seitenweisen Anzeigen (d.h. dem
Durchlaufen der Ausgabe) das Öffnen von oder Schreiben in andere Dateien und die Ausführung von
beliebigen Shell-Befehlen. Werden Befehle mit erhöhten Berechtigungen, beispielsweise unter sudo(8)
oder pkexec(1), aufgerufen, wird das Seitenanzeigeprogramm zur Sicherheitsgrenze. Es muss darauf
geachtet werden, dass nur Programme mit streng begrenzter Funktionalität als Seitenanzeigeprogramm
verwandt werden und unerwünschte interaktive Funktionalitäten wie das Öffnen oder Erstellen von neuen
Dateien oder das Starten von Subprozessen nicht erlaubt sind. Der »Sichere Modus« für das
Seitenanzeigeprogramm kann wie nachfolgend beschrieben aktiviert werden, falls das
Seitenanzeigeprogramm dies unterstützt (die meisten Seitenanzeigeprogramme sind nicht so geschrieben,
dass sie dies berücksichtigen). Es wird empfohlen, den »Sicheren Modus« explizit zu aktivieren oder
das Seitenanzeigeprogramm komplett mittels --no-pager oder PAGER=cat zu deaktivieren, wenn nicht
vertrauenswürdigen Benutzern die Ausführung von Programmen mit erhöhten Privilegien erlaubt wird.

Diese Option akzeptiert ein logisches Argument. Ist es auf »true« gesetzt, wird der »Sichere Modus«
des Seitenanzeigeprogramms aktiviert. Im »Sicheren Modus« wird LESSSECURE=1 beim Aufruf des
Seitenanzeigeprogramms gesetzt. Dies weist das Seiteanzeigeprogramm an, Befehle zum Öffnen oder
Erstellen von neuen Dateien sowie das Starten von Subprozessen zu deaktivieren. Derzeit ist nur von
less(1) bekannt, dass es diese Variable versteht und den »Sicheren Modus« implementiert.

Ist diese Variable auf »false« gesetzt, unterliegt das Seitenanzeigeprogramm keinen Beschränkungen.
Setzen auf SYSTEMD_PAGERSECURE=0 oder das Beibehalten der Variable von der geerbten Umgebung könnte
den Benutzern die Ausführung beliebiger Befehle erlauben.

Ist $SYSTEMD_PAGERSECURE nicht gesetzt, versuchen die Systemd-Werkzeuge automatisch herauszufinden,
ob der »Sicheren Modus« aktiviert werden soll und ob das Seitenanzeigeprogramm dies unterstützt. Der
»Sichere Modus« wird aktiviert, falls die effektive UID nicht mit der UID des Eigentümers der
Anmeldesitzung übereinstimmt, siehe geteuid(2) und sd_pid_get_owner_uid(3), oder wenn die Ausführung
unter Werkzeugen wie sudo(8) oder ähnlichem erfolgt ($SUDO_UID ist gesetzt [7]). In diesen Fällen
wird SYSTEMD_PAGERSECURE=1 gesetzt und Seitenanzeigeprogramme, von denen nicht bekannt ist, dass sie
den »Sicheren Modus« unterstützen, werden überhaupt nicht verwandt. Beachten Sie, dass diese
automatische Erkennung nur die typischsten Mechanismen zur Erlangung von Privilegien abdeckt und dem
Komfort dient. Es wird empfohlen, explizit $SYSTEMD_PAGERSECURE zu setzen oder das
Seitenanzeigeprogramm zu deaktivieren.

Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt sein muss, damit die Variablen $SYSTEMD_PAGER
oder $PAGER (außer zum Deaktivieren des Seitenanzeigeprogramms) berücksichtigt werden.

$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn true, werden systemd und verwandte Hilfswerkzeuge Farben in
ihrer Ausgabe verwenden, andernfalls wird die Ausgabe einfarbig sein. Zusätzlich kann die Variable
eine der folgenden besonderen Werte annehmen: »16«, »256«, um die Verwendung von Farbe auf die
grundlegenden 16 bzw. 256 ANSI-Farben zu beschränken. Dies kann festgelegt werden, um die auf $TERM
und der vorliegenden Verbindung der Konsole basierende automatische Entscheidung außer Kraft zu
setzen.

$SYSTEMD_URLIFY
Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links für Terminal-Emulatoren, die dies
unterstützen, erstellt werden sollen. Dies kann angegeben werden, um die Entscheidung, die systemd
basierend auf $TERM und anderen Bedingungen trifft, außer Kraft zu setzen.

BEISPIELE

       Beispiel 1. Herunterladen eines Ubuntu-TAR-Abbildes und Öffnen einer Shell darin

           # importctl pull-tar -mN https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz
           # systemd-nspawn -M jammy-server-cloudimg-amd64-root

       Dies lädt das angegebene .tar-Abbild herunter, verifiziert es und verwendet dann systemd-nspawn(1) zum
       Öffnen einer Shell darin.

       Beispiel 2. Bauen und Starten einer minimalen Fedora-Distribution in einem Container

           # dnf -y --releasever=42 --installroot=/var/lib/machines/f42 \
                 --use-host-config --setopt=install_weak_deps=0 \
                 --repo=fedora --repo=updates install \
                 passwd dnf fedora-release nano util-linux systemd systemd-networkd
           # systemd-nspawn -bD /var/lib/machines/f42

       (Lassen Sie --use-host-config fort, wenn Sie dnf <= 4 verwenden.) Dies installiert eine minimale
       Fedora-Distribution in das Verzeichnis /var/lib/machines/f42 und startet dann dies Betriebssystem in
       einem Namensraum-Container. Da sich die Installation unterhalb des
       Standard-/var/lib/machines/-Verzeichnisses befindet, ist es möglich, die Maschine mittels systemd-nspawn
       -M f42 zu starten.

       Beispiel 3. Erzeugen einer Shell in einem Container einer minimalen Debian-Unstable-Distribution

           # debootstrap unstable ~/debian-tree/
           # systemd-nspawn -D ~/debian-tree/

       Dies installiert eine minimale Debian-Unstable-Distribution in ein Verzeichnis ~/debian-tree/ und erzeugt
       dann eine Shell aus diesem Abbild in einem Namensraum-Container.

       debootstrap unterstützt Debian[8], Ubuntu[9] und Tanglu[10] von Haus aus, daher kann der gleiche Befehl
       zur Installation von allen drei verwandt werden. Für andere Distributionen der Debian-Familie muss ein
       Spiegel angegeben werden, siehe debootstrap(8).

       Beispiel 4. Starten einer minimalen Arch-Linux-Distribution in einem Container

           # pacstrap -c ~/arch-tree/ base
           # systemd-nspawn -bD ~/arch-tree/

       Dies installiert eine minimale Arch-Linux-Distribution in das Verzeichnis ~/arch-tree/ und startet dann
       ein Betriebssystem in einem Namensraum-Container darin.

       Beispiel 5. Installion der OpenSUSE-Tumbleweed-Rolling-Distribution

           # zypper --root=/var/lib/machines/tumbleweed ar -c \
                 https://download.opensuse.org/tumbleweed/repo/oss tumbleweed
           # zypper --root=/var/lib/machines/tumbleweed refresh
           # zypper --root=/var/lib/machines/tumbleweed install --no-recommends \
                 systemd shadow zypper openSUSE-release vim
           # systemd-nspawn -M tumbleweed passwd root
           # systemd-nspawn -M tumbleweed -b

       Beispiel 6. Starten eines flüchtigen Schnappschusses des Systems

           # systemd-nspawn -D / -xb

       Dies führt eine Kopie des Systems in einem Schnappschuss aus, der sofort wieder entfernt wird, wenn sich
       der Container beendet. Alle zur Laufzeit erfolgten Dateiänderungen gehen daher beim Herunterfahren
       verloren.

       Beispiel 7. Ausführen eines Containers mit SELinux-Sandbox-Sicherheitskontext

           # chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container
           # systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \
                 -Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh

       Beispiel 8. Ausführen eines Containers mit einer OSTree-Verwendung

           # systemd-nspawn -b -i ~/image.raw \
                 --pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \
                 --bind=+/sysroot/ostree/deploy/$OS/var:/var

EXIT-STATUS

       Es wird der Exit-Code des im Container ausgeführten Programms zurückgeliefert.

SIEHE AUCH

       systemd(1), systemd.nspawn(5), chroot(1), dnf(8), debootstrap(8), pacman(8), zypper(8), systemd.slice(5),
       machinectl(1), importctl(1), systemd-mountfsd.service(8), systemd-nsresourced.service(8), btrfs(8)

ANMERKUNGEN

        1. Container-Schnittstelle
           https://systemd.io/CONTAINER_INTERFACE

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

        3. OCI-Laufzeit-Spezifikation
           https://github.com/opencontainers/runtime-spec/blob/master/spec.md

        4. OSTree
           https://ostree.readthedocs.io/en/latest/

        5. Überlagerungsdateisystem
           https://docs.kernel.org/filesystems/overlayfs.html

        6. ANSI-Maskier-Code (Wikipedia)
           https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters

        7. Es  wird  für  andere  Werkzeuge empfohlen, $SUDO_UID geeignet zu setzen und zu überprüfen und es als
           allgemeine Schnittstelle zu behandeln.

        8. Debian
           https://www.debian.org

        9. Ubuntu
           https://www.ubuntu.com

       10. Tanglu
           https://www.tanglu.org

       11. Arch Linux
           https://www.archlinux.org

       12. OpenSUSE Tumbleweed
           https://software.opensuse.org/distributions/tumbleweed

Ü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: debian-l10n-german@lists.debian.org.

systemd 257.6                                                                                  SYSTEMD-NSPAWN(1)