Set-OPS-Public/roles/serveur_debian/meta/supervision.yml

---
# Supervision derivee du role. Voir docs/supervision-conception.md.
#
# CE QUE CETTE SONDE MESURE, ET POURQUOI ELLE MANQUAIT.
#
# Set-OPS DESARME les mises a jour automatiques de Debian — `unattended-upgrades` est
# masque sur les vingt et une machines — et les applique lui-meme, par `upgrade: full`
# au passage du socle. C'est un choix defendable : un minuteur de fond qui se dispute le
# verrou `dpkg` avec un deploiement est un tirage au sort, et il a fait decrocher
# `infra-mail-01` d'une reconstruction entiere le 2026-09-10.
#
# Mais ce choix a une consequence que rien ne rattrapait : **les correctifs n'arrivent
# que si quelqu'un deploie**. Vingt-deux sondes couvraient les certificats, les journaux,
# les metriques, les sauvegardes, les bases, l'annuaire, les boites — aucune ne disait
# qu'une machine prenait du retard de securite. Une flotte pouvait deriver des mois en
# restant verte.
#
# CE QU'ON NE MESURE PAS, ET C'EST DELIBERE :
#
#   - « le minuteur a-t-il tourne ? » — il est masque, exprès ; mesurer son inactivite
#     serait mesurer une decision, pas un risque.
#   - « la machine est-elle a jour ? » — trop vague : un paquet d'agrement en retard
#     n'est pas un correctif de securite en attente.
#
# CE QU'ON MESURE : les paquets en attente venant d'un depot de SECURITE, et depuis
# COMBIEN DE TEMPS. Le retard seul ne dit rien — c'est sa DUREE qui transforme un
# correctif publie en exposition acceptee.
sondes:
  - nom: correctifs
    ttl: 5400
    raison: >-
      Des correctifs de securite attendent-ils d'etre appliques, et depuis quand ?
      Set-OPS desarme les mises a jour automatiques et les applique au deploiement :
      sans cette mesure, rien ne dit quand le geste est du.
un fichier vide existe, et une sonde pour les correctifs LA GARDE FICHIER ENTIER, en deux corrections. Un telechargement interrompu laisse un fichier de zero octet QUI EXISTE, et toutes les gardes demandaient seulement s il etait la. infra-mail-01 a garde une cle smallstep de 0 octet apres l epreuve hors ligne. La premiere correction n a pas suffi. Ajouter le controle de taille faisait bien s executer la tache - et le fichier faisait toujours 0 octet au passage suivant. get_url sur une destination existante emet une requete CONDITIONNELLE : l amont repond non modifie, le module rend ok, la ruine reste. Le play etait vert et ne reparait rien. Il faut effacer avant de redemander. Controle negatif : 0 -> 1022 octets, 0 erreur apt. Cinq roles. LA SONDE CORRECTIFS, 23e. Set-OPS desarme unattended-upgrades et applique les correctifs au deploiement - choix defendable, le verrou dpkg a fait decrocher une machine d une reconstruction entiere le matin meme. Mais rien ne disait QUAND le geste etait du : une flotte pouvait deriver des mois en restant verte. Elle mesure les paquets de securite en attente ET depuis quand. Elle ne lance pas apt-get update - une sonde qui rafraichit l index toutes les quinze minutes deviendrait la cause de la panne qu elle surveille. Et le seuil de 72 h est un choix d exploitation, pas une derivation : le mecanisme qui applique les correctifs est un geste humain. P64 REFUSAIT UNE DECLARATION CORRECTE. serveur_debian et serveur_durci sont des roles de declaration pure, sans une tache ; le travail est fait par les roles que leur playbook applique. La preuve exigeait declaration et depot dans le meme role - vrai des vingt-deux premieres sondes, faux des qu une sonde appartient au socle. Une garde qui force a contourner ce qu elle protege est un defaut. Elle suit desormais le playbook du groupe. Mesure : 21/21 machines vertes, 65 preuves, 23 sondes, 0 echec. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q 2026-09-10 17:26:35 -04:00			`---`
			`# Supervision derivee du role. Voir docs/supervision-conception.md.`
			`#`
			`# CE QUE CETTE SONDE MESURE, ET POURQUOI ELLE MANQUAIT.`
			`#`
			# Set-OPS DESARME les mises a jour automatiques de Debian — `unattended-upgrades` est
			# masque sur les vingt et une machines — et les applique lui-meme, par `upgrade: full`
			`# au passage du socle. C'est un choix defendable : un minuteur de fond qui se dispute le`
			# verrou `dpkg` avec un deploiement est un tirage au sort, et il a fait decrocher
			# `infra-mail-01` d'une reconstruction entiere le 2026-09-10.
			`#`
			`# Mais ce choix a une consequence que rien ne rattrapait : **les correctifs n'arrivent`
			`# que si quelqu'un deploie**. Vingt-deux sondes couvraient les certificats, les journaux,`
			`# les metriques, les sauvegardes, les bases, l'annuaire, les boites — aucune ne disait`
			`# qu'une machine prenait du retard de securite. Une flotte pouvait deriver des mois en`
			`# restant verte.`
			`#`
			`# CE QU'ON NE MESURE PAS, ET C'EST DELIBERE :`
			`#`
			`# - « le minuteur a-t-il tourne ? » — il est masque, exprès ; mesurer son inactivite`
			`# serait mesurer une decision, pas un risque.`
			`# - « la machine est-elle a jour ? » — trop vague : un paquet d'agrement en retard`
			`# n'est pas un correctif de securite en attente.`
			`#`
			`# CE QU'ON MESURE : les paquets en attente venant d'un depot de SECURITE, et depuis`
			`# COMBIEN DE TEMPS. Le retard seul ne dit rien — c'est sa DUREE qui transforme un`
			`# correctif publie en exposition acceptee.`
			`sondes:`
			`- nom: correctifs`
			`ttl: 5400`
			`raison: >-`
			`Des correctifs de securite attendent-ils d'etre appliques, et depuis quand ?`
			`Set-OPS desarme les mises a jour automatiques et les applique au deploiement :`
			`sans cette mesure, rien ne dit quand le geste est du.`