# 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.