homelab-codex-ws/services/kb-site
oskar bb3792d219 docs(kb-site): przekaz ACCESS_TOKEN generatorowi w procedurze publikacji
Poprzedni commit nauczyl gen_pages.py dopisywac token do linkow, ale nic
go nie podawalo — publikacja poszlaby stara sciezka i dalaby build
z golymi linkami, czyli stan sprzed fiksa.

kb-site nie ma skryptu deployu: generator wolany jest wylacznie recznie
z runbooka (kroki 2 i 7), wiec to tam token musi wejsc.

Zrodlo tokenu: /opt/homelab/config/kb-site/.env na wezle GENERUJACYM
(SATURN/SOLARIA), nie na PIHA. To swiadome odstepstwo od konwencji
config/<serwis>/ z CLAUDE.md — plik trzyma zwykle sekrety wezla, ktory
serwis uruchamia, a ten token jest potrzebny tam, gdzie serwis sie
generuje. Kontener nginx dalej nie ma zadnej konfiguracji ani sekretow;
odnotowane w service.yaml i env.example, zeby nikt nie szukal .env na PIHA.

Token idzie zmienna srodowiskowa (set -a; . plik; set +a), nie flaga
--access-token: argument z linii polecen laduje w historii shella i jest
widoczny w ps dla kazdego uzytkownika wezla.

Lancuch publikacji z kroku 7 dostal dwa nowe ogniwa przed scp: test -n
"$ACCESS_TOKEN" (pusty token = build nieklikalny) oraz grep -q 'key='
w index.html (token byl, ale nie dojechal do generatora). Oba zatrzymuja
publikacje tak samo jak --check.

Krok 6 weryfikuje teraz wlasciwa rzecz: wyciaga href ze spisu i pobiera
GO, zamiast recznie sklejac URL — czyli testuje to, co faktycznie bylo
zepsute. Doszedl tez negatywny test bramki (bez tokenu ma NIE byc 200).

Tabela problemow: "index sie otwiera, ale klikniecie daje 403" (build bez
tokenu) i "403 takze z tokenem" (rotacja tokenu w NPM rozjechana z plikiem
— stary build zostaje z martwym tokenem w kazdym linku).

kb/services/kb-site.md (public) — sekcja Access: token siedzi teraz
w tresci kazdej serwowanej strony, wiec jedna zapisana strona wydaje go
w calosci. Model zagrozen bez zmian (URL wejsciowy zawsze go niosl), ale
warto, zeby dokument mowil to wprost obok zdania "to obscurity, not
access control".

Test: sekwencje z krokow 2 i 7 przepuszczone na symulowanym pliku tokenu
(prod /opt/homelab nietkniety) — token obecny: Token: TAK, 4x key=
w index.html, lancuch dochodzi do tar; token pusty: staje na pierwszym
ogniwie, brak tgz; build bez tokenu przy ustawionej zmiennej: staje na
grep, brak tgz. check_okf.py exit 0, gen_pages --check exit 0,
service.yaml parsuje sie.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 22:26:48 +02:00
..
docker-compose.yml fix(kb-site): wycofaj robots.txt — blokowal legalny fetch z tokenem 2026-08-05 13:11:43 +02:00
env.example docs(kb-site): przekaz ACCESS_TOKEN generatorowi w procedurze publikacji 2026-08-05 22:26:48 +02:00
healthcheck.sh feat(kb-site): serwis nginx na PIHA + manifesty (wzorzec narty27) 2026-08-04 17:59:05 +02:00
README.md docs(kb-site): przepisz nieaktualne kb.okit.pl na kb-e2a24af3.okit.pl 2026-08-05 13:08:13 +02:00
service.yaml docs(kb-site): przekaz ACCESS_TOKEN generatorowi w procedurze publikacji 2026-08-05 22:26:48 +02:00

kb-site

Public slice of the knowledge base (kb-e2a24af3.okit.pl) — static HTML generated from kb/**/*.md by scripts/kb/gen_pages.py, served by nginx on PIHA.

Sieć

Stack nie tworzy własnej sieci — dołącza do istniejącego bridge'a proxy na PIHA (external: true). Powód: Docker na PIHA wyczerpał domyślne pule adresowe (all predefined address pools have been fully subnetted), więc kolejny kb-site_default nie może powstać.

Warunek wstępny deployu — sieć musi już istnieć na hoście:

docker network ls | grep -w proxy   # brak wyniku => docker network create proxy

Ruch publiczny i tak nie idzie przez tę sieć: npm@PIHA (vhost kb-e2a24af3.okit.pl) trafia do kontenera po opublikowanym porcie hosta 8250.

Dokumentacja: kb/services/kb-site.md