docs(infra): weryfikacja inwentaryzacji 2026-06-30 — stan na 2026-07-02

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

docs/infra/inventory-verify-2026-07-02.md

@@ -0,0 +1,153 @@
+# 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`.