4.8 KiB
Decyzje do podjęcia — filar dokumentów (moduły 2/3/4)
Zbiorcza lista otwartych decyzji z przygotowania configów (2026-07-06, branch
task/paperless-nextcloud-config). Każda pozycja ma odpowiadający komentarz# TODO DECYZJA OSKARA:w plikach serwisów. Configi są gotowe do review — NIC nie zostało zdeployowane.
1. Host Nextclouda: PIHA czy SOLARIA
Jedyna duża decyzja architektoniczna. Moduł 4 i kb-02 skłaniają się ku
SOLARIA (KB czyta własną kopię z archiwum na PIHA, więc dostępność
Nextclouda nie warunkuje zapytań KB; koszt = sync dogania się po wybudzeniu).
Tabela za/przeciw: services/nextcloud/README.md. Compose jest przenośne —
decyzja ustawia tylko owner_node w service.yaml + LAN_BIND_IP
i TRUSTED_PROXIES w .env. Wstępnie wpisane: SOLARIA.
2. Backup Paperlessa (warunek brzegowy hybrydy — musi być przed produkcyjnym użyciem)
Propozycja w services/paperless/README.md:
- nocny
document_exporter(oryginały + archiwa + manifest metadanych, odtwarzalny bez dumpa SQL) do/opt/homelab/data/paperless/export, - kopia eksportu poza hosta: rsync/borg → SOLARIA (2 TB, ta sama LAN); otwarte: czy dokładać offsite (restic → chmura?),
- retencja (propozycja): 7 dziennych + 4 tygodniowe + 6 miesięcznych.
Do zatwierdzenia: cel kopii (SOLARIA wystarczy? offsite?), retencja, narzędzie.
3. Porty (potwierdzić na żywym PIHA przed deployem)
Dobrane wg inwentaryzacji 2026-06-30 (snapshot! zweryfikować ss -tlnp):
| Port | Serwis | Uwagi |
|---|---|---|
| 8210 | paperless web | za npm@PIHA |
| 5434 | paperless postgres | 5433 zajęte przez kb-postgres |
| 6380 | paperless redis (broker dla workera) | 6379 zajęte przez agent-system-redis |
| 8220 | nextcloud web | wolny i na PIHA, i na SOLARII |
Wszystkie bindowane na LAN IP (nie 0.0.0.0); ruch worker↔broker/DB/NFS po LAN 192.168.31.x, nie Tailscale.
4. Redis brokera bez auth na bindzie LAN
Broker (6380) i Postgres (5434) są wystawione na LAN IP PIHA dla workera na
SOLARII. Postgres ma auth (scram); Redis defaultowo nie ma. Zaufany LAN
domowy — akceptować, czy dołożyć requirepass (wtedy PAPERLESS_REDIS
z hasłem wędruje do .env po obu stronach)?
5. Fallback-worker na PIHA a indeks Whoosh po NFS
Stockowy obraz na PIHA zawsze ma wbudowany worker (concurrency 1) — to
naturalny fallback „domiela wolno". Ryzyko: gdy SOLARIA pracuje, dwa hosty
piszą do plikowego indeksu Whoosh (PIHA lokalnie, SOLARIA po NFS) — znane
upstreamowe objawy wyścigu („This writer is closed", korupcja indeksu).
Indeks jest odtwarzalny (document_index reindex), oryginałom nic nie grozi.
Decyzja: zaakceptować i obserwować (rekomendacja), czy od razu wymusić
tryb „kolejka-czeka" (batch-OCR tylko w oknach pracy SOLARII)?
Szczegóły: services/paperless-worker/README.md.
6. Domeny + wpisy DNS + vhosty npm
Założone w configach: paper.kapala.org (Paperless), cloud.kapala.org
(Nextcloud) — moduły dopuszczały też *.okit.pl. Potwierdzić, potem:
A-recordy (DNS Only) → PIHA + vhosty w npm@PIHA + rejestracja OAuth2 apps
w Forgejo (redirect URIs w README serwisów zależą od domeny).
7. Wyłączenie lokalnego loginu w Paperless po weryfikacji OIDC
Bootstrap idzie przez lokalnego admina (PAPERLESS_ADMIN_USER). Po
potwierdzeniu działania Forgejo-OIDC: ustawić
PAPERLESS_DISABLE_REGULAR_LOGIN=true + PAPERLESS_REDIRECT_LOGIN_TO_SSO=true?
(Vikunja ma dziś oba tryby równolegle.)
8. Pin wersji Nextclouda
Compose ma ruchomy nextcloud:stable-apache; przy deployu przypiąć aktualny
major (np. :31-apache — sprawdzić bieżący stable w dniu deployu). Nextcloud
nie wspiera skoków o >1 wersję major, więc ruchomy tag na produkcji = ryzyko
niekontrolowanego skoku.
9. Sizing workera OCR pod batch 70k załączników
WORKER_CONCURRENCY=4 × PAPERLESS_THREADS_PER_WORKER=4 = ~16 wątków na
24 rdzeniach SOLARII. Przed batchem 70k (moduł 5): zmierzyć na próbce i
zdecydować, czy podbić concurrency, czy zostawić zapas na ollama/AI.
Rozstrzygnięte w tym przygotowaniu (dla porządku)
- Split-host OCR-worker przez NFS: WYKONALNY — wzorzec potwierdzony przez
maintainerów paperless-ngx (nieoficjalnie wspierany): ten sam obraz,
command: celery --app paperless worker, wspólny Redis+Postgres+storage, identyczne ścieżki kontenerowe i numeryczny UID po obu stronach. Pełny wynik badania + ryzyka:services/paperless-worker/README.md. - Storage dokumentów na PIHA; NFS export → SOLARIA po LAN (192.168.31.5 → 192.168.31.70), nie Tailscale.
- AOF w Redis brokera (kolejka przeżywa restart — zero utraty zadań).
- OIDC: Paperless przez
django-allauth openid_connect(env), Nextcloud przez appkęuser_oidc(krokioccw README). - Limity RAM na PIHA:
hosts/piha/runtime/paperless/docker-compose.override.yml(stack ≤ ~1.9 Gi worst-case).