reconstruction d'un trait : 43 groupes, 0 echec, 37 minutes

Chezlepro rase puis reconstruit SANS UNE SEULE INTERVENTION. Les sept correctifs
de la nuit tiennent sur une flotte entierement neuve. Sept devis CONFORME,
prouver 36/36, make test 0, neuf sauvegardes reussies et cinq sans objet.

LA BATAILLE CONTRE NodeName N'AVAIT QU'UNE CAUSE. icinga2 api setup ecrit
NodeName d'apres `hostname -f`. Tant que /etc/hosts placait le nom court en
premier, hostname -f mentait et le certificat devenait inverifiable. Depuis que
le FQDN est en tete, Icinga s'emet spontanement un certificat CN et SAN = FQDN.
Il n'y avait rien a forcer : il suffisait que la machine sache comment elle
s'appelle.

Le contournement par le nom court est RETIRE — il etait devenu faux des que la
cause reelle a ete corrigee.

Ce que ca enseigne : trois heures passees a corriger un symptome visible (le nom
du certificat) alors que la cause vivait deux couches plus bas et affectait toute
la flotte. Le signe qui aurait du alerter : CHAQUE correction etait effacee au
passage suivant. Un correctif qu'on doit reposer sans cesse ne corrige pas.

Dette notee : le clone de mon-01 a depasse proxmox_clone_timeout (600 s) pendant
la generation de son ISO cloud-init. Quatre clones complets simultanes saturent
le stockage.

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

CHANGELOG.md

@@ -1,5 +1,43 @@
 # CHANGELOG — Set-OPS
 
+## 2026-08-13 — Reconstruction **d'un trait** : 43 groupes, 0 échec, 37 minutes
+
+```
+DEBUT 08:05:17   FIN 08:42:11   code=0
+43 groupes   0 fatal   0 hote en echec
+```
+
+Chezlepro rasé puis reconstruit **sans une seule intervention**. Les sept correctifs de la
+nuit tiennent sur une flotte entièrement neuve. Sept devis CONFORME, `prouver` 36/36,
+`make test` 0, neuf sauvegardes réussies et cinq sans objet.
+
+### La bataille contre `NodeName` n'avait qu'une cause
+
+Toute la lutte d'hier soir — aligner `NodeName` avant `api setup`, après, dériver de
+l'inventaire, puis adopter le nom court — visait un **symptôme**.
+
+`icinga2 api setup` écrit `NodeName` d'après `hostname -f`. Tant que `/etc/hosts` plaçait
+le nom court en premier, `hostname -f` mentait et le certificat devenait invérifiable.
+**Depuis que le FQDN est en tête, Icinga s'émet spontanément un certificat `CN` et `SAN`
+= FQDN.** Il n'y avait rien à forcer : il suffisait que la machine sache comment elle
+s'appelle.
+
+Le contournement par le nom court est donc **retiré** — il était devenu faux dès que la
+cause réelle a été corrigée. Le commentaire du rôle dit maintenant la causalité, pas ma
+fausse piste.
+
+> **Ce que ça enseigne sur le diagnostic.** J'ai passé trois heures à corriger un
+> symptôme visible (le nom du certificat) alors que la cause vivait deux couches plus bas
+> et affectait toute la flotte. Le signe qui aurait dû alerter : *chaque* correction était
+> effacée au passage suivant. Un correctif qu'on doit reposer sans cesse ne corrige pas.
+
+### Une dette notée, pas traitée
+
+Le clone de `mon-01` a dépassé `proxmox_clone_timeout` (600 s) pendant la génération de
+son ISO cloud-init — la VM était debout quelques minutes plus tard. Quatre clones complets
+simultanés saturent le stockage. À régler par le délai ou le parallélisme, pas en urgence.
+
+
 ## 2026-08-13 — Reconstruction complète en `10.17.x.x` : sept défauts, tous invisibles avant
 
 Chezlepro reconstruit **depuis zéro** sur l'adressage dérivé sans décalage. Sept défauts

roles/serveur_backup/templates/verifier-sauvegardes.sh.j2

@@ -18,7 +18,7 @@
 set -uo pipefail
 
 RACINE="{{ serveur_backup_racine }}"
-API="https://{{ serveur_backup_icinga_hote }}:5665"   # nom COURT : c'est celui du certificat
+API="https://{{ serveur_backup_icinga_hote }}.{{ domaine_interne }}:5665"
 TTL={{ serveur_backup_ttl_icinga }}
 AGE_WARN={{ serveur_backup_age_warn_h }}
 AGE_CRIT={{ serveur_backup_age_crit_h }}

roles/serveur_icinga/tasks/main.yml

@@ -51,15 +51,18 @@
   no_log: true
 
 # --- Identite TLS de l'API (5665) ---
-# ON NE TOUCHE PAS A `NodeName`, et c'est une lecon payee cher (2026-08-12).
+# ON NE TOUCHE PAS A `NodeName` — et il n'y a rien a corriger ici.
-# `icinga2 api setup` REECRIT lui-meme NodeName d'apres le nom COURT de la machine, puis
-# nomme ses certificats d'apres lui : CN=mon-01, SAN=DNS:mon-01. Toute tentative de
-# l'aligner sur le FQDN est effacee au passage suivant — on l'a essaye avant et apres
-# `api setup`, sans succes.
 #
-# Plutot que de lutter contre sa convention, on l'ADOPTE : le consommateur appelle l'API
+# `icinga2 api setup` ECRIT lui-meme NodeName d'apres `hostname -f`, puis nomme ses
-# par le nom que le certificat porte (`serveur_backup` compose son URL sur le nom court).
+# certificats d'apres lui. Tant que `/etc/hosts` mettait le nom COURT en premier,
-# Le plancher `/etc/hosts` deploye par `hosts_statiques` le resout sur chaque machine.
+# `hostname -f` rendait « mon-01 » et le certificat devenait invérifiable en appelant par
+# le nom complet. On a longuement tente d'aligner NodeName a la main, avant et apres
+# `api setup` : efface a chaque fois.
+#
+# LA CAUSE ETAIT AILLEURS. Depuis que `hosts_statiques` place le FQDN en premier
+# (2026-08-13), `hostname -f` rend le nom complet et Icinga s'emet spontanement un
+# certificat CN et SAN = FQDN. Rien a forcer : il suffisait que la machine sache
+# comment elle s'appelle.
 - name: Configurer l'API Icinga 2
   ansible.builtin.command:
     cmd: icinga2 api setup