143 lines
7.2 KiB
Markdown
143 lines
7.2 KiB
Markdown
# Déblocage DeepSeek V4.1 Flash — whitelist à plusieurs niveaux (11/09/2026)
|
|
|
|
Ticket : infra-2026-09-040 (clôturé définitif par Claude)
|
|
|
|
## Contexte
|
|
|
|
DeepSeek V4.1 Flash sorti le 10/09/2026 (remplace V4 Flash chez DeepSeek, prix
|
|
Flash reduits ~11-57%). Sur OpenCode Go (abonnement $10/mois deja utilise par
|
|
Bifrost), ce modele beneficie en plus d'un boost temporaire x4 sur les limites
|
|
d'usage. Nabil a signale ne pas pouvoir en profiter, ni des modeles gratuits
|
|
OpenRouter, sur aucun de ses assistants (Hermes NAS/VPS, openclaw-perso, DSH,
|
|
OpenCode CLI natif VPS).
|
|
|
|
## Diagnostic
|
|
|
|
Le blocage n'etait PAS un manque d'acces reseau/abonnement : le modele est
|
|
immediatement disponible sur le catalogue OpenCode Go (`GET /zen/go/v1/models`)
|
|
et testable en direct avec la cle deja en place. Les modeles gratuits
|
|
OpenRouter sont eux aussi deja largement whitelistes cote Bifrost pour la
|
|
plupart des VK (Gemma, Nemotron, GPT-OSS, Qwen3-coder, GLM-4.5-air, etc.).
|
|
|
|
Le vrai frein est une architecture a **quatre niveaux de whitelist**, aucun
|
|
avec hot-reload, qui doivent tous autoriser un modele avant qu'un agent donne
|
|
puisse reellement l'appeler :
|
|
|
|
1. Catalogue du provider OpenCode Go lui-meme (pas un blocage ici, juste la
|
|
source de verite sur les IDs de modele reels).
|
|
2. Bifrost — whitelist au niveau de la cle provider (`config.json`,
|
|
`providers.opencode.keys[0].models`).
|
|
3. Bifrost — whitelist par VK (`governance_virtual_key_provider_configs.allowed_models`,
|
|
une par (VK, provider) en base SQLite `config.db`) ; necessite un restart de
|
|
Bifrost pour etre relue (pas de hot-reload SQL).
|
|
4. Catalogue local fige de chaque agent, quand il en a un : container `opencode`
|
|
natif VPS (`opencode.json`), DSH (`settings.yaml`, providers `bifrost` +
|
|
`opencode-direct`, tous deux avec liste de modeles en dur), openclaw-perso
|
|
(`openclaw.json`, `models.providers.bifrost.models` + `agents.defaults.models`).
|
|
Hermes (tt/nyora/perso/nabil) n'a PAS ce niveau — provider `custom` generique
|
|
sans whitelist locale, donc deja debloque des que le niveau 3 l'est.
|
|
|
|
`bifrost-proxy` (nginx/openresty, port 3086, colocalise avec Bifrost sur le
|
|
VPS) a aussi un fichier `models.json` mais c'est purement un catalogue de
|
|
decouverte pour `/v1/models` — ne bloque aucun appel reel.
|
|
|
|
## Correctifs appliques
|
|
|
|
Backups pris avant chaque modification (suffixe `.bak-20260911*`).
|
|
|
|
1. **Bifrost core** (`/home/dsh-agent/bifrost/data/`) : `deepseek-v4.1-flash`
|
|
ajoute a `config.json` (cle provider opencode) et aux 21 lignes
|
|
`governance_virtual_key_provider_configs` (toutes les VK utilisant le
|
|
provider opencode) dans `config.db`. Container `bifrost` redemarre (healthy).
|
|
`bifrost-proxy/models.json` mis a jour pour la decouverte.
|
|
|
|
2. **DSH** (`settings.yaml`) : `deepseek-v4.1-flash` ajoute aux catalogues
|
|
`opencode-direct` et `bifrost`. **Bonus** : `baseURL` du provider `bifrost`
|
|
corrige — pointait encore vers l'ancien relais NAS (100.86.197.88:3086) au
|
|
lieu du VPS local (100.94.90.119:3086), alors que DSH tourne sur le VPS et
|
|
n'a plus besoin de transiter par le NAS/Sfax depuis la relocalisation du
|
|
08/09 (voir bifrost-routing memory). Container redemarre, teste avec la
|
|
vraie cle BIFROST_API_KEY.
|
|
|
|
3. **opencode natif VPS** (`/home/gemini-ops/opencode/config/opencode.json`) :
|
|
entree `deepseek-v4.1-flash` ajoutee au provider `bifrost`. Container
|
|
redemarre, entree confirmee dans la config active (`GET /config`).
|
|
|
|
4. **openclaw-perso** (`openclaw.json`) : entree ajoutee a
|
|
`models.providers.bifrost.models` (avec metadata complete) et a
|
|
`agents.defaults.models` (cle prefixee `bifrost/`, comme les entrees
|
|
existantes — premiere tentative sans prefixe corrigee en cours de route).
|
|
Container redemarre, healthy, teste.
|
|
|
|
5. **Hermes** (tt/nyora/perso/nabil) : aucune modification necessaire, deja
|
|
debloques via le niveau 3.
|
|
|
|
## Verification
|
|
|
|
Chaque instance testee en bout en bout via son propre chemin d'appel reel
|
|
(pas juste `curl` depuis l'exterieur) : hermes-perso (NAS, relais bifrost-proxy
|
|
NAS->VPS), DSH (VPS, vraie cle BIFROST_API_KEY), opencode natif VPS (cle
|
|
opencode directe + header session), openclaw-perso (Authorization Bearer via
|
|
bifrost-proxy). Toutes les reponses confirment `"model":"deepseek-v4.1-flash"`
|
|
avec une reponse coherente.
|
|
|
|
## Piege a retenir
|
|
|
|
`bifrost-proxy` (nginx) n'accepte le VK que via `Authorization: Bearer <vk>`
|
|
ou `x-api-key` — **pas** `x-bf-vk` en entree (ce header est ce qu'il injecte
|
|
lui-meme vers Bifrost apres resolution). Un test manuel avec `x-bf-vk` direct
|
|
contre `bifrost-proxy` echoue systematiquement (`virtual_key_required`), meme
|
|
si la cle est valide — a ne pas confondre avec un vrai probleme de VK.
|
|
|
|
## Reste ouvert
|
|
|
|
Aucun. Les 5 assistants cites par Nabil (Hermes NAS x3, hermes-nabil VPS, DSH,
|
|
openclaw-perso, opencode natif VPS) sont confirmes fonctionnels sur
|
|
deepseek-v4.1-flash au 11/09/2026.
|
|
|
|
## Addendum 11/09/2026 — token Gitea expiré + panne SSH memory-sync decouverte
|
|
|
|
En corrigeant le token Gitea `bolbol` expire (signale en fin de premiere session),
|
|
deux choses distinctes ont ete trouvees et traitees :
|
|
|
|
1. **Token sur le miroir reel** : le clone de travail avait ete corrige, mais
|
|
pas le miroir bare que le cron `memory-sync.sh` utilise reellement
|
|
(`/opt/memory-node/git/nas-runbooks.git` sur le VPS, proprietaire
|
|
`claude-oversight`). Corrige et confirme via l'execution cron reelle de
|
|
03:17 (`354361f..26bef7d main -> main`).
|
|
|
|
2. **Panne SSH decouverte au passage** : le meme script echouait depuis un
|
|
moment sur 100% des runs (`Best0f@100.86.197.88: Permission denied
|
|
(publickey,password)`) pour le volet rsync (nyora-notes + context-hub).
|
|
Cause : consequence collaterale du verrouillage progressif de l'acces
|
|
`Best0f` (migration vers comptes scopes claude-ops/gemini-ops/claude-code-ops,
|
|
voir memoire `gemini-ops-access`) — ce script n'avait jamais ete migre.
|
|
|
|
Fix : `memory-sync.sh` repointe sur `claude-ops@NAS`. Cle publique
|
|
`claude-oversight@vps-memory-node` (deja utilisee, identity file existant)
|
|
ajoutee a `authorized_keys` de `claude-ops` sur le NAS, avec **forced
|
|
command** restreignant strictement a `rsync --server --sender` en lecture
|
|
seule sur `/volume1/docker/nyora-notes/` et `/volume1/docker/context-hub/`
|
|
uniquement (aucun shell, `no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding`).
|
|
Backups : `authorized_keys.bak-20260911-ajout-cle-memory-node`,
|
|
`memory-sync.sh.bak-20260911`.
|
|
|
|
Verifie : `context-hub` synchronise integralement et a jour.
|
|
|
|
## Reste ouvert (nouveau, 11/09/2026)
|
|
|
|
`nyora-notes` bloque uniquement sur un sous-dossier isole,
|
|
`/volume1/docker/nyora-notes/app` (mode `700`, proprietaire uid 1026 —
|
|
seul dossier de toute l'arborescence hors de la convention `755` du reste).
|
|
Ni `claude-ops` (non proprietaire) ni le root conteneurise de `mcp-nas`
|
|
(`Operation not permitted` malgre `uid=0` — la couche de permission Synology
|
|
bloque meme le root du container) ne peuvent corriger ce mode.
|
|
|
|
**Action Nabil requise (une seule commande, en root ou via Best0f)** :
|
|
```
|
|
chmod -R g+rX /volume1/docker/nyora-notes/app
|
|
```
|
|
**RESOLU** -- applique par Nabil le 11/09/2026. Verifie en reel : run memory-sync
|
|
suivant (09:01) termine en rc=0, nyora-notes et context-hub integralement
|
|
synchronises, plus aucune erreur.
|