homelab-codex-ws/kb/subsystems/fleet-inventory-verify.md

okf	type	visibility	status	updated	links
0.1	subsystem	private	active	2026-07-02

Weryfikacja inwentaryzacji floty 2026-06-30 — stan na 2026-07-02

Zebrano: 2026-07-02 ~15:20 CEST (read-only recon, zero zmian na nodach). Metoda: ssh + docker ps -a / inspect / logs, free/df/nproc/lscpu/lsblk, git branch/log (odczyt), curl do fleet-prometheus API. Porównanie z docs/infra/inventory-2026-06-30.md (23 rozjazdy) oraz z repo na master (HEAD 22adfb1).

Dostępność nodów podczas weryfikacji:

Node	Dostęp	Uwagi
SOLARIA	lokalnie	—
PIHA	ssh piha	—
VPS	ssh vps	—
SATURN	ssh saturn.local	—
LUSTRO	ssh pi@100.99.85.73	alias lustro NIE rezolwuje z SOLARIA; hostname faktyczny: pimirror2
CHELSTY-INFRA (100.98.91.98)	UNREACHABLE	timeout 8s (LTE offline)
CHELSTY-HA (100.70.180.90)	UNREACHABLE	timeout 8s (LTE offline)
chelsty (100.122.201.22)	UNREACHABLE	timeout 8s

---

TL;DR

Z 23 rozjazdów: 20 wciąż AKTUALNYCH, 2 ZMIENIŁY SIĘ (dysk SATURN poprawił się 91%→83%; ocena postgres:18 w audycie zdezaktualizowana), 1 WYJAŚNIONY (storage SOLARIA — rozjazdu nie było, to dual-boot). 0 naprawionych w pełni. Repo-side nic się nie zmieniło od audytu (manifesty hosts/*, services/*/service.yaml, capabilities — identyczne); zmiany zaszły tylko w runtime (safeclean SATURN, restart NPM na PIHA, rebuild brain-watchdog).

Świeże ustalenia (spoza audytu): fleet-prometheus na VPS zgodny z repo w 100%, brain-watchdog na PIHA biega z nowym kodem (poll Prometheus), ghost-kontenery na VPS zniknęły, ale checkout na PIHA wciąż stoi na gałęzi task/kb-gmail-import (incydent 2026-06-30 naprawiony tylko połowicznie).

---

Weryfikacja 23 rozjazdów z audytu

Statusy: AKTUALNY (rozjazd trwa bez zmian) / NAPRAWIONY / ZMIENIŁ SIĘ (jak) / NIE DA SIĘ ZWERYFIKOWAĆ (czemu). Kolumna "Kierunek" = którą stronę naprawiać: repo czy rzeczywistość.

