systemd-nspawn - En ligne dans le Cloud

PROGRAMME:

Nom

systemd-nspawn - Générer un conteneur d'espace de noms pour le débogage, les tests et la construction

SYNOPSIS

systemd-nspawn [OPTIONS...] [COMMAND [ARG...]]

systemd-nspawn -b [OPTIONS...] [ARG...]

DESCRIPTION

systemd-nspawn peut être utilisé pour exécuter une commande ou un système d'exploitation dans un conteneur d'espace de noms léger.
À bien des égards, il est similaire à chroot(1), mais plus puissant puisqu'il virtualise entièrement le
hiérarchie du système de fichiers, ainsi que l'arborescence des processus, les différents sous-systèmes IPC et le
hôte et nom de domaine.

systemd-nspawn limite l'accès aux diverses interfaces du noyau dans le conteneur en lecture seule,
tel que / sys, /proc/sys ou /sys/fs/selinux. Les interfaces réseau et l'horloge système peuvent
ne pas être modifié depuis l'intérieur du conteneur. Les nœuds de périphérique ne peuvent pas être créés. Le système hôte
ne peut pas être redémarré et les modules du noyau peuvent ne pas être chargés depuis le conteneur.

Notez que même si ces précautions de sécurité sont prises systemd-nspawn ne convient pas
pour des configurations de conteneurs entièrement sécurisées. De nombreux dispositifs de sécurité peuvent être contournés et
sont donc principalement utiles pour éviter les modifications accidentelles du système hôte à partir du
récipient.

Contrairement à chroot(1) systemd-nspawn peut être utilisé pour démarrer un fonctionnement basé sur Linux complet
systèmes dans un conteneur.

Utilisez un outil comme DNF(8), debootstrap(8), ou pacman(8) pour configurer une arborescence de répertoires du système d'exploitation
approprié comme hiérarchie de système de fichiers pour systemd-nspawn conteneurs.

Notez que systemd-nspawn montera les systèmes de fichiers privés sur le conteneur pour / dev, / courir
et similaire. Ceux-ci ne seront pas visibles à l'extérieur du conteneur et leur contenu sera
être perdu à la sortie du conteneur.

Notez que l'exécution de deux systemd-nspawn les conteneurs de la même arborescence de répertoires ne feront pas
les processus en eux se voient. La séparation de l'espace de noms PID des deux conteneurs est
complet et les conteneurs partageront très peu d'objets d'exécution, à l'exception du sous-jacent
système de fichiers. Utilisation machinectl(1) vous connecter commande pour demander une invite de connexion supplémentaire dans un
conteneur en cours d'exécution.

systemd-nspawn met en œuvre le Contenant Interface[1] spécification.

Comme contrôle de sécurité systemd-nspawn vérifiera l'existence de /usr/lib/os-release or
/etc/os-release dans l'arborescence des conteneurs avant de démarrer le conteneur (voir OS-release(5)).
Il peut être nécessaire d'ajouter manuellement ce fichier à l'arborescence des conteneurs si le système d'exploitation du
conteneur est trop ancien pour contenir ce fichier prêt à l'emploi.

OPTIONS

Si option -b est spécifié, les arguments sont utilisés comme arguments pour le binaire d'initialisation.
Dans le cas contraire, COMMAND spécifie le programme à lancer dans le conteneur, et le reste
les arguments sont utilisés comme arguments pour ce programme. Si -b n'est pas utilisé et aucun argument n'est
spécifié, un shell est lancé dans le conteneur.

Les options suivantes sont comprises :

-D, --répertoire=
Répertoire à utiliser comme racine du système de fichiers pour le conteneur.

Si ni l'un ni l'autre --répertoire=, ni --image= est spécifié le répertoire est déterminé par
recherche d'un répertoire portant le même nom que le nom de la machine spécifié avec
--machine=. Voir machinectl(1) rubrique "Fichiers et répertoires" pour la recherche précise
chemin.

Si ni l'un ni l'autre --répertoire=, --image=, ni --machine= sont spécifiés, le répertoire courant
sera utilisé. Ne peut pas être spécifié avec --image=.

