From b216db2eb286c61a087d910f43f555f66ccee235 Mon Sep 17 00:00:00 2001 From: Nabil Derouiche Date: Wed, 2 Sep 2026 23:44:25 +0100 Subject: [PATCH] docs: whitelist Bifrost double-couche (redaction-pro), bug prefixe nginx /api/, dualite catalogues opencode/opencode-go, fix model_override deprecie hermes-perso --- _INDEX.md | 6 +- common/bifrost-vk-incidents.md | 16 ++++++ common/nginx-proxy-dns-resolution.md | 37 ++++++++++++ common/opencode-go-migration.md | 17 ++++++ ...ox-alpha-free-deprecated-model-override.md | 57 +++++++++++++++++++ 5 files changed, 131 insertions(+), 2 deletions(-) create mode 100644 hermes-perso/ox-alpha-free-deprecated-model-override.md diff --git a/_INDEX.md b/_INDEX.md index 512e514..79cd8f1 100644 --- a/_INDEX.md +++ b/_INDEX.md @@ -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 | --- diff --git a/common/bifrost-vk-incidents.md b/common/bifrost-vk-incidents.md index 86abf10..2aff118 100644 --- a/common/bifrost-vk-incidents.md +++ b/common/bifrost-vk-incidents.md @@ -52,3 +52,19 @@ curl -X POST http://bifrost:8080/v1/chat/completions -H 'x-bf-vk: ' \ ## 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 ) — 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`. diff --git a/common/nginx-proxy-dns-resolution.md b/common/nginx-proxy-dns-resolution.md index 354954a..7d32b58 100644 --- a/common/nginx-proxy-dns-resolution.md +++ b/common/nginx-proxy-dns-resolution.md @@ -78,3 +78,40 @@ Lors de la mise en place ou modification d'un reverse proxy Nginx : 1. Valider la syntaxe : `docker exec nginx -t` 2. Recharger la config : `docker exec nginx -s reload` 3. **Test d'attribution dynamique** : Redémarrer le conteneur backend (`docker restart `) 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 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 | diff --git a/common/opencode-go-migration.md b/common/opencode-go-migration.md index 56ee92f..011d104 100644 --- a/common/opencode-go-migration.md +++ b/common/opencode-go-migration.md @@ -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. diff --git a/hermes-perso/ox-alpha-free-deprecated-model-override.md b/hermes-perso/ox-alpha-free-deprecated-model-override.md new file mode 100644 index 0000000..758327b --- /dev/null +++ b/hermes-perso/ox-alpha-free-deprecated-model-override.md @@ -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 `) 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)