docs: whitelist Bifrost double-couche (redaction-pro), bug prefixe nginx /api/, dualite catalogues opencode/opencode-go, fix model_override deprecie hermes-perso

2026-09-02 23:44:25 +01:00
parent 46a12f6abd
commit b216db2eb2
5 changed files with 131 additions and 2 deletions
@@ -81,8 +81,9 @@
 | [Hermes Hub — Déploiement et Exploitation Multi-Univers sur VPS (FastAPI, proxy async, design tokens, Tailscale)](common/hermes-hub-deploiement.md) | 2026-08-19 | hermes, hub, multi-univers, vps, tailscale, cloudflare-access, fastapi |
 | [Migration cerveau Hermes DeepSeek V4 Flash → Mimo V2.5 (perso, HARNESS/dsh-vps, tt, nyora) — desynchro git/live, auth key_env cassee sur Bifrost, context_length/max_tokens recalibres. Suite 18/08 : straggler nyora-veille corrige + Tirith reste sur DeepSeek (exception assumee, decision Nabil)](common/migration-mimo-v25-cerveau-hermes.md) | 2026-08-17 -> 2026-08-18 | mimo, hermes, migration, bifrost, opencode-go, context-length, nyora-veille, tirith |
 | [Accès Bifrost (passerelle LLM, vision/OCR)](common/bifrost-access.md) | 2026-07-11 | bifrost, llm, x-bf-vk, bifrost-proxy, hermes-desktop |
