Podman rootless et rootful sur les hôtes de la famille RHEL : stockage, subuid et lingering

Objectif

Comprendre la différence concrète entre Podman rootless et rootful sur un hôte de la famille RHEL, inspecter les conteneurs en cours d'exécution et maintenir un service rootless actif après la déconnexion.

Prérequis

Podman installé ; les droits root ne sont nécessaires que pour les étapes rootful et pour attribuer des plages d'ID subordonnés.

Étapes

1. Vérifier les informations de base de l'hôte, notamment si l'invocation courante est rootless : podman info --format '{{.Host.Security.Rootless}}', ou consulter la sortie complète de podman info pour le chemin store.graphRoot.
2. Le stockage rootless se trouve dans le répertoire personnel de l'utilisateur qui lance la commande, généralement ~/.local/share/containers/storage (graph root) et ~/.config/containers/storage.conf pour la configuration ; le stockage rootful est par défaut dans /var/lib/containers/storage. Confirmer le chemin actif avec podman info plutôt que de le supposer.
3. Lister et inspecter les conteneurs : podman ps (uniquement ceux en cours d'exécution) ou podman ps -a (tous), puis podman inspect <container> pour obtenir le détail complet au format JSON, y compris les montages, le chemin du network namespace et l'environnement.
4. Consulter les journaux : podman logs <container> (-f pour les suivre en continu).
5. Les conteneurs rootless associent les UID du conteneur à une plage d'UID non privilégiés de l'hôte appartenant à l'utilisateur qui les lance ; cette plage est configurée dans /etc/subuid et /etc/subgid. Vérifier d'abord avec grep <user> /etc/subuid /etc/subgid : useradd attribue normalement automatiquement une plage aux nouveaux utilisateurs. S'il n'en existe aucune, en attribuer une avec sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 <user> (65 536 ID ; le manuel de useradd documente ces fichiers et ces options), puis exécuter podman system migrate sous cet utilisateur afin que l'état de Podman en cours prenne en compte le nouveau mappage. Une plage est indispensable pour que Podman rootless puisse associer plus d'un ID dans un conteneur.
6. Les conteneurs rootless s'arrêtent normalement à la fin de la dernière session de l'utilisateur : l'instance systemd de l'utilisateur est alors arrêtée, et les processus lancés depuis la session peuvent également être tués (selon le paramètre KillUserProcesses de logind). Pour les maintenir actifs sans surveillance, activer le lingering : sudo loginctl enable-linger <user>. Le manuel de loginctl décrit enable-linger comme le fait de permettre à l'instance systemd d'un utilisateur de démarrer au boot et de rester active sans session ouverte.
7. Vérifier le lingering : loginctl show-user <user> --property=Linger doit indiquer Linger=yes, et le fichier indicateur /var/lib/systemd/linger/<user> doit exister. Pour annuler : sudo loginctl disable-linger <user>.

Résultat attendu

podman info affiche le mode rootless ou rootful attendu et le chemin de stockage correspondant ; un conteneur rootless survit à la déconnexion ssh une fois le lingering activé, à condition qu'il ait été démarré comme service géré par systemd (voir l'article complémentaire sur Quadlet) et non comme tâche d'un shell interactif.

Limites et base de vérification

Les plages d'ID subordonnés ne doivent pas se chevaucher entre les utilisateurs d'un même hôte ; ne comptez pas sur usermod pour rejeter une plage qui en chevauche une autre : comparez vous-même /etc/subuid et /etc/subgid avant d'en ajouter une. L'activation du lingering démarre l'instance systemd de l'utilisateur au boot, mais ne suffit pas, à elle seule, à faire survivre à la déconnexion un podman run lancé manuellement au premier plan : seuls les services rootless gérés par une unité en profitent.