Veille Infra v2 — montée + fix activation n8n "Version not found"

Date : 15/07/2026 · Sphère : infra · Statut : opérationnel

Objectif

Digest infra quotidien unique : santé (conteneurs, disques, SMART, certs, VPS Contabo, backup USB) + veille techno/CVE (releases GitHub, CVE NVD), synthèse par LLM gratuit (Bifrost/gemini-2.5-flash), livré Email + Telegram.

Architecture

Collecteur /volume1/docker/veille-infra/veille_infra.py (py3.8 + requests, aucun secret dans le script).
- Santé : docker ps (Best0f, sans sudo) ; df -Ph /volume1 / ; SMART best-effort → need_root si non-root ; certs acme/*bolbol* (glob échappé) ; VPS via tailscale ping sinon "non vérifié" (jamais de faux "injoignable") ; backup /volumeUSB1.
- Veille : GitHub releases/latest (n8n, gitea, portainer, crowdsec, baserow) ; CVE NVD par mot-clé.
- Verdict OK/ATTENTION/CRITIQUE + alertes. Synthèse LLM si /volume1/docker/veille-infra/.bifrost_vk (chmod 600) présent → POST http://192.168.100.33:3085/v1/chat/completions header x-bf-vk, model gemini-2.5-flash.
- Rendu HTML (navy #1A1A2E / or #B8862A, footer Nyora) + Telegram, POST https://n8n.nd.i234.me/webhook/veille-infra.
- Debug : VEILLE_DUMP=1 → écrit last_payload.json, pas de POST.
Workflow livraison n8n X51xQsOpXeedaBKt : Webhook POST veille-infra → Email (IK.ME SMTP 7eBO8ta5EiZOVufh) + Telegram (ND_Telegram OyOHh6jAzCDsiBux, chat 2084513684). Creds auto-assignées. E2E OK (exec 32550 success).
Ordonnancement : tâche DSM Planificateur root, quotidienne 08:00 Tunis, python3 /volume1/docker/veille-infra/veille_infra.py (root requis pour SMART). À créer via UI web DSM.

FIX RÉUTILISABLE — publish n8n "Version not found"

Depuis la coupure/purge, workflow_entity.versionId peut pointer vers une version absente de workflow_history (les updates MCP changent versionId sans historiser) → publishVersion échoue en FK. La recréation NE corrige PAS. Le restart n8n NON PLUS.

Correctif (DB Postgres n8n-DB, rayon d action = 1 ligne) :

select "versionId" from workflow_history where "workflowId"='<WF>' order by "createdAt" desc limit 1;
update workflow_entity set "versionId"='<versionId-historisée>' where id='<WF>';

puis publish_workflow MCP → actif (active=t, activeVersionId==versionId).

Dette sécu (rotation)

Token Telegram en clair dans le node Code de "INFRA | OpenHuman Watch" (9MkE8Fx3ZlY485Y5) → roter + passer sur credential ND_Telegram.
Mot de passe Postgres n8n faible (n8npass).
VK Bifrost bfk-0c… (déjà flaggée, transitée en clair).

INCIDENT 25/07/2026 — digest jamais parti depuis le 15/07 (tache DSM jamais creee)

Constat : execution_entity du workflow X51xQsOpXeedaBKt ne compte que 2 executions, 32550 et 32551, toutes deux le 15/07/2026 (tests manuels de validation). Zero execution depuis, soit 10 jours de silence total sur Telegram et email. Cause confirmee : /etc/crontab ne contient aucune ligne pour veille_infra.py ; les 10 taches synoschedtask existantes datent toutes d'avant juillet 2026 (taches systeme historiques). L'etape "a creer via UI web DSM" du plan initial n'a jamais ete faite, le pipeline est valide bout-en-bout mais n'a jamais ete branche a un declencheur automatique.

Statut : passe de "operationnel" a "construit, non ordonnance".

Effet de bord repere en creusant : conteneur veille-frontend (app nyora-veille, dashboard de curation, sans lien avec ce digest infra) tombe le 21/07, notifie uniquement via l'alerte Synology native (sns@synologynotification.com), redemarre depuis (17h up au 25/07). Ce canal natif fonctionne bien pour du temps reel ; le digest quotidien n'a pas vocation a le dupliquer.

Action requise (root, DSM UI, non automatisable via mcp-nas) : creer la tache Panneau de configuration -> Planificateur de taches -> Creer -> Tache declenchee -> Script defini par l'utilisateur, executee en tant que root, quotidienne 08:00, commande python3 /volume1/docker/veille-infra/veille_infra.py.

Recommandation v2 (a construire, necessite acces n8n MCP) : ajouter un heartbeat, un second workflow n8n (Schedule Trigger 09:00) qui verifie si X51xQsOpXeedaBKt a eu une execution success dans les dernieres 30h et alerte Telegram si silence. Objectif : que ce type de panne silencieuse de 10 jours ne puisse plus se reproduire sans alerte.

CORRECTIF 25/07/2026 (suite) — acces O365 reel via hermes-mail-browser, vrai coupable trouve

L'incident ci-dessus concerne bien X51xQsOpXeedaBKt (digest sante, toujours non ordonnance, DSM task a creer). Mais un second constat, plus important pour le bruit quotidien recu par Nabil : le workflow actif 9MkE8Fx3ZlY485Y5 ("INFRA | OpenHuman Watch", Schedule Trigger 4h) spammait sa boite O365 depuis des jours avec des notifications de release Vellum/OpenHuman dupliquees en boucle.

Cause reelle : le node Code "Fetch Releases GitHub & Vellum" ne comparait que le tout premier item du flux Atom GitHub (entries[0].id) au dernier ID connu (lastSeen_<repo>, une seule valeur). Le flux Atom de vellum-ai/vellum-assistant fait alterner en tete la release stable (v0.10.12) et une prerelease (v0.10.12-staging.2) selon les republications - chaque bascule etait interpretee comme "nouvelle release", d'ou un renvoi des deux items toutes les ~4h a l'infini.

Fix applique (25/07, en direct) : dedup remplacee par un historique d'IDs deja vus (seen_<repo>, array cape a 30, migre depuis l'ancien lastSeen_<repo>) au lieu d'une comparaison au seul dernier ID. Toute release deja notifiee reste exclue meme si elle repasse en tete du flux. Code valide (syntax check local) puis pousse en DB (workflow_entity.nodes, update cible sur le node, via base64 pour eviter l'enfer des quotes) puis docker restart n8n pour forcer le rechargement (necessaire : n8n ne relit pas les nodes actifs a chaud). Verifie post-restart : n8n healthy, les deux workflows toujours actifs.

Non traite (dette sécu deja notee ci-dessus, toujours vraie) : token Telegram en clair dans ce meme node. Pas touche aujourd'hui car ca demanderait de re-brancher sur credential ND_Telegram, changement plus large, a faire separement avec validation UI.

Outil decouvert au passage : hermes-mail-browser (container healthy, port API 192.168.100.33:3110, VNC 8810), Playwright + Edge piloté sur la vraie session OWA (nabil.derouiche@tunisietelecom.tn). Endpoints utiles : /health, /auth/status, /folders, /inbox?limit=N&folder=..., /message/{index}. A utiliser en priorite pour toute question "qu'est-ce que je recois par mail" au lieu de deduire depuis les seuls logs n8n/DB.

6.6 KiB Raw Blame History