---
# 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
    serveur_backup_verification_locale: false
    # 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, ET DESSERRÉ LÀ OÙ CE DÉPÔT L'EXIGE (mesuré le 2026-09-01).
  #
  # DEUX DÉFAUTS EN UN, TROUVÉS EN LANÇANT DOUZE SAUVEGARDES D'UN COUP.
  #
  # 1. Le gabarit transporte des fichiers de durcissement PÉRIMÉS — dont
  #    `20-chezlepro-hardening.conf`, celui-là même que `ssh_hardening_fichiers_perimes`
  #    existe pour retirer. Il a été figé dans l'image, donc chaque VM clonée en hérite.
  #    Les machines du SITE ne recevaient jamais `ssh_hardening` (leur socle est
  #    `serveur_debian` seul, là où un locataire reçoit aussi `serveur_durci`) : rien ne
  #    venait donc jamais le corriger. Le dépôt tournait avec `MaxStartups 5:30:20` et
  #    `MaxSessions 2`, des valeurs abandonnées depuis le 2026-08-09.
  #
  # 2. `MaxStartups` compte les connexions NON ENCORE AUTHENTIFIÉES. Un dépôt
  #    d'écosystème en voit une poignée ; celui d'un SITE en voit la somme de tous ses
  #    locataires, et leurs minuteurs se réveillent à la même heure. Au-delà du seuil,
  #    sshd coupe AVANT la bannière : le client rapporte
  #    `kex_exchange_identification: Connection reset by peer`, qui accuse le réseau
  #    pour un refus applicatif. Une sauvegarde perdue qui se lit comme un incident
  #    réseau ne sera pas cherchée au bon endroit.
  #
  # 60 : large devant la somme des flottes servies. Le port 22 de ce dépôt n'est
  # atteignable que depuis les locataires déclarés (`meta/flux.yml`) ; l'inondation dont
  # `MaxStartups` protège est déjà couverte à la frontière, la panne qu'il créait ne
  # l'était pas. Même arbitrage que `ssh_hardening` a fait pour la voie d'administration.
  - role: ssh_hardening
    ssh_hardening_max_startups: "60:30:200"