104 lines
4.8 KiB
Markdown
104 lines
4.8 KiB
Markdown
|
# 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` (kroki `occ` w README).
|
|||
|
|
- Limity RAM na PIHA: `hosts/piha/runtime/paperless/docker-compose.override.yml`
|
|||
|
|
(stack ≤ ~1.9 Gi worst-case).
|