Set-OPS-Public/roles/client_backup/templates/setops-verification-depot.service.j2

# Géré par Set-OPS (rôle client_backup). Ne pas éditer à la main.
[Unit]
Description=Vérification de MON dépôt distant et rapport passif vers Icinga
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/setops-verifier-mon-depot.sh
Nice=10
IOSchedulingClass=idle
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			`# Géré par Set-OPS (rôle client_backup). Ne pas éditer à la main.`
			`[Unit]`
			`Description=Vérification de MON dépôt distant et rapport passif vers Icinga`
			`After=network-online.target`
			`Wants=network-online.target`

			`[Service]`
			`Type=oneshot`
			`ExecStart=/usr/local/sbin/setops-verifier-mon-depot.sh`
			`Nice=10`
			`IOSchedulingClass=idle`