2026-07-07 03:08:09 -04:00
|
|
|
---
|
|
|
|
|
# Flux réseau d'Icinga 2 (moteur de supervision). Voir docs/flux-conception.md.
|
|
|
|
|
# IcingaDB (Redis 6380) est co-localisé : consommé en localhost par le frontal Icinga Web 2.
|
|
|
|
|
flux:
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 5665
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: localhost
|
|
|
|
|
chiffrement: clair
|
|
|
|
|
raison: "API Icinga 2 consommée en local par Icinga Web 2 co-localisé."
|
2026-09-02 18:53:44 -04:00
|
|
|
# LES NOEUDS RAPPORTENT EUX-MEMES DEPUIS LE 2026-09-02.
|
|
|
|
|
#
|
|
|
|
|
# Tant que le depot vivait dans l'ecosysteme, il rapportait pour tout le monde et
|
|
|
|
|
# `serveur_backup` suffisait comme pair. Depuis que les ecosystemes deposent chez leur
|
|
|
|
|
# HEBERGEUR — qui heberge du chiffre et ne peut rien juger — c'est chaque detenteur
|
|
|
|
|
# d'etat qui verifie SON depot et le rapporte. Le pair, c'est donc `client_backup`.
|
|
|
|
|
#
|
|
|
|
|
# Les deux coexistent : un ecosysteme qui garde son propre depot continue de le laisser
|
|
|
|
|
# rapporter. `serveur_backup` reste declare juste en dessous.
|
|
|
|
|
- sens: ingress
|
|
|
|
|
port: 5665
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: client_backup
|
|
|
|
|
chiffrement: tls-requis
|
|
|
|
|
raison: "Rapport passif de chaque detenteur d'etat sur SON depot distant : le depot du site heberge du chiffre et ne peut pas le juger."
|
supervision : c'est le DEPOT qui dit ou en sont les sauvegardes
Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement
la config Debian d'origine sur localhost.
Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme :
l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud
sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc
ses depots et pousse un resultat passif par noeud vers l'API Icinga.
Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est
recent (26 h / 50 h), il contient au moins un fichier.
Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse
— compromettre mon-01 ne donne aucun acces aux sauvegardes.
Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les
services tout seul. C'est le silence qui a laisse le defaut vivre un mois.
Deux erreurs corrigees par la mesure :
- --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS
et l'auth marchaient, seule la charge etait perdue.
- le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF
d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le
verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont
disparu » de « il n'y en a pas encore ».
Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:39:05 -04:00
|
|
|
- sens: ingress
|
|
|
|
|
port: 5665
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: serveur_backup
|
|
|
|
|
chiffrement: tls-requis
|
|
|
|
|
partage: true
|
|
|
|
|
raison: "Le depot de sauvegarde depose ses resultats passifs (portee : process-check-result sur « sauvegarde: * »)."
|
2026-07-07 03:08:09 -04:00
|
|
|
- sens: egress
|
|
|
|
|
port: 5432
|
|
|
|
|
protocole: tcp
|
|
|
|
|
pair: serveur_postgresql
|
|
|
|
|
chiffrement: tls-requis
|
|
|
|
|
raison: "Base relationnelle du moteur Icinga (verify-full)."
|