runbook: addendum 3 — decouplage credentials hermes-nabil du miroir memory-node (disaster-recovery != auth operationnelle)

2026-08-13 15:29:42 +00:00
parent ab055f8b1a
commit 3afcc6c78e
1 changed files with 21 additions and 0 deletions
@@ -128,3 +128,24 @@ Suite a la demande explicite de tout resoudre sans rien laisser trainer.
 **Secret en dur retire (trouvaille de securite)** : `generate-infra-index.py` et `.sh` contenaient le mot de passe SSH Best0f en clair (`SSHPASS="..."` hardcode), deja expose dans l'historique git sous une ancienne valeur (`2L2u519w@ommi`, rotee depuis vers la valeur actuelle). Remplace par lecture `BEST0F_SSH_PASS` (variable d'environnement, avec repli sur `nyora-notes/.env` si absente — ces scripts tournent hors conteneur, sans dotenv, et n'ont pas de tache planifiee identifiee dans le Task Scheduler DSM ni dans une crontab, execution probablement manuelle depuis mcp-nas). Valeur ajoutee dans `.env` (gitignore, jamais commit). L'ancienne valeur exposee dans l'historique n'a pas ete purgee (rewrite d'historique juge disproportionne pour un secret deja rote et un repo Gitea prive sans autre acces) — a signaler si une politique de purge d'historique est un jour mise en place (cf. `common/rotation-secrets-inventaire.md`).

 **Verification finale** : conteneur `nyora-notes` sain (`healthy`) apres toutes les operations — uniquement des refs git et deux fichiers hors execution (scripts de maintenance, jamais importes par l'application) touches, zero redemarrage necessaire.
+
+---
+
+## Addendum 3 — 13/08/2026 — decouplage credentials hermes-nabil / miroir memory-node
+
+Question posee : ou hermes-nabil (VPS) trouve-t-il son token NyoraNotes ?
+
+**Constat** : le token etait bien present sur le VPS, mais uniquement via effet de bord du miroir `/mnt/memory-node` (rsync horaire PULL, cf. `common/vps-memory-node.md`, Objectif A = survie au swap HDD du NAS). Ce miroir exclut `.env` et `*.bak` mais pas `*.token` — coincidence de scope, pas conception.
+
+**Pourquoi ne pas s'appuyer dessus** : le miroir memory-node est un mecanisme de reprise apres sinistre, cense rester dormant. Le durcissement naturel de ce genre de backup (exclure aussi `*.token`, une bonne pratique de securite) aurait casse l'authentification hermes-nabil silencieusement, sans lien evident avec la cause. Coupler un besoin operationnel courant a un mecanisme de secours est une fragilite cachee — exactement le type de probleme traite plus haut dans ce runbook (branches, pollution, secret en dur).
+
+**Solution** : credentials dediees, independantes du miroir — `/root/.hermes-nabil/nyora-notes.env` (chmod 700/600) sur le VPS :
+
+```
+NYORA_NOTES_URL=http://100.86.197.88:8787
+NYORA_NOTES_TOKEN=<token hermes-nabil>
+```
+
+Bundle volontairement l'URL (IP Tailscale du NAS, PAS 192.168.100.33 — LAN inaccessible depuis le VPS) et le token dans le meme fichier, pour qu'une session n'ait qu'un seul endroit a lire. Teste bout-en-bout (POST + DELETE reels sur NyoraNotes) apres creation — fonctionne independamment de l'etat du miroir memory-node.
+
+**A considerer plus tard (hors perimetre de cette session)** : durcir le rsync de memory-node pour exclure `*.token` desormais que plus rien n'en depend — amelioration de securite legitime sur le miroir de secours, mais touche un systeme different (cron + cle SSH forced-command + utilisateur claude-oversight) qui n'a pas ete audite ici.