g9-migration/g9-migration/journal.md

Journal d'exécution — Migration G9 (G8)

Chaque action est journalisée : date, action, raison, résultat, rollback. Rempli pendant la migration. Ce fichier est la trace de ce qui a réellement été fait.

Date	Phase	Action	Raison	Résultat	Rollback
2026-10-06	—	Kit d'exécution préparé (scripts + configs + compose)	Migration G9 à venir	Prêt à exécuter	—
2026-10-06	—	Conformisation des scripts à la charte G1–G10	Audit des garde-fous (C1–C5)	journal() 6 colonnes (G8) dans les 10 scripts ; renvois garde-fous en en-tête (G1) ; tableau G→script dans README (G2) ; secrets hors git confirmés (G9)	git checkout des fichiers modifiés
2026-10-06	—	Corrections post-revue (6 findings)	Revue de code du kit G9	Binds compose → 0.0.0.0 (accessibles LAN via J5040, ufw restreint) ; retrait mount /etc/timezone (Gitea) ; user DB dédié photoprism ; fstab USB = vrai FSTYPE ; docs credentiels import ; suppression fichiers morts (ufw.rules, smb.conf, RESTIC_APPEND_ONLY)	git checkout des fichiers modifiés
2026-10-09	1 (T1.4-a1)	Backup Valheim J5040 → .11:/run/media/folzo/Folzo Save/migration-j5040/valheim/	G2 : filet avant migration ; serveur arrêté proprement (shutdown backup 20261009-074115)	3 artefacts : valheim-world.tar.gz (53.6 Mo), valheim-backups.tar.gz (53.6 Mo), valheim-steam.tar.gz (2.13 Go) + valheim-env.json (chmod 600) ; sha256 source == destination vérifiés	Suppression du dossier migration-j5040/valheim/ sur Folzo Save (aucune donnée source touchée)
2026-10-09	1 (T1.4-b1)	Valheim UP sur G9 .24 (conteneur direct, sans Pterodactyl)	Ami joueur — priorité ; serveur source J5040 redémarré (double-run G4)	Docker installé sur G9 (T2.3 de fait) ; image valheim-pterodactyl:1 transférée par docker save/load (ghcr denied) ; monde restauré : 37 chunks sha256 identiques source ; conteneur healthy, ports 2456-2458 ouverts, lobby enregistré (ZDOS:84), UDP 2456 joignable depuis J5040	docker compose down + docker rmi sur G9 ; J5040 intact (serveur source redémarré et healthy)
2026-10-09	1 (T1.4-a)	Inventaire J5040 + backup stateful → Folzo Save	G2 : filet complet avant formatage	34 conteneurs + mounts + 116 images inventoriés ; 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, compose+env. 12 Go sur .11:/run/media/folzo/Folzo Save/migration-j5040/ avec SHA256SUMS.txt (sha256sum -c : Réussi). Inventaire → g9-migration/INVENTAIRE-J5040.md	Suppression du dossier migration-j5040/ (données sources J5040 intactes)
2026-10-09	1 (T1.4-b)	Migration stack IA J5040 → PC IA .11	Délester J5040 avant formatage ; IA sur GPU .11	22 images transférées docker save/load ; stack monté dans ~/migration-j5040 (binds :z SELinux) ; endpoints vérifiés : open-webui/searxng/pipelines/qdrant (6 collections)/couchdb/mcpo/tts 200, dify 307 (14 healthy), llm-proxy 3011/3012/3017, ollama 28 modèles, whisper large-v3. Test LLM bout en bout : proxy 3012 → « MIGRATION-OK ». Doublons supprimés (whisper/ocr/stt déjà présents)	docker compose down + docker rmi sur .11 ; J5040 inchangé (source des images)
2026-10-09	1 (T1.1-a)	Inventaire des conteneurs xpenology .25 : 30 conteneurs (sudo docker ps -a DSM), cross-check 12 projects compose /volume1/docker + 7 conteneurs GUI	Base du durcissement watchtower et de l'inventaire stateful	g9-migration/conteneurs-xpenology.csv (nom, image:tag, mode, stateful, label, data_paths) ; 15 yml compose récupérés via ssh cat dans /tmp/nas-yml/ (+ .orig) ; tailles du -sh mesurées par projet	Fichiers locaux, aucune action destructive sur .25
2026-10-09	1 (T1.4-c)	Migration n8n + notes → G9 .24	Continuité des services notes/automatisation	3 images (n8n/obsidian/couchdb) transférées save/load ; données : n8n database.sqlite sha 693ee229 IDENTIQUE source, obsidian-vault 79M, couchdb-data. Compose ~/docker-compose.yml+g9.env (600) : n8n 5678→200, couchdb 5984→200, obsidian 3100→200	docker compose down sur .24 ; J5040 intact, backups Folzo Save intacts
2026-10-09	1 (T1.1-b)	Labels watchtower.enable=false — stack .24 appliqué, .25 BLOQUÉ	Durcissement : exclure les stateful du auto-update	.24 : n8n, couchdb, obsidian, valheim → label false vérifié docker inspect ; watchtower → label true. .25 bloqué : clé id_ed25519_effi_server retirée de ~/.ssh (11:43) + mot de passe refusé (Synology a bloqué le compte effi). 22 conteneurs .25 + 7 GUI = labels non appliqués, yml préparés localement /tmp/nas-yml/ prêts à pousser. Action requise côté utilisateur : débloquer effi (Panneau → Utilisateurs, blocage IP)	Retirer les labels avec docker compose up -d (yml .orig sauvegardés sur .25 en .bak)
2026-10-09	1 (T1.1-c)	Watchtower durci sur .24 : image pinnée par digest + CLEANUP=false + INCLUDE_STOPPED=false	Durcissement S11.4 (pas de :latest, pas de cleanup des états)	Image nickfedor/watchtower@sha256:45b54f6d... (digest épinglé, 1.23.0, fork maintenu — containrrr/watchtower:1 n'existe pas sur Docker Hub, vérifié API). Env vérifiés : CLEANUP=false, INCLUDE_STOPPED=false, POLL=3600, label-scope. Statut running, API Docker v1.52. À répliquer sur .25 (watchtower .25 = :latest CLEANUP=true → yml durci prêt /tmp/nas-yml/watchtower.yaml)	Rester sur containrrr/watchtower:latest avec CLEANUP=true (state actuel .25, non durable)
2026-10-09	1 (T1.1-d)	Notification watchtower → webhook n8n → Matrix — chaîne complète testée sur .24	Exigence ops : tracer chaque MAJ d'image	Watchtower (shoutrrr generic) → webhook n8n POST /webhook/watchtower (workflow w1pfhX0A7KvaDrtk, Webhook→Build log→Matrix→Respond) → Synapse .24:8008 salon ops. Notification réelle de startup watchtower reçue (exec #10) + 2 notifs de test distinctes (exec #31/#32, event_ids $OSVIb…/$XcR0…/$bu5f… vérifiés dans event_json de Synapse). Utilisateurs : ops-bot (token), n8n login owner recréé. Points techniques : n8n v2.42 exige publication (workflow_history+published_version) ; URL Matrix = expression full ={{ }} (URL statique non évaluée en prod) ; txnId = image+timestamp Build log (ids sandbox déterministes → doublons sinon). Notification sur .25 : yml prêt (watchtower .25 durci + URL webhook → n8n .24)	Désactiver WATCHTOWER_NOTIFICATION_URL sur .24 ; supprimer salon/ops-bot via Synapse admin
2026-10-09	1 (T1.1-d)	Ouverture salon Matrix ops sur Synapse .24 + user ops-bot	Forwarding notifications (Synapse absent de .11, déjà déployé sur .24)	Room !mp7MFx9QbrJ0ARtzw… ("ops") créée via createRoom (room_creation: true ajouté à homeserver.yaml via sudo, restart synapse) ; user ops-bot enregistré ; 6 messages de probe redactés	Supprimer room + user via administration Synapse ; retirer room_creation: true
2026-10-10	1 (T1.1-b)	Labels watchtower.enable=false .25 : 28/28 stateful labellés	Accès .25 débloqué (compte Master, port 222, clé id_ed25519_synology + NOPASSWD sudo). Compose (13 projets) : yml avec labels installés (backups .bak-labels) + compose up -d (12/13 OK, postgres16 géré GUI). GUI (8 conteneurs dont postgres16) : docker update --label-add indisponible sur docker 24.0.2 → clonage via API unix socket (rename -old-lbl, create avec labels racine, start ; backup auto si échec).	Vérif docker inspect loop : les 28 stateful = false, watchtower = true. Preuves dans /tmp/clone_labels.py + logs session	Supprimer label : restaurer .bak-labels + compose up -d ; conteneurs clonés = mêmes binds/env (données intactes)
2026-10-10	1 (T1.1-c/.25)	Watchtower durci sur .25 : nickfedor/watchtower@sha256:45b54f6d… + CLEANUP=false + INCLUDE_STOPPED=false + POLL=3600 + label-scope	Réplication du durcissement .24 sur NAS (watchtower .25 était :latest CLEANUP=true). Projet compose watchpower (COMPOSE_PROJECT_NAME requis, up -d OK). Nickfedor refuse SCHEDULE+POLL ensemble → POLL 3600 conservé.	Notification startup réelle reçue dans Matrix : « Watchtower 1.23.0 using Docker API v1.43 … Next scheduled run 02:48 » (event vérifié). Nœud n8n corrigé (payload shoutrrr generic = title/message, pas event_name/image_name)	Restaurer compose.yaml.bak-labels + compose up -d (containrrr/watchtower:latest CLEANUP=true)
2026-10-10	1 (T1.4-e)	GO utilisateur — vérification finale services sans .27, avant formatage	Condition posée : .27 éteint + tout vérifié OK = GO (formatage SSD fait par l'utilisateur).	Vérifiés depuis .11 : OpenFox .11:10369 200 (thread survit à la bascule), dify/open-webui/llm-proxy 3011-3012 .11 200, n8n/couchdb/obsidian/matrix .24 OK (API 200), NAS .25 : 31/31 conteneurs Up, labels stateful 28/28 false (0 exception), watchtower digest healthy (notif Matrix confirmée). Clé SSH .25 recréée sur .11 (id_ed25519_openfox11, authorized_keys Master). Backup Folzo Save 24 Go SHA256 23/23. GO donné, formatage J5040 par l'utilisateur	Rollback : rallumer .27 (données intactes, rien de destructive n'a été fait sur .27)
2026-10-09	1 (T1.2-a)	Inventaire stateful .25 → g9-migration/INVENTAIRE-STATEFUL.md	Préparer l'export/migration des données sans perte	30 conteneurs docker ps -a couverts (cross-check CSV), pour chaque stateful : image:tag, data paths, du -sh mesuré, type DB, mode GUI/compose, dépendances, méthode d'export + destination (G9/.11/.25/supprimé). Tailles : n8n 75M, Joplin 706M, NextCloud 2.3G, valheim 2.8G, openwebui 4.7G, beszel 11M, InfluxDB 188K, gitea 2M, vaultwarden 8.8M, Leantime 298M, AFFiNE 94M, postgres16 70M. Points de vigilance : 7 GUI sans CLI labels, flux .25→.11	Suppression du fichier INVENTAIRE-STATEFUL.md (aucune action sur .25)
2026-10-10	1 (T1.4-f)	OpenFox recopié J5040 (.27) → PC IA .11 : thread + sessions préservés avant formatage	Les sessions OpenFox vivent dans .27:~/.local/share/openfox/sessions.db (66 sessions, 107 Mo) → formatage = perte sans copie.	Bundle openfox-share.tar.gz 942M (projets ~/openfox 1.1G, .config/openfox 486M auth+config, .local/share/openfox 922M sessions, node v24 global) + node-bin.tar.gz 52M vers .11, SHA256 vérifiés « Réussi », archivés sur Folzo Save. Déploiement .11 : extract, symlink /home/effi → /home/folzo, launcher corrigé, SELinux chcon -R -t bin_t, unit systemd openfox.service activé → HTTP 200 sur .11:10369 (LAN), thread OpenFox re-pris sur .11 après bascule proxy. Vérifié sans .27 (éteint) : endpoints .11/.24/.25 tous OK	systemctl disable --now openfox + suppression ~/.config/openfox et ~/.local/share/openfox sur .11 ; .27 non touché (données intactes avant formatage)
2026-10-10 12:52	2	hardening : SSH keys-only activé	Durcissement SSH (G6)	PasswordAuthentication no, PermitRootLogin prohibit-password	Re-activer PasswordAuthentication yes dans sshd_config
2026-10-10 12:52	2	hardening : ufw activé	Firewall LAN-only (G6)	deny incoming, allow outgoing, OpenSSH + services LAN-only 192.168.1.0/24 (TCP 2342 3000 3100 5678 5984 8008 8009 8080 8081 8096 + Valheim 2456-2458 TCP/UDP)	ufw disable
2026-10-10 12:52	2	hardening : unattended-upgrades activé	Mises à jour de sécurité auto (G7)	installé + activé	systemctl disable --now unattended-upgrades
2026-10-10 12:52	2	hardening : fail2ban activé	Anti brute-force SSH (G7)	installé + activé	systemctl disable --now fail2ban
2026-10-10 12:53	2	data : Espace /data créé (Option 0)	Données famille sur mono-disque 990 Pro, LUKS abandonné (protection = ufw LAN + restic chiffré)	/data, /data/famille, /data/docker (owner folzo, 2775)	rmdir /data/famille /data/docker /data
2026-10-10 12:53	2	docker : Docker + compose installés	Runtime conteneurs du G9	folzo dans le groupe docker	apt-get remove docker.io docker-compose-v2
2026-10-10 12:53	2	smb : Samba installé, partage [famille] (invité LAN)	Accès SMB données famille sans maintenance par appareil	partage [famille] → /data/famille, guest ok, force user folzo, ufw SMB LAN-only	systemctl disable --now smbd nmbd ; suppression [famille] ; ufw delete règles SMB
2026-10-10 13:05	2	hardening : correctif drop-in 50-cloud-init.conf	Ubuntu 26 : Include sshd_config.d en tête → 1re occurrence gagne → PasswordAuthentication yes gagnait	sshd -T : passwordauthentication no effectif ; script 01 patché (boucle drop-ins) ; anti-lockout vérifié (session clés OK, auth mot de passe refusée)	Restaurer .bak du drop-in + restart ssh
2026-10-10 13:10	2	smb : netbios activé + smbclient + tests R/W	Ubuntu default disable netbios=Yes bloque la découverte par nom	Partage \\192.168.1.24\famille visible depuis .11 (LAN) ; put/get/rm testés avec diff sha → SMB_RW_OK ; invité (guest ok, force user folzo)	disable netbios = Yes + restart smbd/nmbd
2026-10-10 13:20	2	docs : bascule G9 mono-disque 990 Pro + abandon LUKS (Option 0, validation utilisateur)	2ᵉ disque interne prévu = aucun ; données familiales non critiques ; fuite internet = ufw/edge, pas LUKS	DOSSIER-RECREATION.md v2.3 (R1/R3/3.1/R4/R5/R8/plan 0.4 + changelog) ; DOSSIER-SOFTWARE.md S9/S10/AC5/AC6 + statut révisé 10/10 ; g9-migration/README.md (02-data.sh, note disque) ; 02-disk-luks.sh supprimé → 02-data.sh (non destructif) ; prompt Kanban Phase 2 T2.2 réaligné	git checkout des docs (historique non destructif, aucune donnée touchée)
2026-10-10 16:50	2	beszel : agent v0.21.0 installé (hub .25:8090)	Monitoring G9 (T2.5) — token universel fourni par l'utilisateur, transmis hors journal (G9), fichiers temporaires supprimés	service beszel-agent active, logs : « WebSocket connected host=192.168.1.25:8090 » → G9 visible dans le hub ; script 05 réécrit (get.beszel.dev, version épinglée, token par env)	systemctl disable --now beszel-agent ; install-agent.sh -u
2026-10-10 16:58	2	smb : correctif nmbd (disable netbios = No)	Ubuntu 26 pose disable netbios = yes par défaut → nmbd inactive (découverte par nom impossible)	smbd+nmbd active, testparm OK, partage famille visible, guest map OK ; script 04 patché	disable netbios = yes + restart
2026-10-10 17:30	2	corrections post-revue code (8 findings)	Revue de code du kit (diff Phase 2)	1 watchtower compose aligné déploiement réel (nickfedor digest + POLL 3600 + shoutrrr→n8n, placeholder marqué) ; 2 vaultwarden compose : ADMIN_TOKEN_FILE/TRUSTED_HOSTS, ./data:/data, healthcheck curl /alive ; 3 restic : append-only déplacé après 1er backup avec latest ; 4 07-migrate : stop/start conteneurs source autour du rsync (cohérence bases + manifeste stable, G4 respecté) ; 5 secrets 644 (n8n uid 1000) ; 6 scripts chmod +x ; 7 accès xpenology → Master/clé (07/08/README) ; 8 06b : grep || true + fstab fsck 0 pour ntfs/exfat. Vérif : bash -n 10/10 OK, YAML compose OK	git checkout des fichiers modifiés
2026-10-10 18:40	2	stack .24 : correctifs tests utilisateur (Element, n8n)	Tests Phase 2 : Element tournait en boucle (lisait /app/config.json défaut matrix.org, le mount /config.json n'est pas lu) ; n8n refusait l'accès http par IP (secure cookie)	element recréé avec ./config.json:/app/config.json:ro → homeserver 192.168.1.24:8008 chargé ; n8n : N8N_SECURE_COOKIE=false + N8N_HOST=192.168.1.24 + N8N_PROTOCOL=http ; vérif HTTP 200 sur 8009 et 5678 ; backups .bak.$TS des 2 compose. Obsidian 3100 : « secure connection required » = attendu (web viewer exige HTTPS) → résolu en Phase 4 via Caddy TLS (obsidian.folzocorp.fr), pas de fix Phase 2	restaurer les .bak + compose up -d
2026-10-10 17:55	2	valheim : diagnostic connexion jeu (ufw FORWARD + port de jeu)	Utilisateur : « serveurs indisponibles » en jeu	Cause 1 : ufw FORWARD DROP cassait l'UDP docker (TCP passait via docker-proxy) → règle DOCKER-USER -A -p udp --dport 2456:2458 -j ACCEPT posée (+ RETURN, à persister dans /etc/ufw/before.rules). Cause 2 : le serveur Valheim lie le port de jeu = UDP 2457 (2456 = steam query, non bindé) — tcpdump prouve que les paquets 2457 arrivent bien au conteneur. → En jeu, rejoindre 192.168.1.24:2457. Amis hors LAN : redirection Freebox UDP 2456-2458 → .24 (action utilisateur, G6 ; l'ancienne redirection pointait .27)	iptables -D DOCKER-USER 1
2026-10-10 20:05	2	valheim : restauration du VRAI monde + persistance	Le serveur tournait dans un monde NEUF : le SAVE_LOCATION de l'image (valheim-pterodactyl) pointe /home/steam/.config (couche conteneur, non persistée) → le monde restauré Phase 1 a été perdu à la recréation du conteneur (09/10 20:34). Sauvegarde saine unique = backup .11 Folzo Save (172 chunks, 848 saves, sha 8e68a82f vérifié)	sha vérifié sur .24 ; monde neuf archivé (monde-neuf-20261010-archivage) ; vrai monde extrait dans le bind data/save (33 chunks, _main.848.db2) ; compose: SAVE_LOCATION=/home/container/save (persistant) ; serveur relancé avec -savedir /home/container/save. À faire: l'utilisateur rejoint 192.168.1.24:2457 et valide la base. Note: le job AUTO_BACKUP de l'image regarde l'ancien chemin (backups auto à reconfigurer sur /home/container/save)	restaurer compose .bak + monde neuf depuis l'archivage
2026-10-10 20:15	2	valheim : restauration du monde depuis le SSD J5040 (USB)	La build de l'ami (10/10 matin) était sur .27, postérieure au backup .11 (848). SSD branché USB sur .24, LVM intact (non formaté)	VG USB renommé j5040-vg (nom dupliqué avec le VG système, collision) ; monté RO ; monde trouvé wings/data/aff5199c…/steam/.config/.../worlds_local/LeRepaireDuGrandFrak = _main.897 du 10/10 06:20 ; serveur stoppé, version 848 archivée (monde-848-20261010-archivage), 897 + player.list/prefs/lists déployés dans le bind persistant data/save (chown 1000) ; serveur redémarré, world chargé puis save 898. USB démonté, VG désactivé. À valider en jeu : base de l'ami visible.	mv des dossiers d'archivage (monde-848-20261010-archivage) vers data/save ; redémarrer le serveur
2026-10-10 20:22	2	backup .11 Folzo Save : valheim-world.tar.gz écrasé par la version 897 (10/10 06:20)	Demande utilisateur expresse : la copie de référence doit être la plus récente (build de l'ami)	Nouveau tar 64.6 Mo (worlds_local 897/898 + backups auto + player.list/prefs/lists), sha256 e766ae2c… (ancien 8e68a82f… remplacé dans SHA256SUMS.txt, sha256sum -c OK)	L'archive valheim-backups.tar.gz sur .11 conserve les versions antérieures
2026-10-10 20:30	2	reboot test G9 validé (GO utilisateur)	Valider la persistance post-reboot (durcissement, montages, services)	G9 up en ~75 s ; ufw actif + règle DOCKER-USER valheim persistée (before.rules) ; passwordauthentication no effectif ; smbd/nmbd/fail2ban/unattended/beszel-agent actifs ; 7 conteneurs up (valheim healthy) ; /data/famille présent ; partage famille visible ; endpoints 5678/8008/8009/5984/3100 OK ; monde valheim 897/898 intact	—
2026-10-10 20:32	2	G9 éteint (poweroff) sur demande — déplacement physique sur onduleur	Fin de Phase 2, tâche Kanban déplacée en Done par l'utilisateur	G9 éteint proprement (ping KO après poweroff) ; données saines (valheim 898, world .11 sha e766ae2c). Prochain boots : tout est persistant (validé par reboot test). Prévu : onduleur USB → installer NUT (nut-server) en Phase 3 pour arrêt propre sur batterie	rallumer = action physique utilisateur
2026-10-10 20:12	3	restic : premier backup OK	Backup chiffré du G9 (G2)	snapshot 21de0787 — 4 564 fichiers, 6.956 GiB lus / 4.178 GiB stockés, sources /data /home/folzo /etc ; conteneurs stateful stoppés (valheim, n8n, synapse, couchdb, obsidian) puis relancés	restic forget 21de0787 && restic prune
2026-10-10 20:20	3	transport backup : SMB/CIFS écarté, rclone retenu	mount.cifs (vers 1.0) + restic → chmod … no such file or directory (chmod impossible sur le partage) ; rclone mount FUSE → cache d'écriture qui a perdu des objets du repo ; rclone 1.60 (apt) sans backend smb	Transport final = backend rclone de restic (FTP/SMB), repo rclone:freeboxftp:Freebox/backup/g9 ; 3 repos de test ont été créés puis purgés (4.176 GiB libérés)	retirer -o rclone.args=… --append-only des jobs ; restaurer le mount CIFS depuis /etc/fstab.bak.* + unité rclone-freebox.service
2026-10-10 20:22	3	repo restic initialisé sur la Freebox	Backup chiffré + versionné du G9	Repo Freebox/backup/g9 (Delta, 1.79 To, 1.785 To libres) ; clé de repo générée par openssl dans /etc/restic/repo.key (600, jamais affichée)	rclone purge freeboxftp:Freebox/backup/g9 (DESTRUCTIF, volontaire)
2026-10-10 20:53	3	append-only vérifié	Anti-ransomware (G2)	forget --prune REFUSÉ par rclone serve restic --stdio --append-only (rc=1), snapshots toujours lisibles ; repo de preuve _appendonly-test créé puis purgé	retirer -o rclone.args=… --append-only des jobs
2026-10-10 20:53	3	test de restauration OK	Vérification G2 (restauration testée)	/data/famille/Test/PXL_20261009_130502121.jpg_compressed.JPEG restauré depuis la Freebox, sha256 9352a905d9bb… identique à l'original	restauration dans un dossier temporaire, aucun impact sur les données sources
2026-10-10 20:55	3	jobs + cron installés	Backup automatique quotidien + alerte	/usr/local/bin/restic-{daily,prune,health,notify}.sh (root 755) ; cron root : 03:30 backup, 04:00 prune, 09:15 health (alerte webhook n8n → Matrix)	supprimer les 4 lignes du crontab root + les 4 scripts
2026-10-10 20:31	3	artefact secret supprimé	G9 : les secrets ne doivent pas traîner	dossier racine créé par erreur (heredoc collé) contenant le mot de passe SMB, mode 600 root → supprimé ; le mot de passe n'a jamais été affiché ; cifs.cred / rclone-smb.cred / ftp.conf / repo.key restent en 600 (root)	rien (suppression)
2026-10-10 20:47	3	unité systemd rclone-freebox retirée	Mount CIFS abandonné au profit du backend rclone : plus besoin de montage persistant	service désactivé, unit et /etc/systemd/system/rclone-*.d/override.conf supprimés, daemon-reload ; ligne fstab CIFS ajoutée puis retirée (sauvegardes /etc/fstab.bak.*)	recréer l'unit + l'override
2026-10-10 21:12	3	alerte Matrix en place (directe, sans n8n)	Prévenir l'ops si le backup échoue (C3)	restic-notify.sh poste sur Synapse (http://192.168.1.24:8008, salon ops, token ops-bot récupéré du workflow n8n « Watchtower Notification », écrit dans /etc/restic/matrix.env 600 root, jamais affiché) ; 2 messages de test envoyés et reçus ; fallback webhook n8n conservé	retirer les 3 lignes de /etc/restic/matrix.env + les 3 lignes cron
2026-10-10 21:12	3	accès n8n : à recréer (bloquant pour la voie n8n → Matrix)	L'utilisateur n'a plus accès à n8n	1 workflow présent (« Watchtower Notification »), CLI n8n 2.42.5 sans création d'utilisateur → recréer l'accès par l'UI (propriétaire) puis créer une clé API (Settings → n8n API) ; la voie directe Matrix est opérationnelle en attendant	—
2026-10-10 21:19	3	jobs lancés à la main + logs	Vérifier que le backup et la purge s'exécutent hors kit (C3)	restic-daily.sh rc=0 → snapshot cccdb2c7 (+5.175 MiB stockés, parent 21de0787) ; restic-prune.sh rc=0 ; logs /var/log/restic-{daily,prune,health}.log ; restic check --read-data-subset=1% sans erreur	restic forget cccdb2c7 && restic prune
2026-10-10 21:19	3	rétention appliquée (7/4/12/5)	Rétention et espace (C5)	forget --prune exécuté (append-only refusé → purge appliquée sans append-only, alerte envoyée), 2 snapshots conservés ; repo 4.19 GiB pour 1.785 TiB libres sur le RAID5 de la Delta (1.79 TiB) — marge conforme aux 2 To	rien (rétention non destructrice à ce stade)
2026-10-10 21:20	3	lock stale supprimé + unlock sans append-only	Le lock laissé par une exécution interrompue bloquait le prune (rc=11)	restic unlock (1 lock retiré) ; règle intégrée aux jobs : unlock tourne sans l'option append-only (les locks sont supprimables), ajout en tête de restic-daily.sh et restic-prune.sh	retirer les lignes unlock des jobs
2026-10-10 21:25	3	incident : crontab root effacé par le kit (corrigé)	Le bloc cron du kit pipait crontab -l | grep -vE … dans crontab - ; avec set -e, le grep sans correspondance tuait le sous-shell → stdin vide → crontab vidé	détecté et documenté : le crontab root ne contenait que les 3 lignes restic (aucune ligne utilisateur perdue) ; kit corrigé (grep … || true + écriture dans un fichier + contrôle « 3 lignes attendues » avant installation, refus et crontab intact sinon) ; crontab re-créé puis vérifié après reboot	restaurer le crontab : sudo crontab -l (3 lignes restic)
2026-10-10 21:36	3	reboot G9 validé (persistance post-reboot)	Valider C1 après le changement de transport (plus de montage CIFS)	systemctl reboot (21:36:32), retour SSH en ~75 s ; 06c-postboot-check.sh : 15 contrôles OK / 0 KO (binaires, env 600, clé repo, config rclone, aucun montage CIFS requis, 3 lignes cron, 4 jobs, restic snapshots, check --read-data-subset=1%, health < 26 h, 5 conteneurs stateful relancés)	rien (validation en lecture seule)
2026-10-10 21:40	3	.gitignore élargi (secrets)	Renforcer G9 côté dépôt local	ajout de *.cred, *.key, repo.key, matrix.env (les patterns *.env et le chemin explicite couvraient déjà) ; vérifié : aucun secret dans le repo (recherche du mot de passe SMB et du token Matrix = 0 occurrence), git check-ignore OK, aucun fichier suivi par git de type env/cred/key	retirer les lignes ajoutées
2026-10-10 21:52	3	configs/restic.env.example rechargé sur le transport retenu	Revue T3.1 : l'exemple restait sur le mount CIFS/rclone-FUSE abandonné (C8)	exemple aligné sur RESTIC_REPOSITORY=rclone:freeboxftp:Freebox/backup/g9 + RESTIC_RCLONE_REMOTE/PATH, RCLONE_CONFIG, RESTIC_RCLONE_APPENDONLY=1, SCRATCH_REPO, RESTIC_VERSION/SHA256, G9_JOURNAL, alerte Matrix directe (/etc/restic/matrix.env) + webhook n8n de secours, transports écartés documentés (CIFS/FUSE/SMB/FTPES) ; aucun secret dans le fichier	restaurer l'exemple depuis git (fichier versionné)
2026-10-10 21:55	3	sous-point « thermique Freebox < 70 °C » déchargé de T3.1	Revue T3.1 (C0) : jamais mesuré, et non mesurable par l'agent	décision utilisateur (10/10/2026) : API Freebox OS = appairage requis (mot de passe Freebox OS + code saisi sur l'écran de la Freebox) ; SSH Delta fermé (port 22 refused, testé) → relevé reporté en Phase 1 / T1.3 (COMPTE-RENDU-PHASE-1.md, DOSSIER-RECREATION plan 0.2 : seuil 85 °C) ; à lire dans Freebox OS (app Sapeur) puis journaliser	réintégrer le sous-point dès qu'un relevé est disponible
2026-10-10 21:55	3	énoncé C1 réaligné sur le transport réellement retenu	Revue T3.1 : C1 décrivait un montage CIFS (/mnt/freebox, vers=2.x, x-systemd.automount) exécutée en rclone/FTP	critère réécrit : cible = rclone:freeboxftp:Freebox/backup/g9, aucun montage, snapshots + check --read-data-subset=1% OK, persistance prouvée par reboot réel (15/15) ; abandon CIFS/FUSE tracé (20:20, 20:47)	réécrire l'énoncé si la cible change (Phase 5 : rest: en VM)
2026-10-10 22:05	3	format du journal corrigé (6 colonnes)	Revue T3.1 : la ligne « transport SMB/CIFS écarté » (20:20) n'avait que 5 colonnes (Rollback absent) — violation G8	19 lignes phase 3 toutes en 6 colonnes (vérifié par rendu markdown, 0 ligne non conforme) ; rollback ajouté sur la ligne 20:20 (retirer -o rclone.args=… --append-only / restaurer le mount CIFS depuis /etc/fstab.bak.* + unité) ; rollback isolé en 6ᵉ cellule sur la ligne valheim 20:15 (phase 2)	restaurer les lignes depuis git (journal versionné)
2026-10-10 22:08	3	RCLONE_CONFIG harmonisé sur un seul fichier	Revue T3.1 : docs annonçaient rclone.conf, le live pointait ftp.conf (2 fichiers, 2 remotes séparés)	les 2 remotes réunis dans /root/.config/rclone/rclone.conf ([freeboxftp] FTP + [freebox] SMB secours, 600 root, .bak.1791670085 daté) ; /etc/restic.env → RCLONE_CONFIG=/root/.config/rclone/rclone.conf ; vérifié : FTP liste le repo, SMB lit 4.184 GiB, restic snapshots = 2, kit rejoué rc=0 ; ftp.conf conservé en copie FTP-only (600) ; docs (kit + RESTORE-G9.md) alignés	cp /root/.config/rclone/rclone.conf.bak.1791670085 à l'emplacement + remettre l'ancien RCLONE_CONFIG
2026-10-10 22:09	3	repo de preuve append-only purgé	Artefact du test append-only laissé sur la Freebox (_appendonly-test)	rclone purge freeboxftp:Freebox/backup/_appendonly-test → il ne reste que g9/ sur le partage ; kit rejoué rc=0 (append-only prouvé, restore testée)	re-créé automatiquement par le kit à chaque exécution (puis purgé)
2026-10-10 22:40	3	corrections post-revue code (12 findings)	Revue de code du kit (diff T3.1)	1 jq installé par le kit + garde command -v jq avec repli JSON dans restic-notify.sh ; 2 configs/excludes.txt.example créé et installé par le kit s'il est absent (jamais écrasé) + contrôle dans 06c ; 3 restic-notify.sh || true dans le job prune ; 4 le refus d'append-only au prune est journalisé seulement (plus d'alerte « normale » quotidienne ; vérifié : 0 ligne PURGE dans le log, alerte uniquement si la purge sans append-only échoue) ; 5 03b-secrets.sh : wording 644 aligné sur le code (3 endroits) ; 6 lignes vides intra-tableau supprimées dans journal.md ; 7 branche restic ls | awk morte supprimée (fichier test = find déterministe) ; 8 rclone épinglé v1.75.2 + sha256 349ac8fb…3702 vérifié ; 9 transport/append-only canonique dans RESTORE-G9.md §6 (tableau des transports testés), README/env.example/en-tête du script = pointeurs ; 10 liste stateful dynamique (RESTIC_STATEFUL) dans 06c ; 11 arbre vide Save/migration-j5040/ supprimé + .gitignore dégraissé ; 12 règles ufw sauvegardées avant ufw --force reset (/etc/ufw/{before,user}.rules.bak.<epoch>) + note « liste de ports à aligner sur les compose ». Vérif live : kit rc=0, prune rc=0 (0 alerte), notify rc=0, 06c = 17 OK / 0 KO, excludes intacts (6 lignes)	git checkout des fichiers du kit ; restaurer /etc/ufw/*.rules.bak.<epoch>
2026-10-11 07:32	4	migrate:gitea : backup restic pré-migration	Garde-fou G2 avant import Gitea	snapshot restic Freebox (voir logs /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:35	4	migrate:gitea : backup restic pré-migration	Garde-fou G2 avant import Gitea	snapshot restic Freebox (voir logs /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:36	4	migrate:gitea : backup restic pré-migration	Garde-fou G2 avant import Gitea	snapshot restic Freebox (voir logs /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:36	4	migrate:gitea : import ÉCHEC intégrité (repositories)	Vérification G4	manifeste sha256 source ≠ stage	purger stage/repositories et re-exécuter
2026-10-11 07:37	4	migrate:gitea : backup restic pré-migration	Garde-fou G2 avant import Gitea	snapshot restic Freebox (voir logs /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:38	4	migrate:gitea : backup restic pré-migration	Garde-fou G2 avant import Gitea	snapshot restic Freebox (voir logs /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:39	4	migrate:gitea : backup restic pré-migration	Garde-fou G2 avant import Gitea	snapshot restic Freebox (voir logs /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:40	4	migrate:gitea : Gitea migré + lancé sur le G9	T4.4 (double-run G4, .25 lecture seule)	pg_dump fcab4f2231ee… restauré ; dépôts+LFS+appdata sha256 identiques ; healthz ; .25 intact	docker compose -f /data/docker/gitea/docker-compose.yml down + rm -rf /data/docker/gitea (G9 seul)
2026-10-11 07:50	4	migrate:gitea : validation T4.4 (T4.4)	Critère C-T4.4 (service accessible + données importées)	Gitea G9 : 15 repos (13 importés + g9-migration + obsidian-vault), 4 users (3 importés + g9ops) ; git ls-remote OK sur Folzo/hermes (privé), Folzo/effi, Folzo/jean ; clone + push testés depuis le G9 ; vault Obsidian 80 Mo / 346 fichiers commité et poussé ; healthz 200 ; .25 intact (13 repos / 3 users revérifiés)	docker compose -f /data/docker/gitea/docker-compose.yml down + rm -rf /data/docker/gitea (G9) ; repos g9-migration/obsidian-vault supprimables via API
2026-10-11 07:47	4	migrate:gitea : compte ops g9ops créé	API Gitea bloque les comptes « must_change_password » hérités de la source (master/antoine/folzo) → compte d'automatisation dédié nécessaire	gitea admin user create g9ops --admin --must-change-password=false (mot de passe dans /data/docker/gitea/secrets/g9ops-pass, 644 root, hors git) + token API « ops-phase4 » (read/write user+repository, 600, jamais affiché) ; endpoint 1.27 = POST /api/v1/user/repos	gitea admin user delete -u g9ops ; révocation du token via l'UI
2026-10-11 07:36	4	kit : transport .25 → G9 = tar sur SSH (rsync/scp refusés)	Le sshd de DSM refuse rsync --server (« Permission denied, please try again. ») et scp (subsystem request failed, sftp = internal-sftp)	ssh 'sudo tar cz' + ssh 'sudo cat' fonctionnels ; 07a-migrate-gitea.sh réécrit sur ce transport ; manifestes sha256 avec LC_ALL=C sort (le tri local fr_FR ≠ tri DSM → faux échecs d'intégrité)	restaurer l'ancien transport depuis git (kit versionné)
2026-10-11 07:55	4	migrate:vaultwarden : backup restic pré-migration	Garde-fou G2 avant import Vaultwarden	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:55	4	migrate:vaultwarden : backup restic pré-migration	Garde-fou G2 avant import Vaultwarden	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:56	4	migrate:vaultwarden : backup restic pré-migration	Garde-fou G2 avant import Vaultwarden	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 07:57	4	migrate:vaultwarden : coffre importé + service lancé	T4.1 (double-run G4)	Source stoppée → tar/ssh → source relancée healthy ; 621 fichiers sha256 identiques (source == stage == G9) ; G9 = 953 ciphers / 1 user (identiques à .25, revérifié après coup : .25 healthy 953) ; migrations diesel OK (v.20260902120000) ; alive 200, WebVault 200 ; DOMAIN conservé = pass.folzocorp.fr (clients existants intacts) ; image épinglée 1.37.4 (génération source, image .25 pullée 2026-10-05)	docker compose -f /data/docker/vaultwarden/docker-compose.yml down + rm -rf /data/docker/vaultwarden ; .25 intact
2026-10-11 08:01	4	migrate:vaultwarden : 2FA + ADMIN_TOKEN + emergency access	T4.1 (critères 2FA + emergency access)	2FA TOTP déjà actif côté source et importé avec le coffre : twofactor(atype=0, enabled=1, last_used=59703916) identique sur le G9 → l'appli d'authentification de l'utilisateur continue sans re-scannage ; ADMIN_TOKEN haché argon2id (m=64MiB,t=3,p=4 — preset bitwarden, python3-argon2) : avis « plain text ADMIN_TOKEN » disparu, login admin 200 (dashboard Users/Invitations/Organizations/Emergency accessibles) ; token clair dans /data/docker/vaultwarden/secrets/admin-plain (600 root, à consigner dans le coffre puis supprimer) ; EMERGENCY_ACCESS_ALLOWED=true + INVITATIONS_ALLOWED=true posés	restaurer secrets/admin (token clair) + restart ; retirer les 2 env
2026-10-11 08:13	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 08:16	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 08:21	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 08:28	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 08:35	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 08:40	4	audit .25 : « disparition » de /volume1/docker-REC = VUE de partage DSM, pas une perte	Inventaire d'abord pris sur /volume1/docker-REC (60 entrées), puis 10 entrées une heure plus tard, propriétaire de « . » passé de Master à root, mtime /volume1 = 03:01	docker inspect = vérité terrain : nextcloud_app → /volume2/docker-REC/NextCloud/{data,config} (+ volume nommé /volume1/@docker/volumes/f5f0…/_data), vaultwarden-server-1 → /volume1/docker/vaultwarden, gitea → /volume1/docker/Gitea/data. /volume1/docker-REC est une vue multi-volumes du partage « docker-REC », remontée à 03:01. Aucune donnée perdue : /volume2/docker-REC/NextCloud/data = 1.9 Go / 2608 fichiers ; db.sqlite3 de vaultwarden sha256 2cad5eea42ef4b04… identique entre .25 et le G9	lecture seule, aucune action ; chemins canoniques consignés dans 07c (XP_DATA/XP_CONF = /volume2/…)
2026-10-11 08:42	4	kit : lancer les scripts de migration en folzo, jamais en sudo global	sudo remplace $HOME par /root → « Identity file /root/.ssh/id_ed25519_openfox11 not accessible » puis « Host key verification failed » (root n'a ni clé ni known_hosts) ; 3 runs de 07c échoués en préflight	07c réécrit : appels « G9 » en local (sh -c + sudo local, la machine de pilotage EST le G9), clé en chemin absolu ; import du dump via MARIADB_USER/MARIADB_PASSWORD (env du conteneur MariaDB G9, pas MYSQL_*)	relancer en root avec SSH_KEY= explicite si besoin
2026-10-11 09:03	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 09:10	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 09:18	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 10:10	4	clarification 08:42 : le 07c déposé est la variante SSH, pas « local »	La ligne 08:42 décrit une réécriture « appels G9 en local » jamais commitée ; le 07c-migrate-nextcloud.sh du dépôt passe TOUTES les ops G9 par SSH (folzo@.24, clé sur le pilot) — cohérent avec son en-tête	07c déposé = variante SSH : préflight SSH .25 + .24, import rsync/ssh, restore via MARIADB_USER + secrets/dbpass. La formulation « local » de 08:42 ne décrit PAS le code du dépôt. + garde-fou idempotence backup (07c/07d) + nettoyage dumps (07c) + n8n.env builder (03b) + mount secrets collabora + label watchtower collabora=false	aucune — ligne documentaire
2026-10-11 10:46	4	récupération du thread Phase 4 supprimé (session e67f1166…)	suppression accidentelle de la session 07:20 UTC (cascade events) ; le runner a continué à travailler (journal 09:18→10:13)	thread réinséré : 130 messages / 64 657 événements / 33,85 Mo ; caravage des pages SQLite libérées = 51 420 payloads JSON (34,68 Mo) + 79 830 entrées d'index ; ~35 % du volume, prose en fragments désordonnés, messages utilisateur quasi tous perdus ; intégrité ok avant/après ; rapport complet g9-migration/PHASE4-RECOLLEMENT.md	chirurgical : DELETE FROM events WHERE session_id='e67f1166…'; DELETE FROM sessions WHERE id='e67f1166…' — ou restauration snap2 (voir §4 du rapport)
2026-10-11 11:05	4	corrections post-revue code (5 findings)	Revue de code du diff Phase 4	1 sécurité : collabora ne lisait PAS password_file (non supporté par collabora/code) → console 9980 sans mot de passe ; remplacé par env_file: ./secrets/collabora.env (password=…) généré par 03b (pattern n8n) ; 2 import 07c : DEFINER retirés du dump + import en root (rootpass) + rc contrôlé (l'ancien | tail -5 masquait ERROR 1227) ; 3 07c : SRC_USERS avec || true (préflight tué par grep rc=1) ; 4 07d : progression tar --checkpoint=50000 sur la copie 530 Go ; 5 README : arborescence + ligne phase 4 = 07a–07d (07-migrate-stateful = générique rsync, inopérant sur DSM) ; 6 PHASE4-RECOLLEMENT.md dégraissé (821→75 l., dump §5 hors dépôt). Vérif : bash -n 3/3 OK, YAML compose OK (env_file présent, password_file absent), sed DEFINER testé	git checkout des fichiers modifiés (compose nextcloud, 03b, 07c, 07d, README)
2026-10-11 12:44	4	migrate:nextcloud : backup restic pré-migration	Garde-fou G2 avant import Nextcloud	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 10:45	4	migrate:nextcloud : migration complète (07c)	T4.2 (double-run G4)	export app stoppée (db vivante, mysqldump --single-transaction 31,9 Mo) + tars data (1,9 Go, 2608 fichiers sha256 identiques) + config + custom_apps → app .25 relancée healthy ; import G9 : MariaDB 10.11 (utf8mb4_bin, DEFINER retirés, import root, filecache=2727, users=8), occ status installed/maintenance off, version 35.0.1.1 = image épinglée, occ upgrade « No upgrade required », occ app:list identique à la source (66 apps) ; overrides LAN dans config/g9-double-run.config.php (réversible) ; dumps supprimés sur les 3 machines (hashs mots de passe users)	docker compose -f /data/docker/nextcloud/docker-compose.yml down + rm -rf /data/docker/nextcloud ; .25 intact
2026-10-11 11:02	4	migrate:nextcloud : Collabora — TLS interne désactivé	L'image collabora/code:26.04 sert TLS par défaut : discovery http = 000, https -k = 200 ; env extra_features/EXTRA_FEATURES et O:ssl.enable non appliqués (mesuré : entrypoint = coolwsd --use-env-vars sans script)	fix = command: --o:ssl.enable=false (CMD appendu à l'entrypoint) → logs « SSL is disabled », discovery http 200 ; wopi_url = http://192.168.1.24:9980 (occ, persisté) ; Caddy (T4.6) terminera le TLS	retirer la ligne command: du compose + restart
2026-10-11 13:40	4 (T4.5)	jellyfin : wizard + auth API	Déploiement frais G9 (aucun Jellyfin sur .25 — stack *arr reste sur .25) ; média par RÉFÉRENCE : bind /mnt/usb-media → /media:ro (aucune copie)	wizard 10.9.11 accompli via navigateur (langue → admin « g9ops » → médiathèque « Films3 » → /media/films) ; PIÈGE mesuré : le wizard laisse Users.EnableLocalPassword=0 → AuthenticateByName = « Invalid username or password » ; fix = UPDATE sqlite + restart (hash PBKDF2-SHA512 vérifié == secret) ; en-tête API requis = X-Emby-Authorization combiné (400 « Value cannot be null » sans lui) ; médiathèques vides doublons supprimées → 1 lib « Films3 » = /media/films ; Items?IncludeItemTypes=Movie = 1 (test-reference.mkv, 0 octet, média de test en lecture seule) ; /system/info 200 ; label watchtower=false ; ufw 8096 ALLOW IN 192.168.1.0/24	DELETE /Library/VirtualFolders?name=… + UPDATE Users SET EnableLocalPassword=0 ; compose down (données source : aucune touchée)
2026-10-11 13:55	4 (T4.2)	collabora : healthcheck retiré du compose	Limage collabora/code:26.04.5.1.1 est minimale : ni sh ni curl dans limage → CMD curl = « executable file not found » = unhealthy permanent (mesuré : 3 échecs successifs dans le log de santé)	healthcheck retiré (source de vérité = kit) + recréation du conteneur → healthy ; re-vérifications T4.2 complètes : occ installed/maintenance off 35.0.1.1, users=8, files:scan --all = 1522 fichiers 0 erreur, wopi_url (oc_appconfig richdocuments) = http://192.168.1.24:9980, discovery 200, status.php 200, 67 apps activés ; .25 relancé (nextcloud_app/db/redis + vaultwarden + gitea up)	remettre un healthcheck si une image avec shell est épinglée
2026-10-11 13:50	4	edge : déploiement Caddy (T4.6)	Reverse proxy LAN + HTTPS interne (CA interne) pour vaultwarden/nextcloud/gitea/jellyfin/n8n/matrix	Caddyfile validate OK ; conteneur edge up ; ufw 443/tcp exposé WAN (seul), 80 redirect, 9980 LAN-only ; HTTPS+SNI vérifiés sur les 5 briques	docker compose -f /data/docker/edge/docker-compose.yml down ; ufw delete allow 443 (briques joignables en http direct LAN)
2026-10-11 14:10	4 (T4.6)	edge : Caddy déployé (reverse proxy LAN + HTTPS interne)	Briquage T4.6 : TLS interne pour vaultwarden/nextcloud/gitea/jellyfin/n8n/matrix, sous-domaines déjà configurés côté apps (DOMAIN/ROOT_URL/N8N_HOST) → aucune brique touchée	caddy:2 (digest f2a1290d…) up healthy (healthcheck = caddy validate) ; tls internal = CA interne (LE + DNS challenge = suite S9.1 via AdGuard J5040) ; PIÈGES mesurés : (1) snippet (name) importé → « ambiguous site definition » si utilisé comme adresse ; (2) request_id nest PAS un directive site (validate KO) ; (3) Caddy logue les en-têtes reçus du client, pas ceux envoyés en amont → preuve X-Forwarded prise côté app ; ufw 443/tcp exposé WAN (seul, default deny protège les ports briques) + 80 redirect + 9980 LAN-only ; Nextcloud : merge config = array_replace_recursive (le dépôt dun 2e fichier *.config.php a été avalé par lentrée existante → résolu en écrivant g9-double-run.config.php = source de vérité du kit, monté :ro) → occ : overwritehost=cloud.folzocorp.fr, overwriteprotocol=https, trusted_proxies=[192.168.1.0/24, 172.16.0.0/12] ; preuve côté app : redirect https://cloud.folzocorp.fr/ → Location https://cloud.folzocorp.fr/index.php/login (schéma https + host forwardé rendus par Nextcloud) ; curl -k via edge : pass 200 / git 200 / cloud 200 / media 200 / n8n 200 / matrix 302 / SNI IP 200 ; vaultwarden TRUSTED_HOSTS += 172.16.0.0/12 (aligné)	docker compose -f /data/docker/edge/docker-compose.yml down ; ufw delete allow 443 ; supprimer g9-double-run.config.php (retour double-run http LAN)
2026-10-11 14:20	4 (T4.7)	watchtower : vérification scope stateless + dry-run	S11.4 : MAJ auto uniquement des briques stateless ; leçon incident Nextcloud 06/10 = CLEANUP=false	Conteneur up healthy, image nickfedor/watchtower épinglée par digest sha256:45b54f6d… (fork : containrrr/watchtower:1 n'existe pas) ; env mesuré = POLL=3600, LABEL_ENABLE=true, CLEANUP=false, INCLUDE_STOPPED=false ; labels vérifiés sur les 16 conteneurs .24 : stateful enable=false = nextcloud, collabora, jellyfin, nextcloud_db, nextcloud_redis, vaultwarden, gitea, gitea-db, valheim, n8n, element, synapse, couchdb, obsidian ; enable=true = edge (stateless, T4.6) + watchtower ; dry-run docker run --rm -v /var/run/docker.sock nickfedor/watchtower@sha256:45b54f6d… --label-enable --monitor-only -R → « Only checking containers with label … enable », scanned=2 updated=0 failed=0 = les 14 stateful sont ignorés ; notification : webhook n8n testé en POST depuis le réseau Docker → 200 (le compose affichait un placeholder https://n8n.folzocorp.fr → aligné sur generic+http://n8n:5678, nom de service : l'edge n'écoute que 443) ; nickfedor : SCHEDULE et POLL exclusifs, pas de --once (=-R)	docker compose -f /data/docker/watchtower/docker-compose.yml down ; aucun effet sur les briques (label-driven)
2026-10-11 14:25	4 (clôture)	Phase 4 consolidée + kit poussé sur Gitea	Clôture Phase 4 (critère 5)	PHASE4-RECOLLEMENT.md §0 ajouté : briques déployées + versions épinglées (vaultwarden 1.37.4, nextcloud 35.0.1/mariadb 10.11/redis 7/collabora 26.04.5.1.1, gitea 1.27.3/postgres 16, jellyfin 10.9.11, caddy 2 digest f2a1290d, watchtower digest 45b54f6d), 6 incidents + correctifs mesurés, alignement proxy (trusted_proxies/overwrite/TRUSTED_HOSTS/ufw 443 seul WAN), état .25 (services relancés, dumps supprimés, rien de destructif) ; PhotoPrism T4.3 = reportée (script 07d prêt, copie 530 Go) ; README aligné (07e + compose/edge + jellyfin T4.5) ; push gitea master : HEAD local 366c5ca == gitea/master 366c5ca (API Gitea vérifiée) ; vault Obsidian = repo g9ops/obsidian-vault présent (47 Mo, import T4.4) ; zéro secret dans git : git ls-files (secrets/*.env/token/key/cred) = 0 fichier de secret, git grep des valeurs (token, hash jellyfin, Pw=) = 0, historique -S token = 0 ; durcissement : token retiré de l'URL du remote → ~/.git-credentials 600 + credential.helper store	git push gitea a1864c6:master (fast-forward annulable) ; suppression de ~/.git-credentials
2026-10-11 15:49	4	migrate:photoprism : backup restic pré-migration	Garde-fou G2 avant import PhotoPrism	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 15:56	4	migrate:photoprism : backup restic pré-migration	Garde-fou G2 avant import PhotoPrism	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 16:21	4	migrate:photoprism : backup restic pré-migration	Garde-fou G2 avant import PhotoPrism	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-11 16:10	J5040 (E1)	durcissement J5040 .27 (01-hardening paramétré)	E1 : edge Ubuntu 26.04 neuf, RAM 8 Go test (décision utilisateur)	SSH keys-only + ufw actif (LAN-only 53/3000/8081 + WAN 80/443/51820) + unattended-upgrades + fail2ban ; sudo NOPASSWD folzo ; clés SSH pilot installées ; portable à ajouter via ssh-copy-id	restaurer sshd_config .bak + ufw disable
2026-10-11 16:12	J5040 (E1)	Docker + compose installés sur .27	Runtime edge	docker 29.1.3 + compose 2.40.3, folzo dans groupe docker	apt-get remove docker.io docker-compose-v2
2026-10-11 16:14	07d : copie SANS gzip (photos déjà compressées)	gzip sur CPU NAS = 10-13 Mo/s mesuré → flux brut ~17 Mo/s	tar c	x (sans compression), copie relancée propre (originals purgés, rien de destructif sur .25)	restaurer le script depuis git
2026-10-11 16:20	J5040 (E2)	AdGuard Home déployé sur .27 (migration depuis VM Freebox .1)	E2 : DNS filtré sur l'edge	config VM récupérée en LECTURE SEULE (ssh master@.1, AdGuardHome.yaml 415 l. : 2 filtres 182128+6540 règles, safe_search, services bloqués parents, users bcrypt conservé) ; image épinglée digest aba9e3bf ; UI 8081 LAN, DNS 53 LAN ; systemd-resolved désactivé sur .27 ; tests : doubleclick→0.0.0.0, example.org résolu, UI 302	docker compose down -v ; VM .1 intacte ; resolv.conf .27 restauré
2026-10-11 17:05	J5040 (E3)	Préparation DHCP : baux statiques récupérés (38 appareils, capture Freebox via OCR utilisateur) + /srv/dnsmasq/leases (35 entrées, .1 réservé E4, VM adguard exclue) + 09-j5040-dhcp.sh	E3 : pré-bascule bridge, G6 = baux identiques (mêmes IP)	dnsmasq --test = syntax OK ; scan ARP cross-check (g9 48:ea:62, j5040 60:be:b4, nas 10:e7:c6, backup-218 .26 00:11:32) ; anomalie relevée : VM debian 02:11:32 en conflit sur .24 → à repositionner .23 côté Freebox (utilisateur)	rien (préparation, dnsmasq non démarré)
2026-10-11 17:15	J5040 (E2)	Bascule DNS : Freebox DHCP DNS1 .1 → .27 (GO utilisateur) + bail G9 renouvelé	E2 : AdGuard J5040 remplace la VM Freebox	resolvectl G9 = DNS .27 ; doubleclick→0.0.0.0, example.org résolu ; clients = renouvellement de bail progressif (baux 12 h) ; VM .1 conservée en secours (arrêt = action utilisateur G3 après stabilité) ; .254 freebox intact	remettre DNS1=.1 dans la Freebox (VM intacte, rollback immédiat)
2026-10-11 18:05	J5040 (E4)	Clé API OVH du NAS retrouvée (LE env, longueurs 16/32/32 OK) mais NON SOUSCRITE/EXPIRÉE (test /auth/credential → 404)	E4 : LE DNS-01 nécessite clé valide	secret copié en 600 sur J5040 (compose/edge-j5040/secrets/ovh.env, hors git) ; NAS : renewal LE cassée depuis expiration → nouvelle clé requise (droits API legacy /domain/zone/folzocorp.fr/*, utilisateur)	rien
2026-10-11 18:40	J5040 (E4)	Nouvelle clé API OVH créée+souscrite (droits legacy /domain/zone) ; clé NAS expirée confirmée (90 j)	E4 : LE DNS-01	python-ovh GET /domain/zone/folzocorp.fr/record = 12 records OK ; secrets 600 sur J5040 (ovh.env hors git) ; NAS : mettra la nouvelle clé lors du renouvellement LE	révoquer la clé dans manager OVH
2026-10-11 18:45	J5040 (E4)	Caddy OVH déployé sur .27 : 7/7 certs Let's Encrypt émis (DNS-01) + proxy 6 briques	E4 : TLS auto achève T4.6/S9.1	maxcryger/caddy-ovh digest 502996b5 healthy ; cloud 302/pass 200/git 200/media 302/photos 502 (stack en copie)/n8n 200/matrix 302, issuer = Let's Encrypt ; WAN (forward Freebox→G9) et démontage edge G9 = après bascule bridge E3	docker compose down ; révoquer clé
2026-10-11 18:10	07d : copie parallèle 4 flux (tar par dossier racine)	mono-flux SSH plafonné ~13 Mo/s (lecture HDD NAS, CPU NAS 7% = non saturé)	29 dirs, xargs -P4 ; + chmod u+rwX post-copie ; intégrité/stack/index = 07d SKIP_COPY=1	rien (source .25 lecture seule)
2026-10-11 21:30	4	décision chiffrement restic MAINTENU	Critère 3 : arbitrage chiffrement vs simplicité restore	Décision utilisateur : chiffrement restic conservé, clé de repo locale G9 (/etc/restic/repo.key 600, sauvegardée hors repo git), restore simple via sudo restic sur le G9 ; test restore photo prévu par scripts/10-verify-restore-photo.sh	révoquer/cloner la clé si changement de politique
2026-10-12 13:40	4	migrate:photoprism : backup restic pré-migration	Garde-fou G2 avant import PhotoPrism	snapshot restic Freebox (log /var/log/restic-daily.log)	restic forget && restic prune
2026-10-12 14:06	4	migrate:photoprism : intégration PhotoPrism	copie de 530 Go à vérifier avant indexation	manifeste chemins+tailles identique (433941 fichiers, 567394182751 o) + échantillon sha256 200/200	re-copie ciblée via tar/ssh
2026-10-12 14:11	4	migrate:photoprism : intégration PhotoPrism	copie de 530 Go à vérifier avant indexation	manifeste chemins+tailles identique (433941 fichiers, 567394182751 o) + échantillon sha256 200/200	re-copie ciblée via tar/ssh
2026-10-12 14:17	4	migrate:photoprism : intégration PhotoPrism	copie de 530 Go à vérifier avant indexation	manifeste chemins+tailles identique (433941 fichiers, 567394182751 o) + échantillon sha256 200/200	re-copie ciblée via tar/ssh
2026-10-12 14:18	4	migrate:photoprism : stack PhotoPrism déployée + indexation lancée	T4.3 : stack saine, index progressif (photothèque 530 Go sur le G9)	image épinglée 260919, MariaDB 10.11 (watchtower OFF), secrets via env_file 600, port 2342 LAN ; originals = copie locale	docker compose down + rm -rf /data/docker/photoprism
2026-10-12 15:07	4	test restauration photo depuis restic	Critère 3 : preuve restore du snapshot incluant les photos	snapshot 06a7e3b89ef3e97d5f5c1dc9098496fab8ad79d48f4455eabdde07255143e33b contient 505836 entrées sous /data/docker/photoprism/originals ; restore 1 fichier ; sha256 restauré == source .25 (00cbfed8da81…) ; chiffrement maintenu (clé locale G9)	rm -rf /tmp/restore-photo-test (fait)
2026-10-12 14:17	4.5	registre : 11-registry.sh génère la moitié technique	T-A.1 : inventaire généré (pas de saisie manuelle)	REGISTRE-BRIQUES.md : 21 conteneurs (.24+.27), endpoints Caddy mappés, images/labels lus par docker ps/inspect en lecture seule ; 13 constats réels (4 images :latest non épinglées : n8n, element, synapse, obsidian ; 6 conteneurs non déclarés dans le kit : n8n, element, synapse, couchdb, obsidian, valheim ; 1 conteneur inconnu sweet_feynman .27 sans label Watchtower)	git rm REGISTRE-BRIQUES.md scripts/11-registry.sh scripts/registry_*.py (aucun effet sur les briques)
2026-10-12 14:27	4.5	sondes applicatives : 12-probes.sh installé sur le G9 (cron root)	T-C.1/C.2/C.5 : le trou mesuré est up ≠ utilisable (5 incidents de la semaine avec conteneur up)	install /usr/local/bin/g9-probes.sh + 2 lignes cron (*/15 + digest 08:30) ; passe = 13 OK / 0 KO (nextcloud login + occ status, vaultwarden /alive, gitea /api/v1/version, jellyfin /System/Info/Public, photoprism /, collabora discovery, n8n healthz, synapse versions, element, edge TCP 443, cloud WAN 200, AdGuard UI) ; --selftest → NOTIFY_OK 200 (KO provoqué sans toucher aucune brique) ; g9-verify-alert.py 20 → payloads JSON conformes: 1 / non conformes: 0, VERIFY_OK	sudo bash /usr/local/bin/g9-probes.sh --uninstall (cron retiré, script + état supprimés)
2026-10-12 14:40	4.5	docs identité : REGISTRE-IDENTITES.md (moitié humaine)	T-A.2/A.3/A.4/A.8/A.9/A.11 : « quel compte a servi ? »	table par brique (.24 + .27) : compte, type, 2FA, référence d'entrée coffre, comment réinitialiser, responsable + 4 procédures de récupération (n8n owner, Gitea must_change_password, Jellyfin EnableLocalPassword, Synapse sans admin) + convention coffre infra//famille//enfants/ + hygiène (~/.git-credentials en clair traité en T-A.5) ; 0 secret (références seules)	git rm REGISTRE-IDENTITES.md
2026-10-12 14:45	4.5	docs : RUNBOOKS/ ×7, PARTAGE-SECRET-MAITRE.md, RESTORE-NAS-USB.md	T-C.3 (runbooks = matière première de l'IA, G11) + T-A.9 + T6.5	7 runbooks (nextcloud, matrix, jellyfin, photoprism, vaultwarden, registre, digest) sur les pièges mesurés du journal ; procédure de partage du secret maître (détenteurs à nommer, enveloppe, test annuel — test non réalisé) ; procédure lecture disques DSM hors boîtier (mdadm/LVM, lecture seule, interdits — test non réalisé, critère Phase 6)	git rm -r RUNBOOKS PARTAGE-SECRET-MAITRE.md RESTORE-NAS-USB.md
2026-10-12 14:50	4.5	études : EXPOSITION-INTERNET.md + BRIDGE-WHATSAPP.md	T-D (étude, 0 règle) + T-W (étude, 0 install)	exposition mesurée (ufw status numbered .24/.27, ss -ltnu .27) : constats — 22/tcp et 443/tcp ouverts au WAN sur le G9 sans nécessité, edge G9 en TLS auto-signé, Tailscale actif sur le pilot (voie non documentée), CouchDB 5984 LAN sans auth ; grille par brique + playbook classé 8 rangs + 5 décisions à rendre ; 0 règle posée. Pont WhatsApp : AGPL-3.0, session QR/12 jours, risque de bannissement → numéro familial interdit, 0 installation	git rm EXPOSITION-INTERNET.md BRIDGE-WHATSAPP.md (aucun changement réseau)
2026-10-12 14:55	4.5	08-decommission.sh : texte aligné sur son comportement	T-A.6 : l'en-tête annonçait « ARRÊTE et WIPE » + saisie WIPE XPENOLOGY alors que le corps fait arrêt + consignes GUI/débranchement (wipe optionnel)	en-tête = « aucun wipe exécuté par le kit », prereq = « éteint et débranché, disques intacts, 0 effacement », confirmation = ETEINDRE XPENOLOGY, étape 3 = étiqueter/conserver + pointeur RESTORE-NAS-USB.md, journal rollback = « rebrancher (données intactes) ». Corps du script inchangé (mêmes commandes, même gates)	git checkout scripts/08-decommission.sh
2026-10-12 15:00	4.5	charte G11 + docs DOSSIER-SOFTWARE.md v1.6	G11 (paliers IA) + S8/S9.2/S11/S14 alignés sur les décisions 12/10	README : G11 (L0→L3, portes chiffrées, interdits, traçabilité) + arborescence (11/12/g9-notify/g9-verify-alert/lib-notify) + docs d'identité/observabilité ; S8 = complément (plus « remplace WhatsApp »), S9.2 = pass/prisme/photos alignés, S11 = registre + sondes, S14.7→S14.10 (coffre, identité, suivi, IA)	git checkout DOSSIER-SOFTWARE.md g9-migration/README.md
2026-10-12 15:20	4.5	sondes applicatives installées sur le G9 (g9-probes.sh)	C-AP1, C-AP3, C-AP4 : 13 checks / 0 KO, 15 min, anti-bruit	install -m 0755 root /usr/local/bin/g9-probes.sh + 2 lignes ajoutées à la crontab root (*/15 * * * * sondes, 30 8 * * * digest) ; crontab sauvegardée avant (/root/crontab.backup-20261012-1520) ; état dans /var/lib/g9-probes/. Checks KO provoqués : jellyfin 401 → /System/Info/Public, photoprism 307 → curl -L, gitea 404 → /api/v1/version, edge G9 000 → probe TCP 443 (SNI absent), edge WAN /login 404 → /, adguard /api/stats 401 → /	sudo crontab -r puis sudo crontab /root/crontab.backup-20261012-1520 ; sudo rm -f /usr/local/bin/g9-probes.sh /usr/local/bin/g9-notify.py /usr/local/bin/g9-verify-alert.py ; sudo rm -rf /var/lib/g9-probes
2026-10-12 15:25	4.5	chaîne de notification vérifiée de bout en bout	C-AP2, C-AP3 : payload structuré reçu, auto-vérifié	g9-notify.py et g9-verify-alert.py installés en /usr/local/bin (root 755) ; 2 bugs corrigés : préfixe Bearer manquant et room URL-encodé (!… → %21…) → NOTIFY_OK 200 ; g9-verify-alert.py 20 → payloads JSON conformes: 1, VERIFY_OK. 3e ligne de test auto-supprimée par g9-verify-alert.py (selftest). lib-notify.sh : payload en argument (sudo sans SETENV, sudo -E inutilisable)	sudo rm -f /usr/local/bin/g9-notify.py /usr/local/bin/g9-verify-alert.py (aucun fichier G9 modifié par ailleurs)
2026-10-12 15:30	4.5	dérive registre prouvée de bout en bout	C-ID5 : dérive → rc=1 + payload JSON dans le salon ops	source épinglée jellyfin modifiée 10.9→10.8 → 11-registry.sh --check --alert = DÉRIVE détectée + NOTIFY_OK 200 + rc=1 ; source revertée + doc régénéré + commit → aucune dérive (21 conteneurs, 13 constats) + rc=0. 2 bugs corrigés au passage : set -e + [[ ]] && cmd qui stoppait le script silencieusement, et comparation qui incluait la ligne horodatée (dérive permanente)	sed -i 's/10.8/10.9/' scripts/registry_inputs.py puis git checkout scripts/registry_inputs.py
2026-10-12 15:20	4.5	chaîne de notification installée et vérifiée de bout en bout sur le G9	C-AP2, C-AP3 : payload structuré reçu, auto-vérifié	g9-notify.py + g9-verify-alert.py installés en /usr/local/bin (root 755, sauvegardes dans /root/openfox-backup-20261012/) ; 2 bugs corrigés : préfixe Bearer manquant et room URL-encodée (!… → %21…) → NOTIFY_OK 200 ; g9-verify-alert.py 20 → payloads JSON conformes: 1, VERIFY_OK (les 9 lignes de test des sessions précédentes auto-supprimées) ; lib-notify.sh : payload en argument (sudo sans SETENV → sudo -E inutilisable)	sudo rm -f /usr/local/bin/g9-notify.py /usr/local/bin/g9-verify-alert.py + cp /root/openfox-backup-20261012/* si besoin (aucun fichier G9 modifié par ailleurs)
2026-10-12 15:25	4.5	dérive du registre prouvée de bout en bout + runbook registre.md exécuté	C-ID5, C-AP3 : dérive → rc=1 + payload JSON dans le salon ops ; runbook exécuté sur un KO simulé	source épinglée jellyfin modifiée 10.9→10.8 → 11-registry.sh --check --alert = DÉRIVE détectée + NOTIFY_OK 200 + rc=1 ; runbook suivi : message lu (runbook: RUNBOOKS/registre.md) → --check → lecture du diff → cause identifiée = source du kit, pas le système → action = revert → aucune dérive (21 conteneurs, 13 constats) rc=0. 2 bugs corrigés : set -e + [[ ]] && cmd (script stoppé silencieusement) et comparaison incluant la ligne horodatée (dérive permanente)	sed -i 's/10.8/10.9/' scripts/registry_inputs.py puis git checkout scripts/registry_inputs.py ; rien sur le G9
2026-10-12 15:40	4.5	validation utilisateur tracée pour les actions L3 sur le G9 (G11)	C-G11 : aucune exécution L2/L3 sans validation tracée	GO explicite de l'utilisateur sur le choix « je valide les sondes + digest sur le G9 (trace L3) » → les 2 lignes de crontab root (*/15 sondes, 30 8 digest) et les 3 scripts /usr/local/bin/g9-probes.sh, g9-notify.py, g9-verify-alert.py sont validés. Preuves jointes : 13 sondes OK / 0 KO, NOTIFY_OK 200, dérive → alerte JSON → « aucune dérive ». Aucune autre action L3 sur le G9 : Gitea, Vaultwarden, Nextcloud, Synapse, ufw, Docker non touchés	sudo crontab /root/crontab.backup-20261012-1520 + sudo rm -f /usr/local/bin/{g9-probes.sh,g9-notify.py,g9-verify-alert.py} + sudo rm -rf /var/lib/g9-probes
2026-10-12 17:05	4	test restauration photo depuis restic	Critère 3 : preuve restore du snapshot incluant les photos	snapshot 06a7e3b89ef3e97d5f5c1dc9098496fab8ad79d48f4455eabdde07255143e33b contient 505836 entrées sous /data/docker/photoprism/originals ; restore 1 fichier ; sha256 restauré == source .25 (00cbfed8da81…) ; chiffrement maintenu (clé locale G9)	rm -rf /tmp/restore-photo-test (fait)
2026-10-12 16:10	4.5	3 notifications types reçues dans le salon ops, event_ids relevés	C-MX4 : backup OK, backup KO, sonde KO	restic-notify.sh (prose, canal famille) : BACKUP OK (test lecture seule C-MX4) : snapshot 06a7e3b8 2026-10-12 12:05, 541.4 GiB, 505836 entrees photos, restauration sha256 identique a la source .25 → $U1flqaCJiTEwWSa5H14mMZLoMZ0fekelksXMXC6VEP8 ; BACKUP KO (test provoque, 0 donnee touchee) : verification du canal d alerte C-MX4 - aucun backup reel en echec → $Frb22qftexOLlHl0L8dPAOdKJawZ-DOnLAJ0041zLfg ; sonde applicative KO provoquée (--selftest, payload JSON) → $Hiks3d6fThwsbxOt8wIe38Plu3aLfAtFfCrEwIzOpUU. KO backup réel aussi présent dans l'historique : [G9 backup] BACKUP KO : aucun snapshot depuis 36 h sur le G9 → $GmUPzEtaYuW6h7KBB258oTYzx_WcRDdSOr6hxVfd73Q. Mode --list ajouté à g9-verify-alert.py (lecture seule, GET /messages) pour relever les event_ids	aucune donnée touchée ; sudo rm -f /usr/local/bin/g9-verify-alert.py ; messages conservés dans le salon
2026-10-12 16:20	4.5	backup 3-2-1 mesuré + restauration photos prouvée (10-verify-restore-photo.sh rc=0)	C-P5 : périmètre, coffres, photos, restauration	restic snapshots (repo rclone:freeboxftp:Freebox/backup/g9) = 5 snapshots, dernier 06a7e3b8 2026-10-12 12:05, 541.393 GiB, sources /data /home/folzo /etc. Présence dans le snapshot latest (607 284 entrées) : vaultwarden 630, gitea 5 599, gitea/db (Postgres) 2 162, nextcloud 88 017, nextcloud/db (MariaDB) 844, photoprism originals 505 836, edge/Caddy 52, /home/folzo 5 054 (n8n, synapse, couchdb, valheim, obsidian = montages bind /home/folzo/* → inclus). Médias 15 To + 5,5 To exclus par construction : ils vivent sur le NAS .25, le périmètre du G9 ne contient que 564 Go (/data/docker + /data/famille). Restauration : sha256 restauré identique à la source .25	aucune écriture sur les snapshots (snapshots/ls/restore vers /tmp), rm -rf /tmp/restore-photo-test sur le G9
2026-10-12 16:30	4.5	PHOTOS-DOUBLE-RUN.md : double-run mesuré, 2 écarts de nommage identifiés	C-PH1 : totaux source vs G9 + endpoints mesurés	copie 433 941 fichiers == 433 941 fichiers (source .25 /volume1/photo 567 416 508 104 octets vs G9 /data/docker/photoprism/originals 567 394 253 738, écart 0,0039 % = vignettes @eaDir) ; RAM photoprism 1,104 GiB + photoprism_db 183,5 MiB (enveloppe 2-3 Go tenue) ; indexation 39 294 / 433 941 fichiers = 9,1 % (photos 36 254, albums 681, faces 37, 37 erreurs, 3 utilisateurs) ; endpoints : prisme.folzocorp.fr DNS OK mais 0 route Caddy → 000, photos.folzocorp.fr route J5040 → 192.168.1.24:2342 = PhotoPrism (307) au lieu du NAS, web DSM .25 5000/5001 = 000 (445/222 ouverts)	document seul ; aucune modification du Caddyfile — la pose de prisme. et le repointage de photos. sont des actions L3 (G11/G6) soumises à validation
2026-10-12 16:35	4.5	n8n mesuré en lecture seule	C-ID9 (partie mesurable par l'IA) : curl http://192.168.1.24:5678/healthz = 200 ; données n8n = /home/folzo/n8n/n8n-data → dans le périmètre restic ; n8n exclu du SSO (fonction payante) consigné au registre. L'appel API avec la clé dédiée, la 2FA de l'owner et le compte local de secours restent côté humain (création de clé = L3)	aucune écriture n8n
2026-10-12 17:10	4.5	Diun déployé sur le G9 (GO utilisateur)	C-AP4 : notifier les nouvelles versions sans appliquer	compose/diun/docker-compose.yml + diun.yml (kit) → providers.docker.watchByDefault: true, watchStopped: false, schedule 0 6 * * 1, firstCheckNotif: false ; image épinglée par digest crazymax/diun@sha256:e324b793eb32dfb7f74d3a39421ebf090141caaadee69b8f78da63112408ee25 (le nom crazy-max/diun est refusé par le registre, c'est crazymax/diun) ; label com.centurylinklabs.watchtower.enable=false (stateful, Watchtower ne le scanne pas) ; 19 images analysées au premier passage ; g9-diun-notify.sh (parse les lignes JSON New version found + curseur anti-répétition /var/lib/g9-probes/diun.cursor) installé en /usr/local/bin + cron 20 6 * * * ; --selftest → NOTIFY_OK 200. Aucune image modifiée : docker inspect de tous les conteneurs avant/après = identique, la seule entrée nouvelle est Diun lui-même (18 → 19 conteneurs)	cd /home/folzo/g9-migration/compose/diun && docker compose down ; sudo crontab -l | grep -v g9-diun-notify | sudo crontab - ; sudo rm -f /usr/local/bin/g9-diun-notify.sh ; sudo rm -rf /data/docker/diun
2026-10-12 17:15	4.5	prisme.folzocorp.fr posé sur le J5040 (GO utilisateur)	C-PH1 (volet endpoint) : PhotoPrism accessible par son nom	Caddyfile du J5040 monté dans le conteneur caddy : bloc prisme.folzocorp.fr { import folzocorp; reverse_proxy 192.168.1.24:2342 } ajouté au-dessus de photos. ; sauvegarde Caddyfile.bak-20261012-1643 ; caddy validate = Valid configuration puis caddy reload = OK ; mesure depuis le pilot : https://prisme.folzocorp.fr/ = 200 (certificat Let's Encrypt émis par ACME DNS-01 OVH, curl sans -k). photos. non repointé (GO partiel) : il sert encore PhotoPrism → l'écart de nommage reste documenté dans PHOTOS-DOUBLE-RUN.md	cp /home/folzo/g9-migration/compose/edge-j5040/Caddyfile.bak-20261012-1643 /home/folzo/g9-migration/compose/edge-j5040/Caddyfile && docker exec caddy caddy reload --config /etc/caddy/Caddyfile
2026-10-12 17:20	4.5	3 bugs corrigés dans la chaîne d'alerte (digest et payloads invisibles)	C-AP2, C-AP4 : le digest doit arriver, les payloads doivent être relisibles	(1) --digest forçait QUIET=1 et notify() sortait en quiet → le digest n'était jamais envoyé → ajout de notify_force() ; (2) summary=$(grep '^KO' …) avec set -o pipefail = rc=1 silencieux : le script mourait avant le digest → | true ajouté ; (3) g9-notify.py publiait en type m.text (type hérité) alors que g9-verify-alert.py ne lisait que m.room.message → payloads envoyés (200) et invisibles ; type unifié en m.room.message + listing acceptant les deux. Ajout g9-verify-alert.py --list N (event_ids). Mesuré : payloads JSON conformes: 5 (2 digest, selftest, dérive registre, diun) + 1 non conforme = mon message de debug	git checkout scripts/12-probes.sh scripts/g9-notify.py scripts/g9-verify-alert.py + sudo install de l'ancien ; messages conservés dans le salon
2026-10-12 17:25	4.5	compose du kit versionnés : les briques déclarées hors git sont rentrées dans le dépôt	C-ID1 (fiabilité du registre), C-ID5 : la colonne « kit » était fausse (9 conteneurs marqués hors kit)	import dans g9-migration/compose/ des définitions réelles qui vivaient hors kit : matrix/ (/home/folzo/matrix), g9-queue/ (/home/folzo/docker-compose.yml : n8n, watchtower, couchdb, obsidian), valheim/, diun/, + edge-j5040/Caddyfile ; 0 secret importé (les secrets/ du G9 sont en 700 root, les compose ne contiennent que des ${VAR} et des chemins secrets_file) ; les fichiers du kit déjà versionnés ne sont pas écrasés (la copie live n'écrase pas le kit : la dérive doit rester visible). Constats automatiques 14 → 7 ; restent 7 vrais constats : 4 images :latest non épinglées (n8n, element, synapse, obsidian), g9/valheim dont le projet compose s'appelle compose, j5040/sweet_feynman sans projet compose et sans label watchtower	git rm -r g9-migration/compose/{matrix,g9-queue,valheim,diun} (aucun conteneur touché)
2026-10-12 17:35	4.5	bug fausse dérive permanente corrigé dans 11-registry.sh --check	C-ID5 (fiabilité) : --check répondait DÉRIVE alors que rien n'avait bougé	la ligne <!-- GÉNÉRÉ … ts=… --> est à la ligne 9 (elle suit le bloc de citations d'en-tête), et la comparaison retirait les lignes 1 à 4 → l'horodatage restait dans le corps comparé = dérive à chaque passage. Retrait par motif grep -v '^<!-- GÉNÉRÉ PAR' (plus dépendant de la position). Dérive re-prouvée avec la comparaison corrigée : compose/jellyfin/docker-compose.yml 10.9→10.8 → DÉRIVE détectée (8 constats) + NOTIFY_OK 200 + rc=1 ; revert → aucune dérive (22 conteneurs, 7 constats) + rc=0	git checkout g9-migration/scripts/11-registry.sh (compose reverti par sed, aucun conteneur touché)
2026-10-12 17:55	4.5	grille d'exposition validée avec l'utilisateur, mesurée en entier	C-EX1 : ufw status numbered complet (.24 = 25 règles, .27 = 12 règles)	0 règle posée (G6 respecté). Mesures nouvelles : OpenSSH ALLOW IN Anywhere est présent sur .24 ET .27 (règle [1] sur les deux) ; 443/tcp Anywhere sur le G9 est la règle [22] « seul port exposé WAN » de l'edge T4.6, et il n'existe aucune règle LAN pour 443 sur le G9 → supprimer cette règle couperait aussi git./cloud./media. depuis la maison ; tailscaled = inactive sur le G9, actif seulement sur le pilot ; le pilot et le G9 sont derrière le même NAT (IP publique unique 82.65.198.114) → ce qui est joignable dépend des redirects Freebox, pas de ufw seul ; CouchDB 5984 est déjà LAN-only (ufw règle 6), le reste du risque = absence d'auth sur le LAN. 5 décisions rendues + qui pose le geste (1, 2, 3, 5 = toi ; 4 = moi sur GO)	document seul ; git checkout EXPOSITION-INTERNET.md ; aucune commande ufw exécutée
2026-10-12 18:10	4.5	durcissement pare-feu exécuté sur GO explicite (SSH + 443 LAN-only, Tailscale coupé)	C-EX1 : les 5 décisions sont rendues et les 3 gestes réseau posés par l'utilisateur, exécutés par moi avec scripts/14-firewall-lan-only.sh	.24 : [1] 443/tcp ALLOW IN 192.168.1.0/24 + [2] 22/tcp ALLOW IN 192.168.1.0/24 insérés avant les suppressions, puis suppression de [1] OpenSSH Anywhere, [24] OpenSSH (v6), [22] 443 Anywhere, [25] 443 (v6) → plus aucune règle Anywhere sur le G9 (25 → 23 règles). .27 : [1] 22/tcp from 192.168.1.0/24 puis suppression [1] OpenSSH Anywhere + [10] OpenSSH (v6) ; règles WAN de l'edge conservées (80, 443, 51820 v4+v6). Pilot : systemctl disable --now tailscaled (il n'était actif que sur le pilot ; G9 = inactive). Vérifié après : ssh .24 OK, ssh .27 OK, git ls-remote gitea OK, https://git.folzocorp.fr/api/v1/version (LAN) 200, https://cloud.folzocorp.fr/ (WAN) 200, https://prisme.folzocorp.fr/ 200. Snapshots ufw status numbered conservés avant (25 règles .24 / 17 lignes .27)	rollback : sudo ufw insert 1 allow proto tcp from any to any port 22 et … port 443 sur .24 (+ v6), idem 22 sur .27 ; sudo systemctl enable --now tailscaled ; snapshots dans /tmp/ufw-24-before.txt et /tmp/ufw-27-before.txt sur le pilot
2026-10-12 18:20	4.5	faux positif corrigé : CouchDB n'est PAS sans auth	C-EX1 (exactitude des constats), C-AP1 (fiabilité des sondeurs)	la sonde lisait GET :5984/ = 200 → lu « sans auth ». Mesure directe : GET /_all_databases = 401 et GET /_active_tasks = 401 ; compose/g9-queue/docker-compose.yml déclare bien COUCHDB_USER + COUCHDB_PASSWORD=${COUCHDB_PASSWORD}. / est public par conception dans CouchDB. Décision : ne pas recréer le conteneur pour publier 127.0.0.1:5984 — gain quasi nul (ufw LAN-only + auth déjà en place) et casse probable de la sync Obsidian si le client pointe sur http://192.168.1.24:5984. Échange mauvais → statu quo, consigné	aucun (aucun conteneur recréé, aucun fichier modifié sur le G9)
2026-10-12 18:40	4.5	balayage d'identités en lecture seule (15-identity-sweep.sh, 16-identity-sweep-sqlite.sh) → §7 du registre	C-ID2 (preuve de la moitié B), C-ID4/7/9, C-MX1/3 : l'existant est mesuré, plus supposé	Gitea : 4 comptes (Master, Folzo, Antoine, g9ops), IsAdmin=2, 2FA = false sur les 4 → gitea admin user list (CLI local, rc=0). Nextcloud : 8 comptes, groupes admin={Effi, Master} et Famille Folzo={Audrey, Folzo, carla, ewan, lola, noah}, providers 2FA installés (twofactor_totp, backupcodes, nextcloud_notification). Synapse : 2 comptes (@ops, @ops-bot), admin = 0, locked 0, deactivated 0, 14 devices → aucun admin : C-MX1 et C-MX3 bloqués à la racine, aucune porte de sortie. n8n : 1 compte effi@openfox.local (disabled=0) + basic auth déclarée. PhotoPrism : 3 comptes. Vaultwarden : ADMIN_TOKEN_FILE (jeton en fichier, pas en env en clair). CouchDB : 401 sans identifiants → auth active	0 écriture : commandes admin user list, occ user:list/group:list/twofactorprovider:states, sqlite en mode=ro, mariadb -N -e select. Aucun compte créé, aucun privilège changé
2026-10-12 18:45	4.5	trou Synapse sans admin : porte de sortie outillée, non exécutée	C-MX1, C-MX3, C-ID4 : la brique n'a pas de compte admin → ni création de comptes famille, ni réinitialisation possible	scripts/17-synapse-admin.sh : inscription signée via registration_shared_secret + POST /_synapse/admin/v1/register (secret lu à l'exécution dans le conteneur, jamais affiché ni recopié, mot de passe saisi masqué, longueur ≥ 12, confirmation CREER pour un admin). Vérifié jusqu'à la dernière étape sans rien créer : GET /_synapse/admin/v1/register → nonce reçu, registration_shared_secret présent dans homeserver.yaml (FOUND). Procédure consignée dans RUNBOOKS/matrix.md + §7.1 du registre. Exécution = toi (création de compte = interdit permanent G11)	docker exec synapse python3 -c "… update users set admin=0 where name='<compte>'" (désactivation propre, jamais de purge)
2026-10-12 18:30	4.5	dumps logiques cohérents des 3 bases (18-db-dumps.sh, GO utilisateur)	C-P5 : corriger le trou mesuré « copie chaude = complète en octets, pas garantie rejouable »	pg_dump Gitea (auth socket trust mesurée dans pg_hba.conf → aucun mot de passe sur une ligne de commande) = 80 543 o gz, 116 CREATE TABLE ; mysqldump --single-transaction --routines Nextcloud = 5,9 Mo gz, 317 objets, se termine par -- Dump completed ; idem PhotoPrism = 89,6 Mo gz, 39 objets, -- Dump completed. Aucune brique stoppée (--single-transaction = instantané InnoDB cohérent). Dumps écrits sous /data/docker/<brique>/dumps/ → déjà dans le périmètre restic (visibles au prochain backup de 03:30). Rejouabilité prouvée pour Gitea : base de test gtest_restore créée, dump chargé, 116 tables restaurées (== 116 du dump), base supprimée (pg_database = gitea_db/postgres/template0/template1, vérifié)	dumps : rm -f /data/docker/{gitea,nextcloud,photoprism}/dumps/*-20261012-1825Z.sql.gz. Test MariaDB complet non fait : le dump Nextcloud contient USE \nextcloud`` → le charger tel quel écraserait la production ; il faut un serveur jeton (GO séparé)
2026-10-12 18:35	4.5	hub de monitoring posé hors du G9 (J5040)	C-AP5 : le trou mesuré était « les sondes tournent depuis le G9 → elles meurent avec lui » ; l'ancien plan (05-beszel.sh) mettait le hub sur .25, la machine à mourir en Phase 6	compose/beszel-hub/docker-compose.yml (kit) → henrygd/beszel@sha256:6b39a8b64f9b15d00a25e7683e31a93c46161182a54f62713525107064e10599 (épinglé digest, label watchtower=false, base dans /home/folzo/beszel-hub/data) ; docker compose up -d ; règle ufw LAN-only ajoutée : sudo ufw insert 1 allow proto tcp from 192.168.1.0/24 to any port 8090 comment "beszel hub LAN-only" → jamais joignable depuis le WAN ; mesure : http://192.168.1.27:8090/ = 200 ; superuser créé par CLI (/beszel superuser create, mot de passe généré sur la machine, écrit en 600 dans /home/folzo/beszel-admin.cred, jamais affiché, jamais commité). Reste : les agents (.24/.27) + le token universel, qui se crée dans l'UI (/settings/tokens) — la voie API PocketBase n'est pas trouvée (/api/collections/_superusers/auth-with-password = 404, …/authenticators/superusers/email = « resource not found », /api/collections/_superusers/records = 403 → API bien présente, chemin d'auth non identifié)	cd /home/folzo/g9-migration/compose/beszel-hub && docker compose down ; sudo ufw delete <n° 8090> ; rm -f /home/folzo/beszel-admin.cred ; rm -rf /home/folzo/beszel-hub
2026-10-12 19:00	4.5	compte admin Synapse créé et réparé (26-synapse-admin-repair.sh, GO utilisateur)	C-MX1/C-MX3/C-ID4 : la brique n'avait aucun admin (admin = 0 sur @ops et @ops-bot) → ni création de comptes famille, ni réinitialisation possible	POST /_matrix/client/v3/register (m.login.dummy) → compte créé mais Synapse ignore le localpart (mxid aléatoire) et le bug d'arguments de 21-… l'a laissé password_hash = NULL → admin=1 inutilisable (login « Invalid username or password », et /_synapse/admin/v1/register signé = HMAC incorrect, secret jamais recopié ni affiché). Réparation mesurée : bcrypt 5.0.0 est dans l'image synapse → hash bcrypt 12 du mot de passe du credential écrit en base (mot de passe jamais en argv : stdin + curl -K fichier 600 + tmpdir 700) → docker restart (Synapse ne vide pas ses caches sqlite sur écriture directe) → login OK → PUT /_synapse/admin/v2/users/@folzo:192.168.1.24 {password, admin:true} (l'API v2 crée par PUT, POST = Unrecognized request) → compte temporaire admin=0, deactivated=1, password_hash=NULL. Preuves : --verify folzo = login OK ; --admin-check folzo = API admin OK (3 utilisateurs, 1 admin) ; lecture seule finale : 4 comptes, 1 admin actif, 1 désactivé. 27-synapse-family-users.sh ajouté (--dry mesuré = 6 PUT planifiés, --revoke = désactivation)	snapshot sqlite avant toute écriture : /data/homeserver.db.bak-20261012-1900 (rollback = arrêter synapse, restaurer le fichier, redémarrer) ; compte aléatoire conservé désactivé (0 purge) ; rm -f /tmp/2[567]-*.sh sur le G9
2026-10-12 19:20	4.5	6 critères retoqués par le vérificateur corrigés dans les docs	C-ID2, C-ID8, C-MX5, C-PH2, C-WA1 (+ péages périmés)	C-ID2 : ligne PhotoPrism ajoutée en §2 (16ᵉ ligne .24) avec les 3 comptes mesurés (photoprism.auth_users : admin, visitor, 1 sans nom) + CLI réelle (photoprism users ls|show|mod|add|rm, auth reset --yes) ; §7 « à nommer » supprimé ; ligne Synapse réécrite (3 comptes, @folzo admin, PUT et pas POST) ; convention infra/<brique>/break-glass ajoutée en §1 ; C-ID8 : §2.1 placement des 3 exemplaires (sur place / hors site / hors ligne, aucun 4ᵉ), §2.2 4 garde-fous (2 personnes max, personne de confiance = lecture seule, 1 code de déverrouillage par personne, jamais par mail/cloud), §4 test annuel = 6 points tabulés ; C-MX5 : 0 occurrence de « remplace WhatsApp » (S3.1 #8, S13.3 C.1, GUIDE-MATRIX.md §4 corrigés) + décision + 4 interdictions écrites en S8.2 (mot « interdiction » présent) + numérotation corrigée (S14.5 = grille Matrix/WhatsApp) ; C-PH2 : PHOTOS-DOUBLE-RUN.md §6 grille des 10 requêtes (protocole + colonnes à remplir + classement) et §7 procédure d'auto-upload (10 pas, anti-effacement, EXIF, seuil de réussite 7 jours, format de journal, rollback) ; C-WA1 : §6 = 17 questions de Go/No-Go avec preuve exigée par ligne + risque de bannissement détaillé (2 voies : signalements des correspondants + détection automatisée, aucun seuil public, échelle ban temporaire → permanent → suppression du compte, probabilité non chiffrable) ; péages périmés corrigés : §4 de PHOTOS-DOUBLE-RUN.md (prisme. = 200 avec la route du 17:15), BACKUP-PERIMETRE.md §6 (dumps faits et mesurés + rejouabilité Gitea, plus « à faire »), EXPOSITION-INTERNET.md §7 = choix de machine J5040 pour l'IdP (5 points + déclencheur + rollback)	git checkout des 7 fichiers (aucun effet sur les briques)
2026-10-12 19:25	4.5	salon famille Matrix créé (28-synapse-create-room.sh, GO utilisateur)	C-MX2 : le vérificateur mesure 1 seul salon (!mp7MFx9Q… = ops) — le salon famille annoncé n'existait pas	POST /_matrix/client/v3/createRoom (token admin @folzo) → !9hTrGcLp3bZzw_cXtJEYs7eRfWcr4yUTZe6RTFEr27M, nom Famille, alias #famille:192.168.1.24, preset: private_chat, visibility: private, invites @ops + @ops-bot. Voie admin v1 mesurée morte : POST /_synapse/admin/v1/create_room = 404 M_UNRECOGNIZED sur cette version (Matrix v1.12). Preuves : --list = 2 salons en base (!mp7MFx9Q… créateur @ops-bot, !9hTrGcLp… créateur @folzo), résolution d'alias #famille → !9hTrGcLp…, 0 compte créé, 0 message envoyé. --dry et --purge (rollback) outillés. Constat consigné : joined_members = 1 → les invites sont en attente, les adultes rejoindront depuis Element	CONFIRM=PURGER bash scripts/28-synapse-create-room.sh --purge "!9hTrGcLp3bZzw_cXtJEYs7eRfWcr4yUTZe6RTFEr27M" (DELETE /_synapse/admin/v1/rooms/<id>) ; rm -f /tmp/28-*.sh sur le G9
2026-10-12 19:40	4.5	2 critères retoqués par la vérification indépendante corrigés	C-ID7, C-MX5	C-ID7 : REGISTRE-IDENTITES.md §4.5 = journal de bascule Gitea en 4 colonnes (compte / rôle avant mesuré / rôle après + 2FA / commande + rollback) pour Master, Folzo, Antoine, g9ops, avec le constat mesuré que le CLI Gitea de cette version ne peut pas changer un rôle (gitea admin user = create, list, change-password, delete, generate-access-token, must-change-password) → rôle via UI ou SQL, token à scopes write:repository, ancien token révoqué, preuve de fin (IsAdmin = 1 humain, 2FA = true, g9ops = 0, git ls-remote sans ~/.git-credentials) ; §4 item 4 (Synapse) réécrit sur la voie mesurée (HMAC KO, bcrypt + restart + PUT v2) ; C-MX5 : DOSSIER-SOFTWARE.md ligne 192 (§3.3) « Remplace WhatsApp » → « complément de WhatsApp, pas un remplacement » ; l'auto-contrôle de l'interdiction 1 est réécrit pour ne plus contenir la formule et donne la commande de contrôle (grep -in "rempla.*whatsapp")	git checkout DOSSIER-SOFTWARE.md g9-migration/REGISTRE-IDENTITES.md (aucun effet sur les briques)
2026-10-12 19:50	4.5	auto-contrôle de l'interdiction 1 rendu autosuffisant (revue de code, finding #3)	C-MX5 : le contrôle grep -in "rempla.*whatsapp" échouait sur ses propres lignes légitimes (la définition de l'interdiction et l'énoncé du contrôle), donc le contrôle était faux	S8.2 : le contrôle devient une commande à sortie vide : grep -in "remplace whatsapp" … | grep -vi "pas|complément|interdiction|ne présente" = 0 ligne mesurée (les mentions légitimes sont toutes en négation : S3.1 #8, S3.3, S8, S8.2, S13.3 C.1, S14.5, changelog, journal historique)	git checkout DOSSIER-SOFTWARE.md
2026-10-13 19:30	E3	bascule DHCP faite (GO utilisateur)	Freebox Delta reset usine (bridge complet impossible : J5040 mono-NIC) + DHCP Delta coupé + dnsmasq .27 actif	DHCP servi par .27 (baux 37 appareils = mêmes IP, G9→.24, PING/SSH OK, 18 conteneurs healthy) ; cause racine DHCP muet = ufw .27 bloquait UDP 67/68 (règle ajoutée) ; DNS1=.27 (AdGuard) conservé	couper dnsmasq + rallumer DHCP Delta (baux Delta recréés d usine, à reprendre depuis /srv/dnsmasq/leases)
2026-10-13 19:35	E4	bascule WAN faite (GO utilisateur)	Redirections Delta TCP 80/443 + UDP 51820 → .27	WAN via IP publique 82.65.198.114 : photos 307 / cloud 302 / pass 200, cert LE valide (YE1, CN=photos.folzocorp.fr) ; edge G9 démonté (compose down + ufw 443 retiré) ; zone OVH A* = IP ok ; ménage : redirections d usine obsolètes Delta à purger (utilisateur)	supprimer redirections + remonter edge G9 (compose up -d)
2026-10-13 19:40	E2	VM AdGuard .1	reset usine Delta a isolé la VM (bridge VM derrière Delta, injoignable)	VM éteinte puis rallumée par utilisateur ; coupe AdGuardHome = via UI Delta (action utilisateur) ; DNS LAN = .27 (aucun impact)	redéploiement VM + AdGuardHome start
2026-10-13 19:42	E3	switch 10G SKS7300	port SFP+ Delta éteint par reset usine → G9 isolé (IPv6 link-local seul) ; câble remplacé par RJ45 Delta↔switch (1G)	G9 visible ; SSH switch (admin, telnet) dispo pour remettre les VLANs 10G (untagged trunk uplink) à faire	re-câbler SFP+ + réactiver port fibre Delta