feat(astrololo): Postgres jako lustro baz w SQL + runbook (DAN-28)

Manifest, wpięcie w kustomization i runbook krok po kroku.

DECYZJE ZAPISANE W MANIFEŚCIE, ŻEBY NIE TRZEBA ICH BYŁO ODTWARZAĆ Z GŁOWY:

local-path, NIE NFS. Postgres zakłada semantykę blokad i fsync, której NFS nie
gwarantuje — to klasyczne źródło uszkodzenia bazy przy nagłym restarcie. Ceną
jest przywiązanie do węzła; przy luście odtwarzalnym z Excela to akceptowalne.

strategy: Recreate. Wolumen jest ReadWriteOnce, a dwa procesy Postgresa na jednym
katalogu danych to uszkodzona baza — rolling próbowałby wstać z nowym podem,
zanim stary zejdzie.

PGDATA w PODKATALOGU wolumenu: katalog główny potrafi zawierać wpisy systemu
plików, a initdb odmawia pracy w niepustym katalogu.

Wersja PRZYPIĘTA i poza image-updaterem: podbicie majora wymaga migracji katalogu
danych, więc nie może się zdarzyć samo, w nocy, przy okazji builda aplikacji.

C.UTF-8 zamiast pl_PL.UTF-8: dopasowanie tekstu robimy przez unaccent i pg_trgm,
nie przez collation, a pl_PL wymagałby obrazu z wygenerowanymi lokalizacjami.

DATA_PROVIDER zostaje na `excel`. Postgres można wdrożyć i obejrzeć BEZ ryzyka
dla działającego wyszukiwania; przełączenie to osobna, późniejsza decyzja.

SPRAWDZONE PRZED ODDANIEM: `kubectl kustomize astrololo` składa komplet 21
zasobów bez błędu, YAML parsuje się poprawnie, audyt odwołań potwierdza, że
jedynym brakującym sekretem jest astrololo-postgres (oba klucze), a DSN
postgresql+psycopg:// jest rozpoznawany przez SQLAlchemy z psycopg 3.

NIE SPRAWDZONE: skrypt inicjalizujący nie biegł przeciwko prawdziwemu Postgresowi
— na maszynie, na której to powstawało, nie ma Dockera. Zapisane wprost
w runbooku; krok 4 jest tam prawdziwym testem.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

astrololo/README-stan-prezentacji.md