-| [Bifrost — incidents VK & fallback (consolidé 23/06 + 06/07 + 11/07)](common/bifrost-vk-incidents.md) | 2026-07-11 | bifrost, vk, opencode, cout |
-| [Migration provider → OpenCode Go (consolidé, état des modèles à jour)](common/opencode-go-migration.md) | 2026-07-09 | opencode, hermes, family-help |
+| [Bifrost — incidents VK & fallback (consolidé 23/06 + 06/07 + 11/07 + 02/09)](common/bifrost-vk-incidents.md) | 2026-09-02 | bifrost, vk, opencode, cout, governance |
+| [Migration provider → OpenCode Go (consolidé, état des modèles à jour)](common/opencode-go-migration.md) | 2026-09-02 | opencode, hermes, family-help |
+| [Résolution DNS dynamique nginx + piège troncature prefixe /api/](common/nginx-proxy-dns-resolution.md) | 2026-09-02 | nginx, proxy, docker, dns, redaction-pro |
 | [n8n Code nodes LLM vers Bifrost obligatoire](common/runbook-n8n-llm-bifrost.md) | 2026-06-15 | n8n, bifrost, code-node |
 | [Génération/édition d'images IA (nano-banana)](common/openrouter-image-gen.md) | 2026-06-14 | openrouter, image |

@@ -180,6 +181,7 @@
 | [CrowdSec sur DSM](hermes-perso/security/crowdsec-dsm.md) | 2026-06-12 | securite, ssh, iptables |
 | [SOUL.md hermes-perso — ingest API veille](hermes-perso/soul-veille-ingest.md) | 2026-06-15 | soul, veille |
 | [formation-consultant — site formation autodidacte](hermes-perso/formation-consultant.md) | 2026-07-25 | infra, formation, deploiement |
+| [hermes-perso — model_override déprécié sur session Telegram (ox-alpha-free)](hermes-perso/ox-alpha-free-deprecated-model-override.md) | 2026-09-02 | hermes-perso, telegram, opencode |

 ---

@@ -52,3 +52,19 @@ curl -X POST http://bifrost:8080/v1/chat/completions -H 'x-bf-vk: <Nabil-Key>' \
 ## A surveiller (mis a jour 11/07)

 Le cache VK stale n'est plus un incident isole : 3 occurrences en 5 jours (23/06 racine differente, 06/07, 11/07) avec le meme symptome et le meme fix (restart bifrost). A investiguer en profondeur si ca continue : pourquoi le cache memoire ne s'invalide pas sur ecriture DB (write recent sur config.db sans invalidation cache observe le 11/07). En attendant, reflexe standard confirme : **tout 401 virtual_key_not_found inexplique -> restart bifrost avant toute autre investigation**, ne pas re-tester en boucle sur le meme cache fige.
+
+## Incident 02/09/2026 — modeles bloques sur redaction-pro malgre cle provider correcte
+
+**Contexte** : redaction-pro (VK dediee `vk-redaction-pro`) — presque tous les modeles demandes par Nabil (ox-alpha-free, x-previex-f-free, laguna-s-2.1-free, nemotron-3-*-free, muse-spark-1.2-contributor(-free)) renvoyaient 403 `model_blocked`.
+
+**Cause confirmee** : deux couches de whitelist independantes, il faut les deux pour qu'un appel passe :
+1. `config_keys.models_json` — whitelist au niveau de la cle provider brute (ex. id=8 `opencode-1`), partagee par TOUS les consommateurs de cette cle (Hermes inclus).
+2. `governance_virtual_key_provider_configs.allowed_models` — whitelist specifique a CHAQUE VK (ex. id=72 pour vk-redaction-pro / opencode). C'est cette couche qui bloquait le plus souvent, meme quand la cle provider autorisait deja le modele.
+
+**Piege supplementaire confirme (revalide 4e fois)** : editer ces deux colonnes JSON en DB (sqlite direct, colonnes `models_json` / `allowed_models`) **ne prend PAS effet a chaud** — `docker restart bifrost` obligatoire, cf. "A surveiller" ci-dessus (meme famille que le cache VK stale).
+
+**Verification finale des noms de modeles** : avant d'ajouter un modele a la whitelist, verifier qu'il existe reellement via `GET https://opencode.ai/zen/go/v1/models` (Authorization Bearer <cle opencode-go>) — plusieurs noms fournis par Nabil (ox-alpha-free, x-previex-f-free, laguna-s-2.1-free, nemotron-3-ultra-free, nemotron-3.5-lightning-free) n'existaient PAS dans ce catalogue cote `opencode-go` (Zen REST, celui de Bifrost) alors qu'ils existent bien cote `opencode` natif (OAuth device-flow, utilise par Hermes via Telegram) ou cote OpenRouter sous un nom different (vendor/modele:free) — voir common/opencode-go-migration.md pour le detail de cette dualite de catalogues.
+
+**Resultat** : whitelist nettoyee (retrait des 6 IDs fantomes/deprecies), `hy3` ajoute et confirme fonctionnel (~2-6s, gratuit), `mimo-v2.5` confirme fonctionnel pour redaction-pro (~40-45s, deja whiteliste par ailleurs).
+
+**Backup pris avant toute modification** : `config.db.bak-redaction-pro-models-20260902-163248`.
@@ -78,3 +78,40 @@ Lors de la mise en place ou modification d'un reverse proxy Nginx :
 1. Valider la syntaxe : `docker exec <proxy> nginx -t`
 2. Recharger la config : `docker exec <proxy> nginx -s reload`
 3. **Test d'attribution dynamique** : Redémarrer le conteneur backend (`docker restart <backend>`) et vérifier avec `curl` l'accès via le proxy **sans toucher au conteneur proxy**.
+
+## Piege additionnel confirme (02/09/2026) — le prefixe de location n'est PAS tronque avec proxy_pass + variable
+
+**Symptome** : sur redaction-pro, TOUS les appels API echouaient en 405 Method Not Allowed depuis le navigateur, quel que soit le modele choisi — alors que les memes appels fonctionnaient parfaitement en tapant directement l'URL de Bifrost. Aucun rapport avec la whitelist de modeles (voir common/bifrost-vk-incidents.md, incident du meme jour).
+
+**Cause** : le pattern documente plus haut (`set $upstream ...; proxy_pass $upstream;`) resout bien le probleme de cache DNS, MAIS il a un effet de bord non documente jusqu'ici : quand `proxy_pass` cible une **variable**, nginx ne tronque plus jamais le prefixe du `location` — il transmet l'URI ORIGINALE complete au backend, contrairement a un `proxy_pass` avec une URI litterale qui tronque automatiquement le prefixe du `location` matche.
+
+Concretement sur redaction-pro :
+```nginx
+location /api/ {
+    set $bifrost_upstream http://bifrost:8080;
+    proxy_pass $bifrost_upstream/;   # BUG : le "/" final est ignore avec une variable
+}
+```
+Une requete navigateur vers `/api/v1/chat/completions` etait transmise a Bifrost telle quelle, soit `/api/v1/chat/completions` — un chemin que Bifrost ne reconnait pas comme route API (son router de secours sert alors sa propre page de dashboard en GET, et renvoie 405 sur tout le reste).
+
+**Fix** : ajouter un `rewrite` explicite AVANT le `proxy_pass`, pour forcer la troncature que la variable empeche :
+```nginx
+location /api/ {
+    set $bifrost_upstream http://bifrost:8080;
+    rewrite ^/api/(.*)$ /$1 break;
+    proxy_pass $bifrost_upstream;   # sans "/" final, inutile desormais
+}
+```
+Valider avec `docker exec <proxy> nginx -t` puis `nginx -s reload` (pas besoin de redemarrer le conteneur).
+
+**Regle generale** : des qu'un `location` a un PREFIXE non-racine (`/api/`, `/mcp/`, etc.) ET que le `proxy_pass` cible une variable (pattern DNS dynamique ci-dessus), un `rewrite ... break;` de troncature est **obligatoire**, sinon le backend recoit un chemin errone en silence (pas d'erreur nginx, juste un mauvais routage cote backend).
+
+**A verifier** (non fait le 02/09, hors perimetre de la tache du jour) : `baserow-schema-mcp/nginx.conf` utilise `location /mcp/ { proxy_pass $mcp_upstream; }` — meme pattern a risque, jamais audite sous cet angle precis. A verifier si le backend MCP attend un chemin sans prefixe avant de considerer que c'est fonctionnel par coincidence ou reellement correct.
+
+## Tableau perimetre — mise a jour
+
+| Service Proxy | Statut prefixe non-racine |
+|---|---|
+| `redaction-pro` (`/api/`) | ✅ Bug trouve et corrige le 02/09/2026 (rewrite ajoute) |
+| `baserow-schema-mcp` (`/mcp/`) | ⚠️ A verifier — meme pattern a risque, non audite |
+| `baserow-oauth-proxy` | OK — utilise `$upstream$request_uri` (chemin complet volontaire), pas concerne |
@@ -63,3 +63,20 @@ Bifrost ne recharge PAS les clés provider au restart → `config.json` chargé

 - https://opencode.ai/docs/zen · hermes-agent.nousresearch.com/docs (fallback-providers)
 - hermes-nyora/verdict-pilote-mimo-v25.md · common/bifrost-vk-incidents.md