--modèle=
Répertoire ou sous-volume "btrfs" à utiliser comme modèle pour le répertoire racine du conteneur.
Si cela est spécifié et que le répertoire racine du conteneur (tel que configuré par
--répertoire=) n'existe pas encore, il est créé en tant que sous-volume "btrfs" et rempli à partir de
cette arborescence de modèles. Idéalement, le chemin du modèle spécifié fait référence à la racine d'un
sous-volume "btrfs", auquel cas un simple instantané de copie sur écriture est pris, et
le remplissage du répertoire racine est instantané. Si le chemin du modèle spécifié ne
se référer à la racine d'un sous-volume "btrfs" (ou même pas à un système de fichiers "btrfs" à
all), l'arbre est copié, ce qui peut prendre beaucoup plus de temps. Notez que si
cette option est utilisée dans le répertoire racine du conteneur (contrairement au modèle
répertoire !) doit être situé sur un système de fichiers "btrfs", de sorte que le sous-volume "btrfs"
peut être créé. Ne peut pas être spécifié avec --image= or --éphémère.

Notez que ce commutateur laisse le nom d'hôte, l'ID de la machine et tous les autres paramètres qui pourraient
identifier l'instance non modifiée.

-x, --éphémère
Si spécifié, le conteneur est exécuté avec un instantané temporaire "btrfs" de sa racine
répertoire (tel que configuré avec --répertoire=), qui est supprimé immédiatement lorsque le
conteneur se termine. Cette option n'est prise en charge que si le système de fichiers racine est
"btrfs". Ne peut pas être spécifié avec --image= or --modèle=.

Notez que ce commutateur laisse le nom d'hôte, l'ID de la machine et tous les autres paramètres qui pourraient
identifier l'instance non modifiée.

-i, --image=
Image disque à partir de laquelle monter le répertoire racine du conteneur. Prend un chemin vers un
fichier régulier ou à un nœud de périphérique de bloc. Le fichier ou le périphérique de bloc doit contenir soit :

· Une table de partition MBR avec une seule partition de type 0x83 qui est marquée
amorçable.

· Une table de partition GUID (GPT) avec une seule partition de type
0fc63daf-8483-4772-8e79-3d69d8477de4.

· Une table de partition GUID (GPT) avec une partition racine marquée qui est montée en tant que
répertoire racine du conteneur. En option, les images GPT peuvent contenir une maison et/ou
une partition de données de serveur qui sont montées aux endroits appropriés dans le
récipient. Toutes ces partitions doivent être identifiées par les types de partitions définis
par le Identifiable partitions Spécification[2].

Toutes les autres partitions, telles que les partitions étrangères, les partitions d'échange ou le système EFI
les partitions ne sont pas montées. Ne peut pas être spécifié avec --répertoire=,
--modèle= or --éphémère.

-a, --as-pid2
Appelez le shell ou le programme spécifié en tant qu'ID de processus (PID) 2 au lieu de PID 1 (init).
Par défaut, si ni cette option ni --botte est utilisé, le binaire sélectionné est exécuté comme
processus avec PID 1, un mode uniquement adapté aux programmes conscients des
sémantique que le processus avec PID 1 a sur UNIX. Par exemple, il doit récolter tout
processus qui lui sont rattachés, et devrait mettre en œuvre sysvinit gestion du signal compatible
(plus précisément : il doit redémarrer sur SIGINT, réexécuter sur SIGTERM, recharger
configuration sur SIGHUP, etc.). Avec --as-pid2 un processus d'initialisation de stub minimal est exécuté
comme PID 1 et le binaire sélectionné est exécuté comme PID 2 (et n'a donc pas besoin de
mettre en œuvre toute sémantique spéciale). Le processus d'initialisation du stub récoltera des processus comme
nécessaire et réagir de manière appropriée aux signaux. Il est recommandé d'utiliser ce mode pour
invoquer des commandes arbitraires dans des conteneurs, à moins qu'elles n'aient été modifiées pour s'exécuter
correctement comme PID 1. Ou en d'autres termes : ce commutateur devrait être utilisé pour à peu près tous
commandes, sauf lorsque la commande fait référence à une implémentation init ou shell, car ces
sont généralement capables de fonctionner correctement en tant que PID 1). Cette option n'est pas cumulable
avec --botte or --share-système.

-b, --botte
Recherchez automatiquement un binaire d'initialisation et appelez-le en tant que PID 1, au lieu d'un shell ou
un programme fourni par l'utilisateur. Si cette option est utilisée, les arguments spécifiés sur la commande
sont utilisés comme arguments pour le binaire d'initialisation. Cette option n'est pas cumulable avec
--as-pid2 or --share-système.

