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

36 lines
1.6 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.
*
* Compte d'API dedie au DEPOT de sauvegarde, pour deposer ses resultats passifs.
* 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.
#}
filter = {{ '{{' }} match("sauvegarde: *", service.name) || service.name == "sauvegarde" {{ '}}' }}
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
}
]
}