runbook: verification cle Kaggle API + piege notebook manuel invisible API

2026-09-17 10:43:33 +01:00
parent 0d60299b13
commit 2e83b46d2b
2 changed files with 28 additions and 0 deletions
@@ -0,0 +1,27 @@
+# Kaggle Ollama + tunnel Cloudflare — vérification clé et piège API
+
+**Date** : 17/09/2026
+**Contexte** : suite tuto YouTube "exécuter de grands modèles IA gratuitement via Kaggle" — notebook Kaggle GPU T4x2 + Ollama + tunnel Cloudflare rapide, pour exposer un LLM (choisi : Qwen3.6-27B-AEON-Ultimate-Uncensored-MTP, fine-tune communautaire non officiel base Qwen 3.6).
+
+## Clé Kaggle — localisation et vérification
+- Clé stockée dans `/volume1/docker/.claude/API_KEY.env` (propriétaire Best0f, permissions 600) sous `KAGGLE_API_KEY=KGAT_...`.
+- Format : token Bearer unique (nouveau système Kaggle, ne nécessite plus `KAGGLE_USERNAME` associé).
+- **Méthode de vérification fiable** : `GET https://www.kaggle.com/api/v1/competitions/list?group=entered` avec header `Authorization: Bearer <token>`. Retourne HTTP 200 (liste vide ou non) si le token est valide, HTTP 401 `{"code":401,"message":"Unauthenticated"}` si invalide. Utile comme test de santé générique de la clé.
+- Lister ses propres kernels : `GET /api/v1/kernels/list?group=profile` (le paramètre `mine=true` utilisé dans la doc/exemples historiques renvoie une erreur 400 "Invalid field" sur la version actuelle de l'API — piège documentaire, `group=profile` est le paramètre qui fonctionne).
+
+## Piège majeur découvert : notebooks lancés à la main = invisibles pour l'API
+Le kernel `nabilderouiche/notebook91770f3cc0`, exécuté interactivement depuis l'éditeur web Kaggle (Run manuel dans le navigateur, pas via `kaggle kernels push`), retourne `404 "No runs found for this kernel."` sur `GET /api/v1/kernels/status`. **L'API Kaggle ne trace un run consultable (status, logs, output) que pour les kernels déclenchés via l'API elle-même** (`kaggle kernels push` avec un `kernel-metadata.json`), pas pour un Run cliqué dans le navigateur.
+
+Conséquence directe : impossible d'automatiser la récupération de l'URL du tunnel Cloudflare (générée dans les logs du notebook à chaque run) sans d'abord faire basculer le fonctionnement du notebook cliqué-à-la-main vers un kernel versionné poussé/déclenché via l'API.
+
+## Limites structurelles (indépendantes de toute automatisation)
+- Quota GPU gratuit Kaggle : ~30h/semaine, exécution continue plafonnée (~9-12h par session).
+- Tunnel Cloudflare "rapide" (`cloudflared tunnel --url`) génère une URL aléatoire à chaque redémarrage — aucune stabilité d'adresse possible avec ce mode de tunnel.
+- Aucune authentification réelle côté endpoint exposé (le tuto utilise le placeholder `Ollama` comme "clé API").
+- Usage prolongé comme service d'inférence externe permanent sort du cadre d'usage prévu par Kaggle (notebooks interactifs, pas hébergement/proxy) — risque sur le compte vérifié par téléphone.
+
+**Conclusion** : ce montage reste utilisable en rafale ponctuelle (test lourd occasionnel), pas comme provider stable dans Bifrost au même titre que la convention -OC/-OR/-GQ/-NV déjà en place.
+
+## À noter au passage
+- `claude-ops` (compte NAS scopé, uid 1040) dispose d'un `sudo -n` (sans mot de passe) qui lui permet de lire des fichiers 600 appartenant à Best0f dans `/volume1/docker/.claude/` — contourne partiellement l'isolation prévue par la création des comptes scopés (voir historique gemini-ops/claude-code-ops). À signaler, pas corrigé ici.
+- Token Gitea `bolbol` fonctionnel en HTTPS via `gitea.bolbol.tn` (port 443 standard, **pas** le port 3232 qui timeout en accès direct — 3232 semble réservé au réseau interne docker/n8n).