metriques : le client installait un pilote IPMI qui echoue a chaque demarrage

LE REDEMARRAGE A TENU. obs-01 a redemarre avec son disque cloud-init
RETIRE de Proxmox — sans paquet et sans source de donnees — et elle est
revenue avec son adresse, sa passerelle et son resolveur. Le retrait de
cloud-init est desormais prouve par un demarrage reel.

ET IL A REVELE AUTRE CHOSE. Une unite en echec : openipmi.service. La
chaine est prometheus-node-exporter -> recommande collectors -> recommande
ipmitool -> recommande openipmi. Trois recommandations en cascade,
raisonnables sur du metal. Dans une VM il n y a pas de BMC et le script d
init echoue a chaque demarrage.

LE POINT N EST PAS LE PAQUET, C EST POURQUOI PERSONNE NE L AVAIT VU.
openipmi datait du 2026-09-02. systemctl --failed rendait pourtant ZERO
sur les quatorze machines — non parce qu elles allaient bien, mais parce
qu aucune n avait REDEMARRE depuis. Six jours et vingt heures pour obs-01.
Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que
rien ne demarre.

Le degat n est pas cosmetique : une unite en echec permanent use le seul
signal qui devrait alerter. Le jour ou une vraie unite tombe, --failed
rend 2 au lieu de 1, et personne ne fait la difference.

CORRECTION A LA SOURCE ET CONDITIONNELLE. client_metrique retire ipmitool
et openipmi, mais SEULEMENT dans une VM (virtualization_role == guest) :
sur du metal le collecteur IPMI est legitime. Ils ne sont que RECOMMANDES,
donc les retirer n emporte pas les collectors, qui servent. Un handler
efface l etat failed que le retrait ne nettoie pas.

Applique aux quatorze : ipmi=0, collectors=1, node_exporter=active,
echecs=0. Second passage : zero changement sur zero hote.

RESTE OUVERT : rien dans le harnais ne regarde systemctl --failed sur la
flotte. Ce defaut a ete trouve parce qu un humain a redemarre une machine.

make prouver : CONFORME, 63 OK, 0 echec, 0 saute.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

CHANGELOG.md

@@ -1,5 +1,68 @@
 # CHANGELOG — Set-OPS
 
+## 2026-09-09 (3) — Le redemarrage a tenu, et il a montre autre chose
+
+### Ce que le redemarrage prouve
+
+`obs-01` a redemarre **avec son disque cloud-init retire de Proxmox** — donc sans paquet
+ET sans source de donnees. Elle est revenue avec son adresse (`10.17.20.11/24`), sa
+passerelle (`10.17.20.1`) et son resolveur (`10.0.34.11`). C'est la confirmation que les
+mesures annoncaient : `/etc/network/interfaces.d/50-cloud-init` n'appartient a aucun
+paquet, il survit, et `ifupdown` le relit au demarrage.
+
+Le retrait de cloud-init est desormais **prouve par un demarrage reel**, pas seulement par
+inference.
+
+### Ce que le redemarrage a REVELE, et qui n'a rien a voir
+
+Une unite en echec : `openipmi.service`.
+
+    openipmi[655]: Starting ipmi drivers ipmi failed!
+    systemd[1]: Failed to start openipmi.service
+
+La chaine : `prometheus-node-exporter` **recommande**
+`prometheus-node-exporter-collectors`, qui **recommande** `ipmitool`, qui **recommande**
+`openipmi`. Trois recommandations en cascade, chacune raisonnable sur du metal. Dans une
+VM il n'y a pas de BMC — `/dev/ipmi*` n'existe pas — et le script d'init echoue a chaque
+demarrage.
+
+**LE POINT N'EST PAS LE PAQUET, C'EST POURQUOI PERSONNE NE L'AVAIT VU.** `openipmi` est
+arrive le **2026-09-02**, avec la reconstruction. `systemctl --failed` rendait pourtant
+ZERO sur les quatorze machines — non parce qu'elles allaient bien, mais parce qu'aucune
+n'avait **redemarre** depuis. Six jours et vingt heures pour `obs-01` (`last -x reboot` :
+boot du 2026-09-02 19:24, jusqu'a aujourd'hui 16:10).
+
+*Un controle qui ne peut echouer qu'au demarrage ne mesure rien tant que rien ne demarre.*
+C'est la meme famille que le cheque vert sur un perimetre vide, avec le temps comme
+perimetre.
+
+Et le degat n'est pas cosmetique : une unite en echec **permanent** use le seul signal qui
+devrait alerter. Le jour ou une vraie unite tombe, `systemctl --failed` rend « 2 » au lieu
+de « 1 », et personne ne fait la difference.
+
+### La correction, a la source et conditionnelle
+
+`client_metrique` retire `ipmitool` et `openipmi` — mais **seulement dans une VM**
+(`ansible_facts.virtualization_role == 'guest'`). Sur du metal le collecteur IPMI est
+legitime : c'est la raison meme de la recommandation. Le role s'appuie sur ce qu'Ansible
+SAIT de la machine, pas sur une supposition.
+
+Ils ne sont que RECOMMANDES, donc les retirer n'emporte pas
+`prometheus-node-exporter-collectors`, dont les collecteurs textfile servent vraiment.
+
+Un handler efface l'etat `failed` laisse derriere : retirer le paquet ne l'efface pas,
+systemd le garde jusqu'au prochain demarrage. Sur une flotte qui ne redemarre pas, ce
+serait conserver par inadvertance exactement le bruit qu'on vient de supprimer.
+
+Applique aux quatorze : `ipmi=0`, `collectors=1`, `node_exporter=active`, `echecs=0`
+partout. Second passage : **zero changement sur zero hote** — idempotent.
+
+### Ce qui reste ouvert
+
+Rien dans le harnais ne regarde `systemctl --failed` sur la flotte. Ce defaut-ci a ete
+trouve **parce qu'un humain a redemarre une machine**, pas parce qu'une mesure l'a dit.
+Les treize autres portaient la meme unite condamnee, silencieuses.
+
 ## 2026-09-09 (2) — Le wiki d'`origin` : une garde qui bloquait au lieu de proteger
 
 **Les deux forges servent desormais le meme wiki**, 26 pages, contenu identique au fichier

