Files

T

gitea cea3f4745c docs(pliki): runbook otwarcia udziału z bazami na zapis

Decyzja właściciela: idziemy wariantem, w którym udział z bazami staje się
zapisywalny. DAN-25 dawał gwarancję, że baz nie da się zmienić przez NFS, a
DAN-27 tę gwarancję z definicji znosi — nie da się mieć obu naraz. Runbook mówi
to wprost i wylicza, co z zabezpieczeń zostaje.

mapall_user: root mimo drwxrwxrwx na katalogu. Samo ro: false wystarczyłoby do
zapisu, bo zmapowany nobody mieści się w prawach „innych" — ale nowe pliki
należałyby wtedy do nobody, a istniejące bazy do root. Mieszana własność zemści
się przy pierwszym zaostrzeniu praw.

Krok 3 z ostrzeżeniem, że rollout restart nie wystarcza: pody się na chwilę
nakładają, więc montowanie NFS nie zostaje bez użytkownika i nowy dziedziczy
uprawnienia sprzed zmiany eksportu. To kosztowało najwięcej czasu przy udziale
astrololo-state.

Krok 4 sprawdza wyszukiwanie JAKO OSTATNI I NAJWAŻNIEJSZY punkt — to jedyne
miejsce, w którym ta zmiana mogłaby przejść niezauważona: przejście na rejestr
plików mogłoby wyłączyć wszystkie bazy i wyglądałoby to jak pusta baza, a nie
jak zepsuty deploy.

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

2026-08-09 12:18:29 +02:00

4.4 KiB

Raw Blame History

Zarządzanie plikami baz — otwarcie udziału na zapis (DAN-27)

Ekran „Pliki" pozwala wgrywać bazy, archiwizować je i (dla administratora) kasować, a stan użycia jest klikany, więc musi być trwały. Wymaga to zapisu do udziału z bazami — a ten jest dziś wyeksportowany tylko do odczytu.

Co świadomie tracimy

DAN-25 dawał gwarancję, że baz nie da się zmienić przez NFS. DAN-27 tę gwarancję z definicji znosi — nie da się mieć obu naraz.

Co zostaje:

zabezpieczenie	działa nadal
eksport zawężony do trzech węzłów k8s	✅
token międzywarstwowy	✅
szyfrowane łącze prezentacja ↔ logika ↔ dane	✅
kasowanie plików wyłącznie z konta administracyjnego (PRE-27)	✅
dziennik audytowy (kto, kiedy, co)	✅

Ryzyko, które przybywa: przejęcie warstwy danych pozwala teraz nie tylko odczytać bazy, ale i je zmienić.

Krok 1 — otwórz udział na zapis

midclt call sharing.nfs.query '[["path","=","/mnt/Tank1/astrololo"]]' \
  | python3 -c "import sys,json;[print(s['id'], '| ro:', s['ro'], '| mapall:', s.get('mapall_user')) for s in json.load(sys.stdin)]"

Weź id i podstaw za <ID>:

midclt call sharing.nfs.update <ID> '{"ro": false, "mapall_user": "root", "mapall_group": "root"}'

Dlaczego mapall_user, skoro katalog ma drwxrwxrwx? Samo ro: false wystarczyłoby do zapisu — zmapowany nobody mieści się w prawach „innych". Ale nowe pliki należałyby wtedy do nobody, a istniejące bazy do root. Mieszana własność zemści się przy pierwszym zaostrzeniu praw. mapall_user: root daje spójność i jest tym samym ustawieniem, co na udziale astrololo-state.

midclt call service.restart nfs

Sprawdź, że zmiana faktycznie trafiła do jądra — sama konfiguracja to za mało:

sudo exportfs -v | grep -A1 "Tank1/astrololo "

Przy /mnt/Tank1/astrololo musi być rw, nie ro.

Krok 2 — zmerguj oba PR-y

aplikacja: feat/zarzadzanie-plikami
deploy: feat/pliki-zapis (zdejmuje readOnly z montowania w podzie)

Bez tego drugiego pod nadal montuje udział tylko do odczytu, choćby serwer pozwalał pisać.

Krok 3 — przeładuj warstwę danych PRZEZ ZERO REPLIK

⚠️ rollout restart NIE WYSTARCZY. Stary i nowy pod na chwilę współistnieją, więc montowanie NFS ani na moment nie zostaje bez użytkownika i nowy pod dziedziczy uprawnienia sprzed zmiany eksportu. To kosztowało najwięcej czasu przy udziale astrololo-state — patrz README-stan-prezentacji.md.

kubectl -n astrololo scale deploy/data --replicas=0
kubectl -n astrololo wait --for=delete pod -l app=data --timeout=90s
kubectl -n astrololo scale deploy/data --replicas=1
kubectl -n astrololo rollout status deploy/data

Krok 4 — sprawdź, w tej kolejności

Czy warstwa danych może pisać:

kubectl -n astrololo exec deploy/data -- sh -c 'touch /app/data_files/proba && echo ZAPIS-OK && rm /app/data_files/proba'

Czy powstał plik stanu i czy bazy zostały przyjęte jako aktywne:

kubectl -n astrololo exec deploy/data -- sh -c 'cat /app/data_files/.files-state.json' | head -20

Oczekiwane: każda baza ze "status": "active". Przy pierwszym uruchomieniu bazy zastane na udziale są przyjmowane automatycznie — bez tego wyszukiwanie przestałoby cokolwiek znajdować, bo plik bez wpisu w rejestrze nie bierze udziału w wynikach.

Czy wyszukiwanie NADAL DZIAŁA — to jest najważniejszy sprawdzian tego wdrożenia, bo właśnie tu zmiana mogłaby przejść niezauważona:

kubectl -n astrololo logs deploy/data --tail=20

a potem w przeglądarce: zakładka Sygnifikatory, dowolne wyszukanie. Musi zwracać wyniki jak przedtem. Jeśli nagle nic nie znajduje — zajrzyj do .files-state.json z komendy wyżej.

Czy ekran „Pliki" działa: zakładka Pliki, lista baz, przełącznik przy każdej. Wgraj testowy plik, zarchiwizuj go, skasuj.

Odkręcenie

midclt call sharing.nfs.update <ID> '{"ro": true, "mapall_user": null, "mapall_group": null}'
midclt call service.restart nfs

plus cofnięcie deploy feat/pliki-zapis. Ekran „Pliki" zostanie, ale wgrywanie i kasowanie przestaną działać — a stan użycia przestanie się zapisywać, więc bazy będą przyjmowane od nowa przy każdym starcie (czyli wszystkie aktywne).

4.4 KiB Raw Blame History