From 3afcc6c78eb85a13a4d52529d185ee9d6c2d29ed Mon Sep 17 00:00:00 2001 From: Nabil Date: Thu, 13 Aug 2026 15:29:42 +0000 Subject: [PATCH] =?UTF-8?q?runbook:=20addendum=203=20=E2=80=94=20decouplag?= =?UTF-8?q?e=20credentials=20hermes-nabil=20du=20miroir=20memory-node=20(d?= =?UTF-8?q?isaster-recovery=20!=3D=20auth=20operationnelle)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...ewall-nyora-notes-onboarding-13-08-2026.md | 21 +++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/common/tailscale-firewall-nyora-notes-onboarding-13-08-2026.md b/common/tailscale-firewall-nyora-notes-onboarding-13-08-2026.md index 27571aa..b86e5be 100644 --- a/common/tailscale-firewall-nyora-notes-onboarding-13-08-2026.md +++ b/common/tailscale-firewall-nyora-notes-onboarding-13-08-2026.md @@ -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= +``` + +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.