4658089e21
126 plikow (md, yaml, sh, py) odwolywalo sie do sciezek sprzed migracji.
15 markdown-linkow [..](..) -> policzona sciezka WZGLEDNA wobec pliku
odsylajacego (wczesniej czesc z nich byla repo-root-relative i nie
rozwiazywala sie z katalogu, w ktorym lezala)
200 odwolan tekstowych (backticki, proza, yaml, importy w kodzie)
-> nowa sciezka repo-root-relative, zgodnie z konwencja repo
5 linkow rodzenstwa (gole nazwy plikow, np. "](DEPLOY.md)") — dzialaly
tylko w starym katalogu; przeliczone recznie
Objete m.in.: CLAUDE.md (scripts/onboard/README.md -> kb/runbooks/
node-onboarding-tool.md, docs/backlog.md -> kb/phases/backlog.md),
README.md, .claude/skills/, 20 session logow, kod jobow.
Ostatnie 5 odwolan pochodzi z tresci wciagnietej rebasem z origin/master
(session log 2026-07-31, override node-agenta na SOLARII, dwie pozycje
backlogu) — wskazywaly na docs/incidents/, docs/kb/modules/ i
services/narty27/README.md sprzed migracji.
Dodany wzajemny link miedzy kb/services/control-plane.md (stub kodu)
a kb/subsystems/control-plane.md (opis, deprecated) — dwa dokumenty o tym
samym systemie, latwe do pomylenia.
Weryfikacja na 790 plikach: 0 odwolan do starych sciezek,
0 martwych linkow markdown. Lint OKF: 190/190 plikow ZGODNE.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
163 lines
15 KiB
Markdown
163 lines
15 KiB
Markdown
---
|
||
okf: "0.1"
|
||
type: subsystem
|
||
visibility: private
|
||
status: active
|
||
updated: 2026-07-02
|
||
links: []
|
||
---
|
||
|
||
# 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 `kb/subsystems/fleet-inventory.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`.
|