OVS – Podman / Debian 12 : 2/2

Mémento 5.2 - Conteneurs LXC

Vous allez à présent créer un conteneur plus sécurisé dit rootless, celui-ci diminuant le risque de voir l'utilisateur root du conteneur obtenir tous les droits sur l'hôte ovs.

Le conteneur rootless (non privilégié) se veut plus isolé de l'hôte LXC qu'un conteneur rootfull.

6 - Conteneur ctn3 en mode rootless

Pour le raccordement réseau d'un conteneur rootless, Podman utilise par défaut le paquet slirp4netns qui fournit une interface réseau virtuelle de type Tun/Tap.

Le conteneur partage alors le même espace de noms réseau que l'hôte, ce qui signifie qu'il partage la même interface réseau, les mêmes tables de routage, etc...

Le conteneur rootless ne disposant pas par défaut d'une adresse IP, c'est le mappage de ports qui est utilisé pour joindre celui-ci.

Nota : Depuis la version 4.0, il est possible de faire appel à netavark pour configurer le réseau (non traité ici).

Le conteneur ctn3 sera donc raccordé par défaut ainsi :

6.1 - Création du conteneur Podman ctn3

Les conteneurs rootless sont créés et accessibles sans avoir besoin d'être root ou un utilisateur du groupe sudo.

Ceci est plus sécurisé car l'on ne peut pas devenir root sur l'hôte même si l'on réussit à sortir du conteneur.

Créez et lancez le conteneur ctn3 comme suit :

$ podman pull docker.io/louislam/uptime-kuma:1

$ podman volume create uptime-kuma

$ podman run -dit --name ctn3 -p 3001:3001 -v uptime-kuma:/app/data uptime-kuma:1

Les données persistantes d'Uptime Kuma seront stockées sur le volume créé et resteront disponibles même après une suppression ou une MAJ du conteneur.

Détail des options -dit et -p :
Le d lance le conteneur en arrière plan.
Le i autorise le mode interactif avec le conteneur.
Le t alloue un pseudo terminal au conteneur.
Le p mappe le port 3001 d'ovs sur le port 3001 de ctn3.

Vérifiez le téléchargement et les créations :

$ podman images
$ podman volume ls
$ podman ps

Retour de la Cde podman ps :

Capture - Podman  : Conteneur ctn3 créé et démarré
Podman : Conteneur ctn3 créé et démarré

