nas-runbooks/common/cin-search-tt-migration-docker.md

# Migration cin-search-tt : hors-Docker vers Docker + SMTP OVH -> Infomaniak

## Contexte
Le 10/07/2026, Nabil signale que la migration SMTP globale vers Infomaniak (faite la veille)
n'a pas couvert cin-search-tt car cette app tournait en dehors de la stack Docker, dans
/volume1/web/cin-search-tt (Node.js standalone, jamais containerise).

Audit etendu a tout /volume1/web/ : 4 apps Node y etaient hebergees hors-Docker.

## Etat trouve
| App | Etat | Action |
|---|---|---|
| cin-search-tt | SMTP sur ssl0.ovh.net, Baserow sur ancien alias nd.i234.me, jamais dockerise | Migre vers Docker |
| rla | Copie **obsolete** — la vraie version tourne deja proprement dans /volume1/docker/rla-api (Gotenberg/pptx-tt-api deja purges le 04/07) | Archivee (doublon perime) |
| club-ia | Projet termine (jamais deploye en prod) | Archivee |
| weblinks | Page HTML statique simple, aucune dependance | Conservee en l'etat dans /volume1/web |

## Actions effectuees — cin-search-tt
1. Copie du code (hors node_modules/zip) vers /volume1/docker/cin-search-tt
2. `.env` corrige :
   - SMTP_HOST ssl0.ovh.net -> mail.infomaniak.com (port 587, STARTTLS, meme compte nabil.derouiche@ik.me que Baserow/Vaultwarden)
   - BASEROW_API_URL https://baserow.nd.i234.me -> https://baserow.bolbol.tn (alias reseau Docker, regle absolue)
3. Dockerfile ecrit (node:20-alpine, npm install --omit=dev)
4. Image buildee via API Docker de Portainer (`POST /api/endpoints/2/docker/build` avec tar de contexte) car `docker` CLI absent du container mcp-nas (hardening 08/07)
5. Stack deploye via API Portainer (`POST /api/stacks/create/standalone/string`) — **pas de `env_file:`** dans le compose (Portainer ne voit pas les chemins hote arbitraires), variables passees en `environment:` inline a la place
6. Container `cin-search-tt` : port 3094->3000, reseau `n8n`, volume `/volume1/docker/cin-search-tt/data:/app/data` (persistance database.json)
7. `ports-registry.md` mis a jour (edite via un container alpine ephemere + bind mount, car le fichier appartient a uid 1026 et mcp-nas n'a plus CAP_DAC_OVERRIDE)
8. Reverse-proxy DSM `cin.bolbol.tn` -> `localhost:3094` **NON fait** (hors scope API/Docker, a faire manuellement dans DSM Control Panel)
9. Anciens dossiers archives dans `/volume1/web/.archive/` : `cin-search-tt.archived-20260710-migrated-to-docker`, `rla.archived-20260710-obsolete-superseded-by-docker-rla-api`, `club-ia.archived-20260710`

## Pieges decouverts (a capitaliser)
- **mcp-nas ne peut pas lancer `docker`/`docker compose` directement** (binaire absent, SSH host indisponible depuis le hardening). Solution : API REST Portainer (`/api/endpoints/{id}/docker/build` pour build, `/api/stacks/create/standalone/string` pour deploy).
- **Portainer ne resout pas `env_file:` avec un chemin hote** dans un stack deploye par API string — le moteur compose de Portainer tourne dans son propre filesystem (`/data/compose/<id>/`), pas celui de l'hote. Toujours utiliser `environment:` inline pour les stacks deployes ainsi.
- **Volume bind mounts en chemin absolu hote fonctionnent normalement** (resolus par le daemon Docker, pas par Portainer) — contrairement a `env_file:`.
- **Ecriture de fichiers appartenant a uid 1026 depuis mcp-nas (root) : impossible**, meme en root, a cause de `cap_drop: [ALL]` (pas de CAP_DAC_OVERRIDE). Contournement : creer un container ephemere (alpine) avec bind mount du dossier concerne via l'API Portainer, executer la commande d'ecriture dedans en root reel (container non-hardened), puis le supprimer.
- **Token Gitea `GITEA_DEPLOY_TOKEN` n'a pas le scope `write:organization` ni `read:user`** — peut lire/ecrire du contenu de repos existants, mais pas creer de nouveaux repos ni lister les users/orgs. Creation de nouveaux repos = a faire manuellement dans l'UI Gitea.
- **`/volume1/docker/ports-registry.md` n'est pas versionne dans Gitea** (pas de `.git` a la racine de `/volume1/docker`) — mise a jour uniquement in-place sur le NAS.

## Reste a faire (hors scope automatisable)
- Creer la regle reverse-proxy DSM `cin.bolbol.tn` -> `localhost:3094`
- Creer le repo Gitea `bolbol/cin-search-tt` manuellement (token actuel insuffisant) et y pousser le code

## Correctif post-deploiement (10/07/2026, meme session)

Nabil a signale "Echec de l'envoi email" apres mise en prod. Deux bugs distincts trouves via les logs container :

1. **SMTP code en dur dans server.js** — le transporter nodemailer n'utilisait PAS `config.smtp`
   (qui lit le `.env`) mais des valeurs litterales : `host: 'ssl0.ovh.net'`, `user: 'contact@bolbol.tn'`,
   `pass: '2L2u519wbolbol'`. Corriger le `.env` seul ne changeait donc rien. Patch : les 3 champs
   (host/port/secure/auth) passes en `process.env.SMTP_*`. Le `From` des 2 `sendMail()` (etait
   `contact@bolbol.tn`, adresse OVH desormais coupee) change pour `nabil.derouiche@ik.me` —
   **Infomaniak rejette un From qui ne correspond pas au compte authentifie** (meme contrainte
   deja documentee pour Baserow/Vaultwarden).
2. **BASEROW_API_URL en https:// echouait en interne** (`ECONNREFUSED 172.27.x.x:443`) —
   sur le reseau Docker `n8n`, l'alias `baserow.bolbol.tn` resout directement vers le container
   Baserow qui n'ecoute qu'en HTTP (port 80, cf. `ports-registry.md` : `3888->80`). Pas de TLS
   en interne. Corrige en `http://baserow.bolbol.tn`.

**Piege a capitaliser** : toujours verifier qu'un service qui lit un `.env` via `config.js`
utilise vraiment ce module partout — un `require('dotenv').config()` en tete de fichier
n'empeche pas des valeurs codees en dur ailleurs dans le meme fichier. Grep systematique
sur host/user/pass/api url avant toute migration de credentials.

**Piege reseau** : `https://<alias>.bolbol.tn` ne fonctionne QUE depuis l'exterieur (WAN) ou
un service hors du reseau Docker `n8n` (TLS termine par le reverse-proxy DSM). Un container
sur le meme reseau `n8n` qu'un alias doit taper en `http://` sur le port interne reel du
service cible (verifier `ports-registry.md`), jamais supposer que le HTTPS est disponible
en interne.