oskar 6b85c7ef68 feat(kb): SPLIT service+runbook — 10 serwisow -> 20 dokumentow

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>

2026-08-04 16:58:46 +02:00

2.5 KiB

Raw Blame History

okf

type

visibility

status

updated

links

0.1

runbook

private

active

2026-07-12

../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)

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.5 z SOLARII.
✅ nfs-common na SOLARII.
✅ .env z env.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-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.

2.5 KiB Raw Blame History