+
+## Mise a jour 02/09/2026 — hy3 valide, distinction des deux catalogues opencode
+
+**Deux catalogues distincts existent dans le registre models.dev, a ne pas confondre** :
+- `opencode-go` : API REST Zen (`https://opencode.ai/zen/go/v1`), auth par cle API — c'est celui utilise par Bifrost (voir common/bifrost-vk-incidents.md).
+- `opencode` natif : OAuth device-flow, compte personnel Nabil — utilise directement par les instances Hermes (hermes-agent) pour le picker de modeles Telegram, **sans passer par Bifrost**. Cache local visible dans le conteneur : `/opt/data/models_dev_cache.json` (cle `opencode-go` vs `opencode` a la racine du JSON).
+
+Ces deux catalogues n'ont pas le meme contenu ni la meme disponibilite. Un modele visible/selectionnable sur Telegram (catalogue `opencode` natif) peut tres bien etre absent ou deprecie cote `opencode-go` (celui de Bifrost), et inversement.
+
+**Nouveau modele valide sur opencode-go** : `hy3` — rapide (~2-6s), gratuit, bonne qualite francais. Ajoute a la liste "utilisables" ci-dessus.
+
+**Statuts verifies via `models_dev_cache.json`** (present dans tout conteneur hermes-agent) :
+- `opencode-go/ox-alpha-free` → **status: deprecated**. Ne plus utiliser (401 "not supported" confirme en live).
+- `opencode/laguna-s-2.1-free` (catalogue natif, PAS opencode-go) → **status: deprecated** egalement.
+- `opencode/nemotron-3-ultra-free`, `opencode/nemotron-3.5-lightning-free`, `opencode/muse-spark-1.2-contributor-free` → presents dans le catalogue natif seulement, jamais testes en conditions reelles (pas d'acces direct a ce catalogue OAuth depuis Bifrost/scripts).
+- `x-previex-f-free` → introuvable dans TOUT models_dev_cache.json, tous providers confondus. Probablement une confusion/erreur de nom, jamais rentre.
+- `muse-spark-1.2-contributor` (sans -free) → existe reellement cote opencode-go, mais bloque par une `DataPolicyError` exigeant un opt-in explicite de partage de donnees sur une page workspace personnelle. Necessite une action manuelle de Nabil, pas un fix infra.
@@ -0,0 +1,57 @@
+# hermes-perso — model_override deprecie sur la session Telegram (ox-alpha-free)
+
+**Instance auteur** : hermes-perso
+**Date** : 2026-09-02
+**Tags** : hermes-perso, telegram, opencode, model_override
+**Statut** : valide
+
+---
+
+## Probleme
+
+La session Telegram DM de Nabil (`agent:main:telegram:dm:2084513684` dans `/opt/data/sessions/sessions.json`) avait un `model_override` fige sur `ox-alpha-free` (provider `opencode-go`). Ce modele est marque `"status": "deprecated"` dans le registre `models_dev_cache.json` et l'API `opencode.ai/zen/go/v1/chat/completions` renvoie `401 "Model ox-alpha-free is not supported"` en confirmation directe. Tous les messages Telegram envoyes sous ce override echouaient silencieusement.
+
+## Contexte et contraintes
+
+`/opt/data/` du conteneur `hermes-agent-perso` est en 0700 (uid 1026), illisible en SSH direct meme depuis un compte scope comme claude-ops. Acces uniquement via `docker exec` (qui tourne root dans le conteneur, contourne le mur de permissions cote host).
+
+## Ce qui NE fonctionne PAS
+
+| Tentative | Erreur obtenue | Raison de l'echec |
+|-----------|----------------|-------------------|
+| Lecture directe via SSH claude-ops (`cat /opt/data/...`) | Permission denied | data/ en 0700 uid 1026, claude-ops non proprietaire |
+| Edition via `ssh nas-host` directement sur les fichiers `.env`/`docker-compose.yml.disabled` du dossier hermes-perso | Aucune trace du model_override actif | Config statique ; le choix de modele reel vit dans `sessions.json`, pas dans les fichiers de config au repos |
+
+## Solution validee
+
+```bash
+# 1. Backup avant toute ecriture
+docker exec hermes-agent-perso cp /opt/data/sessions/sessions.json \
+  /opt/data/sessions/sessions.json.bak-fix-ox-alpha-$(date +%Y%m%d-%H%M%S)
+
+# 2. Edition cible via script Python transfere en base64 (docker cp) puis execute root dans le conteneur
+#    -> modifie uniquement sessions[key].model_override.model, rien d'autre
+docker cp fix_model.py hermes-agent-perso:/tmp/fix_model.py
+docker exec hermes-agent-perso python3 /tmp/fix_model.py
+```
+
+Bascule effectuee : `ox-alpha-free` → `hy3` (meme provider `opencode-go`, meme `base_url`, changement minimal).
+
+## Verification
+
+```bash
+docker exec hermes-agent-perso python3 -c "import json; d=json.load(open('/opt/data/sessions/sessions.json')); print(d['agent:main:telegram:dm:2084513684']['model_override'])"
+# Attendu : {'model': 'hy3', 'provider': 'opencode-go', 'base_url': 'https://opencode.ai/zen/go/v1'}
+```
+JSON valide (`json.load` sans exception) confirme apres ecriture.
+
+## Pieges specifiques
+
+- Ne jamais editer `sessions.json` a la main sans backup — c'est un fichier d'etat vivant, reecrit en continu par le process gateway actif (`active_turn_token` doit etre `null` avant d'editer, sinon risque de race condition avec une conversation en cours).
+- Le mecanisme exact par lequel le Telegram bot laisse choisir un modele "directement" (mentionne par Nabil) n'a pas ete localise dans cette session (pas de endpoint `/docs` ou `/openapi.json` trouve sur l'API server interne, port 8642) — probablement une commande bot (`/model <nom>`) qui ecrit dans ce meme `model_override`. A confirmer.
+- Toujours verifier le statut d'un modele OpenCode dans `models_dev_cache.json` (du conteneur hermes-agent concerne) avant de l'assigner en dur quelque part — voir common/opencode-go-migration.md pour la distinction des deux catalogues opencode.
+
+## References
+
+- common/opencode-go-migration.md
+- common/bifrost-vk-incidents.md (incident du meme jour, cause differente mais meme famille de symptome : modele non fonctionnel silencieusement)