L'image, le volume et le conteneur se trouvent dans :
/home/switch/.local/share/containers/storage/*

6.2 - Interaction avec le conteneur

Les dépôts Debian déclarés dans l'image uptime-kuma:1 d'octobre 2025 ne sont pas à jour.

Connectez-vous sur ctn3 :

$ podman exec -it ctn3 bash

Un prompt root@ID du conteneur ctn3 doit s'afficher :

Capture - Podman : Arborescence du conteneur ctn3
Podman : Arborescence du conteneur ctn3

Modifiez ensuite les dépôts comme suit :

[root@106374e6e828:/#] echo "deb http://archive.debian.org/debian buster main contrib non-free" | sudo tee /etc/apt/sources.list

[root@106374e6e828:/#] echo "deb http://archive.debian.org/debian-security buster/updates main contrib non-free" | sudo tee -a /etc/apt/sources.list

[root@106374e6e828:/#] echo "deb http://archive.debian.org/debian buster-updates main contrib non-free" | sudo tee -a /etc/apt/sources.list

[root@106374e6e828:/#] echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared buster main" | sudo tee /etc/apt/sources.list.d/cloudflared.list

Vérifiez le résultat :

[root@106374e6e828:/#] cat /etc/apt/sources.list

Retour normal :

deb http://archive.debian.org/debian buster main contrib non-free

deb http://archive.debian.org/debian-security buster/updates main contrib non-free

deb http://archive.debian.org/debian buster-updates main contrib non-free
[root@106374e6e828:/#] cat /etc/apt/sources.list.d/cloudflared.list

Retour normal :

deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared buster main

Le retour de la Cde cat /etc/resolv.conf doit montrer l'IP de la box Internet et les Cdes de mise à jour apt update et apt upgrade doivent maintenant fonctionner.

Vérifiez depuis le navigateur Firefox de srvlan que l'URL http://192.168.3.15:3001 affiche bien la page setup de l'application Uptime Kuma.

L'IP de l'URL est celle de l'hôte du conteneur soit ovs.

Ajoutez ensuite le paquet iproute2 au conteneur :

[root@106374e6e828:/app#] apt install iproute2

et observez la configuration réseau par défaut :

[root@106374e6e828:/app#] ip address
Capture - Podman : Configuration réseau de ctn3
Podman : Configuration réseau de ctn3

Le résultat montre la présence de l'interface TAP (tap0) au sein du conteneur.

Si non installé, ajoutez également le paquet iputils-ping puis autorisez l'usage de la Cde ping depuis ctn3 en modifiant le paramètre suivant au niveau de l'hôte ovs :

[root@106374e6e828:/app#] exit

$ sudo sysctl -w "net.ipv4.ping_group_range=0     2000000"

Fichier modifié = /proc/sys/net/ipv4/ping_group_range (valeurs par défaut = 1 0).

Reconnectez-vous sur ctn3 et tester la Cde ping :

$ podman exec -it ctn3 bash

[root@106374e6e828:/app#] ping google.fr
Capture - Podman : Cde ping fonctionnelle depuis ctn3
Podman : Cde ping fonctionnelle depuis ctn3

Pour l'autoriser de façon permanente, procédez ainsi :

[root@106374e6e828:/app#] exit

$ sudo nano /etc/sysctl.d/99-allow-ping.conf

Entrez la ligne suivante :

net.ipv4.ping_group_range=0	2000000

7 - Sauvegarde du conteneur modifié

Sauvegardez les modifications réalisées au niveau du conteneur ctn3 en créant une image locale de l'application Uptime Kuma :

$ podman commit ctn3 uptime-kuma:2

Vérifiez la création de l'image locale :

$ podman images
Capture - Podman : Vue de l'image locale uptime-kuma:2
Podman : Vue de l'image locale uptime-kuma:2

et recréez le conteneur ctn3 à partir de celle-ci :

$ podman kill ctn3
$ podman rm ctn3

$ podman run -dit --name ctn3 -p 3001:3001 -v uptime-kuma:/app/data uptime-kuma:2

Vérifiez le démarrage du conteneur :

$ podman ps
Capture - Podman : Conteneur ctn3 issu de l'image locale
Podman : Conteneur ctn3 issu de l'image locale

8 - Démarrage automatique du conteneur

Podman fournit une Cde pour générer le service de démarrage automatique d'un conteneur.

Suivez la séquence de Cdes ci-dessous pour ctn3 :

$ cd /home/switch

$ sudo loginctl enable-linger switch
$ podman generate systemd --new --files --name ctn3
$ cat container-ctn3.service               # Lecture par curiosité

$ mkdir -p .config/systemd/user
$ mv container-ctn3.service .config/systemd/user/container-ctn3.service

$ podman stop ctn3

$ systemctl --user daemon-reload
$ systemctl --user start container-ctn3
$ systemctl --user status container-ctn3
$ systemctl --user enable container-ctn3

Puis rebootez la VM ovs et contrôlez le résultat :

$ podman ps

Le conteneur ctn3 doit avoir le statut UP.

9 - Tests divers sur le réseau virtuel

Connectez-vous sur le conteneur ctn3 :

$ podman exec -it ctn3 bash

et testez les pings suivants :

[root@... :/#] ping lemonde.fr           # Internet
[root@... :/#] ping 192.168.2.1         # VM srvsec
[root@... :/#] ping 192.168.4.2         # VM srvdmz
[root@... :/#] ping 192.168.3.4         # VM debian12-vm2

Tous doivent recevoir une réponse positive.

Testez de nouveau depuis srvlan l'URL d'accès à Uptime Kuma soit http://192.168.3.15:3001.

Si la page setup s'affiche, alors c'est terminé.

Image - Rédacteur satisfait


Voilà pour les bases de Podman !
Le mémento 6.1 vous attend pour
découvrir l'accès à distance sur
les VM et les conteneurs.

2 réflexions au sujet de “OVS – Podman / Debian 12 : 2/2”

  1. Bonjour,
    Soucis pour installer dans cnt3 iproute2
    switch@ovs:~$ podman exec -it ctn3 bash
    root@31702b7905b5:/app# ping google.fr
    PING google.fr (172.217.20.163) 56(84) bytes of data.
    64 bytes from par10s49-in-f3.1e100.net (172.217.20.163): icmp_seq=1 ttl=255 time=7.84 ms
    64 bytes from par10s49-in-f3.1e100.net (172.217.20.163): icmp_seq=2 ttl=255 time=8.01 ms
    64 bytes from par10s49-in-f3.1e100.net (172.217.20.163): icmp_seq=3 ttl=255 time=8.24 ms
    ^C
    — google.fr ping statistics —
    3 packets transmitted, 3 received, 0% packet loss, time 5ms
    rtt min/avg/max/mdev = 7.840/8.030/8.243/0.165 ms
    root@31702b7905b5:/app# apt install iproute2
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    E: Unable to locate package iproute2
    root@31702b7905b5:/app#

    Remerciements

  2. Bonjour Fab,

    1) Le nameserver 10.0.2.3 désigne le serveur DHCP et non DNS fourni par VirtualBox au cas ou l’on utiliserait celui-ci.

    2) Pour le problème iproute, il semble que l’image uptime-kuma:1 utilise toujours un dépôt Debian 10 qui n’est plus accessible. Je vais travailler dessus.

    Cordialement

    InfoLoup

    Nota : Les articles Podman 1/2 et 2/2 ont été modifiés au niveau du service networknamespace et de la gestion des dépôts Debian 10 pour l’image uptime-kuma:1, résultat vérifié plusieurs fois.

Laisser un commentaire