History

Daniel Allaire 671fa1fc60 reconstruction d'un trait : 43 groupes, 0 echec, 37 minutes Chezlepro rase puis reconstruit SANS UNE SEULE INTERVENTION. Les sept correctifs de la nuit tiennent sur une flotte entierement neuve. Sept devis CONFORME, prouver 36/36, make test 0, neuf sauvegardes reussies et cinq sans objet. LA BATAILLE CONTRE NodeName N'AVAIT QU'UNE CAUSE. icinga2 api setup ecrit NodeName d'apres `hostname -f`. Tant que /etc/hosts placait le nom court en premier, hostname -f mentait et le certificat devenait inverifiable. Depuis que le FQDN est en tete, Icinga s'emet spontanement un certificat CN et SAN = FQDN. Il n'y avait rien a forcer : il suffisait que la machine sache comment elle s'appelle. Le contournement par le nom court est RETIRE — il etait devenu faux des que la cause reelle a ete corrigee. Ce que ca enseigne : trois heures passees a corriger un symptome visible (le nom du certificat) alors que la cause vivait deux couches plus bas et affectait toute la flotte. Le signe qui aurait du alerter : CHAQUE correction etait effacee au passage suivant. Un correctif qu'on doit reposer sans cesse ne corrige pas. Dette notee : le clone de mon-01 a depasse proxmox_clone_timeout (600 s) pendant la generation de son ISO cloud-init. Quatre clones complets simultanes saturent le stockage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-08-13 08:49:12 -04:00
..
defaults	icinga : le pair est verifie — mais pas avec un certificat step-ca	2026-08-12 08:33:50 -04:00
meta	supervision : c'est le DEPOT qui dit ou en sont les sauvegardes	2026-08-11 21:39:05 -04:00
tasks	reconstruction from-zero : sept defauts, tous invisibles sur une flotte debout	2026-08-13 03:36:56 -04:00
templates	reconstruction d'un trait : 43 groupes, 0 echec, 37 minutes	2026-08-13 08:49:12 -04:00
README.md	docs : un README par rôle (12 manquants) + carte remise à l'état du code	2026-07-29 11:32:06 -04:00

README.md

serveur_backup

Cible des sauvegardes : héberge les dépôts restic (un sous-dossier par nœud source), servis en SFTP/SSH à un utilisateur restreint. Le pendant de client_backup.

Rôle

Crée l'utilisateur système restic et la racine des dépôts /srv/restic.
Sécurise cette racine (droits stricts).
Autorise la clé publique de sauvegarde dans son authorized_keys.

C'est tout : le rôle est délibérément minimal. Aucun démon, aucune logique de sauvegarde — tout se passe côté client (dumps, chiffrement, rétention).

Sécurité

Le chiffrement est fait par le client (restic) : ce nœud ne détient que des blocs chiffrés et n'a jamais le mot de passe des dépôts. Compromettre la cible ne donne pas accès aux données.

La clé privée correspondante vit dans la voûte, côté client_backup (vault_backup_ssh_privkey) ; seule la publique est déclarée ici.

Variables

Variable	Défaut	Rôle
`serveur_backup_utilisateur`	`restic`	Compte de dépôt
`serveur_backup_racine`	`/srv/restic`	Racine des dépôts
`serveur_backup_pubkey`	(vide — obligatoire)	Clé publique autorisée

Le rôle exige serveur_backup_pubkey (assertion) : sans elle, la cible serait déployée mais inaccessible.

Flux (`meta/flux.yml`)

22/tcp entrant depuis client_backup (SSH, clé dédiée). Aucun autre port.

Notes / limites

Hors-nœud, pas hors-site : la cible protège de la perte d'une VM, pas de la perte du cluster. Une copie hors-site reste à faire.
Dimensionner le disque en conséquence (meta/empreinte.yml : 64 Go par défaut) — c'est la ressource critique de ce nœud.
Le compte restic n'est pas confiné à un shell restreint (rrsync/ForceCommand) : durcissement possible si la cible venait à sortir du périmètre de confiance.

Prérequis

Couche services (avant les agents client_backup).