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

_INDEX.md

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

common/kaggle-qwen-automation-20260917.md

@@ -0,0 +1,31 @@
+# Kaggle Qwen — automatisation complète via l'API (push de kernel) et tunnel Cloudflare nommé
+
+**Date** : 17/09/2026
+**Contexte** : suite du runbook `kaggle-ollama-tunnel-verification-20260917.md`. Objectif : rendre le montage Kaggle GPU + Ollama + tunnel entièrement automatisé (pas de clic dans le notebook), avec une adresse publique stable, et complètement séparé de Bifrost (Qwen coûte plus cher que Mimo dans le forfait OpenCode Go de Nabil).
+
+## Tunnel Cloudflare nommé (remplace le tunnel rapide à URL aléatoire)
+Créé via l'API Cloudflare (Global API Key + email du compte, zone yesminedor.tn — bolbol.tn n'est pas dans ce compte Cloudflare) :
+- Tunnel nommé `kaggle-qwen-tunnel` (id `bb09176f-a0cf-4e3f-ac07-81cb2e7e46c5`), `config_src: cloudflare` (configuration à distance, pas de fichier config.yml côté Kaggle)
+- Hostname fixe : `kaggle-qwen.yesminedor.tn`, CNAME proxied vers `<tunnel_id>.cfargotunnel.com`
+- Token de connexion stocké dans `/volume1/docker/.claude/API_KEY.env` (`CF_TUNNEL_TOKEN`)
+- Ingress : `{hostname: kaggle-qwen.yesminedor.tn, service: http://localhost:11434, originRequest: {httpHostHeader: "localhost:11434"}}`
+
+## Automatisation Kaggle : push de kernel via l'API (pas de notebook manuel)
+`POST /api/v1/kernels/push` (auth `Authorization: Bearer <KAGGLE_API_KEY>`) avec un script Python (`kernelType: script`, `enableGpu: true`, `enableInternet: true`, `isPrivate: true`) qui installe et lance tout, puis boucle ~11h pour garder la session active (marge sous le plafond ~12h GPU de Kaggle). Kernel : `nabilderouiche/kaggle-qwen-runner-auto`.
+
+**Avantage clé découvert** : un kernel poussé via l'API est enfin traçable (`/kernels/status`, `/kernels/output`), contrairement au notebook cliqué à la main du runbook précédent — mais **`/kernels/output` ne renvoie les logs qu'une fois le run terminé, pas en direct pendant qu'il tourne**. Pour déboguer un run encore actif, interroger directement l'endpoint public exposé (le tunnel) plutôt que d'attendre les logs.
+
+## Trois pièges réels rencontrés et corrigés (dans l'ordre)
+
+**1. `ollama install.sh` échoue sur l'image Kaggle : `zstd` manquant.** L'image de base Kaggle n'a ni `zstd` ni `pciutils` (ce dernier utile pour l'auto-détection GPU par le script d'install). Fix : `apt-get install -y zstd pciutils` avant l'install Ollama.
+
+**2. `ollama pull hf.co/<repo>` échoue : `realm host "huggingface.co" does not match original host "hf.co"`.** Bug de redirection dans le pont Ollama↔HuggingFace sur cette version/cet environnement — le modèle `orcarouter/Qwen3.8-27B-Uncensored-GGUF` initialement visé n'a jamais pu être tiré par ce chemin. Fix : utiliser un modèle publié nativement sur le registre Ollama (pas via le pont hf.co), qui pull sans ce problème. Modèle finalement retenu : `huihui_ai/qwen3.5-abliterated:27b` (huihui-ai = référence établie et fiable pour l'abliteration, "27b" disponible directement dans son namespace Ollama officiel).
+
+**3. Le tunnel se connecte (confirmé "healthy" côté API Cloudflare) mais toute requête renvoie 403 vide.** Cause : Ollama rejette par défaut les requêtes dont le header `Host` n'est pas `localhost`/`127.0.0.1` (protection anti-DNS-rebinding), ce qui est exactement le cas derrière un tunnel avec un vrai nom de domaine public. **`OLLAMA_ORIGINS=*` ne corrige PAS ce problème** (ça ne gouverne que le CORS `Origin`, pas le `Host`) malgré ce que suggèrent beaucoup de guides communautaires. Le vrai fix, sans toucher au script Kaggle ni à Ollama : réécrire le header `Host` au niveau du tunnel lui-même, via `originRequest.httpHostHeader: "localhost:11434"` dans la config d'ingress Cloudflare (`PUT /accounts/{id}/cfd_tunnel/{tunnel_id}/configurations`).
+
+## État final vérifié
+`https://kaggle-qwen.yesminedor.tn/v1/models` et `/v1/chat/completions` répondent correctement (testé en direct, réponse française correcte). Débit observé : environ 2,5 tokens/s pour un modèle 27B en Q4 — probablement lié à l'allocation d'un seul GPU T4 (16 Go) via l'API de push, plutôt que le T4x2 (32 Go cumulés) sélectionnable manuellement dans l'éditeur web Kaggle. Utilisable mais pas rapide.
+
+## Non résolu / limites connues
+- Le kernel doit être repoussé manuellement (ou via cron à construire) toutes les ~11h pour rester dans le plafond de session Kaggle ; pas d'automatisation de relance périodique en place à ce stade.
+- Pas de bascule automatique si le tunnel tombe en dehors des heures d'exécution du kernel (aucun repli configuré, assumé volontairement puisque ce montage est hors Bifrost).