bolbol/nas-runbooks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

fix(v2): section 1 corrigee - reduire hermes-hub au lieu de le supprimer (dsh-hub/files-hub en dependent), ingress Cloudflare non pertinent

Browse Source
This commit is contained in:
hermes-nyora
2026-08-26 19:43:24 +01:00
parent d6d5f67e23
commit 8b8cc3063f
1 changed files with 20 additions and 36 deletions
Download Patch File Download Diff File Expand all files Collapse all files
common/brief-gemini-dsh-autonomie-hub-decommission-20260826.md
+20 -36
View File
@@ -1,31 +1,34 @@
# Brief — Décommissionnement hub.yesminedor.tn, historique + mémoire DSH, autonomie accrue # Brief — Réduction de hub.yesminedor.tn, historique + mémoire DSH, autonomie accrue
**Date** : 26 août 2026 **Date** : 26 août 2026 (v2 — corrige la v1 après lecture directe du code hermes-hub et vérification DNS Cloudflare)
**Auteur** : Claude (cerveau stratégique) **Auteur** : Claude (cerveau stratégique)
**Exécutant** : Gemini AntiGravity **Exécutant** : Gemini AntiGravity
**Remplace** : `brief-gemini-dsh-memoire-contexthub-20260826.md` (caduc — ne pas exécuter, scope entièrement revu ci-dessous) **Remplace** : brief-gemini-dsh-memoire-contexthub-20260826.md (caduc) et la section 1 + section 7 de la v1 de ce fichier (hypothese de decommissionnement total invalidee, voir ci-dessous)
**Architecture cible validée par Nabil** : **Architecture cible validée par Nabil** :
- `Hermes (tt/nyora/perso/nabil) <--> Telegram` — seul canal d'accès conservé pour les 4 Hermes - Hermes (tt/nyora/perso/nabil) <--> Telegram — seul canal d'accès conservé pour les 4 Hermes
- `https://dsh-hub.yesminedor.tn/ <--> DSH <--> https://files-hub.yesminedor.tn/files/` — DSH reste l'outil de dépannage rapide, avec plus d'autonomie - https://dsh-hub.yesminedor.tn/ <--> DSH <--> https://files-hub.yesminedor.tn/files/ — DSH reste l'outil de dépannage rapide, avec plus d'autonomie
- `https://hub.yesminedor.tn/` (Workspace Switcher Multi-Univers) et tout ce qui lui est propre : à désinstaller - https://hub.yesminedor.tn/ (Workspace Switcher Multi-Univers) : l'UI switcher et la persistance chat des 4 Hermes disparaissent, mais le processus qui les sert doit être conservé et réduit, pas supprimé — voir section 1.
--- ---
## 1. Désinstaller hub.yesminedor.tn ## 1. Réduire hub.yesminedor.tn à son strict rôle d'origine Cloudflare — pas une désinstallation totale
**Topologie vérifiée en direct (26/08, `docker ps -a` + inspection nginx sur le VPS)** — à connaître avant de couper quoi que ce soit : **Topologie réelle, vérifiée le 26/08 (lecture directe de hermes-hub/app/main.py + interrogation de l'API Cloudflare)** — corrige une hypothèse fausse de la v1 de ce brief :
- Le container `hermes-hub` (image `hermes-hub-hermes-hub`, port `127.0.0.1:8088->8080`, réseaux `dsh_vps_net`+`mcp-vps`) est la seule chose à retirer pour ce point. Il embarque sa propre DB de conversations (`chat_service.py`/`db.py`) et un routeur `/api/chat/{universe}/...` — tout ça part avec lui. - Les 6 hostnames (hub, tt-hub, nyora-hub, perso-hub, nabil-hub, dsh-hub, files-hub .yesminedor.tn) pointent tous en CNAME vers le même tunnel Cloudflare (700c0fe6-2b2c-4e1a-abfa-3f94f2f7c909.cfargotunnel.com) — vérifié via l'API Cloudflare avec le token disponible dans /mnt/docker/.claude/API_KEY.env (CLOUDFLARE_API_TOKEN, scopé zone, sans accès compte). Une seule origine locale existe pour tout ce zonage : hermes-hub (port 127.0.0.1:8088), qui fait lui-même le dispatch par en-tête Host en interne (fonction get_subdomain_target, app/main.py), y compris pour dsh-hub.yesminedor.tn et files-hub.yesminedor.tn.
- `dsh-hub.yesminedor.tn` et `files-hub.yesminedor.tn` sont servis par un container **totalement séparé** : `dsh-vps-proxy` (nginx, réseau `dsh_vps_net`), qui proxy respectivement le port 8900 vers `dsh-vps:3080` et le port 8901 vers `dsh-filebrowser:8080`. Aucune dépendance croisée avec `hermes-hub` — confirmé par lecture directe de sa conf nginx. **Rien à toucher ici.** - **dsh-vps-proxy (nginx, ports 8900/8901) existe et fonctionne, mais n'est pas dans le chemin public réel.** La v1 de ce brief affirmait le contraire — c'était faux, corrigé après lecture du code.
- `hermes-nabil` (le "Master Agent VPS") n'a aucun port exposé en dehors du réseau Docker interne — il n'est atteignable depuis l'extérieur qu'via Telegram (indépendant de `hermes-hub`, préexistant à son ajout du 19/08) ou via le proxy de `hermes-hub` lui-même. Après suppression de `hermes-hub`, `hermes-nabil` reste joignable **uniquement par Telegram** — c'est exactement ce que Nabil veut, mais à confirmer explicitement avant coupure pour ne pas le découvrir après coup. - Conséquence directe : **supprimer hermes-hub en entier casse aussi dsh-hub.yesminedor.tn et files-hub.yesminedor.tn.**
- Les 3 Hermes NAS (tt/nyora/perso, ports 3010/3020/3031 en LAN, `100.86.197.88` en Tailscale) sont indépendants de `hermes-hub` — celui-ci ne fait que les proxifier pour l'UI web. Rien à changer côté NAS. - Ne pas chercher à repointer un ingress Cloudflare : le token disponible n'a pas la portée compte nécessaire pour éditer un tunnel (cfd_tunnel est une ressource de compte), et de toute façon les 6 hostnames partagent déjà le même CNAME — le levier n'est pas côté Cloudflare, il est dans le code de hermes-hub.
**Actions** : **Action retenue : réduire hermes-hub à un dispatcher minimal, ne pas le supprimer.**
1. `docker compose down` sur le service `hermes-hub` (localiser son compose sur le VPS, probablement `/home/.../hermes-hub/`), puis suppression du container, de l'image, des volumes nommés dédiés à sa DB de conversations.
2. Retirer l'entrée DNS/Cloudflare Tunnel pour `hub.yesminedor.tn` (vérifier d'abord si le tunnel Cloudflare est mutualisé avec d'autres domaines avant de toucher à la config du tunnel — ne pas supprimer une route partagée). 1. Dans le code de hermes-hub, retirer : le routeur chat.py (/api/chat/{universe}/...), sa base de conversations (chat_service.py/db.py, fichier hub.db), et la vue index_view/template index.html (l'UI switcher servie à l'apex). Remplacer la racine hub.yesminedor.tn par une réponse simple (404/410) — plus de switcher.
3. Vérifier après coupure : Telegram répond toujours pour les 4 Hermes, `dsh-hub.yesminedor.tn` et `files-hub.yesminedor.tn` répondent toujours normalement. 2. **Conserver intact** : get_subdomain_target, le middleware subdomain_routing_middleware, proxy_request, proxy_websocket. C'est ce qui fait fonctionner dsh-hub.yesminedor.tn et files-hub.yesminedor.tn aujourd'hui, et ça doit rester le seul chemin public vers DSH.
4. `ports-registry.md` : retirer la ligne `hermes-hub`, ajouter une entrée changelog datée. 3. Dans UNIVERSES (config), retirer les entrées tt/nyora/perso/nabil (elles ne servent plus qu'à l'ancienne UI supprimée). Ne garder que l'entrée dsh (et son alias filebrowser files).
4. Rebuild et redéployer hermes-hub avec ce code réduit, même nom de container, même port — aucun changement DNS ni tunnel nécessaire.
5. Vérifier après déploiement, à travers Cloudflare (pas seulement en interne) : dsh-hub.yesminedor.tn et files-hub.yesminedor.tn répondent normalement ; hub.yesminedor.tn seul ne sert plus le switcher ; Telegram répond toujours pour les 4 Hermes (chemin totalement indépendant, non affecté par ce qui précède).
6. ports-registry.md : mettre à jour l'entrée hermes-hub — préciser rôle réduit (dispatcher dsh-hub/files-hub uniquement), pas de suppression de ligne.
--- ---
@@ -79,22 +82,3 @@ Nabil demande "plus d'autonomie" et de "modifier le Full Access". Deux choses à
--- ---
## 7. CORRECTIF CRITIQUE (26/08 soir) — topologie Cloudflare Tunnel, a traiter avant Phase B
Le point 1 de ce brief affirmait que dsh-hub.yesminedor.tn et files-hub.yesminedor.tn etaient servis independamment de hermes-hub par dsh-vps-proxy (nginx). Faux, verifie et corrige : inspection directe de hermes-hub/app/main.py (fonction get_subdomain_target) confirme un routage par en-tete Host, exact :
- dsh-hub.yesminedor.tn -> HERMES_DSH_URL (proxy via hermes-hub)
- files-hub.yesminedor.tn -> DSH_FILEBROWSER_URL (proxy via hermes-hub)
- Les 5 hostnames *-hub.yesminedor.tn (tt/nyora/perso/nabil/dsh) arrivent tous sur la meme origine Cloudflare Tunnel (hermes-hub:8080), redistribues en interne selon le Host header.
Le tunnel cloudflared tourne en mode gere a distance (cloudflared --no-autoupdate tunnel --no-autoupdate run, aucun fichier de config local trouve sur le VPS) : les regles d'ingress vivent dans le dashboard/API Cloudflare, pas sur disque.
Sequence obligatoire, dans cet ordre, avant toute suppression de hermes-hub :
1. Localiser un token API Cloudflare (chercher dans les .env du VPS) ou obtenir de Nabil un acces dashboard Cloudflare Zero Trust pour le tunnel concerne.
2. Repointer l'ingress de dsh-hub.yesminedor.tn vers 100.94.90.119:8900 et files-hub.yesminedor.tn vers 100.94.90.119:8901 (dsh-vps-proxy).
3. Verifier les deux domaines publics de bout en bout a travers Cloudflare (pas seulement en interne/Tailscale) - reponse HTTP correcte, WebSocket fonctionnel pour dsh-hub.
4. Seulement apres validation du point 3 : proceder a la Phase B (arret/suppression de hermes-hub).
Ne pas supprimer hermes-hub avant d'avoir confirme le point 3 - sinon dsh-hub.yesminedor.tn et files-hub.yesminedor.tn tombent avec lui.
Phase A, point 2 (permission preset) : ne pas arbitrer entre danger-full-access et workspace-write sans validation explicite de Nabil - en attente de sa reponse, ne pas downgrader par defaut.