roles/client_metrique/defaults/main.yml

@@ -2,6 +2,33 @@
 client_metrique_paquets:
   - prometheus-node-exporter
 
+# LE MATERIEL QUI N'EXISTE PAS DANS UNE VM (mesure du 2026-09-09 sur `obs-01`).
+#
+# `prometheus-node-exporter` RECOMMANDE `prometheus-node-exporter-collectors`, qui
+# RECOMMANDE `ipmitool`, qui RECOMMANDE `openipmi`. Trois recommandations en cascade,
+# chacune raisonnable sur du metal — et la derniere installe un script d'init qui tente
+# de charger le pilote IPMI a CHAQUE demarrage. Dans une VM il n'y a pas de BMC :
+#
+#     openipmi[655]: Starting ipmi drivers ipmi failed!
+#     systemd[1]: Failed to start openipmi.service
+#
+# CE QUI REND CE DEFAUT INSTRUCTIF : il datait du 2026-09-02, et personne ne l'avait vu.
+# `systemctl --failed` rendait ZERO sur les quatorze machines — non parce qu'elles
+# allaient bien, mais parce qu'aucune n'avait REDEMARRE depuis. Six jours et vingt heures
+# pour `obs-01`. Un controle qui ne peut echouer qu'au demarrage ne mesure rien tant que
+# rien ne demarre.
+#
+# Une unite en echec permanent n'est pas qu'inesthetique : elle use le seul signal qui
+# devrait alerter. Le jour ou une VRAIE unite tombera, `systemctl --failed` rendra « 2 »
+# au lieu de « 1 », et personne ne fera la difference.
+#
+# ON NE RETIRE QUE DANS UNE VM. Sur du metal, le collecteur IPMI est legitime — c'est
+# meme la raison de la recommandation. Le role s'appuie donc sur ce qu'Ansible SAIT de la
+# machine, pas sur une supposition.
+client_metrique_paquets_sans_objet_en_vm:
+  - openipmi
+  - ipmitool
+
 client_metrique_service: "prometheus-node-exporter"
 
 # Adresse d'ecoute de node_exporter. Par defaut toutes les interfaces ; la

roles/client_metrique/handlers/main.yml

@@ -4,3 +4,7 @@
     name: "{{ client_metrique_service }}"
     state: restarted
   listen: Redemarrer node_exporter
+
+- name: Effacer l etat d echec des unites retirees
+  ansible.builtin.command: systemctl reset-failed
+  changed_when: true

roles/client_metrique/tasks/main.yml

@@ -6,6 +6,24 @@
     update_cache: true
     cache_valid_time: 3600
 
+# Retire APRES l'installation, et pas avant : c'est elle qui les fait venir, en cascade
+# de recommandations. `ipmitool` et `openipmi` ne sont que RECOMMANDES — les retirer
+# n'emporte donc pas `prometheus-node-exporter-collectors`, dont les collecteurs
+# textfile, eux, servent.
+- name: Retirer le materiel qui ne peut pas exister dans une VM (IPMI)
+  ansible.builtin.apt:
+    name: "{{ client_metrique_paquets_sans_objet_en_vm }}"
+    state: absent
+    purge: true
+    autoremove: false
+  when: ansible_facts.virtualization_role | default('') == 'guest'
+  # Retirer le paquet n'efface pas l'ECHEC deja enregistre : systemd garde l'unite en
+  # `failed` jusqu'au prochain demarrage. Sur une flotte qui ne redemarre pas, ca
+  # voudrait dire des semaines de `systemctl --failed` non vide pour une unite qui
+  # n'existe plus — exactement le bruit qu'on vient de supprimer, conserve par
+  # inadvertance.
+  notify: Effacer l etat d echec des unites retirees
+
 # --- TLS : synchroniser le cert step_ca AVANT d'activer --web.config.file ---
 - name: TLS — repertoire des certificats (prometheus)
   ansible.builtin.file: