2026-07-03 22:49:26 -04:00
|
|
|
---
|
|
|
|
|
- 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
|
|
|
|
|
|
|
|
|
2026-09-01 22:16:20 -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
|
|
|
#
|
2026-09-01 22:16:20 -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
|