Le tableau suivant explique les différents modes d'invocation et les relations avec
--as-pid2 (voir au dessus):

lampe de table 1. Invocation Mode
?? ??
│Basculer │ Explication │
?? ??
Aucun --as-pid2 ni --botte Les paramètres passés sont │
│spécifié │ interprété comme ligne de commande, │
│ │ qui est exécuté comme PID 1 dans │
│ │ le conteneur. ??
?? ??
│--as-pid2 spécifié │ Les paramètres passés sont │
│ interprété comme ligne de commande, │
│ │ qui sont exécutés comme PID 2 dans │
│ │ le conteneur. Un stub init │
│ │ le processus est exécuté en tant que PID 1. │
?? ??
│--botte spécifié │ Un binaire d'initialisation comme automatiquement │
│ │ recherché et exécuté en tant que PID 1 dans le │
│ conteneur. Les paramètres passés │
│ │ sont utilisés comme invocation │
│ paramètres pour ce processus. ??
?? ??

--chdir=
Accédez au répertoire de travail spécifié avant d'appeler le processus dans le
récipient. Attend un chemin absolu dans l'espace de noms du système de fichiers du conteneur.

-u, --utilisateur=
Après la transition vers le conteneur, passez au conteneur défini par l'utilisateur dans le
base de données des utilisateurs du conteneur. Comme toutes les autres fonctionnalités de systemd-nspawn, ce n'est pas un
fonction de sécurité et offre une protection contre les opérations destructrices accidentelles
seulement.

-M, --machine=
Définit le nom de la machine pour ce conteneur. Ce nom peut être utilisé pour identifier ce
conteneur pendant son exécution (par exemple dans des outils comme machinectl(1) et similaires),
et est utilisé pour initialiser le nom d'hôte du conteneur (que le conteneur peut choisir de
dérogation, cependant). S'il n'est pas spécifié, le dernier composant du chemin du répertoire racine de
le conteneur est utilisé, éventuellement suffixé d'un identifiant aléatoire en cas --éphémère
mode est sélectionné. Si le répertoire racine sélectionné est le répertoire racine de l'hôte, le
le nom d'hôte de l'hôte est utilisé par défaut à la place.

--uuid=
Définissez l'UUID spécifié pour le conteneur. Le système d'initialisation s'initialise
/etc/id-machine à partir de là si ce fichier n'est pas encore défini.

--tranche=
Faites en sorte que le conteneur fasse partie de la tranche spécifiée, au lieu de la machine.slice par défaut.
Ceci ne s'applique que si la machine est exécutée dans sa propre unité de mesure, c'est-à-dire si --garde-unité
N'est pas utilisé.

--propriété=
Définissez une propriété d'unité sur l'unité de portée à enregistrer pour la machine. Cela s'applique uniquement
si la machine est exécutée dans sa propre unité de mesure, c'est-à-dire si --garde-unité N'est pas utilisé. prend
les affectations de propriété d'unité dans le même format que systemctl ensemble-propriété. C'est utile
pour définir des limites de mémoire et similaires pour les machines.

--utilisateurs-privés=
Active l'espacement des noms d'utilisateur. Si activé, le conteneur s'exécutera avec son propre ensemble privé
des identifiants d'utilisateur et de groupe Unix (UID et GID). N'en prend aucun, un ou deux séparés par des deux points
paramètres : le premier paramètre spécifie le premier UID d'hôte à attribuer au
conteneur, le deuxième paramètre spécifie le nombre d'UID d'hôte à attribuer au
récipient. Si le deuxième paramètre est omis, 65536 UID sont attribués. Si le premier
paramètre est également omis (et donc aucun paramètre passé du tout), le premier UID
attribué au conteneur est lu à partir du propriétaire du répertoire racine du
l'arborescence des répertoires du conteneur. Par défaut, aucun espacement de nom d'utilisateur n'est appliqué.

Notez que l'espacement des noms d'utilisateur nécessite actuellement des arborescences de système d'exploitation qui sont préparées pour l'UID
décalage qui est appliqué : UID et GID utilisés pour la propriété du fichier ou dans l'ACL du fichier
les entrées doivent être déplacées vers la base UID du conteneur qui est utilisée pendant le conteneur
Durée.

