126 plikow (md, yaml, sh, py) odwolywalo sie do sciezek sprzed migracji.
15 markdown-linkow [..](..) -> policzona sciezka WZGLEDNA wobec pliku
odsylajacego (wczesniej czesc z nich byla repo-root-relative i nie
rozwiazywala sie z katalogu, w ktorym lezala)
200 odwolan tekstowych (backticki, proza, yaml, importy w kodzie)
-> nowa sciezka repo-root-relative, zgodnie z konwencja repo
5 linkow rodzenstwa (gole nazwy plikow, np. "](DEPLOY.md)") — dzialaly
tylko w starym katalogu; przeliczone recznie
Objete m.in.: CLAUDE.md (scripts/onboard/README.md -> kb/runbooks/
node-onboarding-tool.md, docs/backlog.md -> kb/phases/backlog.md),
README.md, .claude/skills/, 20 session logow, kod jobow.
Ostatnie 5 odwolan pochodzi z tresci wciagnietej rebasem z origin/master
(session log 2026-07-31, override node-agenta na SOLARII, dwie pozycje
backlogu) — wskazywaly na docs/incidents/, docs/kb/modules/ i
services/narty27/README.md sprzed migracji.
Dodany wzajemny link miedzy kb/services/control-plane.md (stub kodu)
a kb/subsystems/control-plane.md (opis, deprecated) — dwa dokumenty o tym
samym systemie, latwe do pomylenia.
Weryfikacja na 790 plikach: 0 odwolan do starych sciezek,
0 martwych linkow markdown. Lint OKF: 190/190 plikow ZGODNE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.5 KiB
2.5 KiB
| okf | type | visibility | status | updated | links | |
|---|---|---|---|---|---|---|
| 0.1 | runbook | private | active | 2026-07-12 |
|
Paperless OCR worker — NFS i cutover
NFS: export na PIHA, mount na SOLARIA
Transfer idzie po LAN (PIHA 192.168.31.5 ↔ SOLARIA 192.168.31.70,
1 Gb/s, ten sam switch) — NIE po Tailscale. Przepustowość nie jest wąskim
gardłem OCR.
Host-side na PIHA (NIE w compose — krok przy deployu modułu 3)
# /etc/exports na PIHA — export TYLKO dla SOLARII:
/opt/homelab/data/paperless 192.168.31.70(rw,sync,no_subtree_check,no_root_squash)
sudo apt install nfs-kernel-server # jesli brak
sudo exportfs -ra
no_root_squash jest potrzebne, bo entrypoint obrazu (root) robi chown na
katalogach przy starcie kontenera na SOLARII; export jest ograniczony do
jednego IP w zaufanym LAN.
Strona SOLARII
Mounty definiuje compose jako named volumes z driverem NFS — zero wpisów w /etc/fstab; jedyny host-side wymóg to pakiet klienta:
sudo apt install nfs-common
UID mapping (krytyczne)
Pliki na exporcie mają numerycznego właściciela — NFS nie tłumaczy nazw.
Dlatego USERMAP_UID/GID=1000 jest ustawione w obu compose (PIHA
i SOLARIA); zmiana po jednej stronie = worker traci dostęp do plików.
Weryfikacja po deployu: ./healthcheck.sh robi test zapisu na mount.
Cutover checklist (przy deployu modułu 3 — po działającym module 2)
- ✅
services/paperless/działa na PIHA (healthcheck zielony). - ✅ Export NFS na PIHA (wyżej) +
showmount -e 192.168.31.5z SOLARII. - ✅
nfs-commonna SOLARII. - ✅
.envzenv.example— sekrety SKOPIOWANE z PIHA, nie nowe. - ✅
docker compose up -d+./healthcheck.sh. - ✅ Test (2026-07-12): PDF-y wrzucone do consume na PIHA, część odebrana i dokończona przez worker@SOLARIA (dowód w logach, zero File not found).
- ⬜ Test fallbacku: stop workera → zadanie czeka/mieli PIHA → start → drenaż (jeszcze niewykonany formalnie, ale mechanizm nie zmienił się tym fixem — fallback na PIHA działał już wcześniej, patrz sekcja "Fallback" wyżej).
- ⬜ OTWARTE: wpis
paperless-workerwhosts/solaria/services.yaml+inventory/topology.yaml(obecnie SOLARIA ma tam tylkonode-agent) — bez tego supervisor/observer nie widzą tego serwisu w desired-state, więc drift międzyhosts/solaria/services.yamla rzeczywistością nie jest wykrywany. Patrzkb/phases/backlog.md.