Set-OPS-Public/roles/serveur_backup/tasks/main.yml
Daniel Allaire 7348eb93d1 serveur_backup : ce qu un depot peut affirmer sans pouvoir lire
Les instantanes sont chiffres cote client : ce serveur heberge des octets qu il
ne peut pas ouvrir, donc pas juger. La verification suit la cle, et
client_backup la fait deja depuis chaque noeud.

Ce que la sonde ajoute : elle voit TOUT DE SUITE, et depuis la cause, ce que les
clients ne decouvriront qu a leur prochaine execution. Lecture seule apres une
erreur disque, volume plein, droits derives — le depot refuse alors tout le
monde, et neuf rouges epars ne designent pas une cause commune.

Elle ECRIT vraiment, sous l identite qui depose. Un test -w ment sur un montage
en lecture seule et sur un quota atteint.

Corrige aussi l en-tete de setops-sauvegardes.conf.j2, qui nommait encore
backup-01 comme pousseur — retire le 2026-09-02, et c est tout le sujet. Le code
avait suivi la decision, l en-tete non.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-14 09:58:54 -04:00

62 lines
2.3 KiB
YAML

---
- name: Exiger la clé publique de sauvegarde
ansible.builtin.assert:
that:
- serveur_backup_pubkey | length > 0
fail_msg: "serveur_backup_pubkey requis (clé publique de la paire de sauvegarde)."
- name: Créer l'utilisateur de sauvegarde
ansible.builtin.user:
name: "{{ serveur_backup_utilisateur }}"
home: "{{ serveur_backup_racine }}"
shell: /bin/bash
create_home: true
system: true
- name: Sécuriser la racine des dépôts
ansible.builtin.file:
path: "{{ serveur_backup_racine }}"
state: directory
owner: "{{ serveur_backup_utilisateur }}"
group: "{{ serveur_backup_utilisateur }}"
mode: "0700"
- name: Autoriser la clé SSH de sauvegarde
ansible.posix.authorized_key:
user: "{{ serveur_backup_utilisateur }}"
key: "{{ serveur_backup_pubkey }}"
state: present
# LA VÉRIFICATION SUPPOSE DE POUVOIR OUVRIR LES DÉPÔTS — CE QUI N'EST PAS TOUJOURS VRAI.
#
# Ce qui suit interroge restic, donc déchiffre. Un dépôt ne peut le faire que s'il
# détient le mot de passe des dépôts qu'il garde — vrai chez un écosystème, qui garde
# les siens ; FAUX chez le dépôt d'un site, qui garde ceux de ses locataires et ne
# détient aucun de leurs mots de passe. Il héberge du chiffré : c'est la propriété qui
# rend l'hébergement acceptable, pas une lacune à combler.
#
# Là où le site ne peut pas vérifier, c'est le LOCATAIRE qui vérifie — il détient la
# clé, et il est seul à savoir ce qu'il a envoyé. La surveillance ne disparaît donc
# pas : elle reste chez celui qui peut réellement l'exercer.
- name: Vérification locale des dépôts (là où ce dépôt peut les ouvrir)
ansible.builtin.include_tasks: verification.yml
when: serveur_backup_verification_locale | bool
# LE ROLE QUI POSSEDE LA VERITE DEPOSE SA PROPRE SONDE. `client_sante` la fait tourner et
# pousse le resultat ; il n'a pas a savoir ce qu'elle mesure.
- name: Assurer le repertoire des sondes de supervision
ansible.builtin.file:
path: /usr/local/lib/setops/sondes
state: directory
owner: root
group: root
mode: "0755"
- name: Deposer la sonde « depot »
ansible.builtin.template:
src: sonde-depot.sh.j2
dest: /usr/local/lib/setops/sondes/depot.sh
owner: root
group: root
mode: "0750"