Il est recommandé d'attribuer au moins 65536 UID à chaque conteneur, afin que le
La plage UID dans le conteneur couvre 16 bits. Pour une meilleure sécurité, n'attribuez pas de chevauchement
L'UID s'étend sur plusieurs conteneurs. C'est donc une bonne idée d'utiliser les 16 bits supérieurs de
les UID 32 bits de l'hôte comme identifiant de conteneur, tandis que les 16 bits inférieurs codent le
UID du conteneur utilisé.

Lorsque des espaces de noms d'utilisateurs sont utilisés, la plage GID attribuée à chaque conteneur est toujours
choisi identique à la gamme UID.

--Réseau privé
Déconnectez la mise en réseau du conteneur de l'hôte. Cela rend tout le réseau
interfaces indisponibles dans le conteneur, à l'exception du périphérique de bouclage et
ceux spécifiés avec --interface-réseau= et configuré avec --réseau-veth. Si ce
est spécifiée, la capacité CAP_NET_ADMIN sera ajoutée à l'ensemble de
capacités que le conteneur conserve. Ce dernier peut être désactivé en utilisant
--drop-capacité=.

--interface-réseau=
Attribuez l'interface réseau spécifiée au conteneur. Cela supprimera le
l'interface spécifiée à partir de l'espace de noms appelant et placez-la dans le conteneur. Quand le
conteneur se termine, il est replacé dans l'espace de noms de l'hôte. Noter que
--interface-réseau= implique --Réseau privé. Cette option peut être utilisée plusieurs fois
pour ajouter plusieurs interfaces réseau au conteneur.

--network-macvlan=
Créez une interface "macvlan" de l'interface réseau Ethernet spécifiée et ajoutez-la à
le conteneur. Une interface "macvlan" est une interface virtuelle qui ajoute un deuxième MAC
adresse à une liaison Ethernet physique existante. L'interface dans le conteneur sera
nommé d'après l'interface sur l'hôte, préfixé par "mv-". Noter que
--network-macvlan= implique --Réseau privé. Cette option peut être utilisée plusieurs fois
pour ajouter plusieurs interfaces réseau au conteneur.

--réseau-ipvlan=
Créez une interface "ipvlan" de l'interface réseau Ethernet spécifiée et ajoutez-la à
le conteneur. Une interface "ipvlan" est une interface virtuelle, similaire à un "macvlan"
interface, qui utilise la même adresse MAC que l'interface sous-jacente. L'interface
dans le conteneur sera nommé d'après l'interface sur l'hôte, préfixé par "iv-".
Notez que --réseau-ipvlan= implique --Réseau privé. Cette option peut être utilisée plus
qu'une fois pour ajouter plusieurs interfaces réseau au conteneur.

-n, --réseau-veth
Créez un lien Ethernet virtuel ("veth") entre l'hôte et le conteneur. Le côté hôte de
le lien Ethernet sera disponible en tant qu'interface réseau nommée d'après le nom du conteneur
nom (comme spécifié avec --machine=), préfixé par "ve-". Le côté conteneur du
Le lien Ethernet sera nommé "host0". Noter que --réseau-veth implique
--Réseau privé.

--network-veth-extra=
Ajoute un lien Ethernet virtuel supplémentaire entre l'hôte et le conteneur. Prend un
paire séparée par des deux-points du nom de l'interface hôte et du nom de l'interface du conteneur. Le dernier
peut être omis, auquel cas les côtés conteneur et hôte se verront attribuer le même
Nom. Ce commutateur est indépendant de --réseau-veth, et -- en revanche -- peut être utilisé
plusieurs fois et permet la configuration des noms d'interface réseau. Noter que
--network-bridge= n'a aucun effet sur les interfaces créées avec --network-veth-extra=.

--network-bridge=
Ajoute le côté hôte du lien Ethernet créé avec --réseau-veth à l'spécifié
pont. Noter que --network-bridge= implique --réseau-veth. Si cette option est utilisée,
le côté hôte de la liaison Ethernet utilisera le préfixe "vb-" au lieu de "ve-".

