Un conteneur non privilégié
Un conteneur non privilégié jppInitialisation d'un conteneur non privilégié :
Comme la plupart des "templates" ne permettent pas de charger des images utilisables en mode non-privilégié il est recommandé d'utiliser le template "download".
Celui-ci nécessite quelques paramètres supplémentaires pour fonctionner en mode automatique. Si ces paramètres ne sont pas fourni le template vous demande les données en affichant pour chaque choix une liste des possibilités, la liste des distributions disponibles est impressionnante ...
Mais avant de créer le premier conteneur non privilégié il faut effectuer quelques mises à jour (utilisateur "testlxc" créé pour la circonstance) :
- Créer un répertoire pour stocker nos conteneurs, sinon ceux-ci seront créés dans .local/share/lxc. Ici j'ai créé un répertoire $HOME/VM/LXC, volontairement en deuxième niveau en dessous de $HOME.
- Créer le fichier /etc/lxc/lxc-usernet contenant :
# user type_de_réseau pont nombre
testlxc veth br2 10
- Créer le répertoire $HOME/.config/LXC
- Créer dans ce répertoire un fichier "lxc.conf" contenant :
lxc.lxcpath = /home/testlxc/VM/LXC
lxc.default_config = /home/testlxc/.config/lxc/default.conf
- Créer un fichier "default.conf" contenant :
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
###
lxc.idmap = u 0 296608 65536
lxc.idmap = g 0 296608 65536
Ces valeurs sont issues de :
grep testlxc /etc/subuid (pour la ligne "u")
grep testlxc /etc/subgid (pour la ligne "g")
Ouf, c'est fini pour la configuration.
Pour les tests j'ai utilisé un script (TC) avec log détaillé dans un fichier, surtout pour les premiers tests :
LOGPRI=DEBUG
TEMPLATE=download
NOM=debian-d
LOTG=" --logfile=/dev/stdout --logpriority=${LOGPRI} "
COMPL=' -- --dist debian --release buster --arch amd64 '
REP=' -P /home/testlxc/VM/LXC/'
lxc-create -n ${NOM} ${REP} -t ${TEMPLATE} ${LOG} ${COMPL} 2>&1 | tee TC.LOG
Et on exécute notre script :
./TC
No such file or directory - Failed to open tty
No such file or directory - Failed to open tty
Using image from local cache
Unpacking the rootfs
.....
You just created a Debian buster amd64 (20200419_05:24) container.
To enable SSH, run: apt install openssh-server
No default root or user password are set by LXC.
Les deux "No such file..." n'ont pas l'air de gêner ...
On va voir de qui se passe dans ce nouveau conteneur :
lxc-start debian-d
lxc-attach debian-d
root@debian-d:/# ls -al
total 68
drwxr-xr-x 21 root root 4096 Apr 19 05:29 .
drwxr-xr-x 21 root root 4096 Apr 19 05:29 ..
drwxr-xr-x 2 root root 4096 Apr 19 05:27 bin
drwxr-xr-x 2 root root 4096 Feb 1 17:09 boot
drwxr-xr-x 6 root root 500 Apr 20 11:43 dev
drwxr-xr-x 40 root root 4096 Apr 20 11:43 etc
drwxr-xr-x 2 root root 4096 Feb 1 17:09 home
drwxr-xr-x 10 root root 4096 Apr 19 05:26 lib
drwxr-xr-x 2 root root 4096 Apr 19 05:25 lib64
....
drwxr-xr-x 2 root root 4096 Apr 19 05:25 srv
dr-xr-xr-x 12 nobody nogroup 0 Apr 20 11:43 sys
drwxrwxrwt 7 root root 4096 Apr 20 11:43 tmp
drwxr-xr-x 10 root root 4096 Apr 19 05:25 usr
drwxr-xr-x 11 root root 4096 Apr 19 05:25 var
Ceci ressemble bien au contenu d'une machine réelle.
On personnalise rapidement le mot de passe de "root" afin de sécuriser un peu ce conteneur.
on en sort par "exit" puis "lxc-stop debian-d" ou par :
"systemctl poweroff" plus court !
Maintenant il reste à connecter notre machine au réseau ...
Non privilégié avec réseau
Non privilégié avec réseau jppConnecter le conteneur au réseau.
Cette action doit être réalisée conteneur stoppé.
Il faut compléter le fichier "config" de notre conteneur avec les éléments liés au réseau, on utilise ici le même pont que pour le premier conteneur (accessible en "br2") :
lxc.net.0.type = veth
lxc.net.0.link = br2
lxc.net.0.name = eth0
lxc.net.0.ipv4.address = 192.168.3.12/24
lxc.net.0.ipv4.gateway = 192.168.3.1
lxc.net.0.flags = up
On relance le tout et on regarde :
~$ lxc-start debian-d
~$ lxc-attach debian-d
root@debian-d:/# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.3.1 0.0.0.0 UG 0 0 0 eth0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
La commande "ping" ne fait pas partie de l'image (bizarre, vous avez dit bizarre?), comme c'est une commande "simple" il suffit de la copier depuis la machine "maître" qui est aussi une Debian Buster (en "root") :
cp /bin/ping /home/testlxc/VM/LXC/debian-d/rootfs/bin
Et dans le conteneur ça marche :
ping -c1 google.fr
PING google.fr (216.58.213.131) 56(84) bytes of data.
64 bytes from par21s03-in-f131.1e100.net (216.58.213.131): icmp_seq=1 ttl=52 time=5.31 ms
Il y a bien du réseau dans ce conteneur, on va y installer un serveur ssh comme proposé lors de la création du conteneur :
apt-get update --> fonctionne très bien
apt-get install openssh-server
.....
Creating config file /etc/ssh/sshd_config with new version
Creating SSH2 RSA key; this may take some time ...
2048 SHA256:jd2wgb/fFjgQZL1bXr9KHu2aK1eA8+6r0G0dx+Rro4c root@debian-d (RSA)
Creating SSH2 ECDSA key; this may take some time ...
256 SHA256:Lr1fp1Ov0PBVG+q0oOs8v5PMaBOh105kXA7rp3Ri9Wg root@debian-d (ECDSA)
Creating SSH2 ED25519 key; this may take some time ...
256 SHA256:+74AKYdcsTI+0Nz/V3YEdo1CBnPC89JY74rKhkkcGE8 root@debian-d (ED25519)
Created symlink /etc/systemd/system/sshd.service → /lib/systemd/system/ssh.service.
Created symlink /etc/systemd/system/multi-user.target.wants/ssh.service → /lib/systemd/system/ssh.service.
rescue-ssh.target is a disabled or a static unit, not starting it.
Processing triggers for systemd (241-7~deb10u3) ...
Processing triggers for libc-bin (2.28-10) ...
Tout est donc pour le mieux.
Après une petite modification dans /etc/ssh/sshd_config pour autoriser la connexion de "root" et un redémarrage du service sshd il est possible de se connecter en ssh dans notre conteneur :
ssh root@192.168.3.12
root@192.168.3.12's password:
Linux debian-d 5.6.4 #3 SMP Sat Apr 18 15:53:49 CEST 2020 x86_64
...
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Apr 20 15:57:58 2020 from 192.168.3.1
root@debian-d:~#
Comme vous pourrez le constater ce conteneur n'a pas de limites, il peut "bouffer" toute la mémoire et occuper autant de CPU qu'il lui plait, truster toutes les IO ...
Il va falloir lui donner des limites à ne pas franchir afin de laisser des possibilités pour d'autres conteneurs ...