runbook: automatisation complete kaggle-qwen (push API + tunnel nomme + 3 pieges corriges)

2026-09-17 11:40:16 +01:00
parent 2e83b46d2b
commit a2784242bb
2 changed files with 32 additions and 0 deletions
@@ -294,3 +294,4 @@
 - [common/backup-usb-cache-io-errors-fix-20260914.md](common/backup-usb-cache-io-errors-fix-20260914.md) -- Échecs backup-usb.sh deux semaines de suite (07/09 puis 14/09/2026, rc=23) : diagnostic — rsync --link-dest relit le backup precedent (31/08) pour le hardlink, et des fichiers de .cache/uv (paquets Python hermes-tt) y remontaient des erreurs Input/output error ; la rotation ne purge qu'en succes donc les backups en echec s'accumulaient sans etre nettoyes. Script corrige (backup .bak-20260914 conserve) : exclusion des caches ephemeres (.cache/uv, .cache/pip, .cache/ms-playwright, __pycache__, node_modules/.cache) et fix du bug exit 0 implicite qui masquait l'echec au Task Scheduler DSM (status affichait Success malgre BACKUP EN ECHEC). Backup relance manuellement et valide : rc=0/rc=0, zero erreur I/O, 96G, _BACKUP_OK present (14/09/2026)
 - [common/watchdog-tailscale-bridge-faux-timeout-restart-20260916.md](common/watchdog-tailscale-bridge-faux-timeout-restart-20260916.md) -- tailscale-bridge-watchdog (cree 05/09, jamais documente/versionne avant ce jour) : fausse alerte Telegram "Echec apres redemarrage automatique / SOCKS5 Name does not resolve" causee par un timeout de 20s trop court sur le docker restart du pont (tailscaled+socat), sous charge NAS elevee (swap 5.0Gi/13Gi, load 8.08) ; pont en fait deja retabli par le 2e cycle de remediation automatique avant intervention. Fix : timeout 20s->45s + attente post-restart 15s->20s, rebuild/redeploy verifie. Piege decouvert au passage : docker compose up -d cible sur un seul service a recree le bridge (depends_on) sans le redemarrer (etat Created, corrige manuellement) -- toujours faire un up -d complet du compose en presence de depends_on. Repo tailscale-nyora-bridge initialise et pousse sur Gitea pour la premiere fois (16/09/2026)
 - [common/kaggle-ollama-tunnel-verification-20260917.md](common/kaggle-ollama-tunnel-verification-20260917.md) -- Vérification clé API Kaggle (format Bearer KGAT_, test santé via competitions/list?group=entered) et diagnostic du montage Kaggle GPU + Ollama + tunnel Cloudflare rapide pour LLM auto-hébergé (modèle Qwen3.6-27B-AEON-Ultimate-Uncensored). Piège majeur : un notebook exécuté à la main dans l'éditeur web est invisible à l'API (404 No runs found) -- seul un kernel poussé via kaggle kernels push est traçable/automatisable. Quota GPU (~30h/semaine), tunnel à URL aléatoire non stable, aucune auth réelle côté endpoint : montage jugé utilisable en rafale ponctuelle, pas comme provider Bifrost permanent. Note annexe : sudo passwordless de claude-ops sur fichiers 600 de Best0f (17/09/2026)
+- [common/kaggle-qwen-automation-20260917.md](common/kaggle-qwen-automation-20260917.md) -- Montage Kaggle Qwen rendu entièrement autonome : push de kernel via l'API (pas de notebook manuel) + tunnel Cloudflare nommé (hostname fixe kaggle-qwen.yesminedor.tn, hors zone bolbol.tn), gardé séparé de Bifrost à la demande de Nabil. Trois pièges corrigés : zstd/pciutils absents de l'image Kaggle, bug de pull hf.co->huggingface.co (contourné avec un modèle publié nativement sur le registre Ollama, huihui_ai/qwen3.5-abliterated:27b), et 403 Ollama sur le header Host derrière un tunnel (OLLAMA_ORIGINS ne le corrige PAS, le vrai fix est originRequest.httpHostHeader dans l'ingress Cloudflare). Endpoint verifie fonctionnel en direct (~2,5 tokens/s, probablement un seul T4 via l'API de push) (17/09/2026)