@@ -1,135 +0,0 @@
-# Udział na stan prezentacji — `astrololo-state`
-
-Potrzebny do kont zakładanych z ekranu „Konta" (PRE-27). **Bez niego pod
-`presentation` nie wstanie.**
-
----
-
-## Dlaczego osobny udział, a nie podkatalog
-
-Pierwsza wersja montowała `/mnt/Tank1/astrololo` z `subPath: presentation-state`
-i pod stanął w `CreateContainerConfigError`:
-
-```
-failed to create subPath directory for volumeMount "state" of container "presentation"
-```
-
-Przyczyna była podwójna i za każdym razem ta sama: udział z bazami jest
-wyeksportowany **`ro: true` z `root_squash`** (patrz runbook DAN-25 w repo
-aplikacji). Zatem:
-
-1. kubelet nie mógł utworzyć podkatalogu — bo udział jest tylko do odczytu,
-2. a gdyby nawet mógł, aplikacja i tak nie zapisałaby tam pliku kont.
-
-**Osobny udział rozwiązuje to bez ruszania DAN-25.** Udział z bazami zostaje tylko
-do odczytu; konta dostają własne, małe miejsce. Przy okazji znika `subPath`, czyli
-znika potrzeba, żeby kubelet cokolwiek zakładał — katalog istnieje, bo jest
-korzeniem udziału.
-
----
-
-## Krok 1 — dataset i udział na TrueNAS
-
-Po SSH na NAS (192.168.1.34). Konwencja jak w DAN-25: **nie edytujemy
-`/etc/exports` ręcznie**, tylko przez `midclt`.
-
-```bash
-# dataset
-sudo zfs create Tank1/astrololo-state
-```
-
-Jeśli `Tank1` nie jest pulą ZFS albo wolisz zwykły katalog:
-
-```bash
-sudo mkdir -p /mnt/Tank1/astrololo-state
-```
-
-### Właściciel i prawa
-
-Kontenery aplikacji działają **jako root**, a eksport ma `root_squash`, więc root
-z klienta NIE jest rootem na udziale. Żeby zapis działał, przypinamy cały ruch
-z tych hostów do jednego, nieuprzywilejowanego użytkownika — to bezpieczniejsze
-niż `no_root_squash`, bo nie oddaje roota.
-
-```bash
-# użytkownik, na którego mapujemy (jeśli nie istnieje — utwórz w UI TrueNAS)
-sudo chown -R apps:apps /mnt/Tank1/astrololo-state
-sudo chmod 770 /mnt/Tank1/astrololo-state
-```
-
-> Podstaw swojego użytkownika w miejsce `apps`. Sprawdzisz istniejących:
-> `midclt call user.query | python3 -c "import sys,json;[print(u['uid'], u['username']) for u in json.load(sys.stdin)]"`
-
-### Eksport NFS
-
-```bash
-midclt call sharing.nfs.create '{
-  "path": "/mnt/Tank1/astrololo-state",
-  "comment": "astrololo — stan prezentacji (konta PRE-27)",
-  "hosts": ["192.168.1.73", "192.168.1.80", "192.168.1.81"],
-  "ro": false,
-  "mapall_user": "apps",
-  "mapall_group": "apps"
-}'
-```
-
-| ustawienie | po co |
-|---|---|
-| `hosts` zawężone | te same trzy węzły k8s co w DAN-25 — nikt inny nie zamontuje |
-| `ro: false` | **musi być zapisywalny**, inaczej konta się nie zapiszą |
-| `mapall_user` | cały ruch pisze jako jeden nieuprzywilejowany użytkownik, niezależnie od UID w kontenerze |
-
-> Podstaw swoje adresy węzłów, jeśli się zmieniły. Aktualne:
-> `kubectl get nodes -o wide`
-
----
-
-## Krok 2 — sprawdź z węzła, ZANIM wdrożysz
-
-To jest ten test, którego zabrakło za pierwszym razem:
-
-```bash
-ssh 192.168.1.73 'sudo mount -t nfs 192.168.1.34:/mnt/Tank1/astrololo-state /mnt/test \
-  && sudo touch /mnt/test/proba && echo "ZAPIS DZIAŁA" \
-  && sudo rm /mnt/test/proba; sudo umount /mnt/test'
-```
-
-Musi wypisać **`ZAPIS DZIAŁA`**. Jeśli zamiast tego widzisz `Permission denied` —
-wróć do praw katalogu i `mapall_user` w kroku 1.
-
----
-
-## Krok 3 — wdróż i sprawdź
-
-```bash
-kubectl apply -k astrololo
-kubectl -n astrololo rollout status deploy/presentation
-```
-
-Sprawdź, że aplikacja faktycznie umie tam zapisać — załóż konto testowe
-na ekranie „Konta", a potem:
-
-```bash
-kubectl -n astrololo exec deploy/presentation -- ls -l /app/state/
-```
-
-Oczekiwane: plik `accounts.json`.
-
----
-
-## Odkręcenie
-
-```bash
-# ID udziału
-midclt call sharing.nfs.query | python3 -c "import sys,json;[print(s['id'], s.get('path')) for s in json.load(sys.stdin)]"
-midclt call sharing.nfs.delete <ID>
-```
-
----
-
-## Uwaga na przyszłość: DAN-27 uderzy w tę samą ścianę
-
-Zarządzanie plikami baz (wgrywanie, archiwizacja, kasowanie) wymaga zapisu do
-**udziału z bazami** — a ten jest `ro: true`. Ten runbook tego **nie rozwiązuje**
-i celowo nie rusza DAN-25: to osobna decyzja, bo oznacza rezygnację z gwarancji,
-że baz nie da się zmienić przez NFS. Patrz PR `feat/pliki-zapis`.

astrololo/README.md

@@ -32,16 +32,6 @@ co musisz zrobić ręcznie (sekret `astrololo-postgres`), jak sprawdzić rozszer
 Postgres trzyma LUSTRO plików Excela, nie źródło prawdy — jego utrata nie jest
 utratą danych, więc kopie zapasowe są opcjonalne.
 
