143 lines
7.9 KiB
Markdown
143 lines
7.9 KiB
Markdown
# Hermes absent du suivi de versions infra — comble le 25/08/2026
|
|
|
|
**Instance auteur** : Claude (session chat)
|
|
**Date** : 2026-08-25
|
|
**Tags** : hermes, baserow, n8n, versioning, infra_versions
|
|
**Statut** : en-cours (verification n8n en attente)
|
|
|
|
---
|
|
|
|
## Probleme
|
|
|
|
Nabil a remarque que Hermes n'etait jamais entre dans le suivi automatique des versions
|
|
infra (table Baserow `infra_versions`, ID 1097, database_id 317 / workflow n8n actif
|
|
`veille-versions-stack`, ID `zUWN5K4Q1A2JKFIS`), alors que ce sont justement les MAJ
|
|
Hermes et n8n qui avaient motive la creation de ce suivi le 21/08/2026.
|
|
|
|
Verification directe (JWT admin Baserow, pas d'hypothese) : la table contenait 11 lignes
|
|
(n8n, bifrost, gitea, portainer, vaultwarden, baserow, crowdsec, tailscale-nyora-bridge,
|
|
trilium, dsh-vps, dsh-vps-filebrowser) — aucune ligne Hermes. Le token API Baserow habituel
|
|
(`XGCwbfgwg8ZiLVb4dxEfagWa7XptyUcM`, cf `topics/baserow-access.md`) n'a PAS les permissions
|
|
sur cette table (`ERROR_NO_PERMISSION_TO_TABLE`) — la lecture/ecriture a du passer par un
|
|
JWT obtenu via `/api/user/token-auth/` avec le compte admin `contact@bolbol.tn` (credentials
|
|
dans `/mnt/docker/baserow-schema-mcp/.env`).
|
|
|
|
---
|
|
|
|
## Trouvaille annexe : changement de schema de version sur hermes-agent
|
|
|
|
Le runbook `common/brief-gemini-skills-hermes-antigravity-20260821.md` (21/08) confirmait
|
|
l'image `nousresearch/hermes-agent` en **v0.20.0** (commit upstream `3c27eb62`). Verification
|
|
en direct aujourd'hui (`docker inspect` sur hermes-agent-tt/nyora/perso) : image maintenant
|
|
en **v2026.8.3** — nouveau schema de versionnage (calver annee.mois.build) plutot qu'un simple
|
|
bump semver. C'est probablement la MAJ que Nabil a trouvee "interessante".
|
|
|
|
---
|
|
|
|
## Ce qui NE fonctionne PAS
|
|
|
|
| Tentative | Erreur obtenue | Raison de l'echec |
|
|
|-----------|----------------|-------------------|
|
|
| Connecteur MCP Baserow standard (`Baserow:get_table_schema` table 1097) | `[]` puis `ERROR_NO_PERMISSION_TO_TABLE` sur l'endpoint direct | Token API scope a un workspace different (achats Zone Sud), pas le workspace infra (workspace_id 187) |
|
|
| `n8n:get_workflow_details` sur `veille-versions-stack` | "Workflow is not available in MCP" | Acces MCP non active sur la fiche du workflow (a activer manuellement depuis n8n) |
|
|
|
|
---
|
|
|
|
## Solution validee
|
|
|
|
4 lignes ajoutees dans `infra_versions` (table 1097) via l'API Baserow (JWT admin) :
|
|
|
|
1. **hermes-agent** (NAS, id ligne 14) — `nousresearch/hermes-agent:v2026.8.3`, methode
|
|
`image_tag`, criticite Critique. Une seule ligne pour les 3 conteneurs
|
|
hermes-agent-tt/nyora/perso (meme image, meme tag sur les 3 — pas de doublon).
|
|
2. **hermes-workspace** (NAS, id ligne 15) — `ghcr.io/outsourc-e/hermes-workspace`,
|
|
actuellement sur `:latest` non pinne (digest verifie via `docker inspect` +
|
|
`ghcr.io/token` API, different du dernier tag semver publie `v2.1.3` — le tag `latest`
|
|
suit la branche `main`, pas les releases). **Decision Nabil (25/08)** : pinner un tag
|
|
explicite a chaque futur deploiement au lieu de `:latest`. Ligne en statut "En pause"
|
|
en attendant ce pin.
|
|
3. **hermes-nabil** (VPS, id ligne 16) — build local (pas de registre public), suit
|
|
`hermes-agent` NAS en miroir. **Decision Nabil (25/08)** : mise a jour manuelle a chaque
|
|
propagation validee NAS -> VPS, pas de verif de registre independante.
|
|
4. **hermes-hub** (VPS, id ligne 17) — build docker-compose 100% custom (image auto-nommee
|
|
`hermes-hub-hermes-hub`), aucun fichier de version trouve dans le conteneur (recherche
|
|
`package.json`/`VERSION*` infructueuse). Meme logique miroir que hermes-nabil, statut
|
|
"En pause" tant qu'aucun marqueur de version n'existe.
|
|
|
|
`hermes-mail-browser` (build local) et `hermes-watchdog-telegram` (image officielle
|
|
`docker:cli` utilisee comme outil) exclus du suivi : ce ne sont pas des composants Hermes
|
|
versionnables au sens de cette table.
|
|
|
|
---
|
|
|
|
## Verification
|
|
|
|
```bash
|
|
TOKEN=$(curl -s -X POST "http://baserow.bolbol.tn/api/user/token-auth/" -H "Content-Type: application/json" -d '{"email":"contact@bolbol.tn","password":"<voir .env baserow-schema-mcp>"}' | python3 -c "import sys,json; print(json.load(sys.stdin)['token'])")
|
|
curl -s "http://baserow.bolbol.tn/api/database/rows/table/1097/?size=200&user_field_names=true" -H "Authorization: JWT $TOKEN" | python3 -c "import sys,json; print(json.load(sys.stdin)['count'])"
|
|
# Resultat attendu : 15 (11 initiales + 4 Hermes)
|
|
```
|
|
|
|
---
|
|
|
|
## A faire (non cloture)
|
|
|
|
- Activer l'acces MCP sur la fiche du workflow `veille-versions-stack` (n8n) pour confirmer
|
|
s'il lit dynamiquement toutes les lignes de `infra_versions` (auto-inclusion de
|
|
`hermes-agent` au prochain passage hebdo, rien d'autre a faire) ou s'il faut lui ajouter
|
|
un noeud dedie pour Hermes.
|
|
- Pinner `hermes-workspace` a un tag explicite au prochain deploiement (au lieu de `:latest`)
|
|
et mettre a jour la ligne 15 en consequence.
|
|
|
|
---
|
|
|
|
## References
|
|
|
|
- Table Baserow `infra_versions`, ID 1097 (database_id 317, workspace_id 187)
|
|
- Workflow n8n `veille-versions-stack`, ID `zUWN5K4Q1A2JKFIS`
|
|
- [common/brief-gemini-skills-hermes-antigravity-20260821.md](brief-gemini-skills-hermes-antigravity-20260821.md)
|
|
|
|
**CORRECTIF (2026-08-25, meme session)** : la "trouvaille" ci-dessus sur un changement de
|
|
schema de versionnage (v0.20.0 -> v2026.8.3) est **erronee** -- confusion entre deux
|
|
identifiants distincts. `docker exec hermes-agent-tt .../hermes version` donne
|
|
`Hermes Agent v0.20.0 (2026.8.3) · upstream 3c27eb62` -- c'etait deja le cas le 21/08
|
|
(cf `common/brief-gemini-skills-hermes-antigravity-20260821.md`). Le tag Docker EST et
|
|
reste `nousresearch/hermes-agent:v2026.8.3`, aucun changement detecte entre le 21/08 et
|
|
le 25/08. `v0.20.0` = version interne du paquet Python (pyproject.toml), `2026.8.3` =
|
|
date de build encodee dans le meme identifiant, pas deux versions successives. Pas de
|
|
nouvelle MAJ image cote hermes-agent pour l'instant -- la MAJ "interessante" evoquee par
|
|
Nabil concerne des fonctionnalites (Browserless mode, Bot Mode), pas un bump de tag.
|
|
|
|
## CLOTURE — Rotation credentials + verrou reseau Bot Mode (25/08/2026)
|
|
|
|
Suite investigation hermes-nyora (brief v3, §1) : fuite HERMES_API_TOKEN tt+perso via
|
|
inspection Portainer (filtre de caviardage defaillant sur "TOKEN"). Rotation faite le jour
|
|
meme : nouvelles `HERMES_TT_API_KEY` / `HERMES_PERSO_API_KEY` dans
|
|
`/volume1/docker/hermes-platform/.env`, 4 conteneurs (agent+workspace tt/perso) recrees,
|
|
tous healthy. nyora non concerne.
|
|
|
|
Verrou reseau applique et verifie en direct le meme jour (Claude, via
|
|
`crowdsec-firewall-bouncer` — network host + NET_ADMIN, pas besoin de sudo) : DROP du port
|
|
peer Bot Mode 8642 sur le bridge Docker partage `n8n` (nom reel du bridge sur ce NAS :
|
|
`docker-8dbc7efc`, PAS `br-<hash>` — convention Synology, a ne jamais supposer generique).
|
|
Trafic legitime workspace->agent confirme passer par le reseau dedie de chaque instance
|
|
(`getent hosts` depuis chaque workspace), donc non affecte par le verrou — verifie par test
|
|
reel (401 sur les 3, pas de timeout) apres application.
|
|
|
|
Script de reference : `/volume1/docker/hermes-platform/scripts/verrou-botmode.sh`.
|
|
Persistance au reboot : tache planifiee DSM "Verrou_Bot_Mode", declenchement au demarrage —
|
|
posee par Nabil (hors acces SSH Best0f, `synoschedtask` indisponible pour ce compte).
|
|
|
|
Incident annexe : une commande d'audit Claude a par erreur affiche la cle tt en clair dans
|
|
un resultat d'outil pendant l'investigation — cle rotee de toute facon, mentionne pour
|
|
tracabilite.
|
|
|
|
Decisions encore ouvertes (brief v3 §8, non bloquantes pour la suite) : durcissement 4.3
|
|
(bind selectif par IP dediee, necessite grep prealable des workflows n8n), activation
|
|
Tirith sur hermes-nyora pour le pilote (actuellement `security.tirith_enabled: false`),
|
|
choix roster headless (tag manuel profile.yaml vs Desktop de gestion) — a trancher pendant
|
|
la conception du cas d'usage Manager + bots specialistes (brief v3 §4.4).
|
|
|
|
Brief v3 valide et transmis a hermes-nyora par Nabil le 25/08 — prochaine etape :
|
|
rapport Phase A (Gemini/AntiGravity), audit Claude a suivre.
|