Set-OPS-Public/roles/serveur_icinga/templates/setops-api-users.conf.j2
Daniel Allaire 6653f49f2e
Some checks are pending
verifier / verifier (push) Waiting to run
sauvegarde : la verification suit la cle, pas le depot
serveur_backup verifiait pour tout le monde — juste tant que le depot vivait
dans l ecosysteme. Depuis qu ils deposent chez leur hebergeur, le site heberge
des octets chiffres COTE CLIENT : il ne peut ni les lire ni dire s ils valent
quelque chose. La verification revient donc au seul qui detient la cle, le noeud.

client_backup verifie SON depot distant — pas le fait d avoir lance sa
sauvegarde. Une unite verte sur un depot vide est ce qui a menti un mois.

serveur_icinga n exige plus un hote serveur_backup et se branche sur deux
modeles : depot local (services sur son hote, nommes sauvegarde: <noeud>) ou
pas de depot (services sur chaque noeud, nommes sauvegarde).

Le 404 qui n etait pas une absence : les noeuds recevaient  No objects found
alors que icinga2 object list montrait le service charge. Le filtre du compte
d API ne portait que la premiere forme de nom — c est la PERMISSION qui
refusait, avec les mots d une absence.

Aussi : ingress 5665 depuis client_backup, le pair ne nommait que
serveur_backup.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
2026-09-02 18:53:44 -04:00

35 lines
1.6 KiB
Django/Jinja

/*
* 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" {{ '}}' }}
}
]
}