48 lines
2.7 KiB
YAML
48 lines
2.7 KiB
YAML
|
|
---
|
||
|
|
# LE DÉPÔT DE SAUVEGARDE DU SITE — le marqueur, pas l'installateur.
|
||
|
|
#
|
||
|
|
# `serveur_backup` pose le dépôt et son utilisateur restreint ; ce rôle dit que CE dépôt
|
||
|
|
# est celui où les écosystèmes du site déposent leur état, et déclare le flux qui le
|
||
|
|
# permet.
|
||
|
|
#
|
||
|
|
# Les valeurs viennent de `serveur_backup` : on ne les redéclare pas ici, une seconde
|
||
|
|
# source finirait par diverger de la première.
|
||
|
|
# LA RACINE PARTAGÉE — parent des dépôts, home de personne.
|
||
|
|
#
|
||
|
|
# Chaque déposant (les locataires, et le site lui-même) a SON sous-répertoire en 0700.
|
||
|
|
# Celui-ci est leur parent commun : il appartient à root, et n'est ni le home ni la
|
||
|
|
# propriété d'aucun compte de dépôt. C'est ce que `sshd` exige (`StrictModes`) pour
|
||
|
|
# accepter une clé, et ce que le noyau exige pour qu'un compte puisse simplement
|
||
|
|
# atteindre son propre répertoire.
|
||
|
|
serveur_backup_site_parent: "/srv/restic"
|
||
|
|
|
||
|
|
# Le sous-répertoire du SITE lui-même. La même valeur est passée à `serveur_backup`
|
||
|
|
# dans `meta/main.yml` — un paramètre de dépendance n'est pas en portée ici, on ne peut
|
||
|
|
# donc pas la lire, seulement la répéter.
|
||
|
|
#
|
||
|
|
# Deux littéraux qui doivent s'accorder finissent toujours par diverger. Ce qui les
|
||
|
|
# tient, c'est la vérification plus bas : le marqueur EXIGE que ce répertoire existe
|
||
|
|
# réellement. S'ils divergent, l'installateur en aura créé un autre, celui-ci sera
|
||
|
|
# absent, et le déploiement s'arrêtera en le nommant — au lieu de laisser un dépôt de
|
||
|
|
# site silencieusement inaccessible.
|
||
|
|
serveur_backup_site_racine: "{{ serveur_backup_site_parent }}/site"
|
||
|
|
serveur_backup_site_utilisateur: "{{ serveur_backup_utilisateur | default('restic') }}"
|
||
|
|
|
||
|
|
# COMBIEN DE PLACE IL FAUT AVOIR DEVANT SOI, ET POURQUOI ON LE MESURE.
|
||
|
|
#
|
||
|
|
# Un dépôt de sauvegarde qui se remplit ne tombe pas : il ACCEPTE moins, puis échoue au
|
||
|
|
# milieu d'un instantané. La panne arrive donc au pire moment — celui où l'on écrit — et
|
||
|
|
# se lit comme une erreur réseau. On refuse en amont plutôt que de la découvrir en aval.
|
||
|
|
#
|
||
|
|
# 20 Go : de quoi absorber plusieurs instantanés complets d'un écosystème. Ce n'est pas
|
||
|
|
# une capacité cible, c'est un plancher sous lequel il ne faut pas descendre sans le voir.
|
||
|
|
serveur_backup_site_espace_minimal_go: 20
|
||
|
|
|
||
|
|
# LES LOCATAIRES — un compte Unix chacun, dérivé par l'inventaire du site.
|
||
|
|
#
|
||
|
|
# Chaque entrée : `{nom, compte, pubkey}`. La liste vient de `site_inventaire.py`, qui
|
||
|
|
# détient les deux sources nécessaires (le plan du site ET les dépôts des tenants) ; le
|
||
|
|
# rôle, lui, tourne sur une machine qui n'a aucune raison de lire la carte de
|
||
|
|
# l'hébergeur. Vide par défaut : un dépôt sans locataire déclaré n'ouvre aucun compte.
|
||
|
|
serveur_backup_site_locataires: []
|