From b11fc344354e1a897b08183e95c18a383fffacc7 Mon Sep 17 00:00:00 2001 From: Claude Date: Fri, 11 Sep 2026 06:16:15 +0000 Subject: [PATCH] deploy: addendum token gitea + panne ssh memory-sync (infra-2026-09-040) --- ...blocage-whitelist-multiniveaux-20260911.md | 45 +++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/common/deepseek-v41-flash-deblocage-whitelist-multiniveaux-20260911.md b/common/deepseek-v41-flash-deblocage-whitelist-multiniveaux-20260911.md index c101f0f..f20a8d2 100644 --- a/common/deepseek-v41-flash-deblocage-whitelist-multiniveaux-20260911.md +++ b/common/deepseek-v41-flash-deblocage-whitelist-multiniveaux-20260911.md @@ -94,3 +94,48 @@ si la cle est valide — a ne pas confondre avec un vrai probleme de VK. Aucun. Les 5 assistants cites par Nabil (Hermes NAS x3, hermes-nabil VPS, DSH, openclaw-perso, opencode natif VPS) sont confirmes fonctionnels sur deepseek-v4.1-flash au 11/09/2026. + +## Addendum 11/09/2026 — token Gitea expiré + panne SSH memory-sync decouverte + +En corrigeant le token Gitea `bolbol` expire (signale en fin de premiere session), +deux choses distinctes ont ete trouvees et traitees : + +1. **Token sur le miroir reel** : le clone de travail avait ete corrige, mais + pas le miroir bare que le cron `memory-sync.sh` utilise reellement + (`/opt/memory-node/git/nas-runbooks.git` sur le VPS, proprietaire + `claude-oversight`). Corrige et confirme via l'execution cron reelle de + 03:17 (`354361f..26bef7d main -> main`). + +2. **Panne SSH decouverte au passage** : le meme script echouait depuis un + moment sur 100% des runs (`Best0f@100.86.197.88: Permission denied + (publickey,password)`) pour le volet rsync (nyora-notes + context-hub). + Cause : consequence collaterale du verrouillage progressif de l'acces + `Best0f` (migration vers comptes scopes claude-ops/gemini-ops/claude-code-ops, + voir memoire `gemini-ops-access`) — ce script n'avait jamais ete migre. + + Fix : `memory-sync.sh` repointe sur `claude-ops@NAS`. Cle publique + `claude-oversight@vps-memory-node` (deja utilisee, identity file existant) + ajoutee a `authorized_keys` de `claude-ops` sur le NAS, avec **forced + command** restreignant strictement a `rsync --server --sender` en lecture + seule sur `/volume1/docker/nyora-notes/` et `/volume1/docker/context-hub/` + uniquement (aucun shell, `no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding`). + Backups : `authorized_keys.bak-20260911-ajout-cle-memory-node`, + `memory-sync.sh.bak-20260911`. + + Verifie : `context-hub` synchronise integralement et a jour. + +## Reste ouvert (nouveau, 11/09/2026) + +`nyora-notes` bloque uniquement sur un sous-dossier isole, +`/volume1/docker/nyora-notes/app` (mode `700`, proprietaire uid 1026 — +seul dossier de toute l'arborescence hors de la convention `755` du reste). +Ni `claude-ops` (non proprietaire) ni le root conteneurise de `mcp-nas` +(`Operation not permitted` malgre `uid=0` — la couche de permission Synology +bloque meme le root du container) ne peuvent corriger ce mode. + +**Action Nabil requise (une seule commande, en root ou via Best0f)** : +``` +chmod -R g+rX /volume1/docker/nyora-notes/app +``` +Puis le prochain run horaire (`:17`) se synchronisera tout seul, rien d'autre +a faire.