TL;DR
Un inventaire en lecture seule de l'écosystème VFG a été livré (85 dépôts GitHub, 67 dépôts locaux, 30 conteneurs VPS, 33 sous-domaines testés). En parallèle, la mission « publier la lettre 004 JahStyle sur blog.vfg.lol » est arrivée à son point de décision : le workflow de déploiement de vfg-system ne vise pas le service qui sert le blog aujourd'hui. Poser la cible sans accord écraserait un site en production. On mesure, on documente, on attend le GO.
Ce que l'inventaire a mesuré
L'inventaire couvre sept volets, chacun appuyé sur une commande rejouable :
- repos GitHub de l'organisation (visibilité, archivage, fork, langage) ;
- dépôts locaux (remote, branche, dernier commit, fichiers sensibles versionnés — chemins uniquement) ;
- services locaux en écoute et leurs processus ;
- VPS en lecture seule : conteneurs, hôtes Caddy et leurs amonts, services systemd ;
- sous-domaines testés en HTTP ;
- exposition éventuelle de points MCP sans authentification ;
- pages de graphes Logseq.
Deux points sont ressortis à la mesure :
crt.shrenvoyait HTTP 502 — la liste des sous-domaines a donc été dérivée des hôtes Caddy lus sur le VPS, pas d'une source externe.dockerétait absent en local ; les conteneurs n'ont été observés que sur le VPS, en lecture seule.
Aucune valeur de secret n'a été recopiée : seuls des chemins de fichiers sensibles apparaissent dans le rapport d'anomalies.
La vraie question : quel service sert blog.vfg.lol ?
Trois cibles distinctes coexistent, et les confondre serait l'erreur :
| Élément | Rôle observé |
|---|---|
blog.vfg.lol (public) | proxifié par Caddy vers :5195 (par défaut) et :5220 (sous /admin) |
service :5195 | blog-read.service → app Node « Gazette — blog.vfg.lol » (SPA + API dynamique), dossier de service dédié, fichier d'environnement dédié |
service :5220 | blog-admin.service → API admin du même service (un second service admin concurrent existe sur le même port) |
| conteneur nginx « blog-static » | sert un dossier statique, mais n'est pas sur le chemin public du blog |
workflow Deploy de vfg-system | construit un site/ statique (7 apps) puis rsync vers une cible fournie par secrets |
Autrement dit : le déploiement de vfg-system livre du statique, tandis que le blog est servi par une application Node dynamique. Viser le dossier de cette application avec --delete écraserait le service en production. C'est exactement le risque que la consigne « ne pas pointer sans GO » protégeait.
Trois issues sont possibles, et elles appartiennent à une décision humaine (gate R3) :
- Cible dédiée hors du dossier servi : déployer le statique dans un sous-dossier prévu, sans
--deletesur la racine de l'app. - Remplacer le service actuel par le site statique et repointer l'hôte public — changement de service en production.
- Coexister : servir le site construit ailleurs, ou brancher le build sur le service existant — décision d'architecture.
État de la mission
vfg-system: 0 secret posé. Le step rsync du workflow est conditionné à la présence de l'hôte de déploiement ; sans lui, il est ignoré (le run reste vert, sans publier).- Run de déploiement le plus récent : succès, mais uniquement build + artefact ; l'étape rsync n'a pas tourné.
mainporte bien le merge de la lettre 004 ; le commit local de la branche de travail, lui, n'est pas encore surmain.- Vérifications en ligne : le blog répond 200, l'image attendue renvoie 404, la lettre n'est pas visible.
Reste à faire
- Trancher la cible (sous-dossier dédié, remplacer le service, ou coexister).
- Poser les secrets de déploiement correspondants.
- Relancer le workflow, surveiller le run, puis vérifier : rsync effectif, image servie (≠ 404), lettre visible.
Règles tenues
Aucun hôte ni clé inventé, aucune variable d'environnement de production touchée, aucun force-push. Chaque constat est daté et rejouable ; ce qui n'a pas été mesuré est marqué comme tel.