Remplacer un hôte mort : de k3 vers un k5 neuf

Document généré automatiquement depuis /home/jerome/pub/docs/05-remplacer-un-hote-mort.md sur kimsufi3, le 11 September 2026 à 14:03. Toute modification faite ici sera écrasée à la prochaine régénération : éditer le fichier source.

Scénario : k4 meurt définitivement, on bascule sur k3, puis on installe un k5 pour reprendre la production.

C’est le rôle de la réplication, pas du backup

Reconstruire k5 depuis le backup rendrait tout sauf les 725 Go de Nextcloud. Le backup reste le filet du cas où l’on perd les deux machines à la fois ; pour remplacer un seul membre de la paire, c’est la réplication qui sert.

Le cœur du dispositif est déjà générique

replique.sh, dump-bases.sh et guard.sh ne connaissent aucun nom d’hôte : ils lisent PAIR dans /etc/dockersync/config. Réappairer k3 sur un k5 ne demande qu’une ligne :

sed -i 's/^PAIR=.*/PAIR=kimsufi5.chabod.eu/' /etc/dockersync/config

L’identité SSH : le point qu’il ne faut pas découvrir le jour J

Si k5 reprend le nom DNS de k4, il doit reprendre ses clés d’hôte, sinon tous les clients affichent REMOTE HOST IDENTIFICATION HAS CHANGED et refusent de se connecter. Et prendre l’habitude de passer outre cet avertissement est précisément ce qui rend une vraie attaque invisible.

sauver-identite.sh archive donc l’identité de chaque hôte dans /var/backup/identite/ (12 Ko), et le flux A la réplique. Ainsi, quand k4 meurt, son identité vit encore sur k3.

À faire une fois sur k4, dès maintenant — c’est aujourd’hui la seule chose qui manque à ce scénario :

sudo bash /opt/ops/dockersync/sauver-identite.sh

Sans cela, si k4 meurt avant la première passe de réplication, son identité est perdue avec lui.

Ne pas restaurer une identité sur le remplaçant d’un hôte compromis : elle serait peut-être entre d’autres mains. Dans ce cas, on laisse k5 se forger la sienne et on accepte de reconfigurer les clients.

Procédure

1. Installer k5 en suivant 00-installation-k3.md, en adaptant le FQDN. Les scripts d’installation (post-install-k3.sh, deployer-sur-k3.sh) sont encore écrits pour k3 : à généraliser le jour où ce sera nécessaire, le travail est mécanique (FQDN, IP et port en variables).
2. Restaurer l’identité de k4 sur k5, depuis la copie vivant sur k3 :

   bash post-install-k3.sh --restaurer-identite /root/kimsufi4-ssh_host_keys.tar

   Comparer ensuite aux empreintes de /var/backup/identite/kimsufi4-empreintes.txt.
3. Appairer k3 et k5 : PAIR de part et d’autre, k5 en veille, k3 restant actif.
4. Répliquer k3 → k5. C’est le transfert long : 725 Go, et k3 émet sur un lien à 100 Mbit/s, donc compter ~20 h comme pour le transfert initial. Lancer le soir.
5. Basculer sur k5 avec bascule.sh --planifie, exécuté depuis k3.
6. Retirer k4 de la configuration et détruire son identité archivée si la machine est rendue à OVH.

Ce que ce scénario impose au dispositif

• Ne jamais coder un nom d’hôte dans les scripts du cœur. C’est respecté.
• Archiver l’identité SSH de chaque hôte, et la répliquer. C’est fait.
• Se souvenir que la paire n’est jamais un couple figé : c’est un rôle actif et un rôle veille, portés par des machines interchangeables.