-p, --port=
Si le réseau privé est activé, mappe un port IP sur l'hôte sur un port IP sur le
récipient. Prend un spécificateur de protocole (soit « tcp » ou « udp »), séparé par deux points
à partir d'un numéro de port hôte compris entre 1 et 65535, séparé par deux points d'un conteneur
numéro de port compris entre 1 et 65535. Le spécificateur de protocole et sa séparation
deux-points peuvent être omis, auquel cas "tcp" est supposé. Le numéro de port du conteneur et
ses deux points peuvent être omis, auquel cas le même port que le port hôte est impliqué.
Cette option n'est prise en charge que si un réseau privé est utilisé, comme avec
--réseau-veth or --network-bridge=.

-Z, --selinux-context=
Définit le contexte de sécurité SELinux à utiliser pour étiqueter les processus dans le conteneur.

-L, --selinux-apifs-context=
Définit le contexte de sécurité SELinux à utiliser pour étiqueter les fichiers dans le fichier API virtuel
systèmes dans le conteneur.

--capacité=
Répertoriez une ou plusieurs fonctionnalités supplémentaires à accorder au conteneur. Prend un
liste de noms de capacités séparés par des virgules, voir capacités(7) pour plus d'informations.
Notez que les capacités suivantes seront accordées de quelque manière que ce soit : CAP_CHOWN,
CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, CAP_FOWNER, CAP_FSETID, CAP_IPC_OWNER,
CAP_KILL, CAP_LEASE, CAP_LINUX_IMMUTABLE, CAP_NET_BIND_SERVICE, CAP_NET_BROADCAST,
CAP_NET_RAW, CAP_SETGID, CAP_SETFCAP, CAP_SETPCAP, CAP_SETUID, CAP_SYS_ADMIN,
CAP_SYS_CHROOT, CAP_SYS_NICE, CAP_SYS_PTRACE, CAP_SYS_TTY_CONFIG, CAP_SYS_RESOURCE,
CAP_SYS_BOOT, CAP_AUDIT_WRITE, CAP_AUDIT_CONTROL. Aussi CAP_NET_ADMIN est conservé si
--Réseau privé est spécifié. Si la valeur spéciale "all" est transmise, toutes les capacités
sont conservés.

--drop-capacité=
Spécifiez une ou plusieurs fonctionnalités supplémentaires à supprimer pour le conteneur. Ceci permet
exécuter le conteneur avec moins de capacités que la valeur par défaut (voir ci-dessus).

--kill-signal=
Spécifiez le signal de processus à envoyer au PID 1 du conteneur lorsque nspawn lui-même
reçoit SIGTERM, afin de déclencher un arrêt ordonné du conteneur. Valeurs par défaut
à SIGRTMIN+3 si --botte est utilisé (sur les systèmes d'initialisation compatibles avec systemd SIGRTMIN+3
déclenche un arrêt ordonné). Prend un nom de signal comme "SIGHUP", "SIGTERM" ou similaire
comme argument.

--link-journal=
Contrôlez si le journal du conteneur doit être rendu visible par le système hôte. Si
activé, permet de visualiser les fichiers journaux du conteneur à partir de l'hôte (mais pas vice
versa). Prend l'un de "no", "host", "try-host", "guest", "try-guest", "auto". Sinon",
le journal n'est pas lié. Si "hôte", les fichiers journaux sont stockés sur le fichier hôte
système (sous /var/log/journal/ID de la machine) et le sous-répertoire est monté en liaison dans
le conteneur au même endroit. Si "invité", les fichiers journaux sont stockés sur le
système de fichiers invité (sous /var/log/journal/ID de la machine) et le sous-répertoire est
lié symboliquement à l'hôte au même endroit. "try-host" et "try-guest" font de même
mais n'échouez pas si l'hôte n'a pas activé la journalisation persistante. Si "auto"
(la valeur par défaut), et le bon sous-répertoire de /var/log/journal existe, il sera lié
monté dans le conteneur. Si le sous-répertoire n'existe pas, aucun lien n'est
effectué. En effet, démarrer un conteneur une fois avec "guest" ou "host" liera le
journal de manière persistante si plus loin la valeur par défaut "auto" est utilisée.

-j
Équivalent à --link-journal=essayer-invité.

--lecture seulement
Montez le système de fichiers racine en lecture seule pour le conteneur.

