Set-OPS-Public/roles/serveur_icinga/templates/setops-api-users.conf.j2

43 lines
2.1 KiB
Text
Raw Normal View History

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
/*
* Gere par Set-OPS (role serveur_icinga). Ne pas editer a la main.
*
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. 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
2026-09-09 20:32:08 -04:00
* Compte d'API par lequel un NOEUD depose ses resultats passifs.
*
* IL S'APPELLE ENCORE `setops-depot` (2026-09-09) : il servait d'abord au seul rapport de
* sauvegarde. Il porte desormais aussi le rapport de SANTE — un second compte serait plus
* pur, un secret par usage, mais exigerait une clef de voute de plus dans chaque
* ecosysteme, donc un geste manuel a chaque nouvel ecosysteme, pour une portee identique.
* Le renommer churnerait les voutes sans rien gagner. Le filtre ci-dessous reste etroit :
* trois noms de service, et aucun autre pouvoir.
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
* Portee minimale : uniquement `actions/process-check-result`, et uniquement sur les
* services de sauvegarde. Ce compte ne peut ni lire la configuration, ni agir ailleurs.
*/
object ApiUser "{{ serveur_icinga_api_utilisateur }}" {
password = "{{ serveur_icinga_api_motdepasse }}"
permissions = [
{
permission = "actions/process-check-result"
{#
DEUX FORMES DE NOM, PARCE QU'IL Y A DEUX MODELES (2026-09-02).
« sauvegarde: <noeud> » — l'ecosysteme a son propre depot, qui rapporte pour
tout le monde : les services vivent sur SON hote, le nom doit donc dire de quel
noeud on parle.
« sauvegarde » — l'ecosysteme depose chez son hebergeur, qui heberge du chiffre
et ne peut rien juger. Chaque noeud verifie le sien : le service vit SUR LUI, et
repeter son nom donnerait « idm-01 / sauvegarde: idm-01 ».
Le filtre n'acceptait que la premiere forme. Les noeuds recevaient
`{"error":404,"status":"No objects found."}` — le message d'un objet ABSENT,
alors qu'il existait et que c'etait la PERMISSION qui refusait. Une heure a
chercher un objet qui etait la.
La portee reste etroite : ce compte ne peut poser un resultat que sur un service
de sauvegarde, jamais ailleurs.
#}
supervision : systemctl --failed entre dans Icinga (role client_sante) CE QU IL FERME. openipmi.service echouait a chaque demarrage sur les quatorze machines depuis le 2026-09-02, et systemctl --failed rendait ZERO partout : non parce qu elles allaient bien, mais parce qu aucune n avait redemarre depuis. Il a fallu qu un humain redemarre une machine pour que le defaut existe aux yeux de quelqu un. Un controle qui ne peut echouer qu au demarrage ne mesure rien tant que rien ne demarre. PASSIF, ET A DUREE DE VIE. Un controle actif ne voit pas la machine MUETTE. Ici c est le noeud qui parle, et le ttl de son envoi fait la fraicheur : sans nouvelle, Icinga perime le service tout seul. Le silence alerte autant que l echec. Le minuteur declenche AU DEMARRAGE autant que toutes les 15 min : les echecs de cette famille naissent au boot. CRITIQUE DES LA PREMIERE UNITE, jamais un seuil — une unite en echec est soit un vrai probleme soit du bruit a retirer, et un seuil ferait vivre le bruit. Les tolerances se nomment une par une, vide par defaut. CONTROLE NEGATIF. Unite factice sur obs-01, etat relu dans IcingaDB : CRITICAL, et le verdict NOMME l unite. Les treize autres OK. Apres nettoyage : 14/14 OK. UN CONFLIT EVITE. setops-sauvegardes.conf definissait les object Host ; un second fichier de controle aurait redefini les memes, et Icinga refuse un objet en double — la configuration entiere aurait ete rejetee, donc AUCUNE supervision, en voulant en ajouter. Les hotes vivent maintenant dans setops-hotes.conf, definis une fois. TROIS OBSTACLES. ${#tableau[@]} contient {# que Jinja lit comme un debut de commentaire (remede : comment_start_string en tete du gabarit). Ma premiere sonde a traduit un 403 « Missing permission: objects/query/service » en « 0 service » — encore un echec qui ecrasait permission ; l etat se lit dans IcingaDB. Et un echec apt transitoire sur mon-01, local et disparu au second essai : mesure avant conclusion. NON FAIT : le SITE n a pas recu client_sante. 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
2026-09-09 20:32:08 -04:00
filter = {{ '{{' }} match("sauvegarde: *", service.name) || service.name == "sauvegarde" || service.name == "sante" {{ '}}' }}
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
}
]
}