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) :

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).
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.
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.
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

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

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.

7.9 KiB Raw Blame History