Provided by: manpages-de_4.23.1-1_all 
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 den Rechner- und Domain-Namen komplett
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.
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.
UNPRIVILEGED OPERATION
systemd-nspawn may be invoked with or without privileges. The full functionality is
currently only available when invoked with privileges. When invoked without privileges,
various limitations apply, including, but not limited to:
• Only disk image based containers are supported (i.e. --image=). Directory based ones
(i.e. --directory=) are not supported.
• Machine registration via --machine= is not supported.
• Only --private-network and --network-veth networking modes are supported.
When running in unprivileged mode, some needed functionality is provided via
systemd-mountfsd.service(8) and systemd-nsresourced.service(8)
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-Container in
dem Container-Abbild) 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 eine hypothetische Datei /etc/foobar möglicherweise schreibbar,
falls --bind=/etc/foobar zum Einhängen von außerhalb des nur lesbaren
Container-/etc/-Verzeichnisses verwnadt 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 │ Die übergebenen Parameter werden │
│angegeben │ 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.
Note that if credentials are used in combination with a non-root --user= (e.g.:
--set-credential=, --load-credential= or --import-credential=), then
--no-new-privileges=yes must be used, and --boot or --as-pid2 must not be used, as the
credentials would otherwise be unreadable by the container due to missing privileges
after switching to the specified user.
--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 wahr, 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 falsch.
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. Falls der Parameter »no« ist, werden Benutzernamensräume ausgeschaltet. Dies ist
die Vorgabe.
4. 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 ist daher oft eine gute Wahl, falls ein ordentlicher Benutzernamensraum mit
unterschiedlichen UID-Zuordnungen nicht angemessen ist.
5. 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).
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 sie die
Container-Sicherheit massiv erhöht und 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
irgendwo 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.
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 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
Change the terminal background color to the specified ANSI color as long as the
container runs. The color specified should be an ANSI X3.64 SGR background color, i.e.
strings such as "40", "41", ..., "47", "48;2;...", "48;5;...". See ANSI Escape Code
(Wikipedia)[6] for details. Assign an empty string to disable any coloring.
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 einer 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 wahr, 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 wahr, 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 werden.
$SYSTEMD_LOG_LOCATION
Ein logischer Wert. Falls wahr, wird den Protokollnachrichten ein Dateinamen 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 wahr, 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
Zu verwendendes Textanzeigeprogramm, wenn --no-pager nicht angegeben ist; 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 der Umgebungsvariablen auf die leere Zeichenkette oder den Wert »cat« ist
äquivalent zur Übergabe von --no-pager.
Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER
(sowie $PAGER) ohne Rückmeldung 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ührungen 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
Akzeptiert einen logischen Wert. Wenn wahr, wird der »sichere« Modus des
Textanzeigeprogramms verwandt, falls falsch, wird dieser deaktiviert. Falls
$SYSTEMD_PAGERSECURE überhaupt nicht gesetzt ist, dann wird der sichere Modus
aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentümer der
Anmeldesitzung ist, siehe geteuid(2) und sd_pid_get_owner_uid(3). Im sicheren Modus
wird LESSSECURE=1 beim Aufruf des Textanzeigeprogramms gesetzt und das
Textanzeigeprogramm muss Befehle deaktivieren, die neue Dateien öffnen oder erstellen
oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE überhaupt nicht
gesetzt ist, werden Textanzeigeprogramme, bei denen unbekannt ist, ob sie einen
sicheren Modus implementieren, nicht verwandt. (Derzeit implementiert nur less(1)
einen sicheren Modus.)
Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels
sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass
keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere« Modus
für das Textanzeigeprogramm kann wie oben beschrieben automatisch aktiviert werden.
Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser Einstellung aus
der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige Befehle auszuführen.
Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen
$SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen. Es kann sinnvoll sein,
stattdessen das Textanzeigeprogramm komplett mit --no-pager zu deaktivieren.
$SYSTEMD_COLORS
Akzeptiert ein logisches Argument. Wenn wahr, 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 starten 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
This downloads and verifies the specified .tar image, and then uses systemd-nspawn(1) to
open a shell in it.
Beispiel 2. Bauen und Starten einer minimalen Fedora-Distribution in einem Container
# dnf -y --releasever=40 --installroot=/var/lib/machines/f40 \
--repo=fedora --repo=updates --setopt=install_weak_deps=False install \
passwd dnf fedora-release vim-minimal util-linux systemd systemd-networkd
# systemd-nspawn -bD /var/lib/machines/f40
Dies installiert eine minimale Fedora-Distribution in das Verzeichnis
/var/lib/machines/f40 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 f40 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[7], Ubuntu[8] und Tanglu[9] 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 Escape Code (Wikipedia)
https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters
7. Debian
https://www.debian.org
8. Ubuntu
https://www.ubuntu.com
9. Tanglu
https://www.tanglu.org
10. Arch Linux
https://www.archlinux.org
11. 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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ oder neuer bezüglich der Copyright-
Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-
Mail an die Mailingliste der Übersetzer ⟨debian-l10n-german@lists.debian.org⟩.