Paillasse/docs/runbooks/images.md

Runbook — Image paillasse-debian

Construire (ou reconstruire) l'image

Sur le serveur, en root. Le script ne supprime jamais une image existante tout seul (règle 3) : il s'arrête si paillasse-debian existe déjà.

ssh paillasse
sudo bash /opt/construction-image/construire-paillasse-debian.sh

Déployé par ansible/images.yml (installe libguestfs-tools, copie le script et paillasse-contenus/07-sql/lycee.sql vers /opt/construction-image/ sur le serveur) :

cd ansible && script -q /dev/null ansible-playbook images.yml -i inventory.ini

Durée : quelques minutes (téléchargement ~700 Mo + personnalisation).

Ce que contient l'image

Depuis debian-12-genericcloud-amd64.qcow2 officiel (somme SHA512 vérifiée) :

• sudo, qemu-guest-agent (correction automatique), getty actif sur ttyS0 (console série).
• Utilisateur eleve (groupe sudo, mot de passe eleve).
• Outils réseau : iproute2, iputils-ping, traceroute, tcpdump, dnsutils, curl, netcat-openbsd.
• openssl, nano, vim, htop.
• nginx, mariadb-server, frr installés mais désactivés (activés par l'étape preparation de certains labs, ex. lab 07).
• /opt/labs/07/lycee.sql : jeu de données du lab 07 (voir paillasse-contenus/07-sql/).
• /opt/paquets/tree_*.deb : paquet tree pour le lab 02, volontairement non installé (le lab demande à l'élève de l'installer lui-même ; voir l'écart avec paillasse-contenus/README.md noté dans le journal du 2026-10-07).
• Pas de cloud-init (retiré) : les réseaux de lab n'ont ni DHCP ni service de métadonnées joignable, cloud-init n'attendrait que pour rien à chaque démarrage. La correction automatique passe par l'agent QEMU, pas par cloud-init/user-data.

Propriétés Glance : hw_qemu_guest_agent=yes, hw_rng_model=virtio, os_type=linux, visibilité public.

Se connecter à une VM par la console série

ssh paillasse
sudo -i
export PATH=/opt/kolla-venv/bin:$PATH
export OS_CLIENT_CONFIG_FILE=/etc/kolla/clouds-paillasse.yaml   # ou clouds.yaml + OS_CLOUD=kolla-admin
export OS_CLOUD=paillasse-service
openstack console url show --serial <nom-ou-id-de-la-vm>

Donne une URL ws://10.10.0.1:6083/?token=..., jointe uniquement depuis le réseau interne (pare-feu : non exposée sur eno1). Pour un test manuel depuis le serveur :

/usr/bin/python3 /opt/construction-image/test-console-serie.py "<url>" "une-commande"

(nécessite le module Python websocket-client, déjà présent sur le serveur). Le script attend login:, envoie eleve, attend Password:, envoie eleve, puis tape la commande. La console série est un flux continu : si un essai précédent a laissé le prompt au milieu d'une saisie (ex. en attente d'un mot de passe), le script suivant hérite de cet état — relire d'abord l'état actuel avant d'envoyer quoi que ce soit, comme fait le script.

Plus tard (étape 9), c'est le proxy Go qui jouera ce rôle côté portail, avec xterm.js côté navigateur, et un jeton à usage unique rangé dans Redis au lieu d'un accès direct à 10.10.0.1:6083.

Vérifié le 2026-10-07

• VM vm-test-console (réseau de test reseau-test, 192.168.100.0/24, sans DHCP) démarrée en ~25 s.
• Console série : prompt localhost login: affiché, connexion eleve/eleve réussie, commande whoami && hostname && echo ---OK--- exécutée avec la sortie attendue.