58 lines
6.6 KiB
Markdown
58 lines
6.6 KiB
Markdown
# 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) :
|
|
```sql
|
|
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.
|