nas-runbooks/hermes-perso/formation-consultant.md

formation-consultant — site de formation autodidacte perso

Date de creation : 25/07/2026 Sphere : perso (aucune donnee TT ou Nyora business)

Objectif

Site web personnel accompagnant le parcours de certification autodidacte "Solution Consultant" (3 phases : Google GenAI / IREB exigences / IIBA ECBA business analysis), a consulter avant l'arrivee du MacBook. Phase 1 (Google GenAI) entierement peuplee, Phase 2/3 a construire au fil des sessions Claude suivantes.

Stack

• Conteneur unique formation-consultant : nginx:alpine, statique (index.html + style.css + app.js)
• Port 8801->80, reseau docker n8n, restart unless-stopped
• Basic Auth au niveau nginx (.htpasswd, utilisateur nabil) — le mot de passe genere vit uniquement dans /volume1/docker/formation-consultant/auth/.pw-generated-once.txt sur le NAS, jamais pousse sur Gitea
• Repo Gitea : bolbol/formation-consultant (prive) — contient site/, docker-compose.yml, nginx.conf. Le dossier auth/ (htpasswd + mot de passe) reste local au NAS uniquement.

Deploiement (deja fait le 25/07/2026)

cd /volume1/docker/formation-consultant
docker compose up -d

Etape manuelle restante — reverse-proxy DSM

Le conteneur n'est pas encore joignable sur formation.bolbol.tn : la creation du vhost DSM necessite un acces root que le compte Best0f (utilise via mcp-nas) n'a pas (sudo demande un mdp, claude-ops NOPASSWD n'a pas de cle presente dans ce container). Meme pattern deja rencontre pour cin-search-tt (ports-registry.md note deja "reverse-proxy DSM a creer manuellement").

A faire une fois dans DSM > Panneau de configuration > Portail de connexion > Avance > Proxy inverse :

• Nom : formation-consultant
• Source : HTTPS, formation.bolbol.tn, port 443
• Destination : HTTP, localhost (ou 127.0.0.1), port 8801

Le certificat wildcard *.bolbol.tn existant couvre deja ce sous-domaine (pas de nouveau certificat a generer). Le DNS bolbol.tn est deja wildcard (aucune entree pihole/OVH specifique necessaire, confirme par l'absence d'entree custom.list pour les autres sous-domaines).

Mise a jour du contenu (sessions suivantes)

Le contenu HTML est genere depuis un pipeline pandoc (markdown -> HTML) construit hors-NAS, puis pousse directement sur Gitea via l'API contents (POST, pas PUT tant que le fichier n'existe pas ; PUT + sha pour mise a jour), puis recupere sur le NAS via curl sur l'endpoint raw interne (http://172.17.0.1:3232/api/v1/repos/bolbol/formation-consultant/raw/site/<fichier>). Cette methode evite le transfert manuel par heredoc (teste, beaucoup plus fiable pour des fichiers de plusieurs dizaines de Ko contenant des caracteres accentues).

Lecons

• Le fichier /usr/syno/etc/www/ReverseProxy.json est lisible par Best0f mais pas modifiable (proprietaire root, 644) : toute creation de vhost DSM reste une etape manuelle tant qu'un acces root (ou la cle SSH claude-ops) n'est pas disponible dans le container mcp-nas.
• Transferer du contenu volumineux vers le NAS via heredoc mcp-nas est lent et fragile (risque de troncature/erreur de recopie). Passer par Gitea (accessible publiquement en HTTPS sur gitea.bolbol.tn) comme relais est nettement plus fiable : push depuis l'environnement source via l'API contents publique, pull sur le NAS via l'API interne.
• GITEA_TOKEN_TT a un scope suffisant pour creer un repo (write:repository implicite), mais GITEA_TOKEN_PERSO/GITEA_TOKEN_NYORA non — a verifier/harmoniser si la creation de repos perso redevient necessaire.