deploy: addendum token gitea + panne ssh memory-sync (infra-2026-09-040)

This commit is contained in:
Claude
2026-09-11 06:16:15 +00:00
parent 26bef7d530
commit b11fc34435
@@ -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, Aucun. Les 5 assistants cites par Nabil (Hermes NAS x3, hermes-nabil VPS, DSH,
openclaw-perso, opencode natif VPS) sont confirmes fonctionnels sur openclaw-perso, opencode natif VPS) sont confirmes fonctionnels sur
deepseek-v4.1-flash au 11/09/2026. 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.