Set-OPS-Public/roles/serveur_backup/tasks/main.yml

45 lines
1.7 KiB
YAML
Raw Normal View History

---
- 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
supervision : c'est le DEPOT qui dit ou en sont les sauvegardes Icinga ne surveillait rien : aucun objet Host ni Service de Set-OPS, seulement la config Debian d'origine sur localhost. Superviser setops-sauvegarde.service aurait reproduit le defaut du jour meme : l'unite etait VERTE sur onze noeuds pendant qu'elle n'emportait rien. Le noeud sait qu'il a LANCE sa sauvegarde, pas qu'elle est ARRIVEE. backup-01 evalue donc ses depots et pousse un resultat passif par noeud vers l'API Icinga. Trois criteres, parce qu'un seul suffit a mentir : l'instantane existe, il est recent (26 h / 50 h), il contient au moins un fichier. Le sens du flux est delibere : le depot parle a la supervision, jamais l'inverse — compromettre mon-01 ne donne aucun acces aux sauvegardes. Le ttl de 6 h fait la fraicheur : si le rapporteur se tait, Icinga perime les services tout seul. C'est le silence qui a laisse le defaut vivre un mois. Deux erreurs corrigees par la mesure : - --data-urlencode refuse en Bad Request (l'API veut du JSON) ; le flux, le TLS et l'auth marchaient, seule la charge etait perdue. - le seuil « vide » en octets signalait a tort idm-01 (2363 o) : un export LDIF d'un annuaire a un compte pese cela. « Vide » se mesure en FICHIERS. Et le verdict est un AVERTISSEMENT : la machine ne distingue pas « les donnees ont disparu » de « il n'y en a pas encore ». Reserve assumee : curl -k — l'API presente le cert de sa propre AC, pas step-ca. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-11 21:39:05 -04:00
# LA VÉRIFICATION SUPPOSE DE POUVOIR OUVRIR LES DÉPÔTS — CE QUI N'EST PAS TOUJOURS VRAI.
reconstruction from-zero : sept defauts, tous invisibles sur une flotte debout Chezlepro reconstruit depuis zero en 10.17.x.x. Sept defauts sont tombes, et AUCUN n'etait detectable autrement — c'est tout l'argument de la reconstruction comme preuve. 1. aucune route vers le tenant sur le poste (posee a la main, jamais persistee) 2. backup-01 exigeait l'AC d'Icinga — dependance non declaree 3. ma correction inversait les couches : REFUSEE PAR P08 avant d'entrer 4. base Forgejo a moitie initialisee (sequelle de l'arret du n°2) 5. /etc/hosts : nom court avant le FQDN -> hostname -f faux sur les 14 machines 6. API Icinga jamais activee (garde `creates:` d'api setup) 7. restic refuse tout le lot si un chemin declare manque LE CINQUIEME DEPASSAIT ICINGA. hostname -f rend le PREMIER nom : toute la flotte se croyait appelee « mon-01 ». Visible sur le certificat d'Icinga, mais le meme piege attendait Postfix (myhostname), les journaux, les certificats. FQDN d'abord. CE QU'ON NE CORRIGE PAS : icinga2 api setup REECRIT NodeName d'apres le nom court et nomme ses certificats d'apres lui. Aligne avant, il est ecrase ; aligne apres, les certificats portent le mauvais nom. On adopte sa convention : le depot appelle l'API par le nom court, celui que le certificat porte. serveur_icinga_node_name derive desormais de l'INVENTAIRE, pas d'ansible_fqdn — un fait qui depend du resolveur et rendait « mon-01 » alors que le FQDN etait bon. Le commentaire ecrit pour avertir qu'une sequence accolade-diese casse les gabarits Jinja contenait cette sequence, et cassait le gabarit. Neuf hotes en echec pour un avertissement mal redige. Sept devis CONFORME, prouver 36/36, make test 0. Neuf sauvegardes reussies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-13 03:36:56 -04:00
#
# 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