SYSTEMD-NSPAWN(1) systemd-nspawn SYSTEMD-NSPAWN(1) BEZEICHNUNG systemd-nspawn - Erzeugt einen Befehl oder ein Betriebssystem in einem leichtgewichtigen Container UBERSICHT systemd-nspawn [OPTIONEN] [BEFEHL [ARG]] systemd-nspawn --boot [OPTIONEN] [ARG] BESCHREIBUNG systemd-nspawn kann zur Ausfuhrung eines Befehls oder Betriebssystems (OS) in einem leichtgewichtigen Namensraum-Container verwandt werden. In vielerlei Art ist es zu chroot(1) ahnlich, aber leistungsfahiger, da es die Dateisystemhierarchie sowie den Prozessbaum, die verschiedenen IPC-Untersysteme und die Rechner- und Domain-Namen virtualisiert. systemd-nspawn kann in jedem Verzeichnisbaum, der einen Betriebssystembaum enthalt, 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 konnen aus dem Container heraus nicht geandert werden. Gerateknoten konnen nicht erstellt werden. Das Wirtssystem kann nicht neu gestartet werden und Kernelmodule durfen von innerhalb des Containers nicht geladen werden. Diese Sandbox kann leicht aus dem Container heraus umgangen werden, falls keine Namensraume verwandt werden. Das bedeutet, dass nicht vertrauenswurdiger Code immer innerhalb eines Benutzernamensraums ausgefuhrt werden muss, siehe die nachfolgende Diskussion der Option --private-users=. Verwenden Sie Werkzeuge wie dnf(8), debootstrap(8) oder pacman(8), um eine geeignete OS-Verzeichnisbaumhierarchie fur systemd-nspawn einzurichten. Lesen Sie den nachfolgenden Abschnitt >>Beispiele<< fur geeignete Aufrufe dieser Befehle. Als Sicherheitsprufung wird systemd-nspawn die Existenz von /usr/lib/os-release oder /etc/os-release im Container-Baum uberprufen, bevor der Systemstart des Containers durchgefuhrt wird (siehe os-release(5)). Es konnte notwendig sein, diese Datei manuell zum Container-Baum hinzuzufugen, 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 ermoglichen; 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, wahrend dies beim Aufruf von systemd-nspawn auf der Befehlszeile nicht der Fall ist. Weitere Unterschiede in den Vorgaben sind zusammen mit den verschiedenen unterstutzten Optionen weiter unten dokumentiert. Das Werkzeug machinectl(1) kann zur Ausfuhrung 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 auszufuhren. Neben jedem Container kann eine Einstellungsdatei mit der Endung .nspawn existieren, die zusatzliche, bei der Ausfuhrung des Containers anzuwendende Einstellungen enthalt. Siehe systemd.nspawn(5) fur Details. Einstellungsdateien setzen die von der Vorlagen-Unit-Datei systemd-nspawn@.service verwandten Vorgabeoptionen ausser Kraft, wodurch es im Allgemeinen unnotig wird, diese Vorlagendatei direkt zu andern. Beachten Sie, dass systemd-nspawn Dateisysteme privat fur den Container nach /dev/, /run/ und ahnlichem einhangen wird. Diese werden ausserhalb des Containers nicht sichtbar sein und ihre Inhalte gehen verloren, wenn sich der Container beendet. Beachten Sie, dass die Ausfuhrung von zwei systemd-nspawn-Containern aus dem gleichen Verzeichnis nicht dazu fuhrt, dass sich die Prozesse in beiden gegenseitig sehen. Die PID-Namensraumtrennung der zwei Container ist vollstandig und die Container nutzen sehr wenige Laufzeitobjekte gemeinsam, ausser das unterliegende Dateisystem. Verwenden Sie eher die Befehle login oder shell von machinectl(1), um zusatzliche Anmeldesitzungen in einem laufenden Container zu erbitten. systemd-nspawn implementiert die Spezifikation Container-Schnittstelle[1]. Wahrend des Betriebs werden mittels systemd-nspawn aufgerufene Container mit dem Dienst systemd-machined(8) registriert. Dieser verfolgt die laufenden Container nach und stellt Programmierschnittstellen bereit, um mit ihnen zu interagieren. NICHT PRIVILEGIERTE OPERATIONEN systemd-nspawn kann mit oder ohne Privilegien aufgerufen werden. Die vollstandige Funktionalitat ist derzeit nur beim Aufruf mit Privilegien verfugbar. Beim Aufruf ohne Privilegien gelten verschiedene Einschrankungen, einschliesslich, aber nicht beschrankt auf: o Es werden nur Platten-basierte Container unterstutzt (d.h. --image=). Verzeichnis-basierte (d.h.--directory=) werden nicht unterstutzt. o Maschinenregistrierung mittels --machine= wird nicht unterstutzt. o Es werden nur die Netzwerkmodi --private-network und --network-veth unterstutzt. Beim Betrieb im nicht privilegierten Modus wird ein Teil der benotigten Funktionalitat mittels systemd-mountfsd.service(8) und systemd-nsresourced.service(8) bereitgestellt. OPTIONEN Falls die Option -boot angegeben ist, werden die Argumente als Argumente fur das Init-Programm verwandt. Andernfalls gibt BEFEHL das zu startende Programm in dem Container an und die verbleibenden Argumente werden als Argumente fur 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 samtliche Statusausgaben des Werkzeuges selbst aus. Wird dieser Schalter verwandt, wird die einzige Ausgabe von Nspawn die Ausgabe der Konsole des Container-Betriebssystems selbst sein. Hinzugefugt 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 uber dem Wurzelverzeichnis des Containers gesucht. Falls die Datei in diesem Fall gefunden wird, werden ihre Einstellungen auch gelesen und verwandt, aber moglicherweise unsichere Einstellungen werden ignoriert. Beachten Sie, dass in beiden Fallen die Einstellungen auf der Befehlszeile Vorrang gegenuber den entsprechenden Einstellungen aus geladenen .nspawn-Dateien haben, falls beide angegeben sind. Alle Einstellungen, die die Privilegien des Containers erhohen oder Zugriff auf zusatzliche Ressourcen wie Dateien oder Verzeichnissen auf der Wirtsmaschine geben konnen, werden als unsichere Einstellungen betrachtet. Fur Details uber 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, unabhangig 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 ausser denen auf der Befehlszeile werden wirksam. Hinzugefugt in Version 226. Abbildoptionen -D, --directory= Verzeichnis, das als Dateisystemwurzel fur 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= ubergebenen Maschinennamen ubereinstimmt, gesucht wird. Siehe den Abschnitt >>Dateien und Verzeichnisse<< in machinectl(1) fur 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<<-Teildatentrager, das/der als Vorlage fur 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 unterstutzt) oder als einfaches Verzeichnis (andernfalls) erstellt und von diesem Vorlagenbaum befullt. Idealerweise bezieht sich der angegebene Vorlagenpfad auf das Wurzelverzeichnis eines >>btrfs<<-Teildatentragers, wodurch in diesem Fall ein einfacher >>Kopieren-beim-Schreiben<<-Schnappschuss gemacht wird und das Befullen des Wurzelverzeichnisses instantan erfolgt. Falls sich der angegebene Vorlagenpfad nicht auf die Wurzel eines >>btrfs<<-Teildatentragers bezieht (oder noch nicht einmal auf einem >>btrfs<<-Dateisystem liegt), wird der Verzeichnisbaum kopiert (moglicherweise allerdings in einem >>reflink<<->>Kopieren-beim-Schreiben<<-Schema -- falls das Dateisystem dies unterstutzt), was deutlich mehr Zeit benotigen kann. Beachten Sie, dass der Schnappschuss von dem angegebenen Verzeichnis oder Teildatentrager vorgenommen wird, einschliesslich aller Unterverzeichnisse und Teildatentrager, aber ausschliesslich aller Untereinhangungen. 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 konnten, unverandert lasst. Hinzugefugt in Version 219. -x, --ephemeral Fuhrt den Container mit einem temporaren 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 konnten, unverandert lasst. Beachten Sie, dass wie bei --template= das Vornehmen eines temporaren Schnappschusses auf Dateisystemen, die Teildatentrager oder nativ >>reflinks<< unterstutzen (>>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 Teildatentrager umfasst, einschliesslich aller Unterverzeichnisse und Teildatentrager darunter, aber ausschliesslich aller Untereinhangungen. Mit dieser Option werden keine Anderungen am Container-Abbild erhalten. Verwenden Sie (das nachfolgend beschriebene) --volatile= als weiteren Mechanismus, um die Dauerhaftigkeit von Container-Abbildern zur Laufzeit zu begrenzen. Hinzugefugt in Version 219. -i, --image= Plattenabbild, aus dem das Wurzelverzeichnis fur den Container geladen werden soll. Akzeptiert einen Pfad zu einer regularen Datei oder zu einem Blockgerateknoten. Die Datei oder das Blockgerat muss eines der Folgenden enthalten: o Eine MBR-Partitionstabelle mit einer einzelnen Partition vom Typ 0x83, der startfahig markiert ist. o Eine GUID-Partitionstablle (GPT) mit einer einzelnen Partition vom Typ 0fc63daf-8483-4772-8e79-3d69d8477de4. o Eine GUID-Partitionstabelle (GPT) mit einer markierten Wurzelpartition, die als Wurzelverzeichnis des Containers eingehangt ist. Optional durfen GPT-Abbilder auch eine Home- oder Serverdatenpartition enthalten, die an den geeigneten Stellen im Container eingehangt sind. Alle diese Partitionen mussen durch die in Spezifikation auffindbarer Partitionen[2] definierten Partitionstypen identifiziert werden. o Keine Partitionstabelle und eine einzelne Datei, die sich uber das gesamte Abbild erstreckt. Falls eine EFI-Systempartition (ESP) auf GPT-Abbildern entdeckt wird, wird diese automatisch nach /efi (oder /boot als Ruckfall) eingehangt, falls ein Verzeichnis dieses Namens existiert und leer ist. Mit LUKS verschlusselte Partitionen werden automatisch entschlusselt. Auf GPT-Abbildern pruft dm-verity auch, ob die Datenintegritats-Hash-Partitionen eingerichtet sind, falls der Wurzel-Hash fur sie mit der Option --root-hash= angegeben wurde. Einzelne Dateisystemabbilder (d.h. Dateisysteme ohne eine umgebende Partitionstabelle) konnen mittels Dm-verity geoffnet werden, falls die Integritatsdaten mittels der Optionen --root-hash= und --verity-data= (und optional --root-hash-sig=) ubergeben werden. Alle anderen Partitionen, wie fremde Partitionen oder Auslagerungspartitionen, werden nicht eingehangt. Darf nicht zusammen mit --directory=, --template= angegeben werden. Anstelle des Abbildpfades kann ein versioniertes Verzeichnis >>.v/<< angegeben werden, siehe systemd.v(7) zu Details. Hinzugefugt 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. Hinzugefugt in Version 254. --oci-bundle= Akzeptiert einen Pfad zu einem aufzurufenden OCI-Laufzeitbundel, 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 ubergebene Daten Vorrang). Hinzugefugt in Version 242. --read-only Hangt das Wurzeldateisystem des Containers (und alle anderen Dateisysteme, die in dem Container-Abbild enthalten sind) nur-lesbar ein. Dies hat fur zusatzliche Einhangungen mit --bind=, --tmpfs= und ahnlichen 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 Anderungen erlaubt sind, aber nur nicht dauerhaft im Arbeitsspeicher gehalten werden. Weitere Details finden Sie nachfolgend. --volatile, --volatile=MODUS Startet den Container im fluchtigen Mouds. Wird kein Modusparameter ubergeben oder der Modus als yes angegeben, dann wird der vollstandige fluchtige Modus aktiviert. Dies bedeutet, dass das Wurzelverzeichnis eine grosstenteils leere >>tmpfs<<-Instanz ist und /usr/ aus dem Betriebssystembaum dort nur-lesbar hineingehangt ist (das System startet daher mit einem nur-lesbaren Betriebssystemabbild aber einem jungfraulichen Zustand und jungfraulicher Konfiguration und samtliche Anderungen 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 verhalt, aber samtliche Anderungen nur an dem temporaren 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 Verfugung gestellt (ausser --read-only ist angegeben, siehe oben). Beachten Sie, dass bei der Auswahl einer der fluchtigen Modi die Auswirkung auf das Wurzeldateisystem (oder im Falle von state /var/) begrenzt wird und jede andere, in der Hierarchie angeordnete Einhangung davon unbetroffen ist, unabhangig davon, ob sie automatisch (z.B. die EFI-Systempartition, die nach /efi/ oder /boot/ eingehangt sein konnte) oder explizit (z..B. durch eine zusatzliche Befehlszeilenoption wie --bind=, siehe unten) etabliert wurden. Dies bedeutet, dass Anderungen an /efi/ oder /boot/ verboten sind, selbst falls --volatile=overlay verwandt wurde und eine solche Partition im betroffenen Container-Abbild existiert und selbst falls --volatile=state verwandt wird, wird die hypothetische Datei /etc/foobar moglicherweise schreibbar, falls --bind=/etc/foobar zum Einhangen von ausserhalb des nur lesbaren Container-/etc/-Verzeichnisses verwandt wird. Die Option --ephemeral hat einen engen Bezug zu dieser Einstellung und stellt ahnliches Verhalten bereit, bei dem eine temporare und vergangliche Kopie des gesamten Betriebssystemabbildes erfolgt und diese dann ausgefuhrt wird. Weitere Details finden Sie weiter oben. Die Option --tmpfs= und --overlay= stellen ahnliche Funktionalitat bereit, allerdings nur fur bestimmte Unterverzeichnisse des Betriebssystemabbildes. Details finden Sie nachfolgend. Diese Option stellt ahnliche Funktionalitat fur Container bereit, wie der Befehlszeilenschalter >>systemd.volatile=<< dies fur Rechner selbst darstellt. Siehe kernel-command-line(7) fur Details. Beachten Sie, dass das Setzen dieser Option auf yes oder state nur funktioniert, falls das Betriebssystem des Containers einen Systemstart mit ausschliesslich eingehangtem /usr/ durchfuhren und dann selbstandig /var/ bevolkern (und im Falle von >>--volatile=yes<< auch /etc/) kann. Dies bedeutet insbesondere, dass Betriebssysteme, die der historischen Aufteilung von /bin/ und /lib/ (und zugehorigen Verzeichnissen) von /usr/ folgen (d.h. bei denen Erstere keine Symlinks in Letztere sind), bei >>--volatile=yes<< nicht als Container-Inhalt unterstutzt werden. Die Option overlay verlangt keine besonderen Vorbereitungen von dem Betriebssystem, aber beachten Sie, dass sich das Verhalten von >>overlayfs<< von dem regularer Dateisysteme in einer Reihe von Punkten unterscheidet und somit die Kompatibilitat eingeschrankt ist. Hinzugefugt in Version 216. --root-hash= Akzeptiert einen hexadezimalen Dateiintegritats-Wurzel-Hash (dm-verity). Diese Option aktiviert Datenintegritatsuberprufungen mittels dm-verity, falls das verwandte Abbild die notwendigen Integritatsdaten enthalt (siehe oben). Der angegebene Hash muss auf den Wurzel-Hash der Integritatsdaten 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<< tragt (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 unterstutzt wird), aber eine Datei mit der Endung .roothash neben dem Abbild gefunden wird, das ansonsten den gleichen Namen tragt (ausser falls das Abbild die Endung .raw enthalt, 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 fur das Wurzeldateisystem konfiguriert. Plattenabbilder konnen auch separate Dateiystem fur die /usr/-Hierarchie enthalten, die auch Verity-geschutzt sein kann. Der Wurzel-Hash fur 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 fur den hier beschriebenen Wurzel-Hash fur das Wurzeldateisystem. Beachten Sie, dass es derzeit keinen Schalter gibt, um den Wurzel-Hash fur /usr/ von der Befehlszeile aus zu konfigurieren. Siehe auch die Option RootHash= in systemd.exec(5). Hinzugefugt 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). Hinzugefugt in Version 246. --verity-data= Akzeptiert einen Pfad zu einer Datenintegritatsdatei (dm-verity). Diese Option aktiviert Datenintegritatsuberprufungen mittels Dm-verity, falls ein Wurzel-Hash ubergeben wird und falls das verwandte Abbild selbst keine Integritatsdaten enthalt. Die Integritatsdaten mussen mit dem Wurzel-Hash ubereinstimmen. Falls diese Option nicht angegeben ist, aber eine Datei mit der Endung >>.verity<< neben der Abbild-Datei gefunden wird, die ansonsten den gleichen Namen tragt (ausser 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. Hinzugefugt in Version 246. --pivot-root= Schwenkt in das angegebene Verzeichnis als / innerhalb des Containers um und hangt 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 ausgehangt) oder ein Doppelpunkt-getrenntes Paar aus neuem Wurzelpfad und Schwenkziel fur die alte Wurzel. Der neue Wurzelpfad wird auf / verschwenkt und die alte / wird auf das andere Verzeichnis verschwenkt. Beide Pfade mussen absolut und im Dateisystemnamensraum des Containers auflosbar sein. Dies ist fur Container, die mehrere startfahige Verzeichnisse enthalten, beispielweise mehrere OSTree[4]-Einsatze. Sie emuliert das Verhalten eines Systemstartprogrammes und einer Initrd, die normalerweise auswahlt, welches Verzeichnis als Wurzel eingehangt und darin PID 1 des Containers gestartet wird. Hinzugefugt in Version 233. Ausfuhrungsoptionen -a, --as-pid2 Ruft die Shell oder das angegebene Programm als Prozesskennung (PID) 2 statt als PID 1 (Init) auf. Standardmassig wird das ausgewahlte Programm als Prozess mit PID 1 ausgefuhrt, falls weder diese noch die Option --boot verwandt wird. Dieser Modus ist nur fur 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 ausfuhren, ihre Konfiguration bei SIGHUP neu einlesen und so weiter). Mit --as-pid2 wird ein minimaler Init-Prozess als PID 1 und das ausgewahlte Programm wird als PID 2 ausgefuhrt (und muss daher keine besonderen Semantiken implementieren). Der minimale Init-Prozess wird (Zombie-)Prozesse wie notig beseitigen und geeignet auf Signale reagieren. Es wird empfohlen, diesen Modus zum Aufruf von beliebigen Befehlen in Containern zu verwenden, ausser diese wurden zum Betrieb als PID 1 angepasst. Mit anderen Worten: dieser Schalter sollte fur so ziemlich alle Befehle verwendet werden, ausser 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. Hinzugefugt 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 ubergebene Argumente als Argumente fur das Init-Programm verwandt. Diese Option darf nicht mit --as-pid2 kombiniert werden. Die nachfolgende Tabelle erklart die verschiedenen Aufrufmodi und die Beziehung zu --as-pid2 (siehe oben): Tabelle 1. Aufrufmodus +---------------------+----------------------------+ |Schalter | Erklarung | +---------------------+----------------------------+ |Weder --as-pid2 noch | Die ubergebenen Parameter | |--boot angegeben | werden als Befehlszeile | | | interpretiert, die als PID | | | 1 im Container ausgefuhrt | | | wird. | +---------------------+----------------------------+ |--as-pid2 angegeben | Die ubergebenen Parameter | | | werden als Befehlszeile | | | interpretiert, die als PID | | | 2 im Container ausgefuhrt | | | wird. Ein minimaler | | | Init-Prozess wird als PID | | | 1 ausgefuhrt. | +---------------------+----------------------------+ |--boot angegeben | Im Container wird | | | automatisch nach einem | | | Init-Programm gesucht und | | | dieses als PID 1 | | | ausgefuhrt. Die | | | ubergebenen Parameter | | | werden als Aufrufparameter | | | fur 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. Hinzugefugt in Version 229. -E NAME[=WERT], --setenv=NAME[=WERT] Gibt die Umgebungsvariablen an, die an den Init-Prozess im Container ubergeben werden soll. Dies kann zum Ausserkraftsetzen der Vorgabenvariablen oder zum Setzen zusatzlicher 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. Hinzugefugt in Version 209. -u, --user= Wechselt nach Ubergang in den Container zu dem angegebenen Benutzer, wie er in der Benutzerdatenbank im Container definiert ist. Wie alle anderen Systemd-nspawn-Funktionalitaten ist dies keine Sicherheitsfunktionalitat und stellt nur einen Schutz gegen versehentliche zerstorerische Aktionen dar. Beachten Sie, dass bei der Verwendung von Zugangsberechtigungen in Kombination mit einem von Root verschiedenen --user= (d.h.: --set-credential=, --load-credential= oder --import-credential=) --no-new-privileges=yes verwandt werden muss und --boot oder --as-pid2 nicht verwandt werden darf, da die Zugangsberechtigungen ansonsten fur den Container aufgrund fehlender Privilegien nach dem Umschalten auf den angegebenen Benutzer nicht lesbar waren. --kill-signal= Gibt das an PID 1 des Containers zu sendende Prozesssignal an, wenn Nspawn selbst SIGTERM empfangt, um ein geordnetes Herunterfahren des Containers auszulosen. Standardmassig SIGRTMIN+3, falls --boot verwandt wird (auf Systemd-kompatiblen Init-Systemen lost 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) fur eine Liste gultiger Signale. Hinzugefugt in Version 220. --notify-ready= Konfiguriert Unterstutzung fur 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 uber Benachrichtigungen finden Sie in sd_notify(3). Hinzugefugt in Version 231. --suppress-sync= Erwartet ein logisches Argument. Falls true, wird fur den Inhalt des Containers jegliche Form von plattengebundener Dateisynchronisation ausgeschaltet. Das bedeutet, dass alle Dateisystemaufrufe wie sync(2), fsync(), syncfs(), nichts ausfuhren werden und die Schalter O_SYNC/O_DSYNC von open(2) und verwandten Aufrufen nicht verfugbar sein werden. Dies ist moglicherweise gefahrlich, da angenommene Datenintegritatsgarantien fur den Inhalt des Containers nicht tatsachlich durchgesetzt werden (dh. Daten, von den Schreiben auf Platte angenommen wurden, konnten verlorengehen, falls das System ungewohnlich heruntergefahren wird). Allerdings kann es die Laufzeitleistung des Containers massiv erhohen - solange diese Garantien weder benotigt noch gewunscht werden, beispielsweise da samtliche vom Container geschriebenen Daten temporarer, redundanter Art sind oder nur ein Zwischenartefakt, das weiterverarbeitet wird und in einem spateren Schritt in dem Verarbeitungssystem finalisiert wird. Standardmassig false. Hinzugefugt in Version 250. Systemidentitatsoptionen -M, --machine= Setzt den Maschinennamen fur diesen Container. Dieser Name kann zur Identifizierung des Containers wahrend der Laufzeit verwandt werden (beispielsweise in Werkzeugen wie machinectl(1) und ahnlichen). Er wird zur Initialisierung des Rechnernamens des Containers verwandt (der im Container allerdings ausser Kraft gesetzt werden kann). Falls nicht angegeben, wird die letzte Komponente des Wurzelverzeichnispfades des Containers verwandt, wobei moglicherweise eine zufallige Kennzeichnung angehangt wird, falls der Modus --ephemeral ausgewahlt ist. Falls das ausgewahlte Wurzelverzeichnis mit dem Wurzelverzeichnis des Rechners ubereinstimmt, wird der eigene Rechnername stattdessen als Vorgabe im Container verwandt. Hinzugefugt in Version 202. --hostname= Steuert den innerhalb des Containers zu setzenden Rechnernamen, falls vom Maschinennamen verschieden. Erwartet einen gultigen 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 fur verschiedene Identifikationsaspekte des Containers von ausserhalb verwandt, der mit dieser Option konfigurierbare Kernel-Rechnername ist fur die Identifikation des Containers von innen nutzlich. 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 ausschliesslich --machine= zu verwenden. Beachten Sie, dass der Container spater seinen Kernel-Rechnernamen selbst frei ausser Kraft setzen kann, unabhangig davon, ob der Name mit der Option --hostname= oder uber die Option --machine= initialisiert wurde. Hinzugefugt in Version 239. --uuid= Setzt die angegebene UUID fur 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= Fugt den Container als Teil der angegebenen Scheibe hinzu, statt der Vorgabe machine.slice. Dies gilt nur, falls die Maschine in ihrer eigenen Bereichs-Unit ausgefuhrt wird, d.h. falls --keep-unit nicht verwandt wird. Hinzugefugt in Version 206. --property= Setzt eine Unit-Eigenschaft der fur diese Maschine zu registrierenden Bereichs-Unit. Dies gilt nur, falls die Maschine in ihrer eigenen Bereichs-Unit ausgefuhrt 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 Speicherbeschrankungen und Ahnlichem fur den Container nutzlich. Hinzugefugt in Version 220. --register= Steuert, ob der Container mit systemd-machined(8) registriert wird. Akzeptiert ein logisches Argument, standardmassig >>yes<<. Diese Option sollte aktiviert werden, wenn der Container ein vollstandiges Betriebssystem ausfuhrt (genauer: ein System- und Diensteverwalter als PID 1). Sie ist nutzlich, 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 ausfuhrt, wird empfohlen, diese Option auf >>no<< zu setzen. Hinzugefugt in Version 209. --keep-unit Verwendet einfach die Dienste- oder Bereichs-Unit, in der systemd-nspawn aufgerufen wurde, anstatt eine fluchtige Bereichs-Unit, in der der Container ausgefuhrt 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 Ausfuhrung eines einzelnen systemd-nspawn-Containers ist. Diese Option ist bei der Ausfuhrung aus einer Benutzersitzung heraus nicht verfugbar. 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. Hinzugefugt in Version 209. Benutzer-Namensraum-Optionen --private-users= Steuert Benutzernamensraume. Falls aktiviert, wird der Container in seiner eigenen privaten Gruppe an UNIX-Benutzer- und Gruppenkennungen (UIDs und GIDs) ausgefuhrt. Dazu gehort die Zuordnung der im Container verwandten privaten UIDs/GIDs (beginnend mit dem Benutzer root mit 0 und hoher) auf den Bereich von UIDs/GIDs auf dem Rechner, die noch nicht fur andere Zwecke verwandt sind (normalerweise im Bereich hoher 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 Benutzernamensraume 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 Benutzernamensraume eingeschaltet. Der zu verwendende UID-/GID-Bereich wird automatisch aus der Dateieigentumerschaft 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 gewunschten Bereich gehoren. Auch mussen alle Datei-ACLs ausschliesslich UIDs/GIDs im gewunschten Bereich referenzieren. In diesem Modus ist die Anzahl der dem Container zugewiesenen UIDs/GIDS 65536, und die Eigentumer-UID/GID des Wurzelverzeichnisses muss ein Vielfaches von 65536 sein. 3. Der besondere Wert >>pick<< schaltet Benutzernamensraume ein. In diesem Fall wird der UID/GID-Bereich automatisch ausgewahlt. Im ersten Schritt wird die Eigentumer-UID/GID des Wurzelverzeichnisses des Verzeichnisbaums des Containers eingelesen und uberpruft, dass ihn derzeit kein anderer Container verwendet. Falls die Uberprufung erfolgreich ist, wird der auf diesem Weg ermittelte UID/GID-Bereich verwandt, ahnlich wie bei der Angabe von >>yes<<. Falls die Uberprufung nicht erfolgreich ist (und daher der durch den Eigentumer 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 zufallig ausgewahlt, wobei immer bei Vielfachen von 65536 begonnen und, falls moglich, konsistent vom Maschinennamen gehasht wird. Diese Einstellung impliziert --private-users-ownership=auto (siehe unten), was moglicherweise bewirkt, dass die Dateien und Verzeichnisse im Verzeichnisbaum des Containers den passenden Benutzern in dem ausgewahlten Bereich gehoren. Mit dieser Option wird das Verhalten von Benutzernamensraumen vollstandig automatisiert. Beachten Sie, dass der erste Aufruf eines bisher nicht verwandten Containers zur Auswahl eines neuen UID/GID-Bereichs dafur fuhren konnte und daher eine (moglicherweise aufwandige) Anpassungsaktion fur Dateieigentumerschaften erfolgen konnte. Der Aufwand fur nachfolgende Ausfuhrungen des Containers wird allerdings gering sein (ausser naturlich der ausgewahlte UID/GID-Bereich wird zu diesem Zeitpunkt anders verwandt). 4. Falls der Parameter >>no<< lautet, werden Benutzernamensraume ausgeschaltet. Diese ist die Vorgabe, wenn systemd-nspawn direkt aufgerufen wird. (Beachten Sie, dass die Unit systemd-nspawn@.service private Benutzer aktiviert.) Diese Option ist nicht sicher und darf nicht zur Ausfuhrung unvertrauenswurdigem Code angewandt werden. 5. Falls dieser Parameter >>identity<< ist, werden Benutzer-Namensraume mit einer identischen Zuordnung fur die ersten 65536 UIDs/GIDs eingesetzt. Dies ist grosstenteils aquivalent zu --private-users=0:65536. Wahrend es keine UID/GID-Isolierung bereitstellt, da alle Rechner- und Container-UIDs/GIDs identisch ausgewahlt werden, bietet es dennoch Isolation der Prozess-Capabilitys und konnte daher nutzlich sein, falls ein ordentlicher Benutzernamensraum mit unterschiedlichen UID-Zuordnungen nicht moglich ist. Diese Option ist nicht sicher und darf nicht zur Ausfuhrung unvertrauenswurdigen Codes verwandt werden. Es wird empfohlen, jedem Container mindestens 65536 UIDs/GIDs zuzuweisen, so dass der verwendbare Bereich an UIDs/GIDs im Container 16 Bit uberdeckt. Fur grosstmogliche Sicherheit sollten sich die UID/GID-Bereiche je zweier Container nicht uberlappen. 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 tatsachlich das Verhalten, das die Option --private-users=pick erzwingt. Werden Benutzernamensraume verwandt, wird der jedem Container zugewiesene GID-Bereich immer identisch zu dem UID-Bereich ausgewahlt. In den meisten Fallen ist --private-users=pick die empfohlene Option, da Benutzer-Namensraume aus Sicherheitsgrunden benotigt werden und diese Option die Container-Sicherheit massiv erhoht und gleichzeitig in den meisten Fallen vollautomatisch funktioniert. Beachten Sie, dass der ausgewahlte UID/GID-Bereich nicht in /etc/passwd oder /etc/group geschrieben wird. Tatsachlich wird die Zuweisung des Bereiches nicht dauerhaft gespeichert, ausser in den Dateieigentumerschaften der Dateien und Verzeichnisse des Containers. Beachten Sie, dass sich dies bei der Verwendung von Benutzernamensraumen in den Dateieigentumerschaften auf der Platte widerspiegelt und alle Dateien und Verzeichnisse des Containers den effektiven Benutzer- und Gruppenkennungen des Containers gehoren. 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. Hinzugefugt in Version 220. --private-users-ownership= Steuert, wie die UIDs und GIDs des Containers angepasst werden, um auf den mit --private-users= gewahlten UID/GID-Bereich zu passen, siehe oben. Akzeptiert entweder >>off<< (um das Abbild unverandert zu lassen), >>chown<< (um den Verzeichnisbaum des Containers nach Notwendigkeit rekursiv mit chown() anzupassen), >>map<< (um Einhangungen mit transparenter Zuordnung der Kennungen zu verwenden) oder >>auto<<, um automatisch >>map<< wo verfugbar zu verwenden und >>chown<< wo nicht. Passt, falls >>chown<< ausgewahlt ist, alle Dateien und Verzeichnisse im Verzeichnisbaum des Containers an, so dass sie den passenden, fur den Container ausgewahlten UIDs/GIDs gehoren (siehe oben). Diese Aktion ist moglicherweise aufwandig, da sie den vollen Durchlauf durch den Verzeichnisbaum des Containers verlangt. Neben der eigentlichen Dateieigentumerschaft werden auch ACLs angepasst. Normalerweise ist >>map<< die beste Wahl, da es transparent die UIDs/GIDs im Speicher wie notwendig ohne Veranderung des Abbilds abbildet und auch keine teure rekursive Anpassungsaktion benotigt. Allerdings ist sie derzeit nicht fur alle Dateisysteme verfugbar. Die Option --private-users-ownership=auto wird impliziert, falls --private-users=pick verwandt wird. Diese Option hat nur eine Auswirkung, falls Benutzernamensraume verwandt werden. Hinzugefugt in Version 230. -U Falls der Kernel die Benutzernamensraumfunktionalitat unterstutzt, ist dies aquivalent 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 ruckgangig gemacht werden, indem die Aktion mit der ersten UID 0 erneut durchgefuhrt wird: systemd-nspawn --private-users=0 --private-users-ownership=chown Hinzugefugt in Version 230. Vernetzungsoptionen --private-network Trennt die Vernetzung zwischen Containers und Rechner. Damit werden alle Netzwerkschnittstellen im Container nicht mehr verfugbar, Ausnahmen sind nur das Loopback-Gerat 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 hinzugefugt, die der Container behalt. Letzteres kann mit --drop-capability= deaktiviert werden. Falls diese Option nicht angegeben (oder durch eine der nachfolgend aufgefuhrten 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 zuruckverschoben und wieder auf seinen ursprunglichen Namen zuruckbenannt. Beachten Sie, dass --network-interface= --private-network impliziert. Diese Option kann mehr als einmal verwandt werden, um mehrere Netzwerkschnittstellen in dem Container hinzuzufugen. Beachten Sie, dass alle auf diese Art festgelegten Schnittstellen zum Zeitpunkt des Startens des Containers bereits existieren mussen. Falls der Container automatisch beim Systemstart mittels der Unit-Dateiinstanz systemd-nspawn@.service gestartet werden soll, kann es daher sinnvoll sein, eine Unit-Dateierganzung fur die Diensteinstanz hinzuzufugen (z.B. /etc/systemd/system/systemd-nspawn@foobar.service.d/50-network.conf), die Inhalte folgender Art enthalt: [Unit] Wants=sys-subsystem-net-devices-ens1.device After=sys-subsystem-net-devices-ens1.device Dies stellt sicher, dass die Aktivierung des Container-Dienstes verzogert wird, bis die Netzwerkschnittstelle >>ens1<< aufgetaucht ist. Dies ist notwendig, da Hardwareermittlung vollstandig asynchron erfolgt und Netzwerkschnittstellen erst spater wahrend des Systemstartprozesses erkannt werden konnten, nachdem der Container normalerweise ohne diese expliziten Abhangigkeiten gestartet worden ware. Hinzugefugt in Version 209. --network-macvlan= Erstellt eine >>macvlan<<-Schnittstelle auf der angegebenen Ethernet-Netzwerkschnittstelle und fugt 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 hinzufugt. 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 hinzuzufugen. Wie bei --network-interface= muss die zugrundeliegende Ethernet-Netzwerkschnittstelle zum Zeitpunkt des Startens des Containers bereits existieren und daher konnten ahnliche Unit-Dateierganzungen wie oben beschrieben nutzlich sein. Hinzugefugt in Version 211. --network-ipvlan= Erstellt eine >>ipvlan<<-Schnittstelle auf der angegebenen Ethernet-Netzwerkschnittstelle und fugt 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, ahnlich 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 hinzuzufugen. Wie bei --network-interface= muss die zugrundeliegende Ethernet-Netzwerkschnittstelle zum Zeitpunkt des Startens des Containers bereits existieren und daher konnten ahnliche Unit-Dateierganzungen wie oben beschrieben nutzlich sein. Hinzugefugt 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 verfugbar sein, die nach dem Namen der Maschine (wie mit --machine= angegeben) benannt ist, der >>ve-<< vorangestellt ist. Die Container-Seite der Ethernetverbindung wird >>host0<< heissen. 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 enthalt, die auf die auf diese Art erstellte Schnittstelle im Rechner passt und die Einstellungen enthalt, um die automatische Adressbereitstellung auf der erstellten virtuellen Verbindung mittels DHCP sowie das automatische IP-Routen auf der externen Netzwerkschnittstelle des Rechners aktiviert. Sie enthalt 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 fur den Client enthalt. Wenn Systemd-networkd sowohl im Rechner als auch im Container lauft, ist daher automatische IP-Kommunikation vom Container zum Rechner verfugbar, 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 Lange von 15 Zeichen haben durfen, wahrend Container-Namen 64 Zeichen lang sein durfen. Da diese Option den Schnittstellennamen auf der Rechnerseite vom Container-Namen ableitet, ist der Name moglicherweise abgeschnitten. Daher muss in diesem Falle aufgepasst werden, dass die Schnittstellennamen eindeutig bleiben; besser noch, Container-Namen sollten im Allgemeinen so ausgewahlt werden, dass sie nicht langer 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 anhangen, um die Moglichkeit von Kollisionen zu verringern. Allerdings ist der Hash-Algorithmus nicht kollisionsfrei. (Siehe systemd.net-naming-scheme(7) fur Details uber altere Benennungsalgorithmen fur diese Schnittstelle). Alternativ kann die Option --network-veth-extra= verwandt werden. Sie erlaubt die freie Konfiguration des Schnittstellennamens auf der Rechnerseite unabhangig vom Container-Namen -- konnte aber ein bisschen mehr an Konfiguration benotigen, falls Bridging im Stile von --network-bridge= erwunscht ist. Hinzugefugt in Version 209. --network-veth-extra= Fugt eine zusatzliche 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 unabhangig 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. Hinzugefugt in Version 228. --network-bridge= Fugt die Rechnerseite der mit --network-veth erstellten Ethernet-Verbindung zu der angegebenen Ethernet-Bridge-Schnittstelle hinzu. Erwartet als Argument einen gultigen Netzwerkschnittstellennamen fur das Bridge-Gerat. Beachten Sie, dass --network-bridge= --network-veth impliziert. Falls diese Option verwandt wird, verwendet die Rechnerseite des Ethernet-Links das Prafix >>vb-<< anstelle von >>ve-<<. Unabhangig vom verwandten Benennungschema gelten die gleichen Langenbeschrankungen von Linux fur Netzwerkschnittstellennamen, zusammen mit den hierdurch entstehenden Komplikationen (siehe oben fur Details). Wie bei --network-interface= muss die zugrundeliegende Bridge-Netzwerkschnittstelle zum Zeitpunkt des Startens des Containers bereits existieren und daher konnten ahnliche Unit-Dateierganzungen wie oben beschrieben nutzlich sein. Hinzugefugt in Version 209. --network-zone= Erstellt eine virtuelle Ethernet-Verbindung (>>veth<<) fur den Container und fugt ihn zu den automatisch verwalteten Ethernet-Bridge-Schnittstellen hinzu. Die Bridge-Schnittstelle wird nach dem ubergebenen Argument benannt, dem >>vz-<< vorangestellt wird. Die Bridge-Schnittstelle wird automatisch erstellt, wenn der erste fur diesen Namen konfigurierte Container gestartet wird und automatisch entfernt, wenn der letzte fur diesen Namen konfigurierte Container sich beendet. Daher existiert jede auf diese Art erstellte Bridge-Schnittstelle nur so lange mindestens ein Container lauft, der sie referenziert. Diese Option ist sehr ahnlich zu --network-bridge=, abgesehen von der automatischen Erstellung/Entfernung des Bridge-Gerates. Diese Einstellung macht es leicht, mehrere zusammengehorige Container in eine gemeinsame, virtuelle, Ethernet-basierte Broadcast-Domane 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 konnen frei ausgewahlt werden (solange sie einen gultigen Netzwerkschnittstellenamen bilden, denen >>vz-<< vorangestellt ist) und es reicht aus, den gleichen Namen an den Schalter --network-zone= fur die verschiedenen, gleichzeitig laufenden Container zu ubergeben, um sie in eine Zone aufzunehmen. Beachten Sie, dass systemd-networkd.service(8) standardmassig eine Netzwerkdatei /usr/lib/systemd/network/80-container-vz.network enthalt, die auf die auf diese Art erstellte Bridge-Schnittstelle passt und die Einstellungen enthalt, 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 Fallen vollautomatisch und ausreichend, um mehrere lokale Container in einer vereinigten Broadcast-Domane mit dem Rechner zu verbinden, einschliesslich weiterer Verbindung zum externen Netzwerk. Hinzugefugt in Version 230. --network-namespace-path= Akzeptiert einen Pfad zu einer Datei, die einen Netzwerk-Namensraum darstellt, in dem der Container ausgefuhrt werden soll. Der angegebene Pfad sollte sich auf eine (moglicherweise >>bind<<-eingehangte) Netzwerk-Namensraum-Datei beziehen, wie diese durch den Kernel unterhalb von /proc/$PID/ns/net offengelegt wird. Dies fuhrt 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=. Hinzugefugt 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 unterstutzt, falls private Netzwerke verwandt werden, wie mit --network-veth, --network-zone= --network-bridge= ausgewahlt. Hinzugefugt in Version 219. Sicherheitsoptionen --capability= Listet eine oder mehrere zusatzliche Capabilities auf, die dem Container gewahrt werden sollen. Akzeptiert eine Kommata-getrennte Liste von Capability-Namen, siehe capabilities(7) fur weitere Informationen. Beachten Sie, dass die folgenden Capabilities auf jeden Fall gewahrt 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<< ubergeben wird, werden alle Capabilities behalten. Falls der besondere Wert >>help<< ubergeben 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= ubergeben werden, begrenzt. Hinzugefugt in Version 186. --drop-capability= Gibt eine oder mehrere zusatzliche Capabilities an, die fur den Container entfernt werden sollen. Dies erlaubt den Betrieb des Containers mit weniger als den Standard-Capabilities (siehe oben). Falls der besondere Wert >>help<< ubergeben 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= ubergeben werden, begrenzt. Hinzugefugt in Version 209. --ambient-capability= Gibt eine oder mehrere zusatzliche Capabilities an, die an die vererbare und Umgebungsmenge von Programmen, die im Container gestartet werden, ubergeben werden sollen. Der Wert >>all<< wird fur diese Einstellung nicht unterstutzt. Alle hier angegebenen Capabilities mussen 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<< ubergeben wird, wird das Programm die bekannten Capability-Namen ausgeben und sich beenden. Hinzugefugt in Version 248. --no-new-privileges= Akzeptiert ein logisches Argument. Gibt den Wert des Schalters PR_SET_NO_NEW_PRIVS fur den Container-Inhalt an. Standardmassig >>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) fur Details uber diesen Schalter. Hinzugefugt in Version 239. --system-call-filter= Andert 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) aufgefuhrt wird). Der Liste kann optional >>~<< vorangestellt werden, wodurch alle aufgefuhrten 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 Eintrage zu dieser Vorgabeerlaubnisliste hinzufugt oder aus ihr entfernt, abhangig, ob >>~<< vorangestellt ist. Beachten Sie, dass der angewandte Systemaufruffilter auch implizit geandert wird, falls mittels --capabilities= zusatzliche Capabilities ubergeben werden. Hinzugefugt in Version 235. -Z, --selinux-context= Setzt den fur die Markierung von Prozessen in dem Container zu verwendenden Sicherheitskontext. Hinzugefugt in Version 209. -L, --selinux-apifs-context= Setzt den fur die Markierung von Dateien in dem virtuellen API-Dateisystem im Container zu verwendenden Sicherheitskontext. Hinzugefugt in Version 209. Ressourcenoptionen --rlimit= Setzt die angegebene POSIX-Ressourcenbeschrankung fur den Container-Inhalt. Erwartet eine Zuweisung der Form >>BESCHRANKUNG=WEICH:HART<< oder >>BESCHRANKUNG=WERT<<, wobei sich BESCHRANKUNG auf einen Ressourcenbeschrankungstyp wie RLIMIT_NOFILE oder RLIMIT_NICE beziehen sollte. Die Felder WEICH und HART sollten sich auf die numerischen weichen und harten Ressourcenbeschrankungswerte beziehen. Falls die zweite Form verwandt wird, kann WERT einen Wert angeben, der sowohl als weiche als auch als harte Beschrankung verwandt wird. Anstelle eines numerischen Wertes kann die besondere Zeichenkette >>infinity<< verwandt werden, die zum Abschalten der Beschrankung fur den angegebenen Ressourcentyp eingesetzt werden kann. Diese Befehlszeilenoption kann mehrfach verwandt werden, um die Beschrankungen fur mehrere Beschrankungstypen zu steuern. Falls sie mehrfach fur den gleichen Beschrankungstyp verwandt wird, gewinnt die letzte Verwendung. Fur Details uber Ressourcenbeschrankungen siehe setrlimit(2). Standardmassig werden Ressourcenbeschrankungen fur den Init-Prozess (PID 1) des Containers auf die gleichen Werte gesetzt, die der Linux-Kernel ursprunglich an das Init-System des Rechners ubergeben hat. Beachten Sie, dass einige Ressourcenbeschrankungen benutzerbezogen erzwungen werden, insbesondere RLIMIT_NPROC. Dies bedeutet, dass samtliche Beschrankungen auf die Ressourcenverwendung des gleichen Benutzers auf allen lokalen Containern sowie dem Rechner angewandt werden, ausser es werden Benutzer-Namensraume eingesetzt (d.h. --private-users= verwandt wird, siehe oben). Dies bedeutet, dass besondere Vorsicht mit diesen Beschrankungen walten gelassen werden muss, da sie von moglicherweise weniger vertrauenswurdigem Code ausgelost werden konnten. Beispiel: >>--rlimit=RLIMIT_NOFILE=8192:16384<<. Hinzugefugt in Version 239. --oom-score-adjust= Andert den OOM (>>Speichererknappheits<<)-Anpassungsbewertungswert fur 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. Fur Details siehe proc(5). Akzeptiert eine Ganzzahl im Bereich -10001000. Hinzugefugt in Version 239. --cpu-affinity= Steuert die CPU-Affinitat fur 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) fur Details. Hinzugefugt in Version 239. --personality= Steuert die durch uname(2) im Container gemeldete Architektur (>>Personalitat<<). Derzeit werden nur >>x86<< und >>x86-64<< unterstutzt. Dies ist zum Betrieb von 32-Bit-Containern auf 64-Bit-Rechnern nutzlich. Falls diese Einstellung nicht verwandt wird, ist die im Container gemeldete Personalitat identisch zu der auf dem Rechner gemeldeten. Hinzugefugt 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 verandert noch eine Bind-Einhangung daruber durchgefuhrt. Falls auf >>copy-host<< gesetzt, wird die Datei /etc/resolv.conf vom Rechner in den Container kopiert, ausser die Datei existiert bereits und ist keine regulare Datei (z.B. ein Symlink). Ahnlich wird beim Einsatz von >>replace-host<< die Datei kopiert und jede existierende Inode ersetzt, einschliesslich Symlinks. Ahnlich wird beim Einsatz von >>bind-host<< die Datei vom Rechner in den Container Bind-eingehangt. 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-eingehangt. 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-eingehangt. 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-eingehangt. Falls auf >>delete<< gesetzt, wird die Datei /etc/resolv.conf geloscht, falls sie existiert. Falls schliesslich auf >>auto<< gesetzt, wird die Datei so belassen, wie sie ist, falls privates Netzwerken aktiviert ist (siehe --private-network). Falls andernfalls Systemd-resolved.service lauft, 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-eingehangt. Es wird empfohlen, >>copy-<< oder >>replace-<< zu verwenden, falls der Container in der Lage sein soll, selbst an seiner DNS-Einstellung Anderungen vorzunehmen, die sich von denen des Rechners unterscheiden. Andernfalls ist >>bind<< zu bevorzugen, da dies bedeutet, dass direkte Anderungen an /etc/resolv.conf im Container nicht erlaubt sind, da es eine schreibgeschutzte Bind-Einhangung ist (beachten Sie aber, dass der Container einfach die Bind-Einhangung aushangen konnte, falls er uber genug Privilegien verfugt). Beachten Sie, dass in beiden Fallen (Bind-Einhangen 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). Standardmassig >>auto<<. Hinzugefugt 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 verandert noch erfolgt daruber eine bind-Einhangung. Falls auf >>copy<< gesetzt, wird die Datei /etc/localtime vom Rechner in den Container kopiert. Ahnlich wird bei der Verwendung von >>bind<< die Datei vom Rechner in den Container bind-eingehangt. 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 geloscht, 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<<. Standardmassig >>auto<<. Hinzugefugt in Version 239. --link-journal= Steuert, ob das Journal des Containers fur 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-eingehangt. 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-eingehangt. Falls das Unterverzeichnis nicht existiert, erfolgt keine Verlinkung. Effektiv fuhrt einmaliges Starten eines Containers mit >>guest<< oder >>host<< dazu, dass das Journal dauerhaft verlinkt wird, falls zukunftig die Vorgabe >>auto<< verwandt wird. Beachten Sie, dass --link-journal=try-guest die Vorgabe ist, falls die Unit-Vorlagendatei systemd-nspawn@.service verwandt wird. Hinzugefugt in Version 187. -j Aquivalent zu --link-journal=try-guest. Hinzugefugt in Version 187. Einhange-Optionen --bind=, --bind-ro= Hangt 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 eingehangt), 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 Einhangeoptionen. 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-Einhangungen innerhalb des Container-Abbildes ermoglicht. Der Quellpfad kann als leere Zeichenkette angegeben werden. Dann wird ein temporares 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 aufgelost. Die Option --bind-ro= erstellt nur-lesbare Bind-Einhangungen. Maskierungen durch Ruckwartsschragstriche werden interpretiert, so kann >>\:<< verwandt werden, um Doppelpunkte in Pfade einzubetten. Diese Option kann mehrfach verwandt werden, um mehrere unabhangige bind-Einhangepunkte zu erzeugen. Einhangeoptionen werden durch Kommata getrennt. rbind und norbind steuern, ob eine rekursive oder eine regulare Bind-Einhangung erstellt wird. Standardmassig rbind. noidmap, idmap, rootidmap und owneridmap steuern die Kennungszuordnung. Die Verwendung von idmap, rootidmap oder owneridmap benotigt Unterstutzung durch das Quelldateisystem fur die Benutzer-/Gruppen-Zuordnung-Einhangungen. Standardmassig noidmap. Ist x der UID-Bereichsversatz des Containers, y die Lange des UID-Bereichs des Containers und p die Eigentumer-UID der Bind-Einhangungs-Inode auf dem Rechner: o 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. o 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. o 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. o Falls owneridmap verwandt wird, wird der Eigentumer des Zielverzeichnisses (von innerhalb des Containers betrachtet) auf p auf dem Rechner abgebildet. Andere Benutzer des Rechners werden auf nobody innerhalb des Containers abgebildet. Unabhangig von der gewahlten Kennungs-Zuordnungsfunktion wird die gleiche Zuordnung fur Benutzer und Gruppen verwandt. Falls rootidmap oder owneridmap verwandt werden, hat die Gruppe, der das Bind-Einhangungsverzeichnis gehort, keine Auswirkung. Beachten Sie, dass die entstehenden Einhangepunkte dem Benutzer nobody gehoren werden, falls dies in Kombination mit --private-users verwandt wird. Dies ist der Fall, da die Einhangung und deren Dateien und Verzeichnisse weiterhin dem relevanten Benutzer und der relevanten Gruppe des Rechners gehoren, die im Container nicht existieren, und daher unter der Joker-UID 65534 (nobody) erscheinen. Falls solche bind-Einhangungen erstellt werden, wird empfohlen, diese mit --bind-ro= nur-lesbar zu machen. Alternativ konnen Sie die Einhangeoption >>idmap<< verwenden, um die Dateisystemkennungen abzubilden. Hinzugefugt 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-eingehangt. 2. Eine zusatzliche UID/GID-Zuordnung wird hinzugefugt, die die UID/GID des Benutzers des Rechners auf die UID/GID des Containers abbildet, ausgewahlt aus dem Bereich 60514...60577. 3. Ein JSON-Benutzer- und -Gruppendatensatz wird in /run/userdb/ erstellt, der die abgebildeten Benutzer beschreibt. Er enthalt 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 Datensatze dort aufnehmen und sie in den Benutzer-/Gruppendatenbanken des Containers zur Verfugung stellen. Die Kombination der obigen drei Aktionen stellt sicher, dass es moglich ist, sich an dem Container mit den gleichen Konto-Informationen wie auf dem Rechner anzumelden. Der Benutzer wird nur fluchtig wahrend der Container betrieben wird abgebildet und die Zuordnung selbst fuhrt nicht zu dauerhaften Anderungen im Container (ausser vielleicht fur erstellte Protokollmeldungen zum Anmeldezeitpunkt und ahnlichem). Beachten Sie, dass insbesondere die UID/GID-Zuweisung im Container nicht dauerhaft erfolgt. Falls der Benutzer fluchtig abgebildet wird, ist es am besten, dem Benutzer keine Anderungen an dem Container zu erlauben. Falls der Benutzer Dateien oder Verzeichnisse, die ihm gehoren, in dem Container zurucklasst und diese UIDs/GIDs wahrend spaterer Container-Aufrufe erneut verwandt werden (moglicherweise 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 enthalt und nss-systemd korrekt in nsswitch.conf konfiguriert ist. Siehe nss-systemd(8) fur 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 moglich 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 ahnlich, mit dem Hash vorangestelltem >>$y$<<). Beim Anbinden eines Benutzers vom Rechner in den Container werden Uberprufungen ausgefuhrt, um sicherzustellen, dass der Benutzername im Container noch nicht bekannt ist. Desweiteren wird uberpruft, dass die zugewiesenen UID/GID derzeit in der Benutzer-/Gruppendatenbank des Containers nicht definiert ist. Beide Uberprufungen greifen direkt auf die /etc/passwd und /etc/group im Container zu und konnten daher bestehende Konten in anderen Datenbanken nicht erkennen. Diese Aktion wird nur in Kombination mit --private-users=/-U unterstutzt. Hinzugefugt in Version 249. --inaccessible= Macht den angegebenen Pfad im Container nicht zugreifbar. Damit wird uber den angegebenen Pfad (der im Container existieren muss) ein leerer Dateiknoten des gleichen Typs eingehangt, der so restriktive Zugriffsmodi wie moglich 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. Hinzugefugt in Version 242. --tmpfs= Hangt ein Tmpfs-Dateisystem in den Container ein. Akzeptiert ein einzelnes, absolutes Pfadargument, das angibt, wohin die Tmpfs-Instanz eingehangt wird (in diesem Fall ist der Verzeichniszugriffsmodus als 0755 und der Eigentumer root/root ausgewahlt) oder optional ein Doppelpunkt-getrenntes Paar von Pfad- und Einhangeoptionszeichenkette, die zum Einhangen verwandt wird (in diesem Fall werden die Kernelvorgaben fur Zugriffsmodus und Eigentumer ausgewahlt, falls nicht anderweitig angegeben). Maskierungen durch Ruckwartsschragstriche 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 temporares Dateisystem verwandt werden kann. Die nachfolgend beschriebene Option --volatile= stellt allerdings eine ahnliche Funktionalitat bereit, wobei der Fokus auf zustandslosen Betriebssystemabbildern liegt. Hinzugefugt in Version 214. --overlay=, --overlay-ro= Kombiniert mehrere Verzeichnisbaume in ein Uberlagerungsdateisystem und hangt es im Container ein. Akzeptiert eine Liste von Doppelpunkt-getrennten Pfaden zu den zu kombinierenden Verzeichnisbaumen und dem Zieleinhangepunkt. Maskierungen durch Ruckwartsschragstriche 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 Zieleinhangepunkt im Container; alle vorher angegebenen Pfade beziehen sich auf Verzeichnisbaume im Rechner und werden in der angegebenen Reihenfolge in das Uberlagerungsdateisystem kombiniert. Der am weitesten links stehende Pfad ist daher der niedrigste Verzeichnisbaum, der vorletzte Pfad der hochste Verzeichnisbaum in der Stapelreihenfolge. Falls --overlay-ro= anstelle von --overlay= verwandt wird, dann wird ein nur-lesbares Uberlagerungsdateisystem erstellt. Falls ein schreibbares Uberlagerungsdateisystem erstellt wird, werden alle an ihm vorgenommenen Anderungen zum hochsten 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 Einhangepunkt fur das Uberlagerungsdateisystem im Container. Es mussen 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 temporares Verzeichnis unterhalb von /var/tmp/ auf dem Rechner verwandt. Das Verzeichnis wird automatisch entfernt, wenn der Container heruntergefahren wird. Dieses Verhalten ist nutzlich, um nur-lesbare Container-Verzeichnisse schreibbar zu machen, wahrend der Container lauft. Verwenden Sie beispielweise >>--overlay=+/var::/var<<, um automatisch ein temporares schreibbares Verzeichnis uber ein nur-lesbares /var/-Verzeichnis zu legen. Falls ein Quellpfad nicht absolut ist, wird er relativ zum aktuellen Arbeitsverzeichnis aufgelost. Fur Details zu Uberlagerungsdateisystemen, siehe Uberlagerungsdateisystem[5]. Beachten Sie, dass sich die Semantiken eines Uberlagerungsdateisystems deutlich von denen normaler Dateisysteme unterscheiden, insbesondere im Hinblick auf die gemeldeten Gerate- und Inode-Informationen. Gerate- und Inode-Informationen einer Datei konnen sich wahrend des Hineinschreibens andern und zeitweilig konnten Prozesse veraltete Versionen von Dateien sehen. Beachten Sie, dass dieser Schalter automatisch die Einhangeoption >>workdir=<< fur das Uberlagerungsdateisystem vom obersten Verzeichnisbaum ableitet und damit zum Geschwisterverzeichnis wird. Es ist damit wesentlich, dass das Verzeichnis oberster Ebene selbst kein Einhangepunkt ist (da das Arbeitsverzeichnis auf dem gleichen Dateisystem wie der oberste Verzeichnisbaum sein muss). Beachten Sie auch, dass die Einhangeoption >>lowerdir=<< die zu stapelnden Pfade in der umgekehrten Reihenfolge wie bei diesem Schalter erhalt. Beachten Sie, dass diese Option nicht zur Ersetzung des Wurzeldateisystems eines Containers durch ein Uberlagerungsdateisystem verwandt werden kann. Allerdings stellt die oben beschriebene Option --volatile= eine ahnliche Funktionalitat bereit, wobei der Fokus auf zustandslosen Betriebssystemabbildern liegt. Hinzugefugt in Version 220. Ein-/Ausgabe-Optionen --console=MODUS Konfiguriert, wie die Standardeingabe, -ausgabe und die Fehlerausgabe fur den Container-Inhalt konfiguriert wird, sowie /dev/console-Gerate fur den Container. Akzeptiert entweder interactive, read-only, passive, pipe oder autopipe. Falls interactive, wird ein Pseudo-TTY reserviert und als /dev/console im Container verfugbar gemacht. Es wird dann bidirektional mit der Standardeingabe verbunden; die Standardausgabe wird an systemd-nspawn ubergeben. read-only ist ahnlich, aber nur die Ausgabe des Containers wird weitergeleitet und keine Eingaben vom Aufrufenden werden gelesen. Falls passive, wird ein Pseudo-TTY-Gerat reserviert, aber es wird mit nichts verbunden. Im pipe-Modus wird kein Pseudo-TTY reserviert, aber die an systemd-nspawn ubergebenen Standardeingabedeskriptoren, -ausgabedeskriptoren und die Fehlerausgabedeskriptoren werden -- so wie sie sind -- an den Container-Inhalt weitergegeben, siehe dazu den nachsten Absatz. autopipe agiert schiesslich wie interactive wenn systemd-nspawn auf einem Terminal gestartet wird und andernfalls wie pipe. Standardmassig 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 vollstandiges Init-System sein kann, da Init-Systeme dazu neigen, /dev/console zu benotigen. Auf der anderen Seite konnen in diesem Modus Container-Aufrufe innerhalb von Shell-Weiterleitungen verwandt werden. Dies liegt daran, dass zwischengeschaltete Pseudo-TTYs keine unabhangige, bidirektionale Weiterleitung der Dateiendebedingung (EOF) erlauben, was allerdings fur den korrekten Betrieb von Shell-Weiterleitungen benotigt wird. Beachten Sie, dass der Modus pipe vorsichtig verwandt werden sollte, da die Ubergabe beliebiger Dateideskriptoren an weniger vertrauenswurdige Container-Inhalte unerwunschte Schnittstellen fur Zugriffe des Container-Inhaltes offnen konnten. Falls sich ein ubergebener Dateideskriptor beispielsweise auf ein TTY in irgendeiner Weise bezieht, konnen APIs wie TIOCSTI dazu verwandt werden, Eingaben kunstlich zu erzeugen, die zum Ausbruch aus dem Container verwandt werden konnen. Daher sollte der Modus pipe nur verwandt werden, wenn dem Inhalt hinreichend vertraut wird oder wenn die Dateideskriptoren der Standardeingabe, -ausgabe und Fehlerausgabe bekanntermassen sicher sind, zum Beispiel Pipes. Hinzugefugt in Version 242. --pipe, -P Aquivalent zu --console=pipe. Hinzugefugt in Version 242. --background=FARBE Andert wahrend der Laufzeit des Containers die Terminal-Hintergrundfarbe auf die angegebene ANSI-Farbe. Die Farbspezifikation sollte eine ANSI-X3.64-SGR-Hintergrundfarbe sein, d.h. Zeichenketten wie >>40<<, >>41<<, , >>47<<, >>48;2;<<, >>48;5;<<. Siehe ANSI-Maskier-Code (Wikipedia)[6] zu Details. Weisen Sie eine leere Zeichenkette zu, um jede Einfarbung zu deaktivieren. Hinzugefugt 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 uber diese Konzepte, sowie die Syntax der Argumente der Optionen. Beachten Sie: Wenn systemd-nspawn als Systemd-Systemdienst ausgefuhrt wird, kann es die mittels LoadCredential=/SetCredential= empfangenen Zugangsdaten an den Nutzinhalt des Containers weiterleiten. Ein Systemd-Diensteverwalter, der als PID 1 im Container ausgefuhrt wird, kann sie noch weiter zu den Diensten, die er selber startet, weiterleiten. Es ist daher moglich, Zugangsdaten leicht vom ubergeordneten Diensteverwalter zu einem Container-Verwalterdienst und von dort in seine Nutzlast weiterzuleiten. Das kann sogar rekursiv erfolgen. Um Binardaten in die Zugangsdaten fur --set-credential= einzubetten, verwenden Sie C-artige Maskierung (d.h. >>\n<< fur einen eingebetteten Zeilenumbruch oder >>\x00<<, um ein Nullbyte (NUL) einzubetten). Beachten Sie, dass die aufrufende Shell die Maskierungen bereits einmal entfernt haben konnte, daher konnte 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 wahrend des ersten Systemstartprozesses des Containers. Dies ist insbesondere in Kombination mit --volatile=yes nutzlich, wo jeder einzelne Systemstart wie der erste Systemstart aussieht, da die in /etc/ angewandte Konfiguration verloren geht, wenn der Container einen Neustart durchfuhrt. Siehe die entsprechenden Handbuchseiten fur 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 fluchtigen 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 ubergebenen Anmeldedaten einliest, um die anfangliche Locale und das Passwort von Root des Systems zu konfigurieren. Hinzugefugt 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 fur ausgegebene Meldungen (Meldungen mit einer hoheren Protokollierstufe, d.h. weniger wichtige, werden unterdruckt). 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 07. Siehe syslog(3) fur weitere Informationen. Jedem Wert kann optional eine Zeichenkette aus console, syslog, kmsg oder journal gefolgt von einem Doppelpunkt vorangestellt werden, um die maximale Protokollierstufe fur dieses spezielle Protokollierziel zu setzen (d.h. SYSTEMD_LOG_LEVEL=debug,console:info legt fest, dass auf der Stufe >>debug<< protokolliert werden soll, ausser beim Protokollieren auf die Konsole, die auf Stufe >>info<< erfolgen soll). Beachten Sie, dass die globale maximale Protokollierstufe Prioritat gegenuber jeder zielbezogenen maximalen Protokollierstufe hat. $SYSTEMD_LOG_COLOR Ein logischer Wert. Falls true, werden auf das TTY geschriebene Nachrichten gemass ihrer Prioritat eingefarbt. Diese Einstellung ist nur nutzlich, falls die Nachrichten direkt auf das Terminal geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbstandig Nachrichten gemass ihrer Protokollierungsstufe einfarben. $SYSTEMD_LOG_TIME Ein logischer Wert. Falls true, wird den Protokollnachrichten der Konsole ein Zeitstempel vorangestellt. Diese Einstellung ist nur nutzlich, falls die Nachrichten direkt auf das Terminal oder in eine Datei geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbstandig Zeitstempel basierend auf ihren Metadaten den Nachrichten anhangen. $SYSTEMD_LOG_LOCATION Ein logischer Wert. Falls true, wird den Protokollnachrichten ein Dateiname und eine Zeilenummer in dem Quellcode, aus dem die Nachrichten stammen, vorangestellt. Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den Journal-Eintragen angehangt ist. Die Aufnahme in den Nachrichtentext kann bei der Fehlersuche in Programmen dennoch praktisch sein. $SYSTEMD_LOG_TID Ein logischer Wert. Falls true, wird den Nachrichten die aktuelle numerische Thread-Kennung (TID) vorangestellt. Beachten Sie, dass diese Informationen sowieso als Metadaten an Journal-Eintrage angehangt wird. Die Aufnahme direkt im Nachrichtentext kann aber trotzdem bei der Fehlersuche in Programmen praktisch sein. $SYSTEMD_LOG_TARGET Das Ziel fur Protokolliernachrichten. Entweder console (auf das angehangte TTY protokollieren), console-prefixed (auf das angehangte TTY protokollieren, aber die Protokollierstufe und >>Einrichtung<< voranstellen, siehe syslog(3)), kmsg (in den zirkularen Kernel-Protokollpuffer protokollieren), journal (in das Journal protokollieren), journal-or-kmsg (in das Journal protokollieren, falls verfugbar, 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. Standardmassig >>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 ausser Kraft. Falls weder $SYSTEMD_PAGER noch $PAGER gesetzt sind, wird eine Reihe wohlbekannter Implementierungen von Textanzeigeprogrammen der Reihe nach ausprobiert, einschliesslich 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 aquivalent zur Ubergabe von --no-pager. Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER (sowie $PAGER) ohne Ruckmeldung ignoriert. $SYSTEMD_LESS Setzt die an less ubergebenen Optionen (standardmassig >>FRSXMK<<) ausser Kraft. Benutzer konnten insbesondere zwei Optionen andern 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 zuruck. Falls der Wert von $SYSTEMD_LESS kein >>K<< enthalt 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 standardmassig gesetzt, damit die Darstellung von Befehlen selbst nach dem Beenden des Textanzeigeprogramms sichtbar bleibt. Allerdings stehen dadurch einige Funktionen des Textanzeigeprogramms nicht zur Verfugung; insbesondere ist das Scrollen in der Ausgabe mit der Maus nicht moglich. Beachten Sie, dass das Setzen der regularen Umgebungsvariablen $LESS keine Auswirkungen auf die Ausfuhrung von less(1) durch systemd(1)-Werkzeuge hat. Siehe less(1) fur weitere Ausfuhrungen. $SYSTEMD_LESSCHARSET Setzt den an less zu ubergebenden Zeichensatz (standardmassig >>utf-8<<, falls das aufrufende Terminal als UTF-8-kompatibel erkannt wurde) ausser Kraft. Beachten Sie, dass das Setzen der regularen Umgebungsvariablen $LESSCHARSET keine Auswirkungen auf die Ausfuhrungen von less(1) durch systemd(1)-Werkzeuge hat. $SYSTEMD_PAGERSECURE Akzeptiert einen logischen Wert. Wenn true, wird der >>sichere<< Modus des Textanzeigeprogramms verwandt, falls false, wird dieser deaktiviert. Falls $SYSTEMD_PAGERSECURE uberhaupt nicht gesetzt ist, dann wird der sichere Modus aktiviert, falls die effektive Kennung nicht identisch zu dem Eigentumer 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 offnen oder erstellen oder die einen neuen Unterprozess starten. Falls $SYSTEMD_PAGERSECURE uberhaupt 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 erhohten Rechten ausgefuhrt werden, beispielsweise mittels sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass keine ungeplanten interaktiven Funktionalitaten aktiviert werden. Der >>sichere<< Modus fur 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 ermoglicht, beliebige Befehle auszufuhren. Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen $SYSTEMD_PAGER oder $PAGER berucksichtigt werden sollen. Es kann sinnvoll sein, stattdessen das Textanzeigeprogramm komplett mit --no-pager zu deaktivieren. $SYSTEMD_COLORS Akzeptiert ein logisches Argument. Wenn true, werden systemd und verwandte Hilfswerkzeuge Farben in ihrer Ausgabe verwenden, andernfalls wird die Ausgabe einfarbig sein. Zusatzlich 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 beschranken. Dies kann festgelegt werden, um die auf $TERM und der vorliegenden Verbindung der Konsole basierende automatische Entscheidung ausser Kraft zu setzen. $SYSTEMD_URLIFY Dies muss ein logischer Wert sein. Er steuert, ob anklickbare Links fur Terminal-Emulatoren, die dies unterstutzen, erstellt werden sollen. Dies kann angegeben werden, um die Entscheidung, die systemd basierend auf $TERM und anderen Bedingungen trifft, ausser Kraft zu setzen. BEISPIELE Beispiel 1. Herunterladen eines Ubuntu-TAR-Abbildes und Offnen einer Shell darin # importctl pull-tar -mN https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64-root.tar.xz # systemd-nspawn -M jammy-server-cloudimg-amd64-root Dies ladt das angegebene .tar-Abbild herunter, verifiziert es und verwendet dann systemd-nspawn(1) zum Offnen einer Shell darin. Beispiel 2. Bauen und Starten einer minimalen Fedora-Distribution in einem Container # dnf -y --releasever=41 --installroot=/var/lib/machines/f41 \ --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/f41 Dies installiert eine minimale Fedora-Distribution in das Verzeichnis /var/lib/machines/f41 und startet dann dies Betriebssystem in einem Namensraum-Container. Da sich die Installation unterhalb des Standard-/var/lib/machines/-Verzeichnisses befindet, ist es moglich, die Maschine mittels systemd-nspawn -M f41 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 unterstutzt Debian[7], Ubuntu[8] und Tanglu[9] von Haus aus, daher kann der gleiche Befehl zur Installation von allen drei verwandt werden. Fur 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 fluchtigen Schnappschusses des Systems # systemd-nspawn -D / -xb Dies fuhrt eine Kopie des Systems in einem Schnappschuss aus, der sofort wieder entfernt wird, wenn sich der Container beendet. Alle zur Laufzeit erfolgten Dateianderungen gehen daher beim Herunterfahren verloren. Beispiel 7. Ausfuhren 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. Ausfuhren 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 ausgefuhrten Programms zuruckgeliefert. 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 fur 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. Uberlagerungsdateisystem https://docs.kernel.org/filesystems/overlayfs.html 6. ANSI-Maskier-Code (Wikipedia) https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters 7. 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 UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 257.3 SYSTEMD-NSPAWN(1)