0b18d2fc3b
Wzorzec mechaniczny: sekcje deploy/verify/install/testy wycinane do kb/runbooks/<serwis>-*.md, reszta zostaje dokumentem type: service. Wzajemne `links` w obie strony. Tresc sekcji nietknieta — przenoszone doslownie, dodany wylacznie naglowek H1 nowego runbooka. kb-query, paperless-worker, planner-agent, ha-diag-agent, ollama-piha, narty27, home-assistant, ha-mcp, job-gmail-header-backfill, job-mail-body-ingest. Weryfikacja: dla kazdego pliku multizbior niepustych linii (main + runbook) == oryginal z HEAD. Zero zgubionych, zero dodanych. Recon szacowal 13 splitow service+runbook; faktycznie 2-typowych jest 10, pozostale 5 (paperless, nextcloud, gokapi, fleet-prometheus, deploy-runner) sa 3-typowe i ida osobno jako splity wielotypowe. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
68 lines
2.5 KiB
Markdown
68 lines
2.5 KiB
Markdown
---
|
|
okf: "0.1"
|
|
type: runbook
|
|
visibility: private
|
|
status: active
|
|
updated: 2026-07-12
|
|
links:
|
|
- ../services/paperless-worker.md
|
|
---
|
|
|
|
# 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)
|
|
```
|
|
|
|
```bash
|
|
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:
|
|
|
|
```bash
|
|
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)
|
|
|
|
1. ✅ `services/paperless/` działa na PIHA (healthcheck zielony).
|
|
2. ✅ Export NFS na PIHA (wyżej) + `showmount -e 192.168.31.5` z SOLARII.
|
|
3. ✅ `nfs-common` na SOLARII.
|
|
4. ✅ `.env` z `env.example` — sekrety SKOPIOWANE z PIHA, nie nowe.
|
|
5. ✅ `docker compose up -d` + `./healthcheck.sh`.
|
|
6. ✅ 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).
|
|
7. ⬜ 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).
|
|
8. ⬜ **OTWARTE**: wpis `paperless-worker` w `hosts/solaria/services.yaml` +
|
|
`inventory/topology.yaml` (obecnie SOLARIA ma tam tylko `node-agent`) —
|
|
bez tego supervisor/observer nie widzą tego serwisu w desired-state, więc
|
|
drift między `hosts/solaria/services.yaml` a rzeczywistością nie jest
|
|
wykrywany. Patrz `docs/backlog.md`.
|