STATUS — vps-rescue-scripts — 2026-10-08

STATUS — vps-rescue-scripts

Article généré automatiquement depuis le STATUS.md de vps-rescue-scripts — 2026-10-08. Les chemins locaux, les hôtes internes et les noms de variables ont été neutralisés.

STATUS — vps-rescue-scripts

• Tier : _prod
• Dernière MAJ : 2026-09-20 (contrôle de dérive blog + diagnostic déploiement)
• Scripts : 6 scripts de sauvetage VPS
• Sécurité : .gitignore credentials/clés SSH, règle 12 respectée

Scripts disponibles

2026-09-20 — contrôle de dérive du blog

Contexte. Le workflow GitHub code-deploy déployait le code du blog vers [chemin serveur] (vestige de l'export statique v1, root:root, non référencé par Caddy) au lieu de [chemin serveur], le WorkingDirectory des units blog-read/blog-admin. Résultat : 30 éxécutions sur 30 en échec au rsync (Permission denied, exit 23), sans qu'aucun contrôle ne le signale. La prod est restée des mois sur une copie antérieure du code — symptômes : /arbre/ en 404, flux RSS figés.

Ajout au healthcheck (section 6) :

• les units blog-read/blog-admin sont vérifiées (actives, WorkingDirectory attendu) ;
• :5195/healthz doit répondre 200 ;
• :5195/arbre/ doit répondre 200 — un 404 n'est pas « une route absente » mais « le service sert une copie antérieure du code ». C'est le contrôle qui manquait ;
• [chemin serveur] est signalé comme vestige s'il existe encore ;
• un flux RSS non régénéré depuis > 30 jours déclenche un avertissement (la publication ou son hook generate-rss ne fonctionne plus).

Vérifié sur le VPS (2026-09-20) : le script détecte correctement la dérive réelle (EXIT=1, /arbre/ 404, flux RSS figé depuis 65 jours) — donc il échouera tant que la correction du déploiement n'est pas en production, ce qui est le comportement attendu.

Correctif côté blog : voir la PR RAPPORT-EXPERIENTIEL #78 (variable BLOG_CODE_DEPLOY_PATH, redémarrage sans sudo, garde anti-dérive). Documentation d'inventaire : vps-infra/docs/vps-inventory/services-systemd.md.

Mise à jour — le déploiement est réparé (2026-09-20, soir)

Le correctif a été fusionné dans main : code-deploy est passé success pour la première fois, /arbre/ répond 200 en production et les flux RSS sont de nouveau frais (538 items, jusqu'au 18/09, contre 12/07 gelé). Le healthcheck devrait donc passer désormais — à confirmer à la prochaine exécution.

Le premier rsync réussi a aussi révélé deux bugs latents (exclusions non ancrées ayant laissé 9 index.html hors du VPS, d'où /bibliotheque/ en 404 ; npm ci lançant prepublish sur le serveur). Les deux sont corrigés, et /bibliotheque/ a été restauré.

Leçon pour ce script : le contrôle /arbre/ a bien fonctionné — il signalait une panne réelle que rien d'autre ne voyait. Un healthcheck qui échoue sur la vraie panne qu'il est censé attraper est un healthcheck qui marche.

Documentation

• README-SAUVETAGE.md — guide complet de sauvetage VPS (mode rescue, Webmin, Tailscale)
• BACKLOG.md — backlog de sécurisation VPS (51.77.244.222)
• AUDIT-2026-06-26.md — audit de sécurité du 26/06
• HANDOFF-2026-06-26.md — handoff de passation
• 00-URGENT-A-FAIRE-MAINTENANT.txt — actions urgentes

Vérification 2026-07-05

Scripts vérifiés en lecture seule (aucune commande destructive exécutée) :

• Tous les scripts sont en bash, compatibles Debian/Ubuntu
• Les chemins référencés (/mnt, /dev/sda*, tailscale, webmin) sont standards
• Aucune commande destructive non protégée détectée
• Le guide README-SAUVETAGE.md couvre : mode rescue, montage partition, LVM, chroot, Webmin, Tailscale, 2FA

Généré le 2026-07-05 par l'agent A13 (Vague 3).