65 lines
5.3 KiB
Markdown
65 lines
5.3 KiB
Markdown
# Watchdog Telegram gateway Hermes -- container autonome, sans acces DSM Task Scheduler
|
|
|
|
**Instance auteur** : Claude
|
|
**Date** : 2026-07-27
|
|
**Tags** : [infra, telegram, watchdog, hermes, transverse]
|
|
**Statut** : valide
|
|
|
|
---
|
|
|
|
## Probleme
|
|
|
|
Incident hermes-perso du 27/07 (voir note memoire du meme jour) : gateway Telegram bloque 2h17 en silence apres une erreur "Bad Gateway" transitoire cote Telegram -- le mecanisme interne de reconnexion de Hermes a lui-meme echoue sans le signaler, et le healthcheck Docker ne detecte pas ce type de panne (il verifie juste que le process tourne). Besoin d'une detection + correction automatique, sans intervention manuelle.
|
|
|
|
## Contexte et contraintes
|
|
|
|
Le compte Best0f (acces SSH utilise par Claude sur ce NAS) a des droits sudo scopes a docker/rsync/journalctl uniquement (pas de sudo general, pas de mot de passe disponible). Consequence directe : impossible de creer une tache dans le Planificateur de taches DSM (Synology, gere par `synoschedtask`, necessite les droits admin DSM) ni d'utiliser un crontab utilisateur classique (le binaire `crontab` n'est meme pas installe pour ce compte). Cette limitation est volontaire et ne doit pas etre contournee en cherchant un mot de passe ou en modifiant sudoers -- seul Nabil peut elargir ces droits, et ca reste un geste manuel equivalent a ce qu'on veut eviter.
|
|
|
|
## Ce qui NE fonctionne PAS
|
|
|
|
| Tentative | Erreur / limite | Raison |
|
|
|-----------|------------------|--------|
|
|
| `sudo -l` / sudo general | "a password is required" | Sudoers scope a docker/rsync/journalctl, pas de mot de passe connu de Claude |
|
|
| Creer une tache DSM Task Scheduler via SSH | Aucun acces -- necessite les droits admin DSM (interface web ou API authentifiee) | `synoschedtask` est une couche proprietaire, pas un simple fichier editable |
|
|
| `crontab -e` (utilisateur Best0f, sans sudo) | `crontab: command not found` | Binaire absent de l'environnement de ce compte |
|
|
| Editer `/etc/crontab` directement | Necessiterait root ; de toute facon ecrase par DSM au prochain enregistrement d'une tache via l'interface | Fichier entierement gere par synoschedtask, pas destine a l'edition manuelle |
|
|
|
|
## Solution validee
|
|
|
|
Le compte Best0f a en revanche un acces docker direct et fonctionnel (deja utilise tout au long de la session : `docker restart`, `docker logs`, etc., sans sudo). Solution : faire tourner le watchdog **dans son propre container**, avec le socket Docker monte, plutot que de dependre d'un ordonnanceur externe (DSM ou cron hote).
|
|
|
|
```bash
|
|
docker run -d --name hermes-watchdog-telegram \
|
|
--restart unless-stopped \
|
|
-v /var/run/docker.sock:/var/run/docker.sock \
|
|
-v /volume1/docker/hermes-platform/watchdog-telegram:/watchdog-data \
|
|
--entrypoint sh \
|
|
docker:cli \
|
|
-c 'apk add --no-cache python3 >/dev/null 2>&1; while true; do python3 /watchdog-data/watchdog_telegram_gateway_container.py; sleep 600; done'
|
|
```
|
|
|
|
Image `docker:cli` (Alpine + CLI Docker officiel) choisie pour rester leger tout en gardant le binaire `docker` deja present -- seul `python3` est ajoute via `apk` au demarrage (une seule fois, pas a chaque cycle). `--restart unless-stopped` : le container survit a un reboot du NAS (redemarre automatiquement avec le demon Docker).
|
|
|
|
Script (`watchdog_telegram_gateway_container.py`) : verifie toutes les 10 min les 3 instances NAS (hermes-agent-perso/tt/nyora) pour le motif exact de l'incident du 27/07 (marqueur d'erreur fatale "Fatal telegram adapter error" / "Restarting gateway" sans marqueur de reconnexion reussie apres, depuis plus de 10 min). Si detecte : `docker restart` du container concerne, silencieux. Si le MEME episode d'erreur persiste apres un redemarrage automatique deja tente (etat trackee dans `state.json`) : alerte envoyee via le webhook veille-infra existant (Email + Telegram) -- escalade uniquement quand un redemarrage automatique n'a pas suffi.
|
|
|
|
## Verification
|
|
|
|
```bash
|
|
docker ps --filter name=hermes-watchdog-telegram # Up, restart policy unless-stopped
|
|
docker exec hermes-watchdog-telegram docker ps # confirme l'acces au socket depuis l'interieur
|
|
cat /volume1/docker/hermes-platform/watchdog-telegram/watchdog.log # vide = rien a signaler (normal)
|
|
cat /volume1/docker/hermes-platform/watchdog-telegram/state.json # etat de suivi par instance
|
|
```
|
|
Premier passage teste le 27/07/2026 : acces socket confirme, aucune anomalie detectee (etat sain au moment du test).
|
|
|
|
## Pieges specifiques
|
|
|
|
- Ne jamais chercher a obtenir ou deviner un mot de passe sudo, ni modifier sudoers sans une demande explicite et deliberee de Nabil realisee par lui-meme -- la portee actuelle (docker/rsync/journalctl) est un choix de securite assume.
|
|
- Pattern reutilisable : tout besoin de tache planifiee cote NAS qui necessiterait normalement le Planificateur DSM peut etre resolu par un petit container autonome avec socket Docker monte, du moment que l'action necessaire est faisable via des commandes docker (pas de sudo general requis).
|
|
- Le container watchdog lui-meme n'apparait pas dans l'audit `EXPECTED = 43` de veille_infra.py (compteur de containers) -- a mettre a jour si le compte devient une source d'alerte "conteneur en trop".
|
|
|
|
## References
|
|
|
|
- Note memoire 27/07 : incident hermes-perso bloque sur Telegram (diagnostic + fix manuel initial)
|
|
- common/smart-approvals-deny-rules-4-instances.md (meme session, meme esprit de garde-fou)
|