ajoute l'inventaire du serveur et le journal (étape 1 : reconnaissance)

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/inventaire-serveur.md

@@ -0,0 +1,90 @@
+# Inventaire du serveur Syllabus
+
+> Relevé le 2026-10-07, en lecture seule, depuis `ssh paillasse` (alias créé dans `~/.ssh/config`, clé dédiée `~/.ssh/id_ed25519_claude`).
+
+## Identité
+
+- Hébergeur : Scaleway Dedibox, offre Start-2-L, datacenter DC2 (France).
+- Nom d'hôte : `sd-124443`.
+- IP publique unique : `163.172.4.195`.
+- Utilisateur d'administration : `adam` (uid 1000), `sudo` sans mot de passe via `/etc/sudoers.d/90-adam` (`adam ALL=(ALL) NOPASSWD:ALL`).
+
+## Système et noyau
+
+- `PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"`.
+- Noyau : `Linux sd-124443 6.1.0-53-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.187-1 (2026-09-07) x86_64`.
+
+## CPU et virtualisation
+
+- Intel Xeon D-1531 @ 2.20 GHz, 1 socket, 6 cœurs, 2 threads/cœur → 12 CPU logiques.
+- Flag `vmx` présent (virtualisation matérielle Intel VT-x active).
+- `/dev/kvm` existe (`crw-rw---- root:kvm`), modules `kvm` et `kvm_intel` chargés.
+- → la virtualisation matérielle est disponible, Nova pourra utiliser `nova_compute_virt_type: kvm`.
+
+## RAM et swap
+
+- RAM totale : 31 Gi (≈ 32 Go), quasiment inutilisée au repos (759 Mi utilisés).
+- Swap : 4,1 Gi, vide.
+
+## Disques et RAID
+
+- 2 × SSD 232,9 Go (`sda`, `sdb`), partitionnés à l'identique :
+  - partition swap de 2 Go sur chaque disque (pas de RAID sur le swap) ;
+  - `md0` (RAID1, `sda2`+`sdb2`) → `/boot`, 511 Mo.
+  - `md1` (RAID1, `sda3`+`sdb3`) → `/`, 230,2 Go.
+- `cat /proc/mdstat` et `mdadm --detail` : les deux grappes sont `active`, `[UU]` (aucun disque dégradé), état `clean`.
+- `/` (`md1`, ext4) : 226 Go, 1,9 Go utilisés, 213 Go libres.
+- `/boot` (`md0`, ext4) : 469 Mo, 102 Mo utilisés.
+- → RAID 1 logiciel (mdadm) sain sur les deux grappes, conforme à ce qu'annonçait Adam.
+
+## Réseau
+
+- `eno1` : UP, seule interface active, porte l'unique IP publique `163.172.4.195/24` (+ lien local IPv6).
+- `eno2` : DOWN, inutilisée pour l'instant — c'est elle qui portera la paire veth NAT de l'étape 4.
+- Route par défaut : `163.172.4.1` via `eno1`.
+- DNS : `51.159.69.156` et `51.159.69.162` (résolveurs Scaleway), domaine de recherche `online.net`.
+- Pare-feu actuel : **aucun** (`nft list ruleset` vide). Seul `sshd` écoute sur une interface publique (port 22, IPv4 et IPv6). Un résolveur `named` (bind9) écoute uniquement sur `127.0.0.1`/`::1` (non exposé).
+
+## SSH (état avant durcissement — étape 2 à venir)
+
+- `sshd -T` effectif : `permitrootlogin without-password`, `passwordauthentication yes`, `pubkeyauthentication yes`, `kbdinteractiveauthentication no`.
+- **`/root/.ssh/authorized_keys` contient déjà 2 clés** : comme `PermitRootLogin` autorise la connexion par clé pour root, une intrusion sur une des clés présentes permettrait aujourd'hui une connexion root directe. À traiter en priorité à l'étape 2 (`PermitRootLogin no`).
+- Mot de passe toujours accepté (`passwordauthentication yes`) : à désactiver à l'étape 2.
+
+## Paquets de durcissement (absents, à installer à l'étape 2)
+
+- `fail2ban` : absent.
+- `chrony` : absent (l'horloge est néanmoins synchronisée, probablement par `systemd-timesyncd` ; `timedatectl` indique `System clock synchronized: yes`, fuseau déjà `Europe/Paris`).
+- `unattended-upgrades` : absent.
+- `nftables` : déjà installé (paquet présent), mais sans règles actives.
+
+## Outillage côté Mac
+
+- `python3` : absent du Mac dans le PATH par défaut testé (à vérifier/installer avec Ansible à l'étape 2 — le Mac a normalement Python 3 via Homebrew, `ansible`/`ansible-playbook` ne sont pas encore installés).
+- Côté serveur : `python3` 3.11.2 présent (nécessaire pour Ansible).
+
+## Choix de version : Kolla-Ansible
+
+**Choix : Kolla-Ansible série `2025.2` (nom de code *Flamingo*).**
+
+Justification (vérifié dans la documentation officielle OpenStack, pas de mémoire) :
+
+- Le support matrix de `2025.2` liste explicitement *Debian Bookworm (12)* comme OS hôte supporté : https://docs.openstack.org/kolla-ansible/2025.2/user/support-matrix.html
+- La série suivante, `2026.1` (*Gazpacho*), a **abandonné Debian 12** au profit de Debian 13 (Trixie) uniquement — confirmé sur son support matrix. Notre serveur est en Debian 12 (choix d'Adam, fait), donc `2026.1` et `2026.2` sont exclus pour l'instant.
+- La série précédente, `2025.1` (*Epoxy*), supporte aussi Bookworm, mais passe en statut « non maintenue » autour du 2 octobre 2026 (https://releases.openstack.org/) — donc déjà en fin de vie au moment de ce choix.
+- `2025.2` est en statut **« maintenue »** jusqu'à une fin de vie estimée au 28 avril 2027 : c'est la série la plus récente qui coche à la fois « supporte Bookworm » et « encore maintenue avec une marge confortable ».
+
+Installation prévue (étape 5), dans un venv Python sur le serveur :
+
+```bash
+pip install git+https://opendev.org/openstack/kolla-ansible@stable/2025.2
+kolla-ansible install-deps
+```
+
+puis la séquence `bootstrap-servers` → `prechecks` → `deploy` → `post-deploy`.
+
+## Critère de l'étape 1 — vérifié
+
+- [x] Inventaire écrit (ce fichier).
+- [x] KVM disponible (`/dev/kvm` + modules chargés, flag `vmx`).
+- [x] Version de Kolla-Ansible choisie (`2025.2`) et justifiée par la documentation officielle (support matrix + statut de maintenance).

docs/journal.md

@@ -0,0 +1,31 @@
+# Journal de bord — Syllabus (ex-Paillasse)
+
+## 2026-10-07 — Étape 1 : reconnaissance du serveur
+
+**Fait**
+
+- Déblocage de l'accès SSH : la clé dédiée `~/.ssh/id_ed25519_claude` avait une passphrase sans invite interactive disponible dans Claude Code. Adam a retiré la passphrase lui-même (`ssh-keygen -p -f ~/.ssh/id_ed25519_claude`, nouvelle passphrase vide).
+- ⚠️ Incident mineur : au premier essai, Adam a collé l'ancienne passphrase directement dans la conversation avec Claude Code au lieu de la taper dans le prompt du terminal. Elle n'a pas été utilisée ni répétée, et elle est devenue sans objet dès que la passphrase de la clé a été retirée. **Point d'attention pour la suite : ne jamais coller de secret dans le chat, toujours dans le terminal.**
+- Alias `paillasse` créé dans `~/.ssh/config` (`163.172.4.195`, utilisateur `adam`, `IdentityFile ~/.ssh/id_ed25519_claude`, `IdentitiesOnly yes`).
+- Reconnaissance en lecture seule via SSH : OS, noyau, CPU, virtualisation, RAM, disques/RAID, réseau, état actuel de SSH et du pare-feu, paquets de durcissement déjà présents ou non.
+- Vérification dans la documentation officielle OpenStack (support matrix + page des séries) de la version de Kolla-Ansible à utiliser : **2025.2 (Flamingo)**, seule série récente qui supporte encore Debian 12 bookworm et qui est encore maintenue.
+- Écriture de `docs/inventaire-serveur.md`.
+
+**Commandes clés**
+
+```bash
+ssh -i ~/.ssh/id_ed25519_claude -o IdentitiesOnly=yes adam@163.172.4.195 ...
+ssh paillasse "lscpu; ls -la /dev/kvm; cat /proc/mdstat; ip -br a; sudo nft list ruleset; sudo sshd -T"
+```
+
+**Problèmes rencontrés et solution**
+
+- Connexion SSH refusée (`Permission denied (publickey,password)`) : la clé privée avait une passphrase, et l'environnement Claude Code n'a pas de terminal interactif pour la saisir (`ssh_askpass` absent). Solution : Adam a retiré la passphrase lui-même avec `ssh-keygen -p`.
+
+**Comprendre**
+
+Avant de changer quoi que ce soit, il fallait savoir précisément sur quoi on allait travailler : est-ce que la virtualisation matérielle marche vraiment (sans ça, pas d'OpenStack utilisable), le RAID est-il sain, combien de RAM reste disponible, et surtout quelle version de Kolla-Ansible est compatible avec Debian 12. C'est important car OpenStack évolue vite : la version la plus récente (2026.1) a justement arrêté de supporter Debian 12, donc l'installer aveuglément aurait bloqué tout le projet dès l'étape 5. On a aussi remarqué que le pare-feu est aujourd'hui totalement ouvert et que root peut encore se connecter par clé : ce sont exactement les deux points que l'étape 2 (durcissement) va corriger. Rien n'a été modifié sur le serveur à cette étape, uniquement des commandes de lecture.
+
+**Suite**
+
+Étape 2 : durcissement SSH + pare-feu nftables + fail2ban/chrony/unattended-upgrades, via un rôle Ansible depuis le Mac. C'est une étape qui touche SSH et le réseau : je vais détailler la commande avant de l'exécuter, prévoir un retour arrière automatique (anti-coupure), et ne redémarrer/couper rien sans l'accord explicite d'Adam pour les points couverts par la règle 3 du prompt de déploiement.