runbook: addendum 4 — correction placement credentials hermes-nabil (vrai conteneur trouve via vps.internal, pas mcp-vps)

This commit is contained in:
Nabil
2026-08-13 15:39:04 +00:00
parent 3afcc6c78e
commit 63fc32ae69
@@ -149,3 +149,17 @@ NYORA_NOTES_TOKEN=<token hermes-nabil>
Bundle volontairement l'URL (IP Tailscale du NAS, PAS 192.168.100.33 — LAN inaccessible depuis le VPS) et le token dans le meme fichier, pour qu'une session n'ait qu'un seul endroit a lire. Teste bout-en-bout (POST + DELETE reels sur NyoraNotes) apres creation — fonctionne independamment de l'etat du miroir memory-node. Bundle volontairement l'URL (IP Tailscale du NAS, PAS 192.168.100.33 — LAN inaccessible depuis le VPS) et le token dans le meme fichier, pour qu'une session n'ait qu'un seul endroit a lire. Teste bout-en-bout (POST + DELETE reels sur NyoraNotes) apres creation — fonctionne independamment de l'etat du miroir memory-node.
**A considerer plus tard (hors perimetre de cette session)** : durcir le rsync de memory-node pour exclure `*.token` desormais que plus rien n'en depend — amelioration de securite legitime sur le miroir de secours, mais touche un systeme different (cron + cle SSH forced-command + utilisateur claude-oversight) qui n'a pas ete audite ici. **A considerer plus tard (hors perimetre de cette session)** : durcir le rsync de memory-node pour exclure `*.token` desormais que plus rien n'en depend — amelioration de securite legitime sur le miroir de secours, mais touche un systeme different (cron + cle SSH forced-command + utilisateur claude-oversight) qui n'a pas ete audite ici.
---
## Addendum 4 — 13/08/2026 — correction : mauvais emplacement, vrai conteneur trouve
L'addendum 3 (credentials dediees) etait construit sur une erreur : `/root/.hermes-nabil/nyora-notes.env` a ete cree dans le conteneur **mcp-vps** (le connecteur MCP lui-meme, `linux_mcp_server.py`), pas dans le conteneur **hermes-nabil** reel. L'agent hermes-nabil tourne dans un conteneur Docker separe et invisible depuis mcp-vps (pas de socket Docker monte, PID namespace different) — a decouvrir via `ssh vps.internal` (alias equivalent a `nas-host` cote NAS, user `claude-oversight`), qui donne acces au vrai host VPS et a `docker ps`.
**Conteneur reel** : `hermes-nabil:v2026.8.3`, actif. Process applicatif tourne en utilisateur `hermes` (uid 1000, gid 1000) — jamais root. Deux montages : bind `/home/claude-oversight/hermes-nabil/data` -> `/data` (config, credentials, SOUL.md, memories/, kanban.db) et volume nomme -> `/opt/data` (workspace de production Dr Nexum, pas pour la config).
**Fix reel** : `NYORA_NOTES_URL` et `NYORA_NOTES_TOKEN` ajoutes a `/data/.env` (existant, deja proprietaire hermes:hermes 600, deja utilise pour ATLAS_CLOUD_API_KEY, ELEVENLABS_API_KEY, TELEGRAM_BOT_TOKEN etc.) — meme fichier, meme convention, pas de nouveau fichier invente. Ancien fichier `/root/.hermes-nabil/` supprime.
**Verifie** : `docker exec -u hermes hermes-nabil` (utilisateur reel, pas root) + source du .env + curl vers NyoraNotes -> HTTP 302, succes.
**Incertitude non levee** : le gateway hermes tourne en continu depuis 17h+ (process `hermes gateway run --replace`, pid stable). Lecture de `/proc/<pid>/environ` refusee (permission denied) — impossible de confirmer depuis l'exterieur si le gateway relit `.env` a chaque appel d'outil (auquel cas la nouvelle variable est deja active) ou seulement au demarrage (auquel cas un restart est necessaire). Pas de redemarrage effectue unilateralement — conteneur en activite reelle (kanban.db, sessions en cours, rendus video recents), decision a prendre avec l'utilisateur si confirmation stricte est necessaire avant premiere utilisation reelle par l'agent.