- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
SYSTEMD-NSPAWN(1) | systemd-nspawn | SYSTEMD-NSPAWN(1) |
BEZEICHNUNG¶
systemd-nspawn - Erzeugt einen Befehl oder ein Betriebssystem in einem leichtgewichtigen Container
ÜBERSICHT¶
systemd-nspawn [OPTIONEN…] [BEFEHL [ARG…]]
systemd-nspawn --boot [OPTIONEN…] [ARG…]
BESCHREIBUNG¶
systemd-nspawn kann zur Ausführung eines Befehls oder Betriebssystems (OS) in einem leichtgewichtigen Namensraum-Container verwandt werden. In vielerlei Art ist es zu chroot(1) ähnlich, aber leistungsfähiger, da es die Dateisystemhierarchie sowie den Prozessbaum, die verschiedenen IPC-Untersysteme und den Rechner- und Domain-Namen komplett virtualisiert.
systemd-nspawn kann in jedem Verzeichnisbaum, der einen Betriebssystembaum enthält, mittels der Befehlszeilenoption --directory= aufgerufen werden. Durch Verwendung der Option --machine= wird der OS-Baum automatisch nach einer Reihe von Orten durchsucht, am wichtigsten dabei ist /var/lib/machines/, das bevorzugte Verzeichnis, um auf dem System installierte OS-Container-Abbilder abzulegen.
Im Gegensatz zu chroot(1) kann systemd-nspawn zum Starten kompletter, Linux-basierter Betriebssysteme in einem Container verwandt werden.
systemd-nspawn begrenzt den Zugriff auf verschiedene Kernelschnittstellen, wie /sys/, /proc/sys/ oder /sys/fs/selinux/, im Container auf nur-lesbar. Die Netzwerkschnittstelle des Wirts und die Systemuhr können aus dem Container heraus nicht geändert werden. Geräteknoten können nicht erstellt werden. Das Wirtssystem kann nicht neu gestartet werden und Kernelmodule dürfen von innerhalb des Containers nicht geladen werden.
Verwenden Sie Werkzeuge wie dnf(8), debootstrap(8) oder pacman(8), um eine geeignete OS-Verzeichnisbaumhierarchie für systemd-nspawn einzurichten. Lesen Sie den nachfolgenden Abschnitt »Beispiele« für geeignete Aufrufe dieser Befehle.
Als Sicherheitsprüfung wird systemd-nspawn die Existenz von /usr/lib/os-release oder /etc/os-release im Container-Baum überprüfen, bevor der Systemstart des Containers durchgeführt wird (siehe os-release(5)). Es könnte notwendig sein, diese Datei manuell zum Container-Baum hinzuzufügen, falls das OS des Containers zu alt ist, um diese Datei bereits mitgeliefert zu haben.
systemd-nspawn kann direkt von der interaktiven Befehlszeile aus oder als Systemdienst im Hintergrund aufgerufen werden. In diesem Modus betreibt jede Container-Instanz seine eigene Dienste-Instanz; eine Standard-Vorlagen-Unit-Datei systemd-nspawn@.service wird bereitgestellt, um dies leicht zu ermöglichen; sie akzeptiert den Container-Namen als Instanzen-Kennzeichner. Beachten Sie, dass andere Vorgabeoptionen gelten, wenn systemd-nspawn durch die Vorlagen-Unit-Datei als wenn es interaktiv auf der Befehlszeile aufgerufen wird. Der wichtigste Unterschied bei den Vorgaben ist, dass die Vorlagen-Unit-Datei die Option --boot verwendet, während dies beim Aufruf von systemd-nspawn auf der Befehlszeile nicht der Fall ist. Weitere Unterschiede in den Vorgaben sind zusammen mit den verschiedenen unterstützten Optionen weiter unten dokumentiert.
Das Werkzeug machinectl(1) kann zur Ausführung einer Reihe von Aktionen an Containern verwandt werden. Es stellt insbesondere leicht zu benutzende Befehle bereit, um Container als Systemdienste mittels der Vorlagen-Unit-Datei systemd-nspawn@.service auszuführen.
Neben jedem Container kann eine Einstellungsdatei mit der Endung .nspawn existieren, die zusätzliche, bei der Ausführung des Containers anzuwendende Einstellungen enthält. Siehe systemd.nspawn(5) für Details. Einstellungsdateien setzen die von der Vorlagen-Unit-Datei systemd-nspawn@.service verwandten Vorgabeoptionen außer Kraft, wodurch es im Allgemeinen unnötig wird, diese Vorlagendatei direkt zu ändern.
Beachten Sie, dass systemd-nspawn Dateisysteme privat für den Container nach /dev/, /run/ und ähnlichem einhängen wird. Diese werden außerhalb des Containers nicht sichtbar sein und ihre Inhalte gehen verloren, wenn sich der Container beendet.
Beachten Sie, dass die Ausführung von zwei systemd-nspawn-Containern aus dem gleichen Verzeichnis nicht dazu führt, dass sich die Prozesse in beiden gegenseitig sehen. Die PID-Namensraumtrennung der zwei Container ist vollständig und die Container nutzen sehr wenige Laufzeitobjekte gemeinsam, außer das unterliegende Dateisystem. Verwenden Sie eher die Befehle login oder shell von machinectl(1), um zusätzliche Anmeldesitzungen in einem laufenden Container zu erbitten.
systemd-nspawn implementiert die Spezifikation Container-Schnittstelle[1].
Während des Betriebs werden mittels systemd-nspawn aufgerufene Container mit dem Dienst systemd-machined(8) registriert. Dieser verfolgt die laufenden Container nach und stellt Programmierschnittstellen bereit, um mit ihnen zu interagieren.
OPTIONEN¶
Falls die Option -boot angegeben ist, werden die Argumente als Argumente für das Init-Programm verwandt. Andernfalls gibt BEFEHL das zu startende Programm in dem Container an und die verbleibenden Argumente werden als Argumente für dieses Programm benutzt. Falls --boot nicht verwandt wird und keine Argumente angegeben sind, wird eine Shell in dem Container gestartet.
Die folgenden Optionen werden verstanden:
-q, --quiet
--settings=MODUS
Falls aktiviert (die Vorgabe), wird eine Einstellungsdatei, die nach der Maschine (wie mit der Einstellung --machine= angegeben oder aus dem Verzeichnis oder Abbildnamen abgeleitet) mit der Endung.nspawn benannt ist, in /etc/systemd/nspawn/ und /run/systemd/nspawn/ gesucht. Falls sie dort gefunden wird, werden deren Einstellungen gelesen und verwandt. Falls sie dort nicht gefunden wird, wird sie nachfolgend in dem gleichen Verzeichnis wie die Abbilddatei oder in dem Verzeichnis direkt über dem Wurzelverzeichnis des Containers gesucht. Falls die Datei in diesem Fall gefunden wird, werden ihre Einstellungen auch gelesen und verwandt, aber möglicherweise unsichere Einstellungen werden ignoriert. Beachten Sie, dass in beiden Fällen die Einstellungen auf der Befehlszeile Vorrang gegenüber den entsprechenden Einstellungen aus geladenen .nspawn-Dateien haben, falls beide angegeben sind. Alle Einstellungen, die die Privilegien des Containers erhöhen oder Zugriff auf zusätzliche Ressourcen wie Dateien oder Verzeichnissen auf der Wirtsmaschine geben können, werden als unsichere Einstellungen betrachtet. Für Details über das Format und die Inhalte von .nspawn-Dateien lesen Sie bitte systemd.nspawn(5).
Falls diese Option auf override gesetzt ist, wird die Datei durchsucht, gelesen und auf die gleiche Art verwandt, allerdings ist die Vorrangreihenfolge umgedreht: Einstellungen aus den .nspawn-Dateien haben Vorrang vor den entsprechenden Einstellungen der Befehlszeilenoptionen, falls beide angegeben sind.
Falls diese Option auf trusted gesetzt ist, wird die Datei durchsucht, gelesen und auf die gleiche Art verwandt, unabhängig davon, wo sie in /etc/systemd/nspawn/, /run/systemd/nspawn/ oder neben der Abbild-Datei oder dem Wurzelverzeichnis des Containers gefunden wurde, alle Einstellungen werden wirksam, allerdings haben Befehlszeilenoptionen weiterhin Vorrang vor den entsprechenden Einstellungen.
Falls deaktiviert, werden keine .nspawn-Dateien gelesen und keine Einstellungen außer denen auf der Befehlszeile werden wirksam.
Abbild-Optionen¶
-D, --directory=
Falls weder --directory= noch --image= angegeben sind, wird das Verzeichnis ermittelt, indem nach einem Verzeichnis, dessen Namen mit einem mittels --machine= übergebenen Maschinennamen übereinstimmt, gesucht wird. Siehe den Abschnitt »Dateien und Verzeichnisse« in machinectl(1) für den genauen Suchpfad.
Falls weder --directory=, --image= noch --machine= angegeben sind, wird das aktuelle Verzeichnis verwandt. Darf nicht zusammen mit --image= angegeben werden.
--template=
Beachten Sie, dass dieser Schalter den Rechnernamen, die Maschinenkennung und alle anderen Einstellungen, die die Instanz identifizieren könnten, unverändert lässt.
-x, --ephemeral
Beachten Sie, dass dieser Schalter den Rechnernamen, die Maschinenkennung und alle anderen Einstellungen, die die Instanz identifizieren könnten, unverändert lässt. Beachten Sie, dass wie bei --template= das Vornehmen eines temporären Schnappschusses auf Dateisystemen, die Teildatenträger oder nativ »reflinks« unterstützen (»btrfs« oder neues »xfs«), effizienter als auf traditionelleren Dateisystemen, die das nicht tun (»ext4«), ist. Beachten Sie, dass der aufgenommene Schnappschuss das gesamte angegebene Verzeichnis oder Teildatenträger umfasst, einschließlich aller Unterverzeichnisse und Teildatenträger darunter, aber ausschließlich aller Untereinhängungen.
Mit dieser Option werden keine Änderungen am Container-Abbild erhalten. Verwenden Sie (das nachfolgend beschriebene) --volatile= als weiteren Mechanismus, um die Dauerhaftigkeit von Container-Abbildern zur Laufzeit zu begrenzen.
-i, --image=
Falls eine EFI-Systempartition (ESP) auf GPT-Abbildern entdeckt wird, wird diese automatisch nach /efi (oder /boot als Rückfall) eingehängt, falls ein Verzeichnis dieses Namens existiert und leer ist.
Mit LUKS verschlüsselte Partitionen werden automatisch entschlüsselt. Auf GPT-Abbildern prüft dm-verity auch, ob die Datenintegritäts-Hash-Partitionen eingerichtet sind, falls der Wurzel-Hash für sie mit der Option --root-hash= angegeben wurde.
Einzelne Dateisystemabbilder (d.h. Dateisysteme ohne eine umgebende Partitionstabelle) können mittels Dm-verity geöffnet werden, falls die Integritätsdaten mittels der Optionen --root-hash= und --verity-data= (und optional --root-hash-sig=) übergeben werden.
Alle anderen Partitionen, wie fremde Partitionen oder Auslagerungspartitionen, werden nicht eingehängt. Darf nicht zusammen mit --directory=, --template= angegeben werden.
--oci-bundle=
--read-only
--volatile, --volatile=MODUS
Beachten Sie, dass bei der Auswahl einer der flüchtigen Modi die Auswirkung auf das Wurzeldateisystem (oder im Falle von state /var/) begrenzt wird und jede andere, in der Hierarchie angeordnete Einhängung davon unbetroffen ist, unabhängig davon, ob sie automatisch (z.B. die EFI-Systempartition, die nach /efi/ oder /boot/ eingehängt sein könnte) oder explizit (z..B. durch eine zusätzliche Befehlszeilenoption wie --bind=, siehe unten) etabliert wurden. Dies bedeutet, dass Änderungen an /efi/ oder /boot/ verboten sind, selbst falls --volatile=overlay verwandt wurde und eine solche Partition im betroffenen Container-Abbild existiert und selbst falls --volatile=state verwandt wird, wird eine hypothetische Datei /etc/foobar möglicherweise schreibbar, falls --bind=/etc/foobar zum Einhängen von außerhalb des nur lesbaren Container-/etc/-Verzeichnisses verwnadt wird.
Die Option --ephemeral hat einen engen Bezug zu dieser Einstellung und stellt ähnliches Verhalten bereit, bei dem eine temporäre und vergängliche Kopie des gesamten Betriebssystemabbildes erfolgt und diese dann ausgeführt wird. Weitere Details finden Sie weiter oben.
Die Option --tmpfs= und --overlay= stellen ähnliche Funktionalität bereit, allerdings nur für bestimmte Unterverzeichnisse des Betriebssystemabbildes. Details finden Sie nachfolgend.
Diese Option stellt ähnliche Funktionalität für Container bereit, wie der Befehlszeilenschalter »systemd.volatile=« dies für Rechner selbst darstellt. Siehe kernel-command-line(7) für Details.
Beachten Sie, dass das Setzen dieser Option auf yes oder state nur funktioniert, falls das Betriebssystem des Containers einen Systemstart mit ausschließlich eingehängtem /usr/ durchführen und dann selbständig /var/ bevölkern (und im Falle von »--volatile=yes« auch /etc/) kann. Dies bedeutet insbesondere, dass Betriebssysteme, die der historischen Aufteilung von /bin/ und /lib/ (und zugehörigen Verzeichnissen) von /usr/ folgen (d.h. bei denen Erstere keine Symlinks in Letztere sind), bei »--volatile=yes« nicht als Container-Inhalt unterstützt werden. Die Option overlay verlangt keine besonderen Vorbereitungen von dem Betriebssystem, aber beachten Sie, dass sich das Verhalten von »overlayfs« von dem regulärer Dateisysteme in einer Reihe von Punkten unterscheidet und somit die Kompatibilität eingeschränkt ist.
--root-hash=
Beachten Sie, dass dies den Wurzel-Hash für das Wurzeldateisystem konfiguriert. Plattenabbilder können auch separate Dateiystem für die /usr/-Hierarchie enthalten, die auch Verity-geschützt sein kann. Der Wurzel-Hash für diesen Schutz kann mit dem erweiterten Dateiattribut »user.verity.usrhash« oder mittels einer .usrhash-Datei neben dem Plattenabbild konfiguriert werden. Dies folgt dem gleichen Format und der gleichen Logik wie für den hier beschriebenen Wurzel-Hash für das Wurzeldateisystem. Beachten Sie, dass es derzeit keinen Schalter gibt, um den Wurzel-Hash für /usr/ von der Befehlszeile aus zu konfigurieren.
Siehe auch die Option RootHash= in systemd.exec(5).
--root-hash-sig=
--verity-data=
--pivot-root=
Dies ist für Container, die mehrere startfähige Verzeichnisse enthalten, beispielweise mehrere OSTree[4]-Einsätze. Sie emuliert das Verhalten eines Systemstartprogrammes und einer Initrd, die normalerweise auswählt, welches Verzeichnis als Wurzel eingehängt und darin PID 1 des Containers gestartet wird.
Ausführungsoptionen¶
-a, --as-pid2
-b, --boot
Die nachfolgende Tabelle erklärt die verschiedenen Aufrufmodi und die Beziehung zu --as-pid2 (siehe oben):
Tabelle 1. Aufrufmodus
Schalter | Erklärung |
Weder --as-pid2 noch --boot angegeben | Die übergebenen Parameter werden als Befehlszeile interpretiert, die als PID 1 im Container ausgeführt wird. |
--as-pid2 angegeben | Die übergebenen Parameter werden als Befehlszeile interpretiert, die als PID 2 im Container ausgeführt wird. Ein minimaler Init-Prozess wird als PID 1 ausgeführt. |
--boot angegeben | Im Container wird automatisch nach einem Init-Programm gesucht und dieses als PID 1 ausgeführt. Die übergebenen Parameter werden als Aufrufparameter für diesen Prozess verwandt. |
Beachten Sie, dass --boot der Standardaktionsmodus ist, falls die Vorlagen-Unit-Datei systemd-nspawn@.service verwandt wird.
--chdir=
-E NAME[=WERT], --setenv=NAME[=WERT]
-u, --user=
--kill-signal=
--notify-ready=
--suppress-sync=
Systemidentitätsoptionen¶
-M, --machine=
--hostname=
--uuid=
Eigenschaftsoptionen¶
-S, --slice=
--property=
--register=
--keep-unit
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.
Benutzernamensraum-Optionen¶
--private-users=
Es wird empfohlen, jedem Container mindestens 65536 UIDs/GIDs zuzuweisen, so dass der verwendbare Bereich an UIDs/GIDs im Container 16 Bit überdeckt. Für größtmögliche Sicherheit sollten sich die UID/GID-Bereiche je zweier Container nicht überlappen. Daher ist es eine gute Idee, die oberen 16 Bit der 32-Bit-UIDs/GIDs des Rechners als Container-Kennzeichner und die unteren 16-Bit zur Kodierung der im Container verwandten UID/GIDs zu verwenden. Dies ist tatsächlich das Verhalten, das die Option --private-users=pick erzwingt.
Werden Benutzernamensräume verwandt, wird der jedem Container zugewiesene GID-Bereich immer identisch zu dem UID-Bereich ausgewählt.
In den meisten Fällen ist --private-users=pick die empfohlene Option, da sie die Container-Sicherheit massiv erhöht und in den meisten Fällen vollautomatisch funktioniert.
Beachten Sie, dass der ausgewählte UID/GID-Bereich nicht in /etc/passwd oder /etc/group geschrieben wird. Tatsächlich wird die Zuweisung des Bereiches nicht irgendwo dauerhaft gespeichert, außer in den Dateieigentümerschaften der Dateien und Verzeichnisse des Containers.
Beachten Sie, dass sich dies bei der Verwendung von Benutzernamensräumen in den Dateieigentümerschaften auf der Platte widerspiegelt und alle Dateien und Verzeichnisse des Containers den effektiven Benutzer- und Gruppenkennungen des Containers gehören. Dies bedeutet, dass das Kopieren von Dateien in und aus dem Container heraus die Anpassung der numerischen UID/GID-Werte verlangt, je nach angewandter UID/GID-Verschiebung.
--private-users-ownership=
Passt, falls »chown« ausgewählt ist, alle Dateien und Verzeichnisse im Verzeichnisbaum des Containers an, so dass sie den passenden, für den Container ausgewählten UIDs/GIDs gehören (siehe oben). Diese Aktion ist möglicherweise aufwändig, da sie den vollen Durchlauf durch den Verzeichnisbaum des Containers verlangt. Neben der eigentlichen Dateieigentümerschaft werden auch ACLs angepasst.
Normalerweise ist »map« die beste Wahl, da es transparent die UIDs/GIDs im Speicher wie notwendig ohne Veränderung des Abbilds abbildet und auch keine teure rekursive Anpassungsaktion benötigt. Allerdings ist sie derzeit nicht für alle Dateisysteme verfügbar.
Die Option --private-users-ownership=auto wird impliziert, falls --private-users=pick verwandt wird. Diese Option hat nur eine Auswirkung, falls Benutzernamensräume verwandt werden.
-U
Beachten Sie, dass -U die Vorgabe ist, falls die Vorlagendatei systemd-nspawn@.service verwandt wird.
Hinweis: Das Ergebnis von --private-users-ownership=chown (oder -U) auf das Dateisystem kann rückgängig gemacht werden, indem die Aktion mit der ersten UID 0 erneut durchgeführt wird:
systemd-nspawn … --private-users=0 --private-users-ownership=chown
Vernetzungsoptionen¶
--private-network
--network-interface=
Beachten Sie, dass alle auf diese Art festgelegten Schnittstellen zum Zeitpunkt des Startens des Containers bereits existieren müssen. Falls der Container automatisch beim Systemstart mittels der Unit-Dateiinstanz systemd-nspawn@.service gestartet werden soll, kann es daher sinnvoll sein, eine Unit-Dateiergänzung für die Diensteinstanz hinzuzufügen (z.B. /etc/systemd/system/systemd-nspawn@foobar.service.d/50-network.conf), die Inhalte folgender Art enthält:
[Unit] Wants=sys-subsystem-net-devices-ens1.device After=sys-subsystem-net-devices-ens1.device
Dies stellt sicher, dass die Aktivierung des Container-Dienstes verzögert wird, bis die Netzwerkschnittstelle »ens1« aufgetaucht ist. Dies ist notwendig, da Hardwareermittlung vollständig asynchron erfolgt und Netzwerkschnittstellen erst später während des Systemstartprozesses erkannt werden könnten, nachdem der Container normalerweise ohne diese expliziten Abhängigkeiten gestartet worden wäre.
--network-macvlan=
Wie bei --network-interface= muss die zugrundeliegende Ethernet-Netzwerkschnittstelle zum Zeitpunkt des Startens des Containers bereits existieren und daher könnten ähnliche Unit-Dateiergänzungen wie oben beschrieben nützlich sein.
--network-ipvlan=
Wie bei --network-interface= muss die zugrundeliegende Ethernet-Netzwerkschnittstelle zum Zeitpunkt des Startens des Containers bereits existieren und daher könnten ähnliche Unit-Dateiergänzungen wie oben beschrieben nützlich sein.
-n, --network-veth
Beachten Sie, dass systemd-networkd.service(8) eine Vorgabe-Netzwerkdatei /lib/systemd/network/80-container-ve.network enthält, die auf die auf diese Art erstellte Schnittstelle im Rechner passt und die Einstellungen enthält, um die automatische Adressbereitstellung auf der erstellten virtuellen Verbindung mittels DHCP sowie das automatische IP-Routen auf der externen Netzwerkschnittstelle des Rechners aktiviert. Sie enthält auch /lib/systemd/network/80-container-host0.network, die auf die auf diese Art erstellte Schnittstelle im Container passt und die Einstellung zur Aktivierung der Adresszuweisung mittels DHCP für den Client enthält. Wenn Systemd-networkd sowohl im Rechner als auch im Container läuft, ist daher automatische IP-Kommunikation vom Container zum Rechner verfügbar, mit weiterer Verbindung zum externen Netz.
Beachten Sie, dass --network-veth die Vorgabe ist, falls die Vorlagen-Unit-Datei systemd-nspawn@.service verwandt wird.
Beachten Sie, dass Netzwerkschnittstellennamen unter Linux eine maximale Länge von 15 Zeichen haben dürfen, während Container-Namen 64 Zeichen lang sein dürfen. Da diese Option den Schnittstellennamen auf der Rechnerseite vom Container-Namen ableitet, ist der Name möglicherweise abgeschnitten. Daher muss in diesem Falle aufgepasst werden, dass die Schnittstellennamen eindeutig bleiben; besser noch, Container-Namen sollten im Allgemeinen so ausgewählt werden, dass sie nicht länger als 12 Zeichen sind, um das Abschneiden zu vermeiden. Falls der Name abgeschnitten ist, wird systemd-nspawn automatisch einen 4-ziffrigen Hash-Wert an den Namen anhängen, um die Möglichkeit von Kollisionen zu verringern. Allerdings ist der Hash-Algorithmus nicht kollisionsfrei. (Siehe systemd.net-naming-scheme(7) für Details über ältere Benennungsalgorithmen für diese Schnittstelle). Alternativ kann die Option --network-veth-extra= verwandt werden. Sie erlaubt die freie Konfiguration des Schnittstellennamens auf der Rechnerseite unabhängig vom Container-Namen — könnte aber ein bisschen mehr an Konfiguration benötigen, falls Bridging im Stile von --network-bridge= erwünscht ist.
--network-veth-extra=
--network-bridge=
Wie bei --network-interface= muss die zugrundeliegende Bridge-Netzwerkschnittstelle zum Zeitpunkt des Startens des Containers bereits existieren und daher könnten ähnliche Unit-Dateiergänzungen wie oben beschrieben nützlich sein.
--network-zone=
Diese Einstellung macht es leicht, mehrere zusammengehörige Container in eine gemeinsame, virtuelle, Ethernet-basierte Broadcast-Domäne zu legen, die hier »Zone« genannt wird. Jeder Container darf nur Teil einer Zone sein, aber jede Zone kann eine beliebige Anzahl an Containern enthalten. Auf jede Zone kann mit ihrem Namen Bezug genommen werden. Namen können frei ausgewählt werden (solange sie einen gültigen Netzwerkschnittstellenamen bilden, denen »vz-« vorangestellt ist) und es reicht aus, den gleichen Namen an den Schalter --network-zone= für die verschiedenen, gleichzeitig laufenden Container zu übergeben, um sie in eine Zone aufzunehmen.
Beachten Sie, dass systemd-networkd.service(8) standardmäßig eine Netzwerkdatei /lib/systemd/network/80-container-vz.network enthält, die auf die auf diese Art erstellte Bridge-Schnittstelle passt und die Einstellungen enthält, die die automatische Bereitstellung von Adressen mittels DHCP im erstellten virtuellen Netzwerk sowie das automatische IP-Routen auf den externen Netzwerkschnittstellen des Rechners aktivieren. Die Verwendung von --network-zone= ist daher in den meisten Fällen vollautomatisch und ausreichend, um mehrere lokale Container in einer vereinigten Broadcast-Domain mit dem Rechner zu verbinden, einschließlich weiterer Verbindung zum externen Netzwerk.
--network-namespace-path=
-p, --port=
Sicherheitsoptionen¶
--capability=
Falls der besondere Wert »help« übergeben wird, wird das Programm die bekannten Capability-Namen ausgeben und sich beenden.
Diese Option setzt die Begrenzungsmenge der Capabilities, die auch die Umgebungs-Capabilities, wie sie mit --ambient-capability= übergeben werden, begrenzt.
--drop-capability=
Falls der besondere Wert »help« übergeben wird, wird das Programm die bekannten Capability-Namen ausgeben und sich beenden.
Diese Option setzt die Begrenzungsmenge der Capabilities, die auch die Umgebungs-Capabilities, wie sie mit --ambient-capability= übergeben werden, begrenzt.
--ambient-capability=
Alle hier angegebenen Capabilities müssen in der mit den Optionen --capability= und --drop-capability= erlaubten Menge sein. Andernfalls wird eine Fehlermeldung angezeigt.
Diese Option kann nicht mit dem Systemstartmodus des Containers (wie mit --boot erbeten) kombiniert werden.
Falls der besondere Wert »help« übergeben wird, wird das Programm die bekannten Capability-Namen ausgeben und sich beenden.
--no-new-privileges=
--system-call-filter=
-Z, --selinux-context=
-L, --selinux-apifs-context=
Ressourcenoptionen¶
--rlimit=
--oom-score-adjust=
--cpu-affinity=
--personality=
Integrationsoptionen¶
--resolv-conf=
Falls auf »off« gesetzt, dann wird die Datei /etc/resolv.conf im Container so belassen, wie sie im Abbild enthalten ist und weder verändert noch eine Bind-Einhängung darüber durchgeführt.
Falls auf »copy-host« gesetzt, wird die Datei /etc/resolv.conf vom Rechner in den Container kopiert, außer die Datei existiert bereits und ist keine reguläre Datei (z.B. ein Symlink). Ähnlich wird beim Einsatz von »replace-host« die Datei kopiert und jede existierende Inode ersetzt, einschließlich Symlinks. Ähnlich wird beim Einsatz von »bind-host« die Datei vom Rechner in den Container Bind-eingehängt.
Falls auf »copy-static«, »replace-static« oder »bind-static« gesetzt, wird die durch systemd-resolved.service(8) bereitgestellte statische resolv.conf-Datei (konkret: /usr/lib/systemd/resolv.conf) in den Container kopiert oder Bind-eingehängt.
Falls auf »copy-uplink«, »replace-uplink« oder »bind-uplink« gesetzt, wird die durch Systemd-resolved.service verwaltete Uplink-resolv.conf-Datei (konkret: /run/systemd/resolve/resolv.conf) in den Container kopiert oder Bind-eingehängt.
Falls auf »copy-stub«, »replace-stub« oder »bind-stub« gesetzt, wird die durch Systemd-resolved.service verwaltete Rumpf-resolv.conf-Datei (konkret: /run/systemd/resolve/stub-resolv.conf) in den Container kopiert oder Bind-eingehängt.
Falls auf »delete« gesetzt, wird die Datei /etc/resolv.conf gelöscht, falls sie existiert.
Falls schließlich auf »auto« gesetzt, wird die Datei so belassen, wie sie ist, falls privates Netzwerken aktiviert ist (siehe --private-network). Falls andernfalls Systemd-resolved.service läuft, wird dessen Rumpf-resolv.conf-Datei verwandt und falls nicht, die Datei /etc/resolv.conf des Rechners. In letzterem Fall wird die Datei kopiert, falls das Abbild beschreibbar ist und andernfalls Bind-eingehängt.
Es wird empfohlen, »copy-…« oder »replace-…« zu verwenden, falls der Container in der Lage sein soll, selbst an seiner DNS-Einstellung Änderungen vorzunehmen, die sich von denen des Rechners unterscheiden. Andernfalls ist »bind« zu bevorzugen, da dies bedeutet, dass direkte Änderungen an /etc/resolv.conf im Container nicht erlaubt sind, da es eine schreibgeschützte Bind-Einhängung ist (beachten Sie aber, dass der Container einfach die Bind-Einhängung aushängen könnte, falls er über genug Privilegien verfügt). Beachten Sie, dass in beiden Fällen (Bind-Einhängen und Kopieren der Datei) im Allgemeinen keine weitere Weitergabe der Konfiguration nach dieser einmaligen Initialisierung erfolgt (dies kommt daher, da die Datei normalerweise durch Kopieren und Umbenennen aktualisiert wird). Standardmäßig »auto«.
--timezone=
--link-journal=
Beachten Sie, dass --link-journal=try-guest die Vorgabe ist, falls die Unit-Vorlagendatei systemd-nspawn@.service verwandt wird.
-j
Einhängeoptionen¶
--bind=, --bind-ro=
Einhängeoptionen werden durch Kommata getrennt. rbind und norbind steuern, ob eine rekursive oder eine reguläre Bind-Einhängung erstellt wird. Standardmäßig »rbind«.
Die Verwendung von idmap oder rootidmap benötigt Unterstützung durch das Quelldateisystem für die Benutzer-/Gruppen-Abbildungs-Einhängungen. Standardmäßig »noidmap«. Ist x der UID-Bereichsversatz des Containers, y die Länge des UID-Bereichs des Containers und p die Eigentümer-UID der Bind-Einhängungs-Inode auf dem Rechner:
Unabhängig von der gewählten Kennungs-Abbildungsfunktion wird die gleiche Abbildung für Benutzer und Gruppen verwandt. Falls rootidmap verwandt wird, hat die Gruppe, der das Bind-Einhängungsverzeichnis gehört, keine Auswirkung.
Beachten Sie, dass die entstehenden Einhängepunkte dem Benutzer nobody gehören werden, falls dies in Kombination mit --private-users verwandt wird. Dies ist der Fall, da die Einhängung und deren Dateien und Verzeichnisse weiterhin dem relevanten Benutzer und der relevanten Gruppe des Rechners gehören, die im Container nicht existieren, und daher unter der Joker-UID 65534 (nobody) erscheinen. Falls solche bind-Einhängungen erstellt werden, wird empfohlen, diese mit --bind-ro= nur-lesbar zu machen. Alternativ können Sie die Einhängeoption »idmap« verwenden, um die Dateisystemkennungen abzubilden.
--bind-user=
Die Kombination der obigen drei Aktionen stellt sicher, dass es möglich ist, sich an dem Container mit den gleichen Konto-Informationen wie auf dem Rechner anzumelden. Der Benutzer wird nur flüchtig während der Container betrieben wird abgebildet und die Abbildung selbst führt nicht zu dauerhaften Änderungen im Container (außer vielleicht für erstellte Protokollmeldungen zum Anmeldezeitpunkt und ähnlichem). Beachten Sie, dass insbesondere die UID/GID-Zuweisung im Container nicht dauerhaft erfolgt. Falls der Benutzer flüchtig abgebildet wird, ist es am besten, dem Benutzer keine Änderungen an dem Container zu erlauben. Falls der Benutzer Dateien oder Verzeichnisse, die ihm gehören, in dem Container zurücklässt und diese UIDs/GIDs während späterer Container-Aufrufe erneut verwandt werden (möglicherweise mit einer anderen --bind-user=-Abbildung), dann kann der »neu« Benutzer nicht auf diese Dateien und Verzeichnisse zugreifen.
Die Benutzer-/Gruppen-Datensatz-Zuordnung funktioniert nur, falls der Container Systemd 249 oder neuer enthält und nss-systemd korrekt in nsswitch.conf konfiguriert ist. Siehe nss-systemd(8) für Details.
Beachten Sie, dass der vom Rechner in den Container ausgebreitete Benutzerdatensatz den UNIX-Passwort-Hash des Benutzers enthalten wird, so dass nahtlose Anmeldungen in dem Container möglich sind. Falls dem Container weniger als dem Rechner vertraut wird, ist es daher wichtig, eine starke UNIX-Passwort-Hash-Funktion zu verwenden (z.B. yescrypt oder ähnlich, mit dem Hash vorangestelltem »$y$«).
Beim Anbinden eines Benutzers vom Rechner in den Container werden Überprüfungen ausgeführt, um sicherzustellen, dass der Benutzername im Container noch nicht bekannt ist. Desweiteren wird überprüft, dass die zugewiesenen UID/GID derzeit in der Benutzer-/Gruppendatenbank des Containers nicht definiert ist. Beide Überprüfungen greifen direkt auf die /etc/passwd und /etc/group im Container zu und könnten daher bestehende Konten in anderen Datenbanken nicht erkennen.
Diese Aktion wird nur in Kombination mit --private-users=/-U unterstützt.
--inaccessible=
--tmpfs=
Beachten Sie, dass diese Option nicht zur Ersetzung des Wurzeldateisystems des Containers durch ein temporäres Dateisystem verwandt werden kann. Die nachfolgend beschriebene Option --volatile= stellt allerdings eine ähnliche Funktionalität bereit, wobei der Fokus auf zustandslosen Betriebssystemabbildern liegt.
--overlay=, --overlay-ro=
Maskierungen durch Rückwärtsschrägstriche werden im Pfad interpretiert; so kann »\:« verwandt werden, um Doppelpunkte in Pfade einzubetten.
Falls drei oder mehr Pfade angegeben werden, dann ist der letzte angegebene Pfad der Zieleinhängepunkt im Container; alle vorher angegebenen Pfade beziehen sich auf Verzeichnisbäume im Rechner und werden in der angegebenen Reihenfolge in das Überlagerungsdateisystem kombiniert. Der am weitesten links stehende Pfad ist daher der niedrigste Verzeichnisbaum, der vorletzte Pfad der höchste Verzeichnisbaum in der Stapelreihenfolge. Falls --overlay-ro= anstelle von --overlay= verwandt wird, dann wird ein nur-lesbares Überlagerungsdateisystem erstellt. Falls ein schreibbares Überlagerungsdateisystem erstellt wird, werden alle an ihm vorgenommenen Änderungen zum höchsten Verzeichnisbaum in der Stapelreihenfolge geschrieben, d.h. im vorletzten angegebenen.
Falls nur zwei Pfade angegeben werden, dann wird der zweite angegebene Pfad sowohl als oberstes Verzeichnis in der Stapelreihenfolge (wie vom Rechner gesehen) betrachtet, sowie auch als Einhängepunkt für das Überlagerungsdateisystem im Container. Es müssen mindestens zwei Pfade angegeben werden.
Den Quellpfaden darf optional das Zeichen »+« vorangestellt werden. In diesem Falle werden die Pfade relativ zum Wurzelverzeichnis des Abbildes behandelt. Der oberste Quellpfad kann auch als eine leere Zeichenkette angegeben werden, dann wird ein temporäres Verzeichnis unterhalb von /var/tmp/ auf dem Rechner verwandt. Das Verzeichnis wird automatisch entfernt, wenn der Container heruntergefahren wird. Dieses Verhalten ist nützlich, um nur-lesbare Container-Verzeichnisse schreibbar zu machen, während der Container läuft. Verwenden Sie beispielweise »--overlay=+/var::/var«, um automatisch ein temporäres schreibbares Verzeichnis über ein nur-lesbares /var/-Verzeichnis zu legen. Falls ein Quellpfad nicht absolut ist, wird er relativ zum aktuellen Arbeitsverzeichnis aufgelöst.
Für Details zu Überlagerungsdateisystemen, siehe Überlagerungsdateisystem[5]. Beachten Sie, dass sich die Semantiken eines Überlagerungsdateisystems deutlich von denen normaler Dateisysteme unterscheiden, insbesondere im Hinblick auf die gemeldeten Geräte- und Inode-Informationen. Geräte- und Inode-Informationen einer Datei können sich während des Hineinschreibens ändern und zeitweilig könnten Prozesse veraltete Versionen von Dateien sehen. Beachten Sie, dass dieser Schalter automatisch die Einhängeoption »workdir=« für das Überlagerungsdateisystem vom obersten Verzeichnisbaum ableitet und damit zum Geschwisterverzeichnis wird. Es ist damit wesentlich, dass das Verzeichnis oberster Ebene selbst kein Einhängepunkt ist (da das Arbeitsverzeichnis auf dem gleichen Dateisystem wie der oberste Verzeichnisbaum sein muss). Beachten Sie auch, dass die Einhängeoption »lowerdir=« die zu stapelnden Pfade in der umgekehrten Reihenfolge wie bei diesem Schalter erhält.
Beachten Sie, dass diese Option nicht zur Ersetzung des Wurzeldateisystems eines Containers durch ein Überlagerungsdateisystem verwandt werden kann. Allerdings stellt die oben beschriebene Option --volatile= eine ähnliche Funktionalität bereit, wobei der Fokus auf zustandslosen Betriebssystemabbildern liegt.
Ein-/Ausgabeoptionen¶
--console=MODUS
Im Modus pipe existiert /dev/console im Container nicht. Das bedeutet, dass der Container-Inhalt im Allgemeinen kein vollständiges Init-System sein kann, da Init-Systeme dazu neigen, /dev/console zu benötigen. Auf der anderen Seite können in diesem Modus Container-Aufrufe innerhalb von Shell-Weiterleitungen verwandt werden. Dies liegt daran, dass zwischengeschaltete Pseudo-TTYs keine unabhängige, bidirektionale Weiterleitung der Dateiendebedingung (EOF) erlauben, was allerdings für den korrekten Betrieb von Shell-Weiterleitungen benötigt wird. Beachten Sie, dass der Modus pipe vorsichtig verwandt werden sollte, da die Übergabe beliebiger Dateideskriptoren an weniger vertrauenswürdige Container-Inhalte unerwünschte Schnittstellen für Zugriffe des Container-Inhaltes öffnen könnten. Falls sich ein übergebener Dateideskriptor beispielsweise auf ein TTY in irgendeiner Weise bezieht, können APIs wie TIOCSTI dazu verwandt werden, Eingaben künstlich zu erzeugen, die zum Ausbruch aus dem Container verwandt werden können. Daher sollte der Modus pipe nur verwandt werden, wenn dem Inhalt hinreichend vertraut wird oder wenn die Dateideskriptoren der Standardeingabe, -ausgabe und Fehlerausgabe bekanntermaßen sicher sind, zum Beispiel Pipes.
--pipe, -P
Zugangsdaten¶
--load-credential=KENNUNG:PFAD, --set-credential=KENNUNG:WERTE
Beachten Sie: Wenn systemd-nspawn als Systemd-Systemdienst ausgeführt wird, kann es die mittels LoadCredential=/SetCredential= empfangenen Zugangsdaten an den Nutzinhalt des Containers weiterleiten. Ein Systemd-Diensteverwalter, der als PID 1 im Container ausgeführt wird, kann sie noch weiter zu den Diensten, die er selber startet, weiterleiten. Es ist daher möglich, Zugangsdaten leicht vom übergeordneten Diensteverwalter zu einem Container-Verwalterdienst und von dort in seine Nutzlast weiterzuleiten. Das kann sogar rekursiv erfolgen.
Um Binärdaten in die Zugangsdaten für --set-credential= einzubetten, verwenden Sie C-artige Maskierung (d.h. »\n«, um einen Zeilenumbruch einzubetten oder »\x00«, um ein Nullbyte (NUL) einzubetten. Beachten Sie, dass die aufrufende Shell die Maskierung bereits einmal entfernt haben könnte, daher könnte dieses doppelte Maskierung benötigen!).
Die Dienste systemd-sysusers.service(8) und systemd-firstboot(1) lesen die auf diese Art konfigurierten Anmeldedaten zum Zweck der Konfiguration des Passworts und der Shell des Benutzers root des Containers, sowie der Locale, der Tastaturzuordnung und der Zeitzone des Systems während des ersten Systemstartprozesses des Containers. Dies ist insbesondere in Kombination mit --volatile=yes nützlich, wo jeder einzelne Systemstart wie der erste Systemstart aussieht, da die in /etc/ angewandte Konfiguration verloren geht, wenn der Container einen Neustart durchführt. Siehe die entsprechenden Handbuchseiten für Details. Beispiel:
# systemd-nspawn -i image.raw \
--volatile=yes \
--set-credential=firstboot.locale:de_DE.UTF-8 \
--set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' \
-b
Der obige Befehl wird die angegebene Abbilddatei image.raw im flüchtigen Modus aufrufen, d.h. mit leerem /etc/ und /var/. Die Nutzlast des Containers wird dies als ersten Systemstart erkennen und den Dienst systemd-firstboot.service startet, der dann die zwei übergebenen Anmeldedaten einliest, um die anfängliche Locale und das Passwort von Root des Systems zu konfigurieren.
Weitere¶
--no-pager
-h, --help
--version
UMGEBUNGSVARIABLEN¶
$SYSTEMD_LOG_LEVEL
$SYSTEMD_LOG_COLOR
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbständig Nachrichten gemäß ihrer Protokollierungsstufe einfärben.
$SYSTEMD_LOG_TIME
Diese Einstellung ist nur nützlich, falls die Nachrichten direkt auf das Terminal oder in eine Datei geschrieben werden, da journalctl(1) und andere Werkzeuge, die Protokolle anzeigen, selbständig Zeitstempel basierend auf ihren Metadaten den Nachrichten anhängen werden.
$SYSTEMD_LOG_LOCATION
Beachten Sie, dass der Protokollierort sowieso oft als Metadaten zu den Journal-Einträgen angehängt ist. Die Aufnahme in den Nachrichtentext kann bei der Fehlersuche in Programmen dennoch praktisch sein.
$SYSTEMD_LOG_TID
Beachten Sie, dass diese Informationen sowieso als Metadatan an Journal-Einträge angehängt wird. Die Aufnahme direkt im Nachrichtentext kann aber trotzdem bei der Fehlersuche in Programmen praktisch sein.
$SYSTEMD_LOG_TARGET
$SYSTEMD_PAGER
Beachten Sie: Falls $SYSTEMD_PAGERSECURE nicht gesetzt ist, dann wird $SYSTEMD_PAGER (sowie $PAGER) ohne Rückmeldung ignoriert.
$SYSTEMD_LESS
Benutzer könnten insbesondere zwei Optionen ändern wollen:
K
Falls der Wert von $SYSTEMD_LESS kein »K« enthält und less das aufgerufene Textanzeigeprogramm ist, wird Strg+C durch das Programm ignoriert und muss durch das Textanzeigeprogramm selbst gehandhabt werden.
X
Siehe less(1) für weitere Ausführungen.
$SYSTEMD_LESSCHARSET
$SYSTEMD_PAGERSECURE
Hinweis: Wenn Befehle mit erhöhten Rechten ausgeführt werden, beispielsweise mittels sudo(8) oder pkexec(1), muss Vorsicht walten gelassen werden, um sicherzustellen, dass keine ungeplanten interaktiven Funktionalitäten aktiviert werden. Der »sichere« Modus für das Seitenanzeigeprogramm kann wie oben beschrieben automatisch aktiviert werden. Durch Setzen von SYSTEMD_PAGERSECURE=0 oder durch Nichtenfernen dieser Einstellung aus der ererbten Umgebung wird es dem Benutzer ermöglicht, beliebige Befehle auszuführen. Beachten Sie, dass auch $SYSTEMD_PAGERSECURE gesetzt werden muss, falls die Variablen $SYSTEMD_PAGER oder $PAGER berücksichtigt werden sollen. Es kann sinnvoll sein, stattdessen den Seitenanzeiger komplett mit --no-pager zu deaktivieren.
$SYSTEMD_COLORS
$SYSTEMD_URLIFY
BEISPIELE¶
Beispiel 1. Herunterladen eines Fedora-Abbildes und starten einer Shell darin
# machinectl pull-raw --verify=no \
https://download.fedoraproject.org/pub/fedora/linux/releases/36/Cloud/x86_64/images/Fedora-Cloud-Base-36-1.5.x86_64.raw.xz \
Fedora-Cloud-Base-36-1.5.x86-64 # systemd-nspawn -M Fedora-Cloud-Base-36-1.5.x86-64
Damit wird ein Abbild mittels machinectl(1) heruntergeladen und eine Shell darin geöffnet.
Beispiel 2. Bauen und Starten einer minimalen Fedora-Distribution in einem Container
# dnf -y --releasever=36 --installroot=/var/lib/machines/f36 \
--repo=fedora --repo=updates --setopt=install_weak_deps=False install \
passwd dnf fedora-release vim-minimal systemd systemd-networkd # systemd-nspawn -bD /var/lib/machines/f36
Dies installiert eine minimale Fedora-Distribution in das Verzeichnis /var/lib/machines/f36 und startet dann dies Betriebssystem in einem Namensraum-Container. Da sich die Installation unterhalb des Standard-/var/lib/machines/-Verzeichnisses befindet, ist es möglich, die Maschine mittels systemd-nspawn -M f36 zu starten.
Beispiel 3. Erzeugen einer Shell in einem Container einer minimalen Debian-Unstable-Distribution
# debootstrap unstable ~/debian-tree/ # systemd-nspawn -D ~/debian-tree/
Dies installiert eine minimale Debian-Unstable-Distribution in ein Verzeichnis ~/debian-tree/ und erzeugt dann eine Shell aus diesem Abbild in einem Namensraum-Container.
debootstrap unterstützt Debian[7], Ubuntu[8] und Tanglu[9] von Haus aus, daher kann der gleiche Befehl zur Installation von allen drei verwandt werden. Für andere Distributionen der Debian-Familie muss ein Spiegel angegeben werden, siehe debootstrap(8).
Beispiel 4. Starten einer minimalen Arch-Linux-Distribution in einem Container
# pacstrap -c ~/arch-tree/ base # systemd-nspawn -bD ~/arch-tree/
Dies installiert eine minimale Arch-Linux-Distribution in das Verzeichnis ~/arch-tree/ und startet dann ein Betriebssystem in einem Namensraum-Container darin.
Beispiel 5. Installion der OpenSUSE-Tumbleweed-Rolling-Distribution
# zypper --root=/var/lib/machines/tumbleweed ar -c \
https://download.opensuse.org/tumbleweed/repo/oss tumbleweed # zypper --root=/var/lib/machines/tumbleweed refresh # zypper --root=/var/lib/machines/tumbleweed install --no-recommends \
systemd shadow zypper openSUSE-release vim # systemd-nspawn -M tumbleweed passwd root # systemd-nspawn -M tumbleweed -b
Beispiel 6. Starten eines flüchtigen Schnappschusses des Systems
# systemd-nspawn -D / -xb
Dies führt eine Kopie des Systems in einem Schnappschuss aus, der sofort wieder entfernt wird, wenn sich der Container beendet. Alle zur Laufzeit erfolgten Dateiänderungen gehen daher beim Herunterfahren verloren.
Beispiel 7. Ausführen eines Containers mit SELinux-Sandbox-Sicherheitskontext
# chcon system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 -R /srv/container # systemd-nspawn -L system_u:object_r:svirt_sandbox_file_t:s0:c0,c1 \
-Z system_u:system_r:svirt_lxc_net_t:s0:c0,c1 -D /srv/container /bin/sh
Beispiel 8. Ausführen eines Containers mit einer OSTree-Verwendung
# systemd-nspawn -b -i ~/image.raw \
--pivot-root=/ostree/deploy/$OS/deploy/$CHECKSUM:/sysroot \
--bind=+/sysroot/ostree/deploy/$OS/var:/var
EXIT-STATUS¶
Es wird der Exit-Code des im Container ausgeführten Programms zurückgeliefert.
SIEHE AUCH¶
systemd(1), systemd.nspawn(5), chroot(1), dnf(8), debootstrap(8), pacman(8), zypper(8), systemd.slice(5), machinectl(1), btrfs(8)
ANMERKUNGEN¶
- 1.
- Container-Schnittstelle
- 2.
- Spezifikation für auffindbare Partitionen
- 3.
- OCI-Laufzeit-Spezifikation
- 4.
- OSTree
- 5.
- Überlagerungsdateisystem
- 6.
- Fedora
- 7.
- Debian
- 8.
- Ubuntu
- 9.
- Tanglu
- 10.
- Arch Linux
- 11.
- OpenSUSE Tumbleweed
ÜBERSETZUNG¶
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.
systemd 252 |