Blog

Document généré automatiquement depuis /home/jerome/pub/docs/08-resultat-paliers-7a-7b.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.

Préparation de bascule sur k3, sans toucher au DNS ni à Home Assistant.

Ce qui est validé

La mémoire n’est plus une inconnue

C’était le risque le plus sérieux du projet : faire tenir mailcow et Nextcloud dans 3,8 Go.

Nuance : clamd et sogo tournent malgré SKIP_*, mais en veille — 151 Mo au lieu de 1023, et 187 au lieu de 329. mailcow ne supprime pas ces conteneurs, il les endort. L’économie est d’environ 1 Go, non 1,4. Avec Home Assistant frais (~600 Mo), on serait à ~2450 Mo, soit 1,4 Go encore libre.

Les données sont exploitables

postfix répond 220 mail.chabod.eu ESMTP Postcow. Le dump SQL restauré donne une base identique à celle de k4 : c’est la preuve que le dump vaut quelque chose, ce qui n’avait jamais été établi.

k3 sert déjà les noms, DNS inchangé (palier 7b)

Certificat servi : CN = mail.chabod.eu, valide jusqu’au 12/11/2026.

Quatre défauts trouvés, qui auraient tué une vraie bascule

Le troisième est le plus instructif : une correction non testée en vaut une autre. Sans relancer le palier, la bascule aurait échoué autrement le jour venu.

Le quatrième est le plus dangereux : tous les indicateurs étaient au vert — conteneur healthy, port ouvert — et le service était pourtant inutilisable.

Trois faux positifs de mes propres contrôles

À retenir, parce qu’ils font perdre du temps et de la confiance :

• du -sh en GiB comparé à docker system df en GB : j’ai annoncé « il manque 50 Go » sur un transfert complet. 677 GiB = 727 GB.
• redis-cli sans authentification : NOAUTH pris pour une absence de clés DKIM, alors qu’elles étaient toutes là.
• grep '^ignoreip' sur une déclaration à continuation de ligne : lisait la première ligne seulement et concluait que la liste blanche était absente.

Règle : mesurer en octets, s’authentifier, et vérifier qu’un contrôle négatif n’est pas un contrôle cassé.

Ce qui reste

• Palier 7c : bascule réelle courte, sur un créneau choisi.
• Palier 7d : le retour, avec --dry-run relu avant d’armer le --delete.
• Phase 5 : noteback.chabod.eu et la publication de la documentation.

Document généré automatiquement depuis /home/jerome/pub/docs/07-tester-sans-casser.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.

La phase 7 est la plus risquée du projet. Elle ne se prend pas en bloc : quatre paliers, chacun franchi seulement quand le précédent est concluant.

Pourquoi la faire quand même

En une journée de mise en place, cinq défauts réels ont été trouvés, dont aucun ne se serait manifesté avant le jour de la vraie panne :

Un plan de secours non testé n’est pas un plan de secours.

Palier 7a — --preparer seul · risque quasi nul

Sans toucher au DNS ni à Home Assistant. Réversible par --annuler.

Ce palier répond aux questions qui comptent le plus, et il n’engage rien :

• mailcow démarre-t-il vraiment sur k3 ?
• tient-on dans 3,8 Go de RAM ? (docker stats, cible : sous 3,3 Go)
• les dumps se restaurent-ils, et les boîtes sont-elles là ?
• le store ACME fusionné porte-t-il bien les 19 noms ?
• combien de temps prend le démarrage sur l’Atom ?

C’est l’essentiel de la valeur du test pour une fraction du risque. À faire en premier, un jour ordinaire.

Palier 7b — test à blanc · risque nul

k3 sert déjà, mais le DNS pointe toujours vers k4. On force la résolution côté client :

for h in chabod.eu mail.chabod.eu cloud.chabod.eu note.chabod.eu ha.chabod.eu; do
  curl -sS -o /dev/null -w "%{http_code} %{ssl_verify_result} $hn" 
       --resolve "$h:443:37.59.39.138" "https://$h/"
done

On vérifie les codes attendus, certificats compris (ssl_verify_result à 0). Rappel de HERITAGE.md : chabod.eu répond 403 et note.chabod.eu 302 — ce sont les réponses normales, pas des pannes.

Puis on annule, et on n’a rien risqué du tout.

Palier 7c — bascule réelle courte · risque réel, maîtrisé

Seulement si 7a et 7b sont propres. Précautions, toutes nécessaires :

• un créneau calme : pas un vendredi soir, pas avant un déplacement ;
• la sauvegarde de la nuit vérifiée (/opt/backup/backup.bash à 23 h) ;
• Nextcloud en lecture seule pendant toute la bascule — c’est ce qui rend le retour trivial : sans écriture, aucun delta de 725 Go à rapatrier ;
• une durée courte et décidée d’avance : 30 minutes, pas « on verra ».

Le courrier est le point le plus tolérant : un serveur distant qui ne joint pas mail.chabod.eu réessaie pendant plusieurs jours. Un retard n’est pas une perte.

Palier 7d — le retour · le vrai moment délicat

C’est ici que deux jeux de données divergents coexistent.

Règle absolue : --dry-run du retour, relu, avant d’armer le --delete. Le sens de la réplication s’inverse, donc --delete traite désormais k3 comme la référence. Une erreur de chemin y détruit des données sur k4.

Ce qui a divergé pendant la bascule, et comment :

L’ordre ne se négocie pas : --ceder sur k3, puis --dry-run relu, puis la réplication, puis --prendre sur k4.

Ce qui reste vrai quoi qu’il arrive

k3 n’est pas une sauvegarde. Si un palier tourne mal, le filet est /opt/backup/daily-backup-2.tar.encrypt — sauf pour NCData, qui n’y figure pas. C’est précisément pourquoi Nextcloud reste en lecture seule pendant toute l’opération : ce qui n’est pas écrit ne peut pas être perdu.

Document généré automatiquement depuis /home/jerome/pub/docs/06-pare-feu-et-fail2ban.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.

Posé le 10 septembre 2026 par scripts/durcir-reseau.sh, aligné sur k4.

Configuration

UFW — entrant refusé par défaut, sortant autorisé :

fail2ban — jail sshd, paramètres identiques à k4 :

• 3 tentatives en 60 minutes
• bannissement permanent (bantime = -1)
• backend systemd
• ignoreip : k4 (37.187.74.187) et k3 (37.59.39.138), pour qu’un incident de réplication ne bannisse jamais le pair

Ce qui a été vérifié, et non supposé

Deux pièges traités

ufw limit bloque la réplication — constaté, pas supposé

Première version de la configuration : limit sur 22103 pour tout le monde. Résultat immédiat le 10/09/2026 : au bout de six commandes lancées depuis k4, la connexion est refusée. L’ordre de redémarrage n’est jamais parti, et uptime a révélé que la machine n’avait pas bougé.

Le problème n’est pas l’administration mais la réplication : une passe ouvre plusieurs connexions SSH — rôle du pair, horodatage, puis un rsync par arborescence. Elle aurait été bloquée en silence.

La correction est une règle ALLOW pour les adresses du parc, posée avant le limit général : UFW évalue ses règles dans l’ordre, et une règle spécifique placée après un limit ne serait jamais atteinte.

Activer UFW à distance peut couper l’accès

Le script autorise le port SSH avant toute activation, et pose un filet : un ufw disable temporisé à 5 minutes, désarmé seulement une fois vérifié que SSH répond encore. Sur une machine distante, c’est la précaution qui évite le recours au mode rescue.

UFW ne filtre pas les ports publiés par Docker

Docker insère ses règles dans nat/PREROUTING, en amont du filtrage d’UFW : un conteneur qui publie un port est joignable même si UFW le refuse. Ce n’est pas une erreur de configuration, c’est le fonctionnement de Docker.

La démonstration est sur k4, où UFW est actif et où les ports 80, 443, 25, 465, 587, 110, 143, 995, 4190 et 22310 sont pourtant tous exposés.

UFW protège donc les services de l’hôte, pas les conteneurs. Quand k3 deviendra actif, mailcow ouvrira ses ports sans qu’UFW n’y puisse rien — c’est son conteneur netfilter qui assure ce blocage, et il fait très bien ce travail. Filtrer les conteneurs demanderait des règles dans la chaîne DOCKER-USER, ce qui sort du cadre de ce projet.

L’appairage doit commencer par les listes blanches

Constaté le 10/09/2026, aux dépens de la mise en service. Le mécanisme de rôle installé sur k3 avant que sa clé ne soit autorisée sur k4 : role.sh a tenté trois connexions, et k4 a banni k3 définitivement.

11:33:27  [sshd] Found 37.59.39.138
11:38:53  [sshd] Found 37.59.39.138
11:39:11  [sshd] Found 37.59.39.138
11:39:11  [sshd] Ban 37.59.39.138

L’action nftables-fwd de la jail zzz-forward-ban bannit sur toutes les chaînes : le port 443 de k4, ouvert au monde entier, devenait injoignable depuis k3. Symptôme trompeur — un « Connection refused » sur tous les ports ressemble à une panne réseau, pas à un bannissement.

Deux causes de bannissement du pair, indépendantes :

1. La réplication ouvre plusieurs connexions SSH par passe — rôle du pair, horodatage, puis un rsync par arborescence. Un incident quelconque (clé pas encore posée, pair en cours de redémarrage) suffit à atteindre les 3 échecs. Avec bantime = -1, c’est irrévocable sans intervention.
2. La sonde externe sonde-chabod.sh, qui tourne sur k3 toutes les 15 minutes, déclenche traefik-4xx-flood sur k4 — traces à 08:45 et 09:00 ce matin-là, avant même ce projet.

Règle à appliquer

Poser les listes blanches des DEUX côtés avant la première tentative de connexion. Pas après, pas « on verra » : avec un bannissement permanent, la première erreur est définitive.

Sur k4, un fragment unique zzz-pair-dockersync.conf remplace les cinq déclarations ignoreip concurrentes qui s’y trouvaient — c’est la dernière lue qui gagnait, ce qui rendait l’ensemble illisible.

Portée réelle de fail2ban ici

PasswordAuthentication no étant posé, aucune attaque par mot de passe n’est possible sur k3 : fail2ban n’y ajoute donc pas de protection contre l’intrusion. Son intérêt est ailleurs, et reste réel — il coupe court aux scans répétés, allège le journal, et évite qu’une adresse hostile occupe des connexions. C’est un réducteur de bruit plus qu’un rempart, et il vaut mieux le savoir que de s’en croire protégé.

Commandes utiles

sudo bash /root/dockersync/durcir-reseau.sh --etat   # état complet
sudo fail2ban-client status sshd                     # jail
sudo fail2ban-client set sshd unbanip <IP>           # débannir
sudo ufw status verbose                              # règles

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.

Document généré automatiquement depuis /home/jerome/pub/docs/04-dns-bascule.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.

Relevé du 10 septembre 2026, directement auprès des serveurs faisant autorité.

Le paysage réel : deux hébergeurs, pas un

La contrainte des 15 minutes ne concerne donc que chabod.eu. Les trois autres domaines sont déjà chez OVH, où la bascule peut être scriptée.

✅ Fait le 10/09/2026 — TTL abaissés à 300 s

Abaissés par import d’un fichier de zone dans le panel LWS, ce qui a permis de descendre à 300 s alors que l’interface annonce 900 s comme minimum.

L’interface LWS affiche encore 24 h : elle se trompe. Seule compte la réponse des serveurs faisant autorité, vérifiable par dig +noall +answer kimsufi4.chabod.eu A @ns1.lws-hosting.biz.

Google (8.8.8.8), Cloudflare (1.1.1.1) et Quad9 (9.9.9.9) renvoient tous 300 s, en 30 à 40 ms. La propagation est effective ; les caches encore porteurs de l’ancien TTL de 24 h se seront alignés au plus tard le 11/09/2026.

Anomalie relevée : deux serveurs de noms sur quatre refusent la zone

ns3.lwsdns.com (91.216.107.20) et ns4.lwsdns.com (91.107.253.2) répondent REFUSED pour chabod.eu, alors qu’ils sont déclarés dans la zone. Seuls ns1 et ns2 la servent. C’est l’anomalie déjà notée dans traefik-migration/README.md.

Impact pratique faible : les résolveurs apprennent vite quels serveurs répondent et privilégient ns1/ns2 — d’où les 40 ms mesurées. Mais la zone n’a en réalité que deux serveurs au lieu de quatre, donc moins de redondance qu’annoncé. À signaler à LWS sans urgence.

Urgent : le TTL de kimsufi4.chabod.eu était à 24 heures

Une bascule faite aujourd’hui mettrait jusqu’à 24 heures à être visible partout, pas 30 minutes. L’enregistrement pivot est le pire des six.

Le piège : abaisser un TTL ne prend effet qu’après son expiration

Un résolveur qui a déjà kimsufi4.chabod.eu en cache le garde 24 h, quelle que soit la nouvelle valeur publiée entre-temps. Il faut donc abaisser les TTL au moins 24 h avant toute bascule, test compris.

Fait le 10/09/2026. C’était le geste le plus rentable du projet.

Plafond de propagation : 10 minutes

Les six enregistrements sont abaissés. Le TTL le plus long est celui de kopains.fr et bunzenthal.lu (600 s) : c’est le plafond de propagation d’une bascule. Les noms les plus critiques — mail, cloud, ha, git, note, music, films, tous dépendants du pivot kimsufi4.chabod.eu — sont à 5 minutes.

Un délai de grâce reste à respecter. L’ancien TTL de kimsufi4.chabod.eu était de 24 h : les résolveurs qui l’avaient encore en cache au moment du changement le conservent jusqu’à 24 h. Tous les caches seront alignés au plus tard le 11/09/2026. Aucune bascule, test compris, avant cette date.

Pas besoin de toucher aux CNAME

Point subtil, qui évite du travail inutile. Les CNAME ont des TTL très variés (note 813 s, music et films 21 600 s, cloud et ha ~7 100 s), mais ils n’entrent pas en jeu dans la bascule : ils continueront de pointer vers kimsufi4.chabod.eu, ce qui reste correct.

Un résolveur ayant en cache cloud.chabod.eu CNAME kimsufi4.chabod.eu refera de toute façon la requête A sur kimsufi4.chabod.eu dès que ce TTL expire, et obtiendra la nouvelle adresse. Seuls les 6 enregistrements A comptent.

RTO réaliste avec un TTL de 300 s

L’objectif de 30 minutes est dépassé. Le facteur dominant n’est plus le DNS mais le démarrage des conteneurs sur l’Atom — c’est désormais là qu’il faut chercher du temps si l’on veut descendre plus bas.

Le mail est le cas le plus favorable

Un serveur distant qui ne joint pas mail.chabod.eu réessaie pendant plusieurs jours — c’est le fonctionnement normal de SMTP. Un courrier retardé de 15 min n’est pas perdu, et il n’y a pas de rejet définitif sur un simple délai. Le RTO du mail est donc bien moins critique que celui du web.

Option devenue peu utile : rapatrier chabod.eu chez OVH

Tes trois autres domaines y sont déjà. OVH offre un TTL minimum de 60 s et une API DNS qui rendrait la bascule scriptable de bout en bout — ce que tu souhaitais au départ et que LWS ne permet pas.

Gain désormais marginal sur le RTO, puisque LWS sert déjà du 300 s. Il resterait l’automatisation (plus de manipulation manuelle) et la correction de l’anomalie ns3/ns4.

Coût : le transfert d’une zone qui porte du courrier (MX, SPF, DKIM, DMARC, autoconfig, autodiscover) est une opération délicate, à mener à part et au calme. Ce n’est pas un prérequis du projet, mais c’est le seul levier qui fasse réellement descendre le RTO.

Le MX secondaire LWS — tranché le 10/09/2026

chabod.eu a un MX 50 91.216.107.237 = mail18.lwspanel.com. La question restait ouverte depuis le début du projet ; la reponse est oui, LWS reprend le courrier quand k4 est injoignable.

Conséquence majeure : aucun courrier n’est perdu pendant une panne. Le seul point que INVENTAIRE-CRITICITE.md mesure en minutes — la réception du courrier — est donc déjà couvert par un tiers, indépendamment de ce projet.

La nuance qui reste à vérifier

« Repris dans le webmail LWS » n’est pas « spoolé puis relayé » :

Si c’est le second cas — ce que la formulation suggère — alors après une panne le courrier vit à deux endroits qui ne se réconcilient pas. Rien n’est perdu, mais il faut aller le chercher, et il n’apparaîtra jamais dans l’IMAP.

À vérifier une fois, au calme : couper mailcow quelques minutes, s’envoyer un message, et regarder où il atterrit — et s’il finit par arriver dans SOGo.

Ce que cela change pour le projet

• Le RPO du courrier est sauvé par LWS : la bascule d’urgence n’a plus à courir après les minutes pour éviter une perte.
• Le RTO reste pertinent : les messages ne sont pas dans la boîte habituelle de l’utilisateur, et l’émission depuis chabod.eu reste indisponible.
• La bascule planifiée (dist-upgrade) n’est pas concernée : elle vise le RPO 0 et un arrêt propre, pas le rattrapage d’une panne.

Autrement dit : le mode urgence devient moins urgent, le mode planifié reste la raison d’être du dispositif.

Document généré automatiquement depuis /home/jerome/pub/docs/03-ticket-ovh-debit.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.

❌ SANS OBJET — vérifié le 10/09/2026

Le manager indique : « Serveur KS-3 – Atom N2800 – 4GB DDR3 1066 MHz – 2To SATA ». Cette offre est vendue avec 100 Mbps.

Le débit mesuré — 10 Mo/s, soit 80 Mbit/s — représente 80 % du lien, ce qui est un bon rendement pour du SSH. Il n’y a rien à réclamer : la machine fournit ce pour quoi elle est vendue.

Le fait que la carte annonce 1000baseT/Full n’y change rien : c’est du matériel générique, bridé au niveau du port par l’offre commerciale.

Ne pas envoyer de ticket. Le planning intègre déjà les 100 Mbit/s (voir 02-planning.md).

Le texte du ticket a été retiré : il aurait été rejeté et aurait fait perdre du temps de part et d’autre. Si le débit venait un jour à tomber nettement sous les 80 Mbit/s sans raison, relancer scripts/verifier-debit-k3.sh --mesure et rouvrir la question — le lien serait alors réellement dégradé.

Document généré automatiquement depuis /home/jerome/pub/docs/02-planning.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.

Établi le 9 septembre 2026. Les durées de transfert sont mesurées, pas estimées.

La machine

Kimsufi KS-3 — Atom N2800, 4 Go DDR3, 2 To SATA, RBX4 (rack 50C18, ID 229830). Reconduction automatique de mois en mois : pas d’échéance à surveiller.

Les 100 Mbit/s sont la spécification vendue de cette offre, pas une panne : aucun ticket à ouvrir (cf. 03-ticket-ovh-debit.md).

La contrainte qui structure tout : 100 Mbit/s

k3 est raccordé à 100 Mbit/s, contre 1 Gbit/s pour k4. Mesure réelle d’un transfert k4 → k3 : 10 Mo/s, soit 80 % du lien — un bon rendement pour du SSH. Le réseau est saturé, pas le CPU : aucun réglage de chiffrement n’y changera rien.

La carte supporte et annonce le gigabit, mais le port est bridé par l’offre. C’est un plafond définitif : le planning ci-dessous est calculé dessus.

Conséquence à assumer : en mode dégradé, k3 servira Nextcloud sur un lien 10 fois plus étroit. Pour le mail et Home Assistant c’est indolore ; pour le téléchargement de gros fichiers, ce sera lent mais utilisable.

Vue d’ensemble

sept.        S37          S38          S39          S40      S41       S42+
         09 ─── 15    16 ─── 22    23 ─── 29    30 ─── 06  07 ── 12  20 ───
         │            │            │            │          │        │
  P0 ────┤            │            │            │          │        │
  réinstall + 19h30   │            │            │          │        │
         │            │            │            │          │        │
         P1 ─ P2 ─────┤            │            │          │        │
         rôle, réplication         │            │          │        │
                      │            │            │          │        │
                      P3 ─ P4 ─────┤            │          │        │
                      dumps, prépa k3           │          │        │
                                   │            │          │        │
                                   P5 ─ P6 ─────┤          │        │
                                   noteback, bascule       │        │
                                                │          │        │
                                                P7 ────────┤        │
                                                aller-retour        │
                                                           ▲        │
                                                    13 oct : ACME   P8
                                                    NE RIEN FAIRE   upgrade k4

Détail

Phase 0 — Réinstallation de k3 · S37, 1 jour + 1 nuit

Le transfert de NCData est le point de non-retour du calendrier : 19 h 30 pendant lesquelles NCData n’existe qu’en un exemplaire, sur k4. Le lancer un soir, le vérifier le lendemain.

Les TTL sont à traiter en premier, et pas seulement pour gagner du temps. kimsufi4.chabod.eu est à 86 400 s (24 h), et abaisser un TTL ne prend effet qu’après expiration de l’ancien : tant qu’ils ne sont pas abaissés depuis plus de 24 h, aucune bascule — test compris — ne peut aboutir en moins d’une journée. Détail dans 04-dns-bascule.md.

Phase 1 — Mécanisme de rôle · S38, ~3 h

Rôle actif/veille, dockersync-guard.service, liste blanche. Test : redémarrer k3 et vérifier que rien ne monte tout seul. Rien ne doit être répliqué avant que cette phase soit finie — c’est elle qui empêche un k4 réparé d’écraser des données fraîches.

Phase 2 — Script de réplication · S38, ~5 h + observation

Le plus gros morceau de code. Premier passage en --dry-run, sortie relue ensemble avant d’armer --delete. Puis quelques jours d’observation : k3 doit cesser de croître, ce qui n’a jamais été le cas jusqu’ici.

Phase 3 — Dumps cohérents · S39, ~3 h

Réutilise la logique de /opt/backup/backup.bash, en ajoutant la cadence horaire pour mailcow. Vérification : restaurer le dump dans un conteneur jetable et compter les boîtes.

Phase 4 — Préparer k3 à la charge · S39, ~3 h

Profil mailcow dégradé, HELO postfix, docker compose pull périodique.

Phase 5 — noteback et documentation · S40, ~4 h

Instance WordPress dédiée sur k3, généralisation de publier-docs-note.sh et extension de son garde-fou anti-fuite.

Phase 6 — Scripts de bascule · S40, ~6 h

bascule.sh --planifie et --urgence, fusion du store ACME, checklist DNS.

Phase 7 — Tests · S41, 1 journée

Test à blanc sans toucher au DNS, puis aller-retour complet chronométré. C’est le seul test qui valide le cas d’usage dist-upgrade.

Prérequis : les TTL doivent avoir été abaissés depuis plus de 24 h.

À terminer avant le 10 octobre. Le 13 octobre tombe le premier renouvellement ACME automatique (cf. HERITAGE.md) : il doit se dérouler sur k4 en conditions normales, pas au milieu d’une bascule.

⚠️ 13 octobre 2026 — renouvellement ACME

Ne rien faire ce jour-là. Rejouer ~/claude/scripts/inspect-acme-store-2026-09-01.sh pour vérifier que les 19 certificats se sont renouvelés proprement.

Phase 8 — Dist-upgrade de k4 vers 26.04 · S42 ou après, 1 journée

L’aboutissement : basculer sur k3, migrer k4, revenir. À ne lancer qu’une fois l’ACME du 13 octobre digéré, et l’aller-retour de la phase 7 réussi.

Récapitulatif

Les six semaines sont une cadence confortable, pas un chemin critique : à part les 19 h 30 de transfert initial, rien n’est incompressible. L’ordre, en revanche, ne se négocie pas — la phase 1 avant toute réplication, et la phase 7 avant la 8.

Document généré automatiquement depuis /home/jerome/pub/docs/01-audit-k3-avant-effacement.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.

Contrôle préalable à la réinstallation. Question posée : k3 contient-il des données qui n’existent nulle part ailleurs ?

Réponse : non. L’effacement peut être fait sans perte.

Ce qui occupe les 1015 Go

Les images ne pèsent que 2,7 Go : ce sont bien les volumes qui remplissent le disque, pas les images.

Le mécanisme du remplissage, mesuré

rsync sans --delete, toutes les 10 minutes, sur des volumes vivants. Rien n’est jamais supprimé côté k3, donc tout s’accumule indéfiniment.

Le cas ttrss-docker_db est exemplaire : 223 Go de déchets pour une base de 84 Mo. PostgreSQL réécrit ses fichiers en permanence ; chaque segment WAL et chaque relation supprimée reste sur k3 à jamais. C’est aussi la preuve que ces copies de bases, prises à chaud, sont inexploitables.

Total : ~254 Go de déchets purs sur les 1004 Go.

Volumes présents sur k3 et absents de k4

Le courrier — le point qui comptait vraiment

La structure vmail est identique des deux côtés :

La seule différence, mailcow.local, est un répertoire vide de 12 Ko contenant 0 message — résidu d’une boîte technique supprimée sur k4 le 28/08.

Fraîcheur de la réplication : fichier le plus récent à 2026-09-09 14:55:55 sur k3 et 2026-09-09 16:55:55 sur k4 — le même instant, à l’écart de fuseau près (k3 en UTC, k4 en CEST). La réplication du courrier est à jour à la minute, et aucun message n’existe uniquement sur k3.

Cet écart de 2 h entre les deux machines est exactement le piège de corrélation de logs signalé dans HERITAGE.md. Il disparaît à la réinstallation : Europe/Luxembourg des deux côtés.

Conséquence pour le dimensionnement

Après réinstallation avec /var porté à ~1,67 To, les 725 Go réels de NCData laissent environ 900 Go de marge. La question « Nextcloud tient-il sur k3 ? » est tranchée : oui, largement.

Verdict

Feu vert pour l’effacement. La sauvegarde de ce qui était propre à k3 (sonde, crontab) est dans ~/claude/dockersync/sauvegarde-k3-avant-reinstall/.

Document généré automatiquement depuis /home/jerome/pub/docs/00-installation-k3.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.

Phase 0 du projet de paire actif/veille. Ce document est la marche à suivre complète, du manager OVH jusqu’au premier transfert de données.

k3 sera intégralement effacé. Tout ce qui lui était propre a été sauvegardé dans ~/claude/dockersync/sauvegarde-k3-avant-reinstall/ sur k4 (répertoire en mode 700 : il contient le topic ntfy, qui est un secret).

Ce qui est déjà vérifié

Étape 1 — Avant de lancer quoi que ce soit

a. Vérifier que k3 ne contient rien d’unique. FAIT le 09/09/2026. Voir 01-audit-k3-avant-effacement.md. Verdict : feu vert, rien d’unique sur k3. Le courrier y est répliqué à la minute près et sa structure est identique à celle de k4 ; les 14 dépôts Subversion sont archivés et vérifiés sur k4 ; le reste est du résidu. Au passage : 254 Go des 1004 Go sont des déchets accumulés faute de --delete, dont 223 Go pour la seule base tt-rss, qui fait 84 Mo sur k4.

b. Abaisser les TTL DNS — à faire maintenant, c’est le geste le plus rentable. kimsufi4.chabod.eu est à 86 400 s (24 h), et il couvre 7 sous-domaines. Abaisser un TTL ne prenant effet qu’après expiration de l’ancien, aucune bascule ne peut aboutir rapidement tant que ce n’est pas fait depuis plus de 24 h. Le minimum chez LWS est 900 s. Voir 04-dns-bascule.md pour le détail des 6 enregistrements et la répartition LWS / OVH.

c. Sauvegarder l’identité SSH de k3. FAIT le 09/09/2026. Les 6 clés d’hôte sont dans sauvegarde-k3-avant-reinstall/identite-hote/ssh_host_keys.tar (mode 600 : il contient des clés privées). Les restaurer après réinstallation évite que tous tes clients affichent REMOTE HOST IDENTIFICATION HAS CHANGED.

d. Vérifier que la sauvegarde quotidienne de k4 a tourné cette nuit. Pendant la réinstallation et le retransfert, NCData n’existera qu’en un seul exemplaire. /opt/backup/daily-backup-2.tar.encrypt ne le contient pas — c’est un trou connu — mais le reste doit être sain.

Étape 2 — Manager OVH

Serveur kimsufi3 → Réinstaller → installation personnalisée.

• Système : Ubuntu 26.04 LTS (server, 64 bits)
• Nom d’hôte : kimsufi3.chabod.eu
• Clé SSH : y déposer la clé publique jerome@kimsufi4 (~/.ssh/id_ed25519.pub sur k4) pour avoir un accès immédiat
• Partitionnement : personnalisé (voir ci-dessous). C’est la raison principale de cette réinstallation, ne pas laisser le schéma par défaut.
• Script post-installation : le laisser vide. Voir ci-dessous.

Pourquoi ne pas utiliser le script post-installation d’OVH

Le manager propose de faire exécuter un script en root à la fin de l’installation, depuis une URL. Ce n’est pas le bon outil ici :

Le champ « clé SSH » du manager, lui, est à utiliser : il évite l’étape ssh-copy-id.

Partitionnement cible

Le schéma actuel gaspille 495 Go : / fait 503 Go pour 8,5 Go utilisés, alors que /var — le seul qui compte — est saturé à 81 %.

Le swap à 8 Go n’est pas un luxe : k3 n’a que 3,8 Go de RAM et devra porter mailcow, Home Assistant et Nextcloud simultanément.

Étape 3 — Post-installation

Dans le manager OVH, dépose la clé publique de k4 au moment de la réinstallation. C’est ce qui rend la suite automatique. Sinon OVH envoie un mot de passe root par courriel, et il faudra d’abord faire, depuis un vrai terminal :

ssh-copy-id -p 22 -i ~/.ssh/id_ed25519.pub root@kimsufi3.chabod.eu

Ensuite, une seule commande depuis k4 :

bash ~/claude/dockersync/scripts/deployer-sur-k3.sh

Elle enchaîne les huit étapes : contrôle de joignabilité, purge de known_hosts, transfert du script et de l’identité, restauration de l’identité, vérification que les empreintes sont bien celles d’origine, configuration complète, puis validation de l’accès sur le port 22103.

Pourquoi ce script existe : la clé d’hôte change deux fois

C’est le piège de l’opération, et il n’est pas évident :

1. La réinstallation donne à k3 une nouvelle clé d’hôte → k4 refuse la connexion (HOST KEY CHANGED) tant que known_hosts n’est pas purgé.
2. --restaurer-identite lui rend son ancienne clé → elle change donc une seconde fois, et il faut purger à nouveau.

Le script purge aux deux moments, dans le bon ordre. À la fin, il compare les empreintes obtenues à celles relevées avant l’effacement :

SHA256:+R1BfgFFUgpC3NF4ygNirV8BOz7ZdE/Mtt77xpjcN4U (RSA)
SHA256:luVObYOfse3Pn3dBh6rnsJuYG2NZFEJSDlcRRldnsOw (ECDSA)
SHA256:biSvhMMQS/h3Ef7BCcxc/6XtqWZagijoVXkPhJa5OQU (ED25519)

Si ces trois empreintes reviennent identiques, aucun de tes clients n’aura quoi que ce soit à reconfigurer. Si elles diffèrent, le script le dit et s’interrompt pour confirmation : c’est le seul contrôle qui prouve que la restauration a réellement fonctionné.

Le .tar contient des clés privées d’hôte. Il n’est pas embarqué dans le script, se transfère à part, et le script le détruit par shred -u juste après usage.

Le script post-install-k3.sh fait, dans l’ordre :

1. contrôle du partitionnement (/var ≥ 1,4 To, swap ≥ 7 Go) — c’est la raison de la réinstallation, autant le vérifier tout de suite ;
2. fuseau Europe/Luxembourg ;
3. paquets de base : rsync, jq, curl, git, util-linux ;
4. purge d’apache2 et de mysql-server s’ils sont présents ;
5. Docker CE depuis download.docker.com, pas le paquet Ubuntu ;
6. utilisateur jerome en uid/gid 1001, groupe docker, sudo NOPASSWD, et les 9 clés clientes reprises de k4 — chacune validée par ssh-keygen avant installation ;
7. net.ipv4.ip_unprivileged_port_start=0, requis par Traefik ;
8. authentification par clé uniquement (voir plus bas) ;
9. Port 22103 en gardant le port 22 ouvert.

Le port SSH est le point dangereux

k3 est une machine distante : perdre sshd, c’est perdre la machine. Le script ouvre donc 22103 en gardant le port 22, et vérifie que 22103 écoute avant de rendre la main. La fermeture du 22 est une seconde commande, délibérée :

# 1. valider depuis k4 que le nouveau port répond
ssh -p 22103 jerome@kimsufi3.chabod.eu 'id'

# 2. seulement alors, fermer le 22
ssh -p 22103 jerome@kimsufi3.chabod.eu 'sudo bash /root/post-install-k3.sh --fermer-22'

Sur Ubuntu 24.04 et suivantes, c’est ssh.socket qui écoute, pas sshd. Un générateur (sshd-socket-generator) relit sshd_config et régénère le socket : poser Port 22103 suffit donc, à condition de faire systemctl daemon-reload puis restart ssh.socket — ce que le script fait.

Authentification par clé uniquement

Trois directives, pas une :

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

PasswordAuthentication no seul ne suffit pas : avec UsePAM yes, un mot de passe passe encore par le canal clavier-interactif. Il faut couper les deux.

Le script ne se contente pas d’écrire ces lignes, il vérifie qu’elles sont effectives avec sshd -T, qui donne la configuration réellement appliquée une fois tous les fragments de sshd_config.d/ fusionnés. Ubuntu en pose deux (50-cloud-init.conf, 60-cloudimg-settings.conf) : sur k3 et k4 ils mettent déjà PasswordAuthentication no, donc pas de conflit, mais c’est le genre de fichier qui réactive silencieusement les mots de passe après une réinstallation. Vérifier la config effective plutôt que celle qu’on croit avoir écrite est le seul contrôle qui vaille.

Si un fragment prenait le dessus, le script le signale et indique quoi inspecter.

Les clés, côté serveur et côté hôte

Deux choses distinctes, souvent confondues :

Le script traite les deux. Restaurer l’identité d’hôte n’est pas qu’un confort : habituer des utilisateurs à passer outre REMOTE HOST IDENTIFICATION HAS CHANGED est précisément ce qui rendrait une vraie attaque invisible. C’est légitime ici parce que la réinstallation est volontaire — à ne pas faire si la machine avait été compromise, son identité pouvant alors être entre d’autres mains.

La clé root@kimsufi3 est volontairement exclue du jeu réinstallé : sa partie privée disparaît avec le disque, et c’est justement l’accès root de k3 vers k4 que le projet cherche à fermer.

Identités à respecter

jerome doit avoir uid 1001 et gid 1001, comme sur k4. OVH crée souvent le premier compte en uid 1000 ; le script corrige. Sans cette correspondance, les fichiers répliqués avec --numeric-ids arriveraient avec un propriétaire inexistant. Le store ACME, lui, est en 2000:2000 sans compte hôte associé — c’est normal, Traefik tourne sous ces numéros.

Étape 4 — Premier transfert

Priorité absolue à NCData (725 Go) : c’est la donnée qui n’existe nulle part ailleurs. Une nuit suffit en intra-OVH (2 ms de latence entre les deux machines).

Le reste (mailcow, /opt/dockerscripts, /var/www) suit ensuite ; c’est l’affaire de quelques minutes.

Après cette phase

Phase 1 : mécanisme de rôle actif/veille. Voir le plan complet dans ~/.claude/plans/.