#	Rozjazd (z audytu)	Status 2026-07-02	Szczegóły weryfikacji	Kierunek naprawy
1	SATURN dysk 91% pełny	ZMIENIŁ SIĘ (poprawa)	/dev/sda5: 125G/159G = 83%, 26G wolne (było 137G/91%, 15G). Safeclean z 2026-06-30 zadziałał. Nadal wysoko. Bonus: lsblk pokazuje dysk 232.9G, partycja / tylko 159G — ~74G niespartycjonowane	Rzeczywistość: dalszy cleanup lub powiększenie partycji o niespartycjonowane ~74G
2	forgejo owner_node=saturn, biega na PIHA	AKTUALNY	service.yaml wciąż owner_node: saturn; forgejo + forgejo-db-1 + forgejo_dind Up 5 days na PIHA	Repo: owner_node: piha + wpis w hosts/piha/services.yaml
3	mosquitto owner_node=piha, biega na VPS	AKTUALNY	service.yaml wciąż owner_node: piha; mosquitto Up 3 weeks na VPS (100.95.58.48:1883); na PIHA brak	Repo: owner_node: vps + wpis w hosts/vps/services.yaml
4	npm — dwie instancje (VPS + PIHA)	AKTUALNY	VPS npm Up 3 weeks; PIHA nginxproxymanager-app-1 Up 2 days (restart ~2026-06-30). Nowy kontekst: topology.yaml sekcja ingress deklaruje proxy: npm-piha dla wildcard *.kapala.org → obie instancje wyglądają na zamierzone (VPS=public ingress, PIHA=mesh ingress kapala.org)	Repo: zalegalizować NPM@PIHA (wpis w hosts/piha/services.yaml, service.yaml per-host lub drugi serwis npm-piha)
5	homeassistant5 na PIHA niedeklarowany	AKTUALNY	Up 5 days na PIHA. topology.yaml ingress odwołuje się do HA (ha.kapala.org → 192.168.31.7:8123), ale nadal zero deklaracji serwisu dla piha	Repo: dodać homeassistant do hosts/piha/services.yaml + topology
6	control-plane podwójny (VPS + SATURN)	AKTUALNY	SATURN: 4 kontenery control-plane Up 3 days, control-plane-ui wciąż UNHEALTHY. VPS: komplet healthy Up 6 days. Repo dalej deklaruje tylko VPS	Decyzja operatora; rekomendacja: rzeczywistość (zatrzymać stack na SATURN), chyba że to świadomy dev-instance — wtedy repo (zadeklarować jako dev)
7	hosts/saturn/services.yaml nie istnieje	AKTUALNY	Pliku nadal brak; na SATURN biega 5 kontenerów (4× control-plane + agent-system-webui:8080)	Repo: stworzyć plik (zależne od decyzji w #6)
8	SATURN capabilities RAM 8 GB vs 14 GiB	AKTUALNY	free -h: 14Gi total; capabilities.yaml wciąż total_gb: 8	Repo: total_gb: 16
9	SATURN capabilities storage sd-card 64 GB	AKTUALNY (doprecyzowany)	Fizyczny dysk sda = 232.9G (audyt widział tylko partycję 159G); capabilities wciąż sd-card, 64	Repo: type: ssd, capacity_gb: 240 (+ nota o partycji / 159G)
10	SOLARIA capabilities CPU 12c/24t vs nproc=32	AKTUALNY (doprecyzowany)	lscpu: i9-14900KF, 24 cores / 32 threads (1 socket). Capabilities wciąż 12/24	Repo: cores: 24, threads: 32
11	SOLARIA storage 2000 GB vs widoczne 890 GB	WYJAŚNIONY — rozjazdu nie ma	lsblk: nvme0n1 = 1.9T (≈2000 GB ✓). Podział: 1002.5G partycja Windows (/mnt/win) + 904.3G root Linux. Audytowe "do weryfikacji" zamknięte	Repo (kosmetyka): adnotacja o dual-boot / faktycznie dostępnych ~900G dla Linuksa
12	ollama zadeklarowana, nie biega na SOLARIA	AKTUALNY	Na SOLARIA biega tylko planner-agent, node-agent, stability-agent, node_exporter (wszystkie Up 3h po reboot). Ollamy brak	Decyzja: repo (usunąć/zarchiwizować services/ollama/) albo rzeczywistość (wdrożyć) — rekomendacja repo, skoro 2+ dni nikt nie wdrożył
13	hosts/vps/services.yaml niekompletne (4 vs 9)	AKTUALNY	Plik wciąż ma 4 serwisy; topology 9; na VPS biega komplet 9 + nadwyżki	Repo: dopisać stability-agent, npm, outline, joplin, ai-cluster
14	planner-agent brak w hosts/solaria + topology	AKTUALNY	Biega na SOLARIA (Up 3h, healthy); w hosts/solaria/services.yaml i topology nadal tylko node-agent	Repo: dopisać planner-agent
15	zigbee2mqtt topology=chelsty-infra, biega na PIHA	AKTUALNY	Up 5 days na PIHA (:8087). topology wymienia z2m tylko pod chelsty-infra (tam też zasadny — deklaracja w hosts/chelsty-infra/services.yaml)	Repo: dodać z2m do sekcji piha w topology (dwie lokalizacje zamierzone)
16	mosquitto brak w topology (vps)	AKTUALNY (częściowo)	W topology vps mosquitto występuje tylko w komentarzu przy ai-cluster; nadal nie jako serwis	Repo: pierwszorzędny wpis (razem z #3)
17	stability-agent owner_node=chelsty	AKTUALNY	Biega na PIHA, VPS, SOLARIA (wszystkie healthy); service.yaml wciąż owner_node: chelsty	Repo: owner_node: per-host (wzorzec ha-diag-agent)
18	node_exporter owner_node=vps	AKTUALNY	Biega na VPS, PIHA (node-exporter), SOLARIA, i LUSTRO (node-exporter, scrapowany przez fleet-prometheus)	Repo: owner_node: per-host
19	outline-postgres-1 anonimowy image	AKTUALNY	Wciąż image ID 4e6e670bb069 bez taga	Rzeczywistość+repo: zidentyfikować wersję (docker inspect → env PG_VERSION), przypiąć named tag w compose
20	joplin-db postgres:18 "pre-release"	ZMIENIŁ SIĘ (ocena, nie stan)	Kontener wciąż na postgres:18, ALE ocena audytu zdezaktualizowana: PostgreSQL 18 jest GA od 2025-09 — to stabilny major, nie pre-release. Zostaje tylko kosmetyka: pin do postgres:18.x	Repo (kosmetyka): pin minor w compose; wpisu "zmień na 16/17" NIE realizować
21	humanai-landing/mailer poza repo (VPS)	AKTUALNY	Oba Up 7 days; brak w repo	Repo: dodać service.yaml albo świadomie oznaczyć jako non-managed w topology
22	umami poza repo (VPS)	AKTUALNY	umami + umami-db Up 7 days (healthy); brak w repo	Repo: jw.
23	PIHA ~33 shadow kontenery	AKTUALNY	docker ps -a na PIHA: 41 kontenerów, 7 powiązanych z repo (6 GitOps + stability-agent z runtime override) → 34 shadow. Skład bez zmian vs audyt	Repo, długoterminowo: iteracyjne dodawanie do hosts/piha/services.yaml

Nody CHELSTY-INFRA / CHELSTY-HA / LUSTRO w audycie nie miały numerowanych rozjazdów; chelsty-* nadal NIE DA SIĘ ZWERYFIKOWAĆ (LTE offline, timeout). LUSTRO — patrz świeże ustalenia.

---

Świeże ustalenia (rzeczy powstałe PO audycie 2026-06-30)

(a) fleet-prometheus na VPS — ✅ ZGODNY z repo

• Image: prom/prometheus:v3.5.0 ✓ (pin zgodny z compose)
• Bind: 100.95.58.48:9090->9090 ✓ (tylko Tailscale IP, zero 0.0.0.0)
• Mounty: prometheus.yml:ro + rules:ro z /home/oskar/homelab-codex-ws/services/fleet-prometheus/ ✓
• /api/v1/targets: 4 targety fleet-node (vps, piha, solaria, lustro) — wszystkie health=up + self-scrape prometheus ✓
• /api/v1/rules: grupa fleet-liveness, reguła NodeDown (up{node=~"vps|piha"} == 0, for 5m) — state inactive, health ok ✓
• Kontener Up 46h (healthy), restart 2026-06-30 wieczorem (deploy reguł)
• Drobiazg: brak hosts/vps/runtime/fleet-prometheus/docker-compose.override.yml — konwencja VPS z CLAUDE.md każe deklarować mem_limit w override; tu mem_limit: 512m siedzi w bazowym compose. Funkcjonalnie OK, formalnie niespójne z konwencją.
• Kontekst: checkout na VPS (/home/oskar/homelab-codex-ws) = master @ d417000, 7 commitów za origin/master (same docs) — mounty proma wskazują na ten checkout, więc git pull na VPS zmienia configi proma "na żywo" (hot-reload dopiero po POST /-/reload).

(b) brain-watchdog na PIHA — ✅ NOWY KOD (poll Prometheus)

• Image brain-watchdog-brain-watchdog zbudowany 2026-06-30 19:22:25 CEST — 31 minut po commicie 62d6fc0 (18:51 CEST, "poll Prometheus /api/v1/alerts"); checkout na PIHA stoi dokładnie na 62d6fc0; docker history pokazuje COPY src/ src/ z tej godziny → kontener biega z kodem zawierającym poll.
• PROMETHEUS_URL=http://100.95.58.48:9090 obecny w /opt/homelab/config/brain-watchdog/.env ✓ i w env kontenera ✓.
• Logi: OK co 60s, zero linii [prometheus] poll failed od startu 2026-06-30 17:22Z — nowy kod loguje poll tylko przy błędzie/alertcie, więc cisza = poll przechodzi (reguła NodeDown inactive → nic do wysłania).
• Jedyne czego nie dało się potwierdzić na twardo read-only: zawartość state.json (klucz prom_alerted) — wolumen root-owned, sudo wymaga hasła. Dowód pośredni (timing buildu + checkout + env) uznaję za wystarczający.

(c) Ghost hash-prefixed kontenery control-plane na VPS — ✅ ZNIKNĘŁY

docker ps -a na VPS: 24 kontenery, wszystkie normalnie nazwane, zero hash-prefixed (grep ^[0-9a-f]{6,} → brak trafień). Lista do wglądu w sekcji (a)/audycie — bez duchów.

(d) Checkout git na PIHA — ❌ NIE naprawiony do końca

/home/oskar/homelab-codex-ws na PIHA:

• gałąź: task/kb-gmail-import (wciąż! incydent 2026-06-30),
• HEAD: 62d6fc0 — to commit z mastera (drzewo czyste, brak lokalnych śmieci),
• czyli: ktoś przestawił gałąź taskową na commit mastera, ale nie przełączył się na master.

Skutek praktyczny: treść plików = master sprzed 2 dni (7 commitów za origin/master, same docs — na dziś niegroźne), ale następny git pull na tej gałęzi nie pociągnie mastera, a następny deploy z PIHA zbuduje z gałęzi taskowej. Mina z opóźnionym zapłonem.

Bonus: LUSTRO (poza zakresem audytu, zebrane przy okazji)

• Alias lustro nie rezolwuje z SOLARIA; działa pi@100.99.85.73 (Tailscale). Hostname faktyczny: pimirror2.
• Biega: node-agent (healthy ✓ zgodnie z repo), node-exporter, piper-tts, pi-watchtower-1 w restart-loopie (Restarting (1)).
• hosts/lustro/services.yaml deklaruje tylko node-agent → node-exporter, piper-tts, watchtower = shadow.
• Brak hosts/lustro/capabilities.yaml (już odnotowane w audycie, wciąż aktualne).

---

Priorytetyzacja: co naprawiać TERAZ (miny) vs PÓŹNIEJ (kosmetyka)

TERAZ — miny

Prio	Co	Kierunek + konkretna rekomendacja
1	PIHA checkout na gałęzi taskowej (świeże d)	Rzeczywistość: na PIHA git checkout master && git pull (operator; to jedyna zmiana stanu, świadomie poza tym reconem). Bez tego każdy kolejny deploy z PIHA buduje ze schodzącej z toru gałęzi. Rozważyć follow-up: guard w deploy.sh odmawiający deployu z gałęzi ≠ master
2	Podwójny control-plane VPS+SATURN, ui na SATURN unhealthy (#6, #7)	Rzeczywistość (rekomendacja): zatrzymać stack control-plane na SATURN — dwa supervisory/executory czytające te same eventy to ryzyko zdublowanych akcji i alertów. Jeśli SATURN ma być dev-instance → wtedy repo: stworzyć hosts/saturn/services.yaml i oznaczyć jako dev (i naprawić unhealthy ui). Decyzja operatora wymagana, ale stan "unhealthy od tygodni + niezadeklarowany" nie może wisieć
3	owner_node kłamie dla forgejo i mosquitto (#2, #3)	Repo (proste, bezpieczne): forgejo → owner_node: piha, mosquitto → owner_node: vps, + wpisy w services.yaml hostów. Mina bo supervisor/deploy kierują akcje wg owner_node — restart/redeploy poleciałby na zły node. Rzeczywistość jest tu "dobra" (serwisy działają tam gdzie mają sens)
4	SATURN dysk 83% (#1)	Rzeczywistość: trend poprawiony (91→83%), ale dalej ciasno. Najtańszy ruch: powiększyć partycję / o ~74G niespartycjonowanego miejsca na sda (232.9G dysk, 159G partycja) — wymaga planu, nie ad-hoc

PÓŹNIEJ — porządki (repo-side, bez ryzyka runtime)

Co	Kierunek
Legalizacja NPM@PIHA + homeassistant@PIHA w manifestach (#4, #5) — topology ingress już zakłada ich istnienie, manifesty nie	Repo
hosts/vps/services.yaml dopisać 5 brakujących serwisów (#13); planner-agent do hosts/solaria + topology (#14)	Repo
stability-agent i node_exporter → owner_node: per-host (#17, #18)	Repo
Capabilities: SATURN RAM 16 / storage 240G ssd (#8, #9), SOLARIA CPU 24c/32t (#10), adnotacja dual-boot (#11)	Repo
ollama: usunąć/zarchiwizować service.yaml albo wdrożyć (#12) — rekomendacja: archiwizacja	Repo
topology: z2m do sekcji piha, mosquitto jako pierwszorzędny wpis vps (#15, #16)	Repo
outline-postgres pin taga (#19), joplin-db pin postgres:18.x (#20 — NIE downgrade do 16/17, PG18 jest stable)	Repo + rzeczywistość przy najbliższym redeployu
humanai-landing/mailer + umami: zadeklarować albo oznaczyć non-managed (#21, #22)	Repo
PIHA 34 shadow kontenerów (#23) — iteracyjnie, osobny projekt	Repo, długoterminowo
LUSTRO: naprawić watchtower restart-loop, dodać capabilities.yaml + node-exporter/piper-tts do manifestów, wyjaśnić rezolucję aliasu lustro	Mieszane, follow-up
fleet-prometheus: formalny override hosts/vps/runtime/fleet-prometheus/ per konwencja VPS (mem_limit już jest w bazie — przenieść lub udokumentować wyjątek)	Repo, kosmetyka

---

Uwagi metodologiczne

• Recon w 100% read-only: docker ps/inspect/logs/history, cat/grep, git odczyt, curl GET. Zero restartów, zero edycji na nodach, zero git pull na nodach.
• CHELSTY-INFRA / CHELSTY-HA / chelsty: timeout ssh 8s na Tailscale IP — UNREACHABLE, pozycje ich dotyczące nieweryfikowalne (jak w audycie).
• state.json brain-watchdoga nieczytelny bez sudo-z-hasłem — jedyny punkt zweryfikowany dowodem pośrednim zamiast bezpośrednim.
• Manifesty repo porównywane z master HEAD 22adfb1 w worktree task/fleet-recon-verify.