Daniel Allaire
f8a84b78d5
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> |
||
|---|---|---|
| .. | ||
| defaults | ||
| meta | ||
| tasks | ||
| templates | ||
| 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
resticet 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
resticn'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).