oskar/homelab-codex-ws
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity
homelab-codex-ws/docs/infra/inventory-verify-2026-07-02.md
oskar 57a6dffc5e docs(infra): weryfikacja inwentaryzacji 2026-06-30 — stan na 2026-07-02 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 15:26:18 +02:00

15 KiB
Raw Blame History

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.