History

Daniel Allaire a070c339ee icinga : l hote de supervision saturait par sa propre demonstration « mon-01 tape dans l fond. » Il tapait : load 5,10 sur 4 coeurs, 8 processus check_disk a 70-99 % de CPU chacun, jusqu a 28 minutes de vie. check_disk 2.4.0-3+deb13u1 ne rend jamais la main sur cet hote (etat R). Icinga en relancait un a chaque intervalle pour le service `disk` de son hote de DEMONSTRATION, et aucun ne mourait. RETIRE : conf.d/hosts.conf, l hote NodeName livre par le paquet. Les apply Service s y accrochaient — disk, http, swap, apt, load, procs, users — et trois etaient rouges en permanence (swap sur une VM sans swap, http sur un port ou rien n ecoute, apt pour un paquet). On retire l HOTE et non les services : sans lui les apply ne s accrochent a rien, et on ne touche pas a un fichier que le paquet remplacera. Ca garde ping4, qui vise nos hotes et sert vraiment. avant : load 5,10 — 8 check_disk — 3 alarmes rouges permanentes apres : load 0,77 — 0 check_disk — certificat 14/14, sante 14/14, ping4 14/14 TROUVE EN VERIFIANT : l Icinga du SITE tenait 6 de ses 7 machines pour MORTES (1/7 UP, contre 14/14 au tenant). hostalive est un ping, le site est decoupe en zones, et l ICMP inter-zones n etait declare nulle part — 100 % de perte, mesure. Or Icinga SUPPRIME les notifications des services d un hote DOWN : une supervision qui croit tout mort n alerte plus de rien, tout en ayant l air de fonctionner. Le flux est declare des DEUX cotes, et le registre a refuse la premiere moitie seule — exactement sa raison d etre. CODES_ICMP apprend echo-request. Regles d hote posees sur les 21 machines. RESTE OUVERT : le generateur de la frontiere ne sait pas traduire un TYPE ICMP pour un pair INTERNE — il le note et n emet rien. Le site reste a 1/7. Corriger devis_opnsense.py est le prochain geste. make prouver : CONFORME, 64 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q	2026-09-09 22:34:32 -04:00
..
meta	icinga : l hote de supervision saturait par sa propre demonstration	2026-09-09 22:34:32 -04:00
README.md	docs : un README par rôle (12 manquants) + carte remise à l'état du code	2026-07-29 11:32:06 -04:00

Daniel Allaire a070c339ee icinga : l hote de supervision saturait par sa propre demonstration

« mon-01 tape dans l fond. » Il tapait : load 5,10 sur 4 coeurs, 8
processus check_disk a 70-99 % de CPU chacun, jusqu a 28 minutes de vie.

check_disk 2.4.0-3+deb13u1 ne rend jamais la main sur cet hote (etat R).
Icinga en relancait un a chaque intervalle pour le service `disk` de son
hote de DEMONSTRATION, et aucun ne mourait.

RETIRE : conf.d/hosts.conf, l hote NodeName livre par le paquet. Les apply
Service s y accrochaient — disk, http, swap, apt, load, procs, users — et
trois etaient rouges en permanence (swap sur une VM sans swap, http sur un
port ou rien n ecoute, apt pour un paquet). On retire l HOTE et non les
services : sans lui les apply ne s accrochent a rien, et on ne touche pas
a un fichier que le paquet remplacera. Ca garde ping4, qui vise nos hotes
et sert vraiment.

  avant : load 5,10 — 8 check_disk — 3 alarmes rouges permanentes
  apres : load 0,77 — 0 check_disk — certificat 14/14, sante 14/14, ping4 14/14

TROUVE EN VERIFIANT : l Icinga du SITE tenait 6 de ses 7 machines pour
MORTES (1/7 UP, contre 14/14 au tenant). hostalive est un ping, le site
est decoupe en zones, et l ICMP inter-zones n etait declare nulle part —
100 % de perte, mesure. Or Icinga SUPPRIME les notifications des services
d un hote DOWN : une supervision qui croit tout mort n alerte plus de
rien, tout en ayant l air de fonctionner.

Le flux est declare des DEUX cotes, et le registre a refuse la premiere
moitie seule — exactement sa raison d etre. CODES_ICMP apprend
echo-request. Regles d hote posees sur les 21 machines.

RESTE OUVERT : le generateur de la frontiere ne sait pas traduire un TYPE
ICMP pour un pair INTERNE — il le note et n emet rien. Le site reste a
1/7. Corriger devis_opnsense.py est le prochain geste.

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

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

2026-09-09 22:34:32 -04:00

README.md

serveur_debian

Rôle-catégorie du socle : il ne porte aucune tâche. Son unique contenu est meta/flux.yml — la déclaration du plan de gestion (SSH) de tout nœud de la flotte.

Pourquoi un rôle sans tâches

Le résolveur de flux (scripts/resoudre_flux.py, make flux) agrège les roles/<rôle>/meta/flux.yml par nom de groupe. Le groupe serveur_debian est le socle appliqué à tous les hôtes ; c'est donc ici que se déclare le flux SSH d'administration.

⚠️ Critique : sans cette déclaration, les rulesets nftables générés (nftables_baseline, policy drop) couperaient l'accès Ansible/SSH à toute la flotte.

Le travail réel

Il est fait par le playbook du groupe, playbooks/groupes/serveur_debian.yml, qui applique dans l'ordre :

Rôle	Apport
`common_packages`	Paquets de base
`hosts_statiques`	Plancher de résolution `/etc/hosts` (indépendant du DNS)
`qemu_guest_agent`	Agent invité Proxmox
`cloud_init`	Cohérence du premier démarrage
`sudo_ansible`	Compte de déploiement
`chrony`	Horloge (`fuseau_horaire`)
`ssh_baseline`	Base SSH
`systemd_ssh_auto`	Démarrage SSH fiable
`motd`	Bannière

Le playbook refuse toute cible non-Debian (assertion ansible_facts.distribution).

Place dans l'ordre

Couche socle (docs/couches-deploiement.yml) — la première. Le durcissement (serveur_durci) vient juste après, tout le reste ensuite.

Notes

Ajouter un flux réseau du socle (pas d'un service) se fait ici, pas ailleurs.
hosts_statiques étant appliqué ici, la résolution par nom fonctionne dès le socle, avant que PowerDNS existe — c'est ce qui permet l'ordre de reconstruction from-zero.