--bind=, --bind-ro=
Lier monter un fichier ou un répertoire de l'hôte dans le conteneur. Prend l'un des : un chemin
argument — auquel cas le chemin spécifié sera monté de l'hôte vers le même
chemin dans le conteneur —, ou une paire de chemins séparés par des deux-points — auquel cas le premier
le chemin spécifié est la source dans l'hôte, et le deuxième chemin est la destination dans
le conteneur —, ou un triplet séparé par des deux-points du chemin source, du chemin de destination et
options de montage. Les options de montage sont séparées par des virgules et actuellement, seuls "rbind" et
« norbind » sont autorisés. La valeur par défaut est "rbind". Les échappements antislash sont interprétés, donc "\:"
peut être utilisé pour incorporer des deux-points dans l'un ou l'autre chemin. Cette option peut être spécifiée plusieurs
fois pour créer plusieurs points de montage de liaison indépendants. Les --bind-ro= option
crée des montages de liaison en lecture seule.

--tmpfs=
Montez un système de fichiers tmpfs dans le conteneur. Prend un seul argument de chemin absolu
qui spécifie où monter l'instance tmpfs (auquel cas le répertoire
le mode d'accès sera choisi comme 0755, appartenant à root/root), ou éventuellement un
paire de chemin d'accès et d'option de montage séparés par des deux-points qui est utilisée pour le montage (dans
auquel cas le noyau par défaut pour le mode d'accès et le propriétaire sera choisi, à moins que
spécifié autrement). Cette option est particulièrement utile pour monter des répertoires tels que
as / var comme tmpfs, pour autoriser les systèmes sans état, en particulier lorsqu'ils sont combinés avec
--lecture seulement. Les échappements antislash sont interprétés dans le chemin, donc "\:" peut être utilisé pour
intégrer des deux-points dans le chemin.

--superposition=, --overlay-ro=
Combinez plusieurs arborescences de répertoires dans un système de fichiers superposé et montez-le dans le
récipient. Prend une liste de chemins séparés par des deux-points vers les arborescences de répertoires à combiner et
le point de montage de destination.

Les échappements antislash sont interprétés dans les chemins, donc "\:" peut être utilisé pour incorporer des deux-points dans
les chemins.

Si trois chemins ou plus sont spécifiés, le dernier chemin spécifié est la destination
point de montage dans le conteneur, tous les chemins spécifiés auparavant font référence aux arborescences de répertoires sur
l'hôte et sont combinés dans l'ordre spécifié dans un système de fichiers superposé. Les
le chemin le plus à gauche est donc l'arborescence de répertoires le plus bas, l'avant-dernier chemin le plus élevé
arborescence de répertoires dans l'ordre d'empilement. Si --overlay-ro= est utilisé au lieu de --superposition=,
un système de fichiers superposé en lecture seule est créé. Si un système de fichiers de superposition inscriptible est
créé, toutes les modifications qui y sont apportées sont écrites dans l'arborescence de répertoires la plus élevée du
ordre d'empilement, c'est-à-dire l'avant-dernier spécifié.

Si seuls deux chemins sont spécifiés, le deuxième chemin spécifié est utilisé à la fois comme
arborescence de répertoires de niveau supérieur dans l'ordre d'empilement vu de l'hôte, ainsi que le
point de montage pour le système de fichiers de superposition dans le conteneur. Au moins deux chemins doivent
être spécifié.