-## ⚠️ Udział `astrololo-state` — wymagany przez konta (PRE-27)
-
-Pod `presentation` **nie wstanie bez niego** (`CreateContainerConfigError:
-failed to create subPath directory`). Osobny runbook:
-**[README-stan-prezentacji.md](README-stan-prezentacji.md)**.
-
-Krótko: udział z bazami jest wyeksportowany `ro` (DAN-25), więc konta nie mogą tam
-mieszkać — dostają własny, mały udział `/mnt/Tank1/astrololo-state`, zapisywalny,
-zawężony do tych samych węzłów.
-
 ## ⚠️ Sekret `astrololo-auth` — utwórz PRZED wdrożeniem
 
 Aplikacja wystawia treść **oryginalnych baz interpretacyjnych**, dlatego wymaga

astrololo/data.yaml

@@ -57,18 +57,9 @@ spec:
           volumeMounts:
             - name: cache
               mountPath: /app/.cache
-            # ZAPISYWALNY od DAN-27. Wcześniej read-only, bo warstwa danych tylko
-            # czytała bazy — teraz ekran „Pliki" pozwala je wgrywać, archiwizować
-            # i (dla administratora) kasować, a stan użycia jest KLIKANY, więc musi
-            # przetrwać restart poda.
-            #
-            # ŚWIADOMY KOSZT: znika jedna warstwa obrony w głąb. Przejęcie warstwy
-            # danych pozwala teraz nie tylko odczytać bazy, ale i je zmienić.
-            # Zostaje reszta: token międzywarstwowy, szyfrowane łącze, ograniczenie
-            # eksportu NFS do konkretnych hostów (DAN-25) i to, że kasować może
-            # wyłącznie konto administracyjne (PRE-27).
             - name: excel
               mountPath: /app/data_files
+              readOnly: true
           resources:
             requests: { cpu: "100m", memory: "256Mi" }
             limits:   { cpu: "500m", memory: "512Mi" }

astrololo/kustomization.yaml

@@ -15,6 +15,6 @@ images:
   - name: gitea.czernobog.pl/gitea/astrololo-logic
     newTag: baf4e0e3
   - name: gitea.czernobog.pl/gitea/astrololo-render
-    newTag: latest
+    newTag: aec3f843
   - name: gitea.czernobog.pl/gitea/astrololo-presentation
-    newTag: a8339659
+    newTag: baf4e0e3

astrololo/presentation.yaml

@@ -66,20 +66,12 @@ spec:
             - name: ACCOUNTS_FILE
               value: "/app/state/accounts.json"
           volumeMounts:
-            # OSOBNY UDZIAŁ, nie podkatalog udziału z bazami. Pierwsza wersja
+            # subPath, NIE cały udział: prezentacja dostaje wyłącznie własny
-            # montowała /mnt/Tank1/astrololo z subPath — i nie wstała:
+            # podkatalog i nie widzi baz interpretacyjnych. Zamontowanie tu całego
-            # „failed to create subPath directory”. Powód był podwójny i oba razy
+            # /mnt/Tank1/astrololo obeszłoby bokiem zamknięcie dostępu z DAN-25.
-            # ten sam brak: udział z bazami jest wyeksportowany `ro: true`
-            # z `root_squash` (DAN-25), więc (1) kubelet nie mógł utworzyć
-            # podkatalogu, a (2) gdyby nawet mógł, aplikacja i tak nie zapisałaby
-            # tam pliku kont.
-            #
-            # Osobny udział rozwiązuje to bez naruszania DAN-25: udział z bazami
-            # ZOSTAJE tylko do odczytu, a konta mają własne, małe miejsce.
-            # Przy okazji znika subPath, czyli znika potrzeba, żeby kubelet
-            # cokolwiek zakładał — katalog istnieje, bo jest korzeniem udziału.
             - name: state
               mountPath: /app/state
+              subPath: presentation-state
           resources:
             requests: { cpu: "100m", memory: "128Mi" }
             limits:   { cpu: "300m", memory: "256Mi" }
@@ -87,9 +79,7 @@ spec:
         - name: state
           nfs:
             server: 192.168.1.34
-            # Udział WYŁĄCZNIE na stan prezentacji (konta z PRE-27). Wymaga
+            path: /mnt/Tank1/astrololo
-            # utworzenia na TrueNAS — patrz README-stan-prezentacji.md.
-            path: /mnt/Tank1/astrololo-state
 ---
 apiVersion: v1
 kind: Service