---
# CE NOEUD VERIFIE SON PROPRE DEPOT DISTANT.
#
# Inclus seulement quand un `serveur_icinga` existe dans l'ecosysteme : sans destinataire,
# le rapport n'irait nulle part, et poser un timer qui echoue chaque nuit apprendrait aux
# gens a ignorer une unite rouge.
- name: Exiger de quoi rapporter à Icinga
  ansible.builtin.assert:
    that:
      - client_backup_icinga_motdepasse | length > 0
    fail_msg: >-
      `vault_icinga_api_depot` requis : un hôte `serveur_icinga` existe, mais aucun
      secret d'API. Le nœud verrait l'état de son dépôt sans pouvoir le dire.

- name: Déposer le mot de passe d'API Icinga
  ansible.builtin.copy:
    content: "{{ client_backup_icinga_motdepasse }}\n"
    dest: /etc/setops/icinga-api.pass
    owner: root
    group: root
    mode: "0600"
  no_log: true

# L'AC d'ICINGA, PAS CELLE DE step-ca : Icinga refuse de servir un certificat qu'il n'a
# pas émis (il renouvelle tout ce qui expire sous 30 jours, nos certificats vivent 24 h).
# Domaine de confiance fermé, pair authentifié malgré tout — ce qui était le vrai enjeu.
- name: L'AC d'Icinga est-elle déjà disponible ?
  ansible.builtin.stat:
    path: "{{ client_backup_icinga_ca_source }}"
  delegate_to: "{{ client_backup_icinga_hote }}"
  register: client_backup_ca_presente

- name: Récupérer l'AC d'Icinga depuis l'hôte de supervision
  when: client_backup_ca_presente.stat.exists
  ansible.builtin.slurp:
    src: "{{ client_backup_icinga_ca_source }}"
  delegate_to: "{{ client_backup_icinga_hote }}"
  register: client_backup_ca_icinga

- name: Déposer l'AC d'Icinga pour la vérification du pair
  when: client_backup_ca_presente.stat.exists
  ansible.builtin.copy:
    content: "{{ client_backup_ca_icinga.content | b64decode }}"
    dest: "{{ client_backup_ca_verification }}"
    owner: root
    group: root
    mode: "0644"

# UN ICINGA QUI NE NOUS A JAMAIS ENTENDUS (2026-09-30). Ses services `sauvegarde` et
# `restauration` sont CRITIQUES tant qu'aucun rapport n'est arrive — c'est voulu, le silence
# doit alerter. Mais les minuteurs ne rapportent que toutes les 4 h (depot) et le DIMANCHE
# (restauration) : apres chaque reconstruction, Icinga restait rouge jusqu'a une semaine.
#
# Le noeud ne peut pas demander a Icinga s'il l'a deja entendu : son compte ne sait que
# DEPOSER. Il retient donc LUI-MEME a quel Icinga il a rapporte — l'empreinte de son AC. Un
# Icinga refait a une AC neuve ; un noeud refait n'a pas de marqueur.
#
# UN MARQUEUR A LUI, PAS LA COPIE DE L'AC. La premiere version se fiait au changement de
# `icinga-ca.crt` — or `client_sante` depose le MEME fichier, plus tot dans le deploiement :
# sur une flotte neuve il etait deja la, « ok », et rien n'etait notifie. Vu a la
# reconstruction de Chezlepro du 2026-09-30 : `restauration` rouge sur sept noeuds, et le
# pare-feu arrete. L'epreuve precedente avait joue `client_backup` SEUL, et ne pouvait pas
# le voir.
#
# ECRIT APRES LE RAPPORT (dernier gestionnaire), jamais avant : un rapport rate laisserait
# sinon le noeud convaincu d'avoir ete entendu, et la passe suivante ne retenterait rien.
- name: Retenir l'empreinte de l'Icinga destinataire
  when: client_backup_ca_presente.stat.exists
  ansible.builtin.set_fact:
    client_backup_icinga_empreinte: "{{ client_backup_ca_icinga.content | b64decode | hash('sha256') }}"

- name: A quel Icinga ce noeud a-t-il deja rapporte ?
  when: client_backup_ca_presente.stat.exists
  ansible.builtin.slurp:
    src: "{{ client_backup_marque_icinga }}"
  register: client_backup_icinga_entendu
  failed_when: false

- name: Cet Icinga ne nous a jamais entendus — premier rapport
  when:
    - client_backup_ca_presente.stat.exists
    - (client_backup_icinga_entendu.content | default('') | b64decode | trim) != client_backup_icinga_empreinte
  ansible.builtin.debug:
    msg: "Icinga {{ client_backup_icinga_empreinte[:12] }} n'a encore rien recu de {{ inventory_hostname }} : rapport immediat."
  changed_when: true
  notify: Premier rapport a Icinga

- name: Installer curl pour le rapport passif
  ansible.builtin.apt:
    name: curl
    state: present

- name: Déployer le contrôle de mon dépôt
  ansible.builtin.template:
    src: verifier-mon-depot.sh.j2
    dest: /usr/local/sbin/setops-verifier-mon-depot.sh
    owner: root
    group: root
    mode: "0700"

- name: Déployer l'unité et le timer de vérification
  ansible.builtin.template:
    src: "{{ item.s }}"
    dest: "/etc/systemd/system/{{ item.d }}"
    owner: root
    group: root
    mode: "0644"
  loop:
    - { s: setops-verification-depot.service.j2, d: setops-verification-depot.service }
    - { s: setops-verification-depot.timer.j2, d: setops-verification-depot.timer }

- name: Activer le timer de vérification
  ansible.builtin.systemd_service:
    name: setops-verification-depot.timer
    enabled: true
    state: started
    daemon_reload: true

# LE CONTROLE DE RESTAURATION (2026-09-28). Meme destinataire, meme compte, un service a
# part : « l'instantane existe » et « l'instantane se rouvre » ne sont pas la meme question.
- name: Déployer le contrôle de restauration
  ansible.builtin.template:
    src: verifier-restauration.sh.j2
    dest: /usr/local/sbin/setops-verifier-restauration.sh
    owner: root
    group: root
    mode: "0700"

- name: Déployer l'unité et le timer du contrôle de restauration
  ansible.builtin.template:
    src: "{{ item }}.j2"
    dest: "/etc/systemd/system/{{ item }}"
    owner: root
    group: root
    mode: "0644"
  loop:
    - setops-verification-restauration.service
    - setops-verification-restauration.timer

- name: Activer le timer du contrôle de restauration
  ansible.builtin.systemd_service:
    name: setops-verification-restauration.timer
    enabled: true
    state: started
    daemon_reload: true
  when: not ansible_check_mode