Pour plus d'informations sur les systèmes de fichiers superposés, consultez superpositionfs.txt[3]. Notez que la sémantique
des systèmes de fichiers superposés sont sensiblement différents des systèmes de fichiers normaux, en
en particulier en ce qui concerne les informations signalées sur le périphérique et l'inode. Périphérique et inode
les informations peuvent changer pour un fichier pendant qu'il est en cours d'écriture, et les processus peuvent
voir parfois des versions obsolètes des fichiers. Notez que ce commutateur automatiquement
dérive l'option de montage "workdir=" pour le système de fichiers de superposition du niveau supérieur
arborescence de répertoires, ce qui en fait un frère. Il est donc essentiel que le plus haut niveau
l'arborescence de répertoires n'est pas un point de montage lui-même (puisque le répertoire de travail doit être sur le
même système de fichiers que l'arborescence de répertoires la plus élevée). Notez également que le montage "lowerdir="
L'option reçoit les chemins à empiler dans l'ordre inverse de ce commutateur.

--setenv=
Spécifie une affectation de variable d'environnement à transmettre au processus d'initialisation dans le
conteneur, au format "NOM=VALEUR". Cela peut être utilisé pour remplacer la valeur par défaut
variables ou pour définir des variables supplémentaires. Ce paramètre peut être utilisé plusieurs fois.

--share-système
Permet au conteneur de partager certaines fonctionnalités du système avec l'hôte. Suite
en particulier, cela désactive l'espacement de noms PID, l'espacement de noms UTS et l'espacement de noms IPC, et
permet ainsi à l'invité de voir et d'interagir plus facilement avec les processus extérieurs au
récipient. Notez que l'utilisation de cette option rend impossible le démarrage d'un
Système d'exploitation dans le conteneur, car un système d'initialisation ne peut pas fonctionner dans ce mode. Ce
n'est utile que pour exécuter des programmes ou des applications spécifiques de cette façon, sans impliquer un
système d'initialisation dans le conteneur. Cette option implique --register=non. Cette option peut ne pas
être combiné avec --botte.

--registre=
Contrôle si le conteneur est enregistré avec systemd-usiné(8). Prend un booléen
argument, qui par défaut est "oui". Cette option doit être activée lorsque le conteneur
exécute un système d'exploitation complet (plus précisément : un système d'initialisation), et est utile pour
s'assurer que le conteneur est accessible via machinectl(1) et illustré par des outils tels que
ps(1). Si le conteneur n'exécute pas de système d'initialisation, il est recommandé de définir cette
option à "non". Noter que --share-système implique --register=non.

--garde-unité
Au lieu de créer une unité de portée transitoire pour exécuter le conteneur, enregistrez simplement
l'unité de service ou de portée systemd-nspawn a été invoqué avec systemd-usiné (8).
Cela n'a aucun effet si --register=non est utilisé. Ce commutateur doit être utilisé si
systemd-nspawn est invoqué depuis l'intérieur d'une unité de service, et le seul
le but est d'exécuter un seul systemd-nspawn récipient. Cette option n'est pas disponible si
exécuter à partir d'une session utilisateur.

--personnalité=
Maîtriser l'architecture ("personnalité") rapportée par ton nom(2) dans le conteneur.
Actuellement, seuls "x86" et "x86-64" sont pris en charge. Ceci est utile lors de l'exécution d'un 32 bits
conteneur sur un hôte 64 bits. Si ce paramètre n'est pas utilisé, la personnalité signalée dans
le conteneur est le même que celui signalé sur l'hôte.

-q, --silencieux
Désactive toute sortie d'état par l'outil lui-même. Lorsque ce commutateur est utilisé, le seul
la sortie de nspawn sera la sortie de la console du système d'exploitation du conteneur lui-même.

--volatil, --volatile=MODE
Démarre le conteneur en mode volatile. Lorsqu'aucun paramètre de mode n'est passé ou lorsque le mode est
spécifié comme oui, le mode volatile complet est activé. Cela signifie que le répertoire racine est
monté en tant qu'instance "tmpfs" pour la plupart non remplie, et / usr de l'arborescence du système d'exploitation est monté
en lecture seule (le système démarre donc avec des ressources OS en lecture seule, mais
état et configuration vierges, toute modification apportée à l'un ou l'autre est perdue lors de l'arrêt).
Lorsque le paramètre mode est spécifié comme Etat, l'arborescence du système d'exploitation est montée en lecture seule, mais
/ var y est monté en tant qu'instance "tmpfs" (le système démarre donc avec
ressources et configuration du système d'exploitation en lecture seule, mais état vierge et toute modification apportée au
ces derniers sont perdus à l'arrêt). Lorsque le paramètre mode est spécifié comme aucune (les
par défaut), l'intégralité de l'arborescence du système d'exploitation est rendue accessible en écriture.

Notez que définir ce paramètre sur oui or Etat ne fonctionnera correctement qu'avec les systèmes d'exploitation
dans le conteneur qui peut démarrer avec seulement / usr monté, et sont capables de remplir
/ var automatiquement, au besoin.

--paramètres=MODE
Contrôle si systemd-nspawn doit rechercher et utiliser des conteneurs supplémentaires
paramètres des fichiers .nspawn. Prend un booléen ou les valeurs spéciales Commande or
confiance.

S'il est activé (valeur par défaut), un fichier de paramètres nommé d'après la machine (comme spécifié avec
le --machine= paramètre, ou dérivé du répertoire ou du nom du fichier image) avec le
le suffixe .nspawn est recherché dans /etc/systemd/nspawn/ et /run/systemd/nspawn/. Si c'est
trouvé là, ses paramètres sont lus et utilisés. S'il ne s'y trouve pas, c'est
recherché par la suite dans le même répertoire que le fichier image ou dans le
parent du répertoire racine du conteneur. Dans ce cas, si le fichier est trouvé, son
les paramètres seront également lus et utilisés, mais les paramètres potentiellement dangereux sont ignorés. Noter
que dans ces deux cas, les paramètres de la ligne de commande ont préséance sur le
les paramètres correspondants des fichiers .nspawn chargés, si les deux sont spécifiés. Peu sûr
les paramètres sont considérés comme tous les paramètres qui élèvent les privilèges du conteneur ou accordent
accès à des ressources supplémentaires telles que des fichiers ou des répertoires de l'hôte. Pour plus de détails
sur le format et le contenu des fichiers .nspawn, consultez systemd.nspawn (5).

Si cette option est définie sur Commande, le fichier est recherché, lu et utilisé de la même manière,
cependant, l'ordre de priorité est inversé : les paramètres lus à partir du fichier .nspawn seront
ont priorité sur les options de ligne de commande correspondantes, si les deux sont spécifiées.

Si cette option est définie sur confiance, le fichier est recherché, lu et utilisé de la même manière,
mais indépendamment du fait qu'il se trouve dans /etc/systemd/nspawn/, /run/systemd/nspawn/ ou à côté de
le fichier image ou le répertoire racine du conteneur, tous les paramètres prendront effet, cependant,
les arguments de ligne de commande ont toujours la priorité sur les paramètres correspondants.

Si désactivé, aucun fichier .nspawn n'est lu et aucun paramètre à l'exception de ceux de la commande
ligne sont en vigueur.

-h, --Aidez-moi
Imprimez un court texte d'aide et quittez.

--version
Imprime une chaîne de version courte et quitte.

EXEMPLES

Exemple 1. Télécharger a Fedora image et Commencer a coquille in it

# machinectl pull-raw --verify=non http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz
# systemd-nspawn -M Fedora-Cloud-Base-20141203-21

Cela télécharge une image en utilisant machinectl(1) et y ouvre une coquille.

Exemple 2. Silhouette et botte a minimal Fedora pour la distribution in a CONTENANT

# dnf -y --releasever=23 --installroot=/srv/mycontainer --disablerepo='*' --enablerepo=fedora --enablerepo=updates install systemd passwd dnf fedora-release vim-minimal
# systemd-nspawn -bD /srv/monconteneur

Cela installe une distribution Fedora minimale dans le répertoire /srv/mycontainer/ puis
démarre un système d'exploitation dans un conteneur d'espace de noms.

Exemple 3. Frayer a coquille in a CONTENANT of a minimal Debian instable pour la distribution

# debootstrap --arch=amd64 instable ~/arbre-debian/
# systemd-nspawn -D ~/arbre-debian/

Cela installe une distribution Debian instable minimale dans le répertoire ~/arbre-debian/ et
génère ensuite un shell dans un conteneur d'espace de noms.

Exemple 4. botte a minimal Ponts en arc Linux/Unix pour la distribution in a CONTENANT

# pacstrap -c -d ~/arbre-arche/ base
# systemd-nspawn -bD ~/arbre-arche/

Cela installe une distribution Arch Linux minimale dans le répertoire ~/arbre-arche/ et alors
démarre un système d'exploitation dans un conteneur d'espace de noms.

Exemple 5. botte développement an éphémère "btrfs" instantané of le hôte Système

# systemd-nspawn -D / -xb

Cela exécute une copie du système hôte dans un instantané "btrfs" qui est immédiatement supprimé
à la sortie du conteneur. Toutes les modifications apportées au système de fichiers pendant l'exécution seront perdues sur
arrêt, donc.

Exemple 6. Courir a CONTENANT avec SELinux tas de sable centré sur l'humain contextes

# 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

EXIT STATUT

Le code de sortie du programme exécuté dans le conteneur est renvoyé.

Utilisez systemd-nspawn en ligne à l'aide des services onworks.net