{"id":10,"date":"2026-09-11T14:03:30","date_gmt":"2026-09-11T14:03:30","guid":{"rendered":"https:\/\/noteback.chabod.eu\/?p=10"},"modified":"2026-09-11T14:03:30","modified_gmt":"2026-09-11T14:03:30","slug":"doc-05-remplacer-un-hote-mort","status":"publish","type":"post","link":"https:\/\/noteback.chabod.eu\/?p=10","title":{"rendered":"Remplacer un h\u00f4te mort : de k3 vers un k5 neuf"},"content":{"rendered":"\n

Document g\u00e9n\u00e9r\u00e9 automatiquement depuis \/home\/jerome\/pub\/docs\/05-remplacer-un-hote-mort.md<\/code> sur kimsufi3, le 11 September 2026 \u00e0 14:03. Toute modification faite ici sera \u00e9cras\u00e9e \u00e0 la prochaine r\u00e9g\u00e9n\u00e9ration : \u00e9diter le fichier source.<\/em><\/p>\n\n\n

Sc\u00e9nario : k4 meurt d\u00e9finitivement, on bascule sur k3, puis on installe un k5 pour reprendre la production.<\/p>\n

C’est le r\u00f4le de la r\u00e9plication, pas du backup<\/h2>\n\n\n\n\n\n\n\n\n
<\/th>\nR\u00e9plication (ce projet)<\/th>\nBackup (\/opt\/backup\/backup.bash<\/code>)<\/th>\n<\/tr>\n<\/thead>\n
Contient NCData<\/code> (725 Go)<\/td>\noui<\/strong><\/td>\nnon<\/strong> \u2014 trou document\u00e9 dans INVENTAIRE-CRITICITE.md<\/code><\/td>\n<\/tr>\n
Forme<\/td>\nen clair, pr\u00eate \u00e0 servir<\/td>\nchiffr\u00e9e AES-256, sur Dropbox<\/td>\n<\/tr>\n
Fra\u00eecheur<\/td>\n1 h (mailcow) \u00e0 24 h<\/td>\n24 h<\/td>\n<\/tr>\n
Reconstruire un h\u00f4te<\/td>\nquelques heures<\/td>\nimpossible pour Nextcloud<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Reconstruire k5 depuis le backup rendrait tout sauf les 725 Go de Nextcloud.<\/strong> Le backup reste le filet du cas o\u00f9 l’on perd les deux<\/strong> machines \u00e0 la fois ; pour remplacer un seul membre de la paire, c’est la r\u00e9plication qui sert.<\/p>\n

Le c\u0153ur du dispositif est d\u00e9j\u00e0 g\u00e9n\u00e9rique<\/h2>\n

replique.sh<\/code>, dump-bases.sh<\/code> et guard.sh<\/code> ne connaissent aucun nom d’h\u00f4te : ils lisent PAIR<\/code> dans \/etc\/dockersync\/config<\/code>. R\u00e9appairer k3 sur un k5 ne demande qu’une ligne :<\/p>\n

<\/a>sed<\/span> -i<\/span> 's\/^PAIR=.*\/PAIR=kimsufi5.chabod.eu\/'<\/span> \/etc\/dockersync\/config<\/span><\/code><\/pre><\/div>\n
L’identit\u00e9 SSH : le point qu’il ne faut pas d\u00e9couvrir le jour J<\/h2>\n
Si k5 reprend le nom DNS de k4, il doit reprendre ses cl\u00e9s d’h\u00f4te<\/strong>, sinon tous les clients affichent REMOTE HOST IDENTIFICATION HAS CHANGED<\/code> et refusent de se connecter. Et prendre l’habitude de passer outre cet avertissement est pr\u00e9cis\u00e9ment ce qui rend une vraie attaque invisible.<\/p>\n
sauver-identite.sh<\/code> archive donc l’identit\u00e9 de chaque h\u00f4te dans \/var\/backup\/identite\/<\/code> (12 Ko), et le flux A la r\u00e9plique<\/strong>. Ainsi, quand k4 meurt, son identit\u00e9 vit encore sur k3.<\/p>\n
\n
\u00c0 faire une fois sur k4, d\u00e8s maintenant<\/strong> \u2014 c’est aujourd’hui la seule chose qui manque \u00e0 ce sc\u00e9nario :<\/p>\n
<\/a>sudo<\/span> bash \/opt\/ops\/dockersync\/sauver-identite.sh<\/span><\/code><\/pre><\/div>\n
Sans cela, si k4 meurt avant la premi\u00e8re passe de r\u00e9plication, son identit\u00e9 est perdue avec lui.<\/p>\n<\/blockquote>\n
Ne pas restaurer une identit\u00e9 sur le rempla\u00e7ant d’un h\u00f4te compromis<\/strong> : elle serait peut-\u00eatre entre d’autres mains. Dans ce cas, on laisse k5 se forger la sienne et on accepte de reconfigurer les clients.<\/p>\n
Proc\u00e9dure<\/h2>\n
    \n
  1. Installer k5<\/strong> en suivant 00-installation-k3.md<\/code>, en adaptant le FQDN. Les scripts d’installation (post-install-k3.sh<\/code>, deployer-sur-k3.sh<\/code>) sont encore \u00e9crits pour k3 : \u00e0 g\u00e9n\u00e9raliser le jour o\u00f9 ce sera n\u00e9cessaire, le travail est m\u00e9canique (FQDN, IP et port en variables).<\/li>\n
  2. Restaurer l’identit\u00e9 de k4 sur k5<\/strong>, depuis la copie vivant sur k3 :\n
    <\/a>bash<\/span> post-install-k3.sh --restaurer-identite<\/span> \/root\/kimsufi4-ssh_host_keys.tar<\/span><\/code><\/pre><\/div>\nComparer ensuite aux empreintes de \/var\/backup\/identite\/kimsufi4-empreintes.txt<\/code>.<\/li>\n
  3. Appairer k3 et k5<\/strong> : PAIR<\/code> de part et d’autre, k5 en veille<\/code>, k3 restant actif<\/code>.<\/li>\n
  4. R\u00e9pliquer k3 \u2192 k5.<\/strong> C’est le transfert long : 725 Go, et k3 \u00e9met sur un lien \u00e0 100 Mbit\/s<\/strong>, donc compter ~20 h<\/strong> comme pour le transfert initial. Lancer le soir.<\/li>\n
  5. Basculer sur k5<\/strong> avec bascule.sh --planifie<\/code>, ex\u00e9cut\u00e9 depuis k3.<\/li>\n
  6. Retirer k4 de la configuration<\/strong> et d\u00e9truire son identit\u00e9 archiv\u00e9e si la machine est rendue \u00e0 OVH.<\/li>\n<\/ol>\n
    Ce que ce sc\u00e9nario impose au dispositif<\/h2>\n
      \n
    • Ne jamais coder un nom d’h\u00f4te dans les scripts du c\u0153ur. C’est respect\u00e9.<\/li>\n
    • Archiver l’identit\u00e9 SSH de chaque h\u00f4te, et la r\u00e9pliquer. C’est fait.<\/li>\n
    • Se souvenir que la paire n’est jamais un couple fig\u00e9<\/strong> : c’est un r\u00f4le actif<\/code> et un r\u00f4le veille<\/code>, port\u00e9s par des machines interchangeables.<\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"
      Document g\u00e9n\u00e9r\u00e9 automatiquement depuis \/home\/jerome\/pub\/docs\/05-remplacer-un-hote-mort.md sur kimsufi3, le 11 September 2026 \u00e0 14:03. Toute modification faite ici sera \u00e9cras\u00e9e \u00e0 la prochaine r\u00e9g\u00e9n\u00e9ration : \u00e9diter le fichier source. Sc\u00e9nario : k4 meurt d\u00e9finitivement, on bascule sur k3, puis on installe un k5 pour reprendre la production. C’est le r\u00f4le de la r\u00e9plication, pas du backup […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-10","post","type-post","status-publish","format-standard","hentry","category-exploitation-dockersync"],"_links":{"self":[{"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/posts\/10","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10"}],"version-history":[{"count":0,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=\/wp\/v2\/posts\/10\/revisions"}],"wp:attachment":[{"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/noteback.chabod.eu\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}