Daniel Allaire
018d55ec6c
7 machines du site deployees, 0 echec au playbook — et CINQ rapports sur sept en TimeoutError. Un playbook vert ne prouve pas qu une chose fonctionne ; seul l essai de bout en bout l a dit. 1. LE PAIR DE LA FRONTIERE. Le role client declarait son egress 5665, la politique de sortie etait accept, la regle d entree de l hote autorisait la source — et les paquets mouraient ENTRE les deux. La frontiere filtre l inter-zones du site et ne resout que les roles que les machines PORTENT AU PLAN ; une integration universelle n y figure pas, elle est derivee. pair: client_sante produisait donc une regle est-ouest correcte et AUCUNE regle a la frontiere. Le pair devient serveur_debian — le vocabulaire du depot pour « tout noeud », que le generateur traite deja comme tel, et exact au sens strict. Six regles creees, zero retiree, une par patte de zone. 2. LE RAPPORTEUR S ACCUSAIT LUI-MEME. Pendant l heure de blocage, setops-sante.service a echoue ; une fois debloque, cinq machines ont rapporte CRITIQUE en citant leur propre rapporteur, et systemd garde l etat failed jusqu a un reset-failed. Sa propre unite est desormais exclue du compte — non par complaisance : sa sante est deja mesuree, et mieux, par la FRAICHEUR de ses envois. S il ne peut plus parler, le ttl perime le service, ce qui se voit precisement quand il ne peut PAS ecrire. ETAT FINAL : 7/7 au site, 14/14 au tenant, tous OK. Controle negatif rejoue sur les deux flottes. 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 |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
client_sante
Le nœud rapporte à Icinga ses unités systemd en échec, par résultat passif.
Pourquoi
Trouvé le 2026-09-09 : openipmi.service échouait à chaque démarrage sur les quatorze
machines de Chezlepro depuis le 2026-09-02. systemctl --failed rendait pourtant zéro
partout — non parce qu'elles allaient bien, mais parce qu'aucune n'avait redémarré
depuis. Six jours et vingt heures pour la première. Il a fallu qu'un humain redémarre une
machine pour que le défaut existe aux yeux de quelqu'un.
Un contrôle qui ne peut échouer qu'au démarrage ne mesure rien tant que rien ne démarre.
Et le dégât n'est pas cosmétique : une unité en échec permanent use le seul signal qui devrait alerter. Le jour où une vraie unité tombe, le compte passe de 1 à 2 et personne ne fait la différence.
Passif, et à durée de vie
Un contrôle actif ne voit pas la machine muette : si elle ne répond plus, la sonde
échoue et on met ça sur le compte du réseau. Ici c'est le nœud qui parle, et le ttl de
son envoi fait la fraîcheur — sans nouvelle, Icinga périme le service tout seul. Le
silence alerte autant que l'échec, et le silence est précisément ce qui n'a alerté
personne.
Le minuteur déclenche au démarrage (OnBootSec=2min) autant que périodiquement : les
échecs de cette famille naissent au boot, et attendre le premier quart d'heure laisserait
une fenêtre pendant laquelle la machine est en panne et le tableau au vert.
Tolérances
client_sante_unites_tolerees nomme les unités acceptées une par une, jamais un motif
large : un filtre qui cache une unité en cache d'autres, et on ne s'en aperçoit que le jour
où l'on cherche pourquoi rien n'a alerté. Le défaut est la liste vide — une unité en
échec est soit un vrai problème, soit du bruit à retirer ; dans les deux cas il faut agir.
Ce dont il dépend
Un hôte serveur_icinga dans l'écosystème (sinon rien n'est posé, et c'est dit), le secret
vault_icinga_api_depot, et le flux sortant TCP 5665 vers lui.