---
# CE RÔLE EN EXIGE UN AUTRE, ET C'EST À ANSIBLE DE LE SAVOIR.
#
# `serveur_backup_site` n'installe rien : il MARQUE un dépôt comme celui où les
# écosystèmes du site déposent leur état, et vérifie qu'il est réellement en mesure de le
# recevoir. Pour cela il lit les variables de `serveur_backup`.
#
# Les valeurs par défaut d'un rôle ne sont en portée que DANS LE PLAY QUI L'INCLUT. Une
# dépendance de rôle règle les deux choses d'un coup : Ansible applique l'installateur
# AVANT le marqueur, dans le MÊME play, donc ses variables sont en portée — et l'ordre
# cesse de dépendre de la façon dont on lance le déploiement.
#
# Même raisonnement que `serveur_cache_site`, `serveur_forge_site` et
# `serveur_resolveur_site`.
dependencies:
  # EN PARAMÈTRE, PAS EN `defaults` — mesuré ici même le 2026-09-01.
  #
  # Une dépendance s'exécute AVANT le rôle qui la déclare, et les `defaults` du rôle
  # dépendant ne sont pas encore en portée quand elle tourne. La valeur posée dans
  # `serveur_backup_site/defaults` était donc lue par tout le monde SAUF par le rôle
  # qu'elle visait. Passée ici, elle porte — c'est le seul endroit où elle porte.
  #
  # CE DÉPÔT NE PEUT PAS OUVRIR CE QU'IL GARDE, ET C'EST LE BUT. Les instantanés sont
  # chiffrés par restic CHEZ LE LOCATAIRE, avec un mot de passe qui ne quitte jamais sa
  # voûte. Le site héberge des octets opaques : il ne peut ni les lire, ni les ouvrir,
  # ni les reconstituer. C'est la propriété qui rend la mutualisation acceptable — la
  # même frontière que pour les voûtes : le site sert, il ne sait pas.
  #
  # La vérification n'est pas supprimée, elle est DÉPLACÉE chez celui qui peut
  # l'exercer : le locataire, qui détient la clé et sait ce qu'il a envoyé.
  - role: serveur_backup
    # `true` DEPUIS QUE LE SITE A UN TEMOIN (2026-09-02).
    #
    # Ce drapeau a longtemps valu `false`, et pour une raison juste : le depot ne peut
    # pas ouvrir les depots des LOCATAIRES — restic chiffre chez eux, avec un mot de
    # passe qui ne quitte pas leur voute. Mais il ne verifiait alors RIEN, y compris ce
    # qu'il pouvait parfaitement ouvrir.
    #
    # `serveur_backup_noeuds_attendus` derive de l'INVENTAIRE OU TOURNE LE ROLE. Ici
    # c'est celui du site : la liste ne contient donc que des machines du site, dont ce
    # depot detient le mot de passe restic — la meme voute. Il verifie exactement ce
    # qu'il peut ouvrir, et reste aveugle au reste. C'etait deja vrai avant ; ce qui
    # manquait, c'etait quelqu'un a qui le dire.
    serveur_backup_verification_locale: true
    # LE SITE N'HABITE PAS LA RACINE DE SON PROPRE DÉPÔT.
    #
    # `serveur_backup` donne au compte `restic` la racine des dépôts pour home. C'est
    # juste chez un écosystème : il n'y a qu'un déposant, la racine EST son home.
    #
    # Ici il y en a plusieurs, et la racine devient le PARENT de leurs homes. Elle ne
    # peut donc appartenir à aucun d'eux — mesuré le 2026-09-01 : `/srv/restic` en 0700
    # au compte `restic`, sshd a refusé `restic-chez` par `StrictModes`, qui exige que
    # chaque répertoire menant au home appartienne à root ou à l'utilisateur lui-même.
    # Le message rendu était « Permission denied (publickey) » — celui d'une mauvaise
    # clé. La clé était la bonne ; c'est le CHEMIN qui était refusé. Rien dans ce
    # message ne pouvait le dire.
    #
    # Le site prend donc un sous-répertoire comme tout le monde. Le parent est à root,
    # traversable et non listable : voir `serveur_backup_site_parent`.
    serveur_backup_racine: "/srv/restic/site"

  # SSH DURCI COMME PARTOUT AILLEURS. Le desserrage que ce depot exige ne se declare PAS
  # ici : voir `serveur_backup_site_max_startups` dans `site_inventaire.py`, et pourquoi.
  - role: ssh_hardening