En bref

Migration progressive de Grav CMS vers Hugo — un générateur de site statique. L’objectif est d’isoler Hugo dans une VM KVM dédiée sur le NUC8i3BEH, avec nginx sur le host en proxy inverse. Le site statique généré est servi par nginx dans la VM, sans PHP, sans base de données, sans surface d’attaque applicative.

• 🖥️ Host : NUC8i3BEH Ubuntu 24.04 — nginx proxy + KVM
• 🗄️ Disque VM : NVMe externe Samsung X5 (exFAT → image ext4 loop)
• 🌐 Accès : hugo-test.arleo.eu
• 🎨 Thème : LoveIt

🧠 Pourquoi

Grav CMS est excellent mais repose sur PHP — une surface d’attaque non négligeable. Hugo génère du HTML statique pur : zéro PHP, zéro base de données, zéro vulnérabilité applicative. Les performances sont aussi radicalement meilleures — le HTML est servi directement par nginx sans traitement dynamique.

En bref

Connecter Claude.ai à son site Grav en 30 minutes : un plugin PHP expose 9 outils (lire, créer, modifier, supprimer des pages, gérer les plugins) via JSON-RPC 2.0, un proxy FastAPI gère l’authentification OAuth 2.1, et nginx fait le pont entre Internet et le homelab. Résultat : Claude peut lire et modifier le contenu du site directement depuis une conversation.

Le code est disponible sur GitHub :

• 🔌 Plugin Grav : jmrGrav/grav-plugin-mcp-server
• 🔐 Proxy OAuth : jmrGrav/mcp-oauth-proxy

Après la migration du site vers Hugo, l’évolution de cette architecture est documentée dans Hugo MCP Server : connecter Claude.ai à Hugo.

En bref

Après le plugin IndexNow (Bing/Yandex), ce second plugin complète le pipeline SEO en soumettant les pages modifiées directement à l’API Google Indexing — sans dépendance Composer, avec un JWT RS256 signé en PHP pur à partir d’un service account Google Cloud.

Le code est disponible sur GitHub :

• 🔌 Plugin : jmrGrav/grav-plugin-google-indexing

🧠 Pourquoi

IndexNow couvre Bing et Yandex, mais Google ne supporte pas IndexNow. Pour notifier Google instantanément, il faut passer par son API dédiée : Google Indexing API v3.

En bref

Grav ne dispose d’aucun plugin IndexNow dans son catalogue officiel. Ce plugin maison comble ce manque en soumettant automatiquement les URLs modifiées à api.indexnow.org à chaque sauvegarde — que ce soit via l’admin Grav ou via le plugin MCP — sans intervention manuelle, sans cron, sans dépendance externe.

Le code est disponible sur GitHub :

• 🔌 Plugin : jmrGrav/grav-plugin-indexnow

Pour Google, qui ne prend pas en charge IndexNow, le complément est le plugin Grav Google Indexing.

En bref

Le pipeline Vector initial inondait BetterStack de ~500 events/24h, dont 434 pulls CAPI sans valeur de supervision locale. Ce travail reconfigure le filtre Vector pour ne garder que les bans à haute valeur (cscli) et corrige un angle mort majeur : les bans effectifs du bouncer nginx-lua n’apparaissaient nulle part dans BetterStack.

🧠 Pourquoi

La stack de sécurité repose sur trois composants qui travaillent ensemble :

• nginx avec le bouncer lua CrowdSec (lua-resty-crowdsec) qui bloque les requêtes en temps réel
• CrowdSec pour la détection et la gestion des décisions de ban
• Vector qui centralise les logs vers BetterStack pour la supervision

Après avoir mis en place le pipeline initial, deux problèmes sont apparus rapidement. D’abord, le signal était noyé dans le bruit : sur 500 events/24h, 434 venaient du pull CAPI communautaire horaire et 66 des listes tierces — ni les uns ni les autres ne représentent une menace détectée sur cette infrastructure. Ensuite, les bans effectifs du bouncer lua (blocages en temps réel dans nginx) n’apparaissaient nulle part dans BetterStack, ce qui créait un angle mort sur l’activité de sécurité réelle.

En bref

La CSP initiale listait 46 hashes SHA-256 pour couvrir les scripts et styles inline — ingérable, fragile, et à la limite des 4 096 caractères de Cloudflare. Cette migration vers des nonces dynamiques réduit la CSP à ~600 caractères, supprime toute maintenance manuelle des hashes, et ajoute un reporting structuré des violations dans BetterStack.

Le plugin Grav utilisé est disponible sur GitHub : 🔌 Plugin : jmrGrav/grav-plugin-csp-nonce

🧠 Pourquoi

Quand on implémente une Content Security Policy stricte sur un site Grav CMS servi via Cloudflare, l’approche naïve consiste à lister les hashes SHA-256 de chaque script inline. C’est fonctionnel, mais ça devient vite ingérable. Plusieurs problèmes cumulés :