From f4bb40c4f24f8553e013da7782ad609986508637 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Wed, 9 Sep 2026 16:20:32 -0400 Subject: [PATCH] metriques : le client installait un pilote IPMI qui echoue a chaque demarrage MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q --- CHANGELOG.md | 63 +++++++++++++++++++++++++ roles/client_metrique/defaults/main.yml | 27 +++++++++++ roles/client_metrique/handlers/main.yml | 4 ++ roles/client_metrique/tasks/main.yml | 18 +++++++ 4 files changed, 112 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 705e2b0..506c3c9 100644 --- a/CHANGELOG.md +++ b/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 diff --git a/roles/client_metrique/defaults/main.yml b/roles/client_metrique/defaults/main.yml index 11e7b69..c55fe02 100644 --- a/roles/client_metrique/defaults/main.yml +++ b/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 diff --git a/roles/client_metrique/handlers/main.yml b/roles/client_metrique/handlers/main.yml index d64b694..3ced565 100644 --- a/roles/client_metrique/handlers/main.yml +++ b/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 diff --git a/roles/client_metrique/tasks/main.yml b/roles/client_metrique/tasks/main.yml index 3a123e1..7c94ff2 100644 --- a/roles/client_metrique/tasks/main.yml +++ b/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: