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.
| RAM utilisée | 1845 Mo / 3881 Mo |
| Disponible | 1901 Mo |
| Swap | 293 Mo |
| Durée de la préparation | 14 min 47 |
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
| Contrôle | k3 | k4 |
|---|---|---|
| Domaines mailcow | 4 | 4 |
| Boîtes | 12 | 12 |
| Alias | 22 | 22 |
| Boîtes vues par dovecot | 13 | — |
| Clés redis (dont DKIM) | 2402 | 2403 |
DKIM_SELECTORS/PRIV/PUB |
présentes | présentes |
| Noms dans le store ACME | 19 | 19 |
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)
| Nom | Code | TLS | Lecture |
|---|---|---|---|
mail.chabod.eu |
200 | valide | correct |
webmail.chabod.eu |
302 | valide | redirection SOGo |
cloud.chabod.eu |
503 | valide | Nextcloud en mode maintenance — attendu |
chabod.eu |
404 | valide | legacy-web hors périmètre, pas de backend |
Certificat servi : CN = mail.chabod.eu, valide jusqu’au 12/11/2026.
Quatre défauts trouvés, qui auraient tué une vraie bascule
| Défaut | Symptôme | Correction | |
|---|---|---|---|
| 1 | sleep 20 fixe avant restauration des dumps |
gzip: stdout: Broken pipe — trompeur, le tube se fermait parce que MariaDB n’était pas prête |
attente active jusqu’à 90 s, en interrogeant la base |
| 2 | Sept réseaux external créés sur k4 par des stacks hors périmètre |
network nextcloud_bridge declared as external, but could not be found — Traefik refuse de démarrer |
extraction par docker compose config et création des manquants |
| 3 | Ma correction du n°2 a volé la plage de mailcow : t_edge_note avait pris 172.22.0.0/16, qui englobe le 172.22.1.0/24 réservé |
invalid pool request: Pool overlaps with other one on this address space |
créer le réseau de mailcow en premier, avec sa plage explicite |
| 4 | Store ACME jamais fusionné — annoncé, jamais implémenté. Et acme//logs/ en root:root alors que Traefik tourne en uid 2000 |
Traefik démarre, se déclare healthy, écoute sur 443, et sert un TLS invalide. curl rend un code 000, qui ressemble à une panne réseau |
fusion du store du pair + chown 2000:2000 |
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 -shen GiB comparé àdocker system dfen GB : j’ai annoncé « il manque 50 Go » sur un transfert complet. 677 GiB = 727 GB.redis-clisans authentification :NOAUTHpris 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-runrelu avant d’armer le--delete. - Phase 5 :
noteback.chabod.euet la publication de la documentation.
Leave a Reply