g9-migration/g9-migration/COMPTE-RENDU-PHASE-1.md

Compte rendu — PHASE 1 : Prérequis & sécurisation

Date de clôture : 2026-10-10 Statut : ✅ TERMINÉE — 12/12 critères validés, GO utilisateur donné, tâche Kanban « PHASE 1 » déplacée en Done. Traçabilité complète : g9-migration/journal.md (18 entrées, 6 colonnes, G8).

---

1. Périmètre et objectifs

Étape Kanban	Objectif	Résultat
T1.1	Sécuriser le xpenology (.25) : stateful hors Watchtower, CLEANUP=false, notifications	✅ Fait sur .25 et répliqué sur .24
T1.2	Inventaire des stateful xpenology + plan d'export	✅ INVENTAIRE-STATEFUL.md
T1.3	Thermique Freebox < 70 °C	⏭️ Hors périmètre agent (action manuelle utilisateur, hors G10 sans validation)
T1.4	J5040 edge / délestage avant formatage	✅ Stack IA迁移 .11, Valheim + n8n/notes sur G9, OpenFox .27→.11, GO formatage

Charte G1–G10 respectée : aucune suppression de données source (G4), backup vérifié avant toute migration (G2), aucune action destructive (G3 — formatage SSD exécuté par l'utilisateur), journal tenu (G8), aucun secret commité (G9).

---

2. T1.1 — Durcissement Watchtower (.25 + .24)

T1.1-a · Inventaire conteneurs .25

• 30 conteneurs (sudo docker ps -a DSM), cross-check 12 projets compose /volume1/docker + conteneurs GUI.
• Livrable : conteneurs-xpenology.csv (name, image:tag, mode GUI/compose, stateful, label, data_paths).
• 22 stateful, 2 stateless (flaresolverr, mini-qr), 1 watchtower. 15 yml compose récupérés.

T1.1-b · Labels watchtower.enable=false

• .24 : n8n, couchdb, obsidian, valheim → label false (docker inspect), watchtower true.
• .25 : 28/28 stateful = false, vérifié par boucle docker inspect (0 exception).
  • 13 projets compose : labels dans les yml + compose up -d (backups .bak-labels sur le NAS, InfluxDB recréé).
  • 8 conteneurs GUI (postgres16, vaultwarden-server-1, qbittorrent, sonarr, radarr, jackett, prowlarr, deluge) : docker update --label-add indisponible sur docker 24.0.2 (DSM) → clonage via API unix socket : stop → rename -old-lbl → create avec Labels au niveau racine du payload (les labels nichés dans Config sont épurés par le daemon Synology) → start. Données intactes (mêmes binds/env), restauration automatique en cas d'échec.
• Incident résolu en cours de route : accès .25 bloqué (clé retirée + compte effi bloqué par Synology) → déblocage par l'utilisateur, nouvel accès via compte Master port 222.

T1.1-c · Watchtower durci (digest-pinné)

• Image : nickfedor/watchtower@sha256:45b54f6dc15227cfb38dbb826f2881aa0f56aaf0c255cdbb38bd80e598bdca9a (1.23.0 ; digest vérifié = :1/:1.23/:latest via API registry — containrrr/watchtower:1 n'existe pas).
• Env sur .24 et .25 : CLEANUP=false, INCLUDE_STOPPED=false, POLL_INTERVAL=3600, LABEL_ENABLE=true, label true.
• .25 était containrrr/watchtower:latest CLEANUP=true (dangereux) → remplacé ; projet compose watchpower (COMPOSE_PROJECT_NAME requis).
• Contrainte fork nickfedor : refuse SCHEDULE + POLL simultanés → POLL 3600 conservé.

T1.1-d · Notifications Watchtower → n8n → Matrix

• Chaîne : watchtower (shoutrrr generic) → n8n .24 workflow w1pfhX0A7KvaDrtk (Webhook → Build log → Matrix → Respond) → Synapse .24:8008, salon ops !mp7MFx9QbrJ0ARtzw…, user ops-bot.
• Preuves : notifs .24 (exec #10, #31, #32) + notif startup réelle du watchtower .25 reçue (« Watchtower 1.23.0 using Docker API v1.43 … Next scheduled run 02:48 »), event_ids vérifiés dans event_json de Synapse.
• Correctif : payload shoutrrr generic = title/message (le workflow lisait event_name/image_name → affichait « undefined »).
• Points techniques notés : n8n v2.42 exige publication du workflow ; URL Matrix en expression full ={{ }} ; txnId = image+timestamp (évite les doublons).

---

3. T1.2 — Inventaire stateful .25

Livrable : INVENTAIRE-STATEFUL.md — pour chaque stateful : image:tag, data paths, taille du -sh mesurée, type DB, mode GUI/compose, dépendances, méthode d'export et destination (G9 / .11 / .25 / supprimé).

Tailles clés : NextCloud 2.3G, valheim 2.8G, openwebui 4.7G, Joplin 706M, Leantime 298M, AFFiNE 94M, postgres16 70M, n8n 75M, gitea 2M, vaultwarden 8.8M, beszel 11M, InfluxDB 188K.

Vigilances relevées : conteneurs GUI sans CLI labels (passage par API), flux .25→.11 (AFFiNE/OpenWebUI → LLM proxy), credentiels DB d'origine conservés à l'import (les seeds G9 sont ignorés sur base initialisée — documenté dans 07-migrate-stateful.sh).

---

4. T1.4 — J5040 (.27) : délestage, migrations, GO formatage

Backups (G2, avant toute migration)

• Valheim : world 53.6M + backups + env + pterodactyl.tar 4.7G → Folzo Save, SHA256 vérifiés.
• Inventaire complet J5040 : 34 conteneurs, 116 images, dumps DB (dify 671M, n8n sqlite, pterodactyl wings 4.7G), volumes nommés (open-webui 3.4G, whisper-cache 2.0G), home 1.8G, cron 6 jobs → 12 Go sur .11:/run/media/folzo/Folzo Save/migration-j5040/ avec SHA256SUMS.txt (sha256sum -c : 23/23 « Réussi » — l'unique « Échec » est l'auto-référence de SHA256SUMS.txt).
• OpenFox : openfox-share.tar.gz 942M + node-bin.tar.gz 52M archivés + SHA256 vérifiés.

Migrations réalisées

Cible	Contenu	Preuve
PC IA .11	Stack IA complète (22 images save/load) : open-webui, searxng, pipelines, qdrant (6 collections), couchdb, mcpo, tts, dify (14 healthy), llm-proxy 3011/3012/3017, ollama 28 modèles, whisper large-v3	Test LLM bout en bout → « MIGRATION-OK » ; endpoints 200
G9 .24	Valheim : monde restauré, 37 chunks sha256 identiques source, conteneur healthy, UDP 2456 joignable	Double-run G4 : source redémarrée healthy
G9 .24	n8n + Obsidian + CouchDB : database.sqlite sha 693ee229 IDENTIQUE source, vault 79M	n8n 5678→200, couchdb 5984→200, obsidian 3100 OK
PC IA .11	OpenFox (66 sessions, thread préservé) : systemd openfox.service, HTTP 200 sur .11:10369, symlink /home/effi→/home/folzo, SELinux chcon -R -t bin_t	Thread de migration repris sur .11 après bascule proxy

T1.4-e · GO utilisateur

Vérification sans .27 (éteint) : OpenFox .11 200, IA .11 200, n8n/couchdb/obsidian/Matrix .24 OK, NAS .25 31/31 Up + labels 28/28 false + watchtower digest healthy. Backup 24 Go SHA256 23/23. GO donné par l'utilisateur — formatage SSD J5040 exécuté par l'utilisateur lui-même (conforme G3).

---

5. Livrables produits

Fichier	Contenu
g9-migration/journal.md	18 entrées 6 colonnes (G8), toutes les actions Phase 1
g9-migration/conteneurs-xpenology.csv	Inventaire 30 conteneurs .25
g9-migration/INVENTAIRE-STATEFUL.md	Inventaire stateful + plan d'export (base Phase 4)
g9-migration/INVENTAIRE-J5040.md	Inventaire J5040 avant formatage
Backups .11:/run/media/folzo/Folzo Save/migration-j5040/	24 Go, SHA256SUMS vérifié
/tmp/nas-yml/ (session)	yml compose .25 modifiés + .orig (répliqués sur le NAS avec .bak-labels)

6. Améliorations post-revue (5 findings, tous résolus)

1. README.md racine : ligne ajoutée pour g9-migration/README.md dans le tableau de lecture.
2. 01-hardening.sh : garde anti-lockout SSH (refuse PasswordAuthentication no si authorized_keys vide).
3. 07-migrate-stateful.sh : multiplexage SSH (ControlMaster/ControlPath/ControlPersist) → 1 seule session par brique au lieu de 4+ ; pré-test command -v rsync sur le NAS.
4. .gitignore : règle no-op !*.env.example supprimée.
5. restic.env.example : suppression du faux backend smb:// ; voies supportées documentées (sftp:, rclone smb:, montage CIFS).

---

7. Restes et points d'attention pour la Phase 2

• T1.3 (thermique Freebox) : non traitée par l'agent (matériel, hors périmètre) — à valider manuellement par l'utilisateur (< 70 °C en charge).
• Cron BomberFox (J5040) : spécifique J5040, à reconfigurer après formatage.
• Proxy inverse openfox.folzocorp.fr : bascule .27→.11 à confirmer définitivement côté utilisateur.
• Clés SSH : la clé .25 utilisée est id_ed25519_openfox11 (nouvelle, ajoutée aux authorized_keys du compte Master) ; les clés de l'ancien bundle .27 sont à reconstituer/archiver.
• Les imports Phase 4 conservent les credentiels DB d'origine du xpenology (documenté).
• Rollback global Phase 1 : rien de destructif sur les sources (.25 lecture seule + labels réversibles via .bak-labels, .27 éteint intact, backups Folzo Save).

8. Dépendances levées pour la suite

Phase 2 (Base G9) peut démarrer : docker est déjà opérationnel sur .24 (T2.3 de fait), durcissement SSH/ufw/fail2ban reste à faire (scripts 01-hardening.sh, 02-disk-luks.sh, 03-docker.sh prêts et conformes à la charte).