<p><em>Les conteneurs Linux (LXC) sont une méthode de virtualisation au niveau du système d’exploitation pour exécuter plusieurs systèmes Linux isolés (conteneurs) sur un seul hôte de contrôle (hôte LXC). Il ne fournit pas de machine virtuelle, mais fournit plutôt un environnement virtuel qui a son propre CPU, mémoire, bloc d’E / S, réseau, etc. et le mécanisme de contrôle des ressources. Ceci est fourni par les espaces de noms et les fonctionnalités de cgroups dans le noyau Linux sur l’hôte LXC. Il est similaire à un chroot, mais offre beaucoup plus d’isolement.</em></p>
<ul>
<li><ahref="#liens">Liens</a></li>
<li><ahref="#conteneurs-privil%C3%A9gi%C3%A9s-ou-non-privil%C3%A9gi%C3%A9s">Conteneurs “privilégiés” ou “non privilégiés”</a></li>
<li><ahref="#cr%C3%A9er-un-conteneur-arch">Créer un conteneur Arch</a></li>
<li><ahref="#cr%C3%A9er-un-conteneur-pour-une-autre-distribution-debianubuntuetc">Créer un conteneur pour une autre distribution (debian,ubuntu,etc…)</a></li>
</ul>
</li>
<li>
<ahref="#configuration-des-conteneurs">Configuration des conteneurs</a>
<ul>
<li><ahref="#configuration-de-base-avec-mise-en-r%C3%A9seau">Configuration de base avec mise en réseau</a></li>
<li><ahref="#ressources-syst%C3%A8me-%C3%A0-virtualiserisoler-varliblxccontainer_nameconfig">Ressources système à virtualiser/isoler (/var/lib/lxc/CONTAINER_NAME/config)</a></li>
</ul>
</li>
<li><ahref="#consid%C3%A9rations-sur-le-programme-xorg-facultatif">Considérations sur le programme Xorg (facultatif)</a></li>
<li><ahref="#consid%C3%A9rations-sur-lopenvpn">Considérations sur l’OpenVPN</a></li>
<li>
<ahref="#gestion-des-conteneurs">Gestion des conteneurs</a>
<ul>
<li>
<ahref="#utilisation-de-base">Utilisation de base</a>
<ul>
<li><ahref="#liste-des-conteneurs---lxc-ls--f">Liste des conteneurs - lxc-ls -f</a></li>
<li><ahref="#d%C3%A9marrerarr%C3%AAter-un-conteneur-lxc">Démarrer/Arrêter un conteneur LXC</a></li>
<li><ahref="#sattacher-%C3%A0-un-conteneur">S’attacher à un conteneur</a></li>
<li><ahref="#conversion-dun-conteneur-privil%C3%A9gi%C3%A9-en-un-conteneur-non-privil%C3%A9gi%C3%A9">Conversion d’un conteneur privilégié en un conteneur non privilégié</a></li>
<li><ahref="#ex%C3%A9cution-de-programmes-xorg">Exécution de programmes Xorg</a></li>
</ul>
</li>
</ul>
</li>
<li>
<ahref="#d%C3%A9pannage">Dépannage</a>
<ul>
<li><ahref="#%C3%A9chec-de-la-connexion-%C3%A0-la-racine">Échec de la connexion à la racine</a></li>
<li><ahref="#pas-de-connexion-au-r%C3%A9seau-avec-veth-dans-la-configuration-du-conteneur">Pas de connexion au réseau avec veth dans la configuration du conteneur</a></li>
<li><ahref="https://www.stgraber.org/2013/12/23/lxc-1-0-some-more-advanced-container-usage/">LXC 1.0: Some more advanced container usage [4/10]</a></li>
<li><ahref="http://www.stgraber.org/2014/02/05/lxc-1-0-scripting-with-the-api/">LXC 1.0: Scripting with the API [8/10]</a></li>
<li><ahref="http://www.stgraber.org/2014/02/09/lxc-1-0-gui-in-containers/">LXC 1.0: GUI in containers [9/10]</a></li>
<li><ahref="http://www.stgraber.org/2014/02/18/lxc-1-0-troubleshooting-and-debugging/">LXC 1.0: Troubleshooting and debugging [10/10]</a></li>
</ul>
</li>
</ul>
<p>Les alternatives d’utilisation des conteneurs sont systemd-nspawn , docker ou rkt AUR</p>
<h2id="conteneurs-privilégiés-ou-non-privilégiés">Conteneurs “privilégiés” ou “non privilégiés”</h2>
<p>Les LXC peuvent être configurés pour s’exécuter dans des configurations <strong>privilégiées (privileged)</strong> ou <strong>non privilégiées (unprivileged)</strong></p>
<p>En général, l’<u>exécution d'un conteneur **non privilégié** est considérée comme plus sûre</u> que l’exécution d’un conteneur privilégié , car les conteneurs non privilégiés ont un degré d’isolation accru en raison de leur conception. La clé de ceci est le mappage de l’UID racine dans le conteneur à un UID non root sur l’hôte, ce qui rend plus difficile pour un piratage à l’intérieur du conteneur d’avoir des conséquences sur le système hôte. En d’autres termes, si un attaquant parvient à s’échapper du conteneur, il ou elle devrait se retrouver avec des droits limités ou inexistants sur l’hôte.</p>
<p>Les packages de noyau Arch linux , linux-lts et linux-zen fournissent actuellement une prise en charge prête à l’ emploi pour les conteneurs non privilégiés . De la même façon, avec le package renforcé Linux , les conteneurs non privilégiés ne sont disponibles que pour l’administrateur système; avec des modifications de configuration du noyau supplémentaires requises, car les espaces de noms des utilisateurs sont désactivés par défaut pour les utilisateurs normaux. Cet article contient des informations permettant aux utilisateurs d’exécuter l’un ou l’autre type de conteneur, mais des étapes supplémentaires peuvent être nécessaires pour utiliser des conteneurs non privilégiés .</p>
<p><strong>Un exemple pour illustrer les conteneurs non privilégiés</strong><br>
Pour illustrer la puissance du mappage d’UID, considérez la sortie ci-dessous d’un conteneur non privilégié en cours d’exécution. Nous y voyons les processus conteneurisés appartenant à l’utilisateur root du conteneur dans la sortie de ps :</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>[root@unprivileged_container /]# ps -ef | head -n 5
<p>Sur l’hôte, cependant, ces processus “root” conteneurisés sont en fait exécutés en tant qu’utilisateur mappé (ID>100000), plutôt que l’utilisateur racine réel de l’hôte :</p>
<p>L’installation de <strong>lxc</strong> et <strong>arch-install-scripts</strong> permettra au système hôte d’exécuter des lxcs <strong>privilégiés</strong>.</p>
</blockquote>
<p><strong>Activer la prise en charge pour exécuter des conteneurs “non privilégiés” (facultatif)</strong><br>
Modifiez <strong>/etc/lxc/default.conf</strong> pour y ajouter les lignes suivantes:</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>lxc.idmap = u 0 100000 65536
lxc.idmap = g 0 100000 65536
</code></pre></div></div>
<p>Enfin, créez <strong>/etc/subuid</strong> et <strong>/etc/subgid</strong> pour contenir le mappage avec les paires uid/gid conteneurisées pour chaque utilisateur qui sera en mesure d’exécuter les conteneurs.<br>
L’exemple ci-dessous est simplement pour l’utilisateur root (et l’unité système systemd):</p>
<p>En outre, l’exécution de conteneurs non privilégiés en tant qu’utilisateur non privilégié ne fonctionne que si vous déléguez un cgroup à l’avance (le modèle de délégation cgroup2 applique cette restriction, pas liblxc). Utilisez la commande systemd suivante pour déléguer le cgroup :</p>
<p><strong>Conteneurs non privilégiés sur des noyaux linux durcis et personnalisés</strong><br>
Les utilisateurs souhaitant exécuter des conteneurs <strong>non privilégiés</strong> sur Linux durci ou leur noyau personnalisé doivent effectuer plusieurs étapes de configuration supplémentaires.</p>
<p>Tout d’abord, un noyau est nécessaire qui prend en charge les espaces de noms d’utilisateurs (un noyau avec CONFIG_USER_NS). Tous les noyaux Arch Linux prennent en charge CONFIG_USER_NS. Cependant, en raison de problèmes de sécurité plus généraux, le noyau durci Linux est livré avec des espaces de noms d’utilisateurs activés uniquement pour l’ utilisateur root . Il existe deux options pour y créer des conteneurs non privilégiés :</p>
<ul>
<li>Démarrez les conteneurs non privilégiés uniquement en tant que root .</li>
<li>Activez le paramètre sysctlkernel.unprivileged_userns_clone pour permettre aux utilisateurs normaux d’exécuter des conteneurs non privilégiés. Cela peut être fait pour la session en cours avec sysctl kernel.unprivileged_userns_clone=1et peut être rendu permanent avec sysctl.d (5) .</li>
</ul>
<h3id="configuration-du-réseau-hôte">Configuration du réseau hôte</h3>
<p>Les LXC prennent en charge différents types de réseaux virtuels et périphériques (voir lxc.container.conf (5) ). Un périphérique de pont sur l’hôte est requis pour la plupart des types de réseaux virtuels, comme illustré dans cette section.</p>
<p>Il y a plusieurs configurations principales à considérer:</p>
<ol>
<li>Le <u>**pont hôte** (host bridge)</u> nécessite que le gestionnaire de réseau de l’hôte gère une interface de pont partagée. L’hôte et tout lxc se verront attribuer une adresse IP dans le même réseau (par exemple 192.168.1.x). Cela pourrait être plus simpliste dans les cas où l’objectif est de conteneuriser un service exposé au réseau comme un serveur Web ou un serveur VPN. L’utilisateur peut considérer le lxc comme simplement un autre PC sur le LAN physique et transférer les ports nécessaires dans le routeur en conséquence. La simplicité supplémentaire peut également être considérée comme un vecteur de menace supplémentaire, encore une fois, si le trafic WAN est acheminé vers le lxc, le fait qu’il s’exécute sur une plage distincte présente une surface de menace plus petite.</li>
<li>Le <u>**pont NAT** (NAT bridge)</u> ne nécessite pas le gestionnaire de réseau de l’hôte pour gérer le pont. lxc est livré avec lxc-netlequel crée un pont NAT appelé lxcbr0. Le pont NAT est un pont autonome avec un réseau privé qui n’est pas ponté vers le périphérique Ethernet de l’hôte ou vers un réseau physique. Il existe en tant que sous-réseau privé dans l’hôte.</li>
</ol>
<h4id="utilisation-dun-pont-hôte">Utilisation d’un pont hôte</h4>
<h4id="utilisation-dun-pont-nat">Utilisation d’un pont NAT</h4>
<p>Installez <strong>dnsmasq</strong> qui est une dépendance pour <strong>lxc-net</strong> et avant de démarrer le pont, créez d’abord un fichier de configuration pour celui-ci:</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code># Laissez USE_LXC_BRIDGE à "true" si vous voulez utiliser lxcbr0 pour votre
# de conteneurs. Mettez "false" si vous utilisez virbr0 ou un autre
# bridge, ou mavlan vers le NIC de votre hôte.
USE_LXC_BRIDGE="true"
# Si vous changez le LXC_BRIDGE pour autre chose que lxcbr0, alors
# vous devrez également mettre à jour votre /etc/lxc/default.conf ainsi que le
# configuration (/var/lib/lxc/<container>/config) pour tous les conteneurs
# déjà créé en utilisant la configuration par défaut pour refléter le nouveau pont
# nom.
# Si vous avez installé le démon dnsmasq, vous devrez également mettre à jour
# /etc/dnsmasq.d/lxc et redémarrez le démon dnsmasq à l'échelle du système.
LXC_BRIDGE="lxcbr0"
LXC_ADDR="10.0.3.1"
LXC_NETMASK="255.255.255.0"
LXC_NETWORK="10.0.3.0/24"
LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"
LXC_DHCP_MAX="253"
# Décommentez la ligne suivante si vous souhaitez utiliser un fichier conf pour le lxcbr0
# dnsmasq. For instance, you can use 'dhcp-host=mail1,10.0.3.100' to have
# container 'mail1' always get ip address 10.0.3.100.
#LXC_DHCP_CONFILE=/etc/lxc/dnsmasq.conf
# Décommentez la ligne suivante si vous voulez que le dnsmasq de lxcbr0 résolve le .lxc
avril 29 12:13:10 yannick-pc dnsmasq-dhcp[23619]: DHCP, plage d'adresses IP 10.0.3.2 -- 10.0.3.254, durée de b>
avril 29 12:13:10 yannick-pc dnsmasq-dhcp[23619]: DHCP, sockets bound exclusively to interface lxcbr0
avril 29 12:13:10 yannick-pc dnsmasq[23619]: Lecture de /etc/resolv.conf
avril 29 12:13:10 yannick-pc dnsmasq[23619]: utilise le serveur de nom 10.16.0.1#53
avril 29 12:13:10 yannick-pc dnsmasq[23619]: utilise le serveur de nom fdda:d0d0:cafe:1302::#53
avril 29 12:13:10 yannick-pc dnsmasq[23619]: utilise le serveur de nom 80.67.169.12#53
avril 29 12:13:10 yannick-pc dnsmasq[23619]: utilise le serveur de nom 80.67.169.40#53
avril 29 12:13:10 yannick-pc dnsmasq[23619]: utilise le serveur de nom fd0f:ee:b0::1#53
avril 29 12:13:10 yannick-pc dnsmasq[23619]: lecture /etc/hosts - 4 adresses
avril 29 12:13:10 yannick-pc systemd[1]: Finished LXC network bridge setup.
</code></pre></div></div>
<h3id="considérations-relatives-au-pare-feu">Considérations relatives au pare-feu</h3>
<p>Étant donné que le lxc fonctionne sur le sous-réseau 10.0.3.x, l’accès aux services tels que ssh, httpd, etc. devra être activement transmis au lxc. En principe, le pare-feu sur l’hôte doit transmettre le trafic entrant sur le port attendu du conteneur.</p>
<h4id="exemple-de-règle-iptables">Exemple de règle iptables</h4>
<p>Le but de cette règle est d’autoriser le trafic ssh vers le lxc:</p>
<p>Cette règle transfère le trafic TCP provenant du port 2221 à l’adresse IP du lxc sur le port 22.<br>
Remarque: Assurez-vous d’autoriser le trafic sur 2221 / tcp sur l’hôte et d’autoriser le trafic 22 / tcp sur lxc.</p>
<p>Pour ssh dans le conteneur depuis un autre PC sur le LAN, il faut ssh sur le port 2221 à l’hôte. L’hôte transmettra ensuite ce trafic au conteneur.</p>
<h3id="exécution-de-conteneurs-en-tant-quutilisateur-non-root">Exécution de conteneurs en tant qu’utilisateur non root</h3>
<p>Pour créer et démarrer des conteneurs en tant qu’utilisateur non root, une configuration supplémentaire doit être appliquée.</p>
<p>Créez le fichier usernet sous /etc/lxc/lxc-usernet. Selon la lxc-usernetpage de manuel, l’entrée par ligne est:</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>user type bridge number
</code></pre></div></div>
<p>Configurez le fichier avec l’utilisateur devant créer des conteneurs. Le pont sera le même que celui défini dans /etc/default/lxc-net.</p>
<p>Une copie de la /etc/lxc/default.confest nécessaire dans le répertoire personnel de l’utilisateur non root, par exemple ~/.config/lxc/default.conf(créez le répertoire si nécessaire).</p>
<p>L’exécution de conteneurs en tant qu’utilisateur non root nécessite des +xautorisations sur ~/.local/share/. Apportez cette modification avec chmod avant de démarrer un conteneur.</p>
<h2id="création-de-conteneurs">Création de conteneurs</h2>
<p>Les conteneurs sont construits en utilisant lxc-create. Avec la sortie de lxc-3.0.0-1, l’amont a déprécié les modèles stockés localement.</p>
<h3id="chemins-standards">Chemins standards</h3>
<p>Un mot rapide sur la façon dont LXC fonctionne habituellement et où il stocke ses fichiers:</p>
<ul>
<li>/var/lib/lxc (emplacement par défaut pour les conteneurs)</li>
<li>/var/lib/lxcsnap (emplacement par défaut pour les instantanés)</li>
<li>/var/cache/lxc (emplacement par défaut pour le cache du modèle)</li>
<li>$HOME/.local/share/lxc (emplacement par défaut pour les conteneurs non privilégiés)</li>
<li>$HOME/.local/share/lxcsnap (emplacement par défaut pour les instantanés non privilégiés)</li>
<li>$HOME/.cache/lxc (emplacement par défaut pour le cache de modèle non privilégié)</li>
</ul>
<p>Le chemin par défaut, également appelé <strong>lxcpath</strong>, peut être remplacé sur la ligne de commande avec l’option <codeclass="language-plaintext highlighter-rouge">-P</code> ou une fois pour toutes en définissant <strong>“lxcpath = /new/path”</strong> dans <codeclass="language-plaintext highlighter-rouge">/etc/lxc/lxc.conf</code> (ou <codeclass="language-plaintext highlighter-rouge">$HOME/.config /lxc/lxc.conf</code> pour les conteneurs non privilégiés).<br>
Le répertoire d’instantanés est toujours <strong>“snap”</strong> ajouté à <strong>lxcpath</strong> afin qu’il suive comme par magie lxcpath. Le cache de modèle est malheureusement codé en dur et ne peut pas être facilement déplacé sans compter sur des montages liés ou des liens symboliques.<br>
La configuration par défaut utilisée pour tous les conteneurs au moment de la création provient de
/etc/lxc/default.conf (pas encore d’équivalent non privilégié). <br>
Les modèles eux-mêmes sont stockés dans /usr/share/lxc/templates.</p>
<h3id="créer-un-conteneur-arch">Créer un conteneur Arch</h3>
<p>Pour créer un conteneur Arch, appelez comme ceci:</p>
Using image from <spanclass="nb">local </span>cache
Unpacking the rootfs
<spanclass="nt">---</span>
You just created a Debian buster amd64 <spanclass="o">(</span>20200429_05:24<spanclass="o">)</span> container.
To <spanclass="nb">enable </span>SSH, run: apt <spanclass="nb">install </span>openssh-server
No default root or user password are <spanclass="nb">set </span>by LXC.
</code></pre></div></div>
<p><strong>Astuce:</strong> les utilisateurs peuvent éventuellement installer <strong>haveged</strong> et lancer haveged.service à éviter un blocage perçu pendant le processus de configuration en attendant que l’entropie du système soit amorcée. Sans cela, la génération de clés privées / GPG peut ajouter une longue attente au processus.<br>
<strong>Astuce:</strong> Les utilisateurs de Btrfs peuvent ajouter -B btrfspour créer un sous-volume Btrfs pour stocker les rootfs conteneurisés. Cela est pratique si vous clonez des conteneurs à l’aide de la lxc-clonecommande. Les utilisateurs ZFS peuvent utiliser -B zfs, en conséquence.<br>
<strong>Note</strong> : les utilisateurs souhaitant utiliser les anciens modèles peuvent les trouver dans lxc-templatesAUR ou bien les utilisateurs peuvent créer leurs propres modèles avec distrobuilderAUR.</p>
<h2id="configuration-des-conteneurs">Configuration des conteneurs</h2>
<p>Les exemples ci-dessous peuvent être utilisés aussi bien avec des conteneurs privilégiés que non privilégiés.<br>
Notez que pour les conteneurs non privilégiés, des lignes supplémentaires seront présentes par défaut qui ne sont pas montrées dans les exemples, y compris les valeurs lxc.idmap = u 0 100000 65536 et lxc.idmap = g 0 100000 65536 définies en option dans la section #Enable support to run unprivileged containers (optional).</p>
<h3id="configuration-de-base-avec-mise-en-réseau">Configuration de base avec mise en réseau</h3>
<p>Note : Avec la sortie de lxc-1:2.1.0-1, de nombreuses options de configuration ont été modifiées. Les conteneurs existants doivent être mis à jour ; les utilisateurs sont dirigés vers le tableau de ces changements dans les <ahref="https://discuss.linuxcontainers.org/t/lxc-2-1-has-been-released/487">notes de version v2.1</a>.</p>
<h3id="ressources-système-à-virtualiserisoler-varliblxccontainer_nameconfig">Ressources système à virtualiser/isoler (/var/lib/lxc/CONTAINER_NAME/config)</h3>
<p>Les ressources système à virtualiser/isoler lorsqu’un processus utilise le conteneur sont définies dans <strong>/var/lib/lxc/CONTAINER_NAME/config</strong><br>
Par défaut, le processus de création effectuera une configuration minimale sans support réseau. Vous trouverez ci-dessous un exemple de configuration avec mise en réseau fourni par <codeclass="language-plaintext highlighter-rouge">lxc-net.service</code> :</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code># Template used to create this container: /usr/share/lxc/templates/lxc-archlinux
# Parameters passed to the template:
# For additional config options, please look at lxc.container.conf(5)
<h2id="considérations-sur-le-programme-xorg-facultatif">Considérations sur le programme Xorg (facultatif)</h2>
<p>Afin d’exécuter des programmes sur l’écran de l’hôte, certains montages de liaison doivent être définis afin que les programmes conteneurisés puissent accéder aux ressources de l’hôte. Ajoutez la section suivante dans <strong>/var/lib/lxc/playtime/config</strong> :</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>## for xorg
<p>Si une erreur de permission est toujours présente dans l’invité LXC, appelez <codeclass="language-plaintext highlighter-rouge">xhost +</code> dans l’hôte pour permettre à l’invité de se connecter au serveur d’affichage de l’hôte. Prenez note des problèmes de sécurité que pose l’ouverture du serveur d’affichage en procédant ainsi. En outre, ajoutez la ligne suivante <strong>avant</strong> les lignes de montage de liaison ci-dessus.</p>
<p><strong>Note :</strong> Cela ne fonctionnera pas si vous utilisez des conteneurs non privilégiés.</p>
<h2id="considérations-sur-lopenvpn">Considérations sur l’OpenVPN</h2>
<p>Les utilisateurs souhaitant utiliser OpenVPN dans le conteneur sont priés de se diriger soit vers <ahref="https://wiki.archlinux.org/index.php/OpenVPN_(client)_in_Linux_containers">OpenVPN (client) dans des conteneurs Linux</a> et/ou <ahref="https://wiki.archlinux.org/index.php/OpenVPN_(server)_in_Linux_containers">OpenVPN (serveur) dans des conteneurs Linux</a>.</p>
<h2id="gestion-des-conteneurs">Gestion des conteneurs</h2>
<h3id="utilisation-de-base">Utilisation de base</h3>
<h4id="liste-des-conteneurs---lxc-ls--f">Liste des conteneurs - lxc-ls -f</h4>
<p>Pour répertorier tous les conteneurs LXC installés :</p>
<h4id="démarrerarrêter-un-conteneur-lxc">Démarrer/Arrêter un conteneur LXC</h4>
<p>Systemd peut être utilisé pour démarrer et arrêter les LXC via <codeclass="language-plaintext highlighter-rouge">lxc@CONTAINER_NAME.service</code><br>
Activez <codeclass="language-plaintext highlighter-rouge">lxc@CONTAINER_NAME.service</code> pour qu’il démarre lorsque le système hôte démarre.</p>
<p>Les utilisateurs peuvent également démarrer/arrêter des LXC sans systemd.<br>
<p>Une fois connecté, traitez le conteneur comme n’importe quel autre système linux, définissez le mot de passe root, créez des utilisateurs, installez des paquets, etc.</p>
<h4id="sattacher-à-un-conteneur">S’attacher à un conteneur</h4>
<p>Cela fonctionne à peu près de la même manière que la console lxc, mais cela provoque des démarrages avec une invite de la racine à l’intérieur du conteneur, contournant la connexion.<br>
<strong>Sans le drapeau <codeclass="language-plaintext highlighter-rouge">--clear-env</code>, l’hôte passera ses propres variables d’environnement dans le conteneur (y compris $PATH, donc certaines commandes ne fonctionneront pas lorsque les conteneurs sont basés sur une autre distribution).</strong></p>
<p>Les utilisateurs ayant besoin de gérer plusieurs conteneurs peuvent simplifier les tâches administratives (gestion des utilisateurs, mises à jour du système, etc.) en utilisant des instantanés. La stratégie consiste à mettre en place et à tenir à jour un seul conteneur de base, puis, si nécessaire, à le cloner (instantané). La puissance de cette stratégie est que l’espace disque et la surcharge du système sont vraiment minimisés puisque les instantanés utilisent un montage par superposition pour n’écrire que sur le disque, uniquement les différences de données. Le système de base est en lecture seule, mais les modifications dans les instantanés sont autorisées par les superpositions.</p>
<p>Note : les superpositions pour les conteneurs non privilégiés ne sont pas supportées dans le noyau principal actuel d’Arch Linux pour des raisons de sécurité.</p>
<p>Par exemple, configurez un conteneur comme indiqué ci-dessus. Nous l’appellerons “base” pour les besoins de ce guide. Créez maintenant 2 instantanés de “base” que nous appellerons “snap1” et “snap2” avec ces commandes :</p>
<divclass="language-shell highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>lxc-copy <spanclass="nt">-n</span> base <spanclass="nt">-N</span> snap1 <spanclass="nt">-B</span> overlayfs <spanclass="nt">-s</span>
lxc-copy <spanclass="nt">-n</span> base <spanclass="nt">-N</span> snap2 <spanclass="nt">-B</span> overlayfs <spanclass="nt">-s</span>
</code></pre></div></div>
<p>Note : Si une IP statique a été définie pour le lxc “base”, elle devra être modifiée manuellement dans la configuration pour “snap1” et pour “snap2” avant de les lancer. Si le processus doit être automatisé, un script utilisant sed peut le faire automatiquement bien que cela dépasse le cadre de cette section du wiki.</p>
<p>Les instantanés peuvent être lancés/arrêtés comme n’importe quel autre conteneur. Les utilisateurs peuvent éventuellement détruire les instantanés et toutes les nouvelles données qu’ils contiennent avec la commande suivante. Notez que le lxc “de base” sous-jacent n’est pas touché :</p>
<p>Des unités systémiques et des scripts de wrapper pour gérer les instantanés pour pi-hole et OpenVPN sont disponibles pour automatiser le processus dans les instantanés du service lxc.</p>
<h4id="conversion-dun-conteneur-privilégié-en-un-conteneur-non-privilégié">Conversion d’un conteneur privilégié en un conteneur non privilégié</h4>
<p>Une fois que le système a été configuré pour utiliser des conteneurs non privilégiés (voir, #Enable support to run unprivileged containers (optional)), nsexec-bzrAUR contient un utilitaire appelé uidmapshift qui est capable de convertir un conteneur privilégié existant en un conteneur non privilégié pour éviter une reconstruction totale de l’image.</p>
<p>Attention :</p>
<ul>
<li>Il est recommandé de sauvegarder l’image existante avant d’utiliser cet utilitaire !</li>
<li>Cet utilitaire ne changera pas les UIDs et GIDs dans ACL, les utilisateurs devront les changer manuellement !</li>
</ul>
<p>Appelez l’utilitaire pour effectuer une conversion de la sorte :</p>
<p>Des options supplémentaires sont disponibles en appelant simplement uidmapshift sans aucun argument.</p>
<h4id="exécution-de-programmes-xorg">Exécution de programmes Xorg</h4>
<p>Soit attacher à ou SSH dans le conteneur cible et préfixer l’appel au programme avec le DISPLAY ID de la session X de l’hôte. Pour la plupart des configurations simples, l’affichage est toujours 0.</p>
<p>Un exemple d’exécution de Firefox à partir du conteneur dans l’affichage de l’hôte :</p>
<p>Pour éviter de s’attacher ou de se connecter directement au conteneur, on peut aussi utiliser les éléments suivants sur l’hôte pour automatiser le processus :</p>
<em>pam_securetty(login:auth): access denied: tty ‘pts/0’ is not secure !</em></p>
<p>Supprimez /etc/securetty[1] et /usr/share/factory/etc/securetty sur le système de fichiers du conteneur. Ajoutez-les éventuellement à <codeclass="language-plaintext highlighter-rouge">NoExtract</code> dans <strong>/etc/pacman.conf</strong> pour éviter qu’ils ne soient réinstallés.</p>
<p>Alternativement, créer un nouvel utilisateur dans lxc-attach et l’utiliser pour se connecter au système, puis passer en root.</p>
<h3id="pas-de-connexion-au-réseau-avec-veth-dans-la-configuration-du-conteneur">Pas de connexion au réseau avec veth dans la configuration du conteneur</h3>
<p>Si vous ne pouvez pas accéder à votre LAN ou WAN avec une interface réseau configurée en tant que veth et configurée via /etc/lxc/containername/config. Si l’interface virtuelle se voit attribuer l’adresse IP et doit être connectée correctement au réseau.</p>
<divclass="language-plaintext highlighter-rouge"><divclass="highlight"><preclass="highlight"><code>ip addr show veth0
inet 192.168.1.111/24
</code></pre></div></div>
<p>Vous pouvez désactiver toutes les formules IP statiques pertinentes et essayer de régler l’IP dans le conteneur amorcé, comme vous le feriez normalement.</p>
<p>L’erreur peut se produire lorsqu’une commande de base (ls, cat, etc.) sur un conteneur attaché est tapée alors qu’une autre distribution Linux est conteneurisée par rapport au système hôte (par exemple, le conteneur Debian dans le système hôte Arch Linux). Lors de l’attachement, utilisez l’argument <codeclass="language-plaintext highlighter-rouge">--clear-env</code> :</p>
You just created a Debian buster amd64 <spanclass="o">(</span>20200429_05:24<spanclass="o">)</span> container.
To <spanclass="nb">enable </span>SSH, run: apt <spanclass="nb">install </span>openssh-server
No default root or user password are <spanclass="nb">set </span>by LXC.
</code></pre></div></div>
<h3id="configurer-le-réseau">Configurer le réseau</h3>
<p>Installez le paquet <em>libvirt</em> car nous avons besoin du programme <em>virsh</em>.
Nous aurons également besoin de <em>ebtables</em> et <em>dnsmasq</em> pour la mise en réseau NAT/DHCP par défaut. <ahref="https://wiki.archlinux.org/index.php/libvirt#Server">(*)</a></p>
<li>Ces deux chemins sont <strong>relatifs à la machine hôte</strong>.</li>
<li>L’emplacement de la racine fs dans le conteneur peut être trouvé à l’adresse
<ul>
<li>Pour les conteneurs LXC normaux : <codeclass="language-plaintext highlighter-rouge">/var/lib/lxc/mycontainer/rootfs/</code>
</li>
<li>Pour les conteneurs LXC <em>non privilégiés</em> : <codeclass="language-plaintext highlighter-rouge">$HOME/.local/share/lxc/mycontainer/rootfs</code>`.</li>
</ul>
</li>
</ul>
</li>
</ul>
<p><strong>Note</strong> : Si l’utilisateur de l’hôte n’existe pas dans le conteneur, le conteneur sera quand même monté, mais avec <codeclass="language-plaintext highlighter-rouge">nobody:nogroup</code> comme propriétaire. Cela peut ne pas poser de problème, sauf si vous devez écrire dans ces fichiers, auquel cas vous devrez donner à tout le monde le droit d’écrire dans ce dossier. (i.e. <codeclass="language-plaintext highlighter-rouge">chmod -R go+w /dossier/to/share</code>)</p>
<h3id="exemple">Exemple</h3>
<p>Je veux partager <codeclass="language-plaintext highlighter-rouge">/home/media/foobar</code> avec mon conteneur <em>non privilégié</em><codeclass="language-plaintext highlighter-rouge">debian-lxc</code>. Dans <codeclass="language-plaintext highlighter-rouge">debian-lxc</code>, je veux que ce dossier se trouve à <codeclass="language-plaintext highlighter-rouge">/mnt/partage</code>.</p>
<span>PRÉCÉDENT</span><ahref="/2020/04/29/Comment_utiliser_les_montages_bind_dans_linux.html">Comment utiliser les montages bind dans linux</a>
</div>
<divclass="next">
<span>SUIVANT</span><ahref="/2020/04/30/GoLang_executer_un_binaire_Go_en_tant_que_service_systemd.html">GoLang exécuter un binaire Go en tant que service systemd</a>
</div>
</div>
</div>
</div>
<script>(function(){
var SOURCES = window.TEXT_VARIABLES.sources;
window.Lazyload.js(SOURCES.jquery, function() {
$(function() {
var $this ,$scroll;
var $articleContent = $('.js-article-content');
var hasSidebar = $('.js-page-root').hasClass('layout--page--sidebar');
var scroll = hasSidebar ? '.js-page-main' : 'html, body';
