docs(backlog): tech-debt — globalny porządek uid/gid/uprawnień floty (systemowy, historia incydentów + kierunek)

This commit is contained in:
oskar 2026-07-10 23:11:38 +02:00
parent 5a0e149031
commit 84c1d40c9a

View file

@ -527,3 +527,36 @@ Zgloszone przy fixie owner_node (`886bc85`), swiadomie NIE ruszone — osobne de
- **`/opt/anaconda3` 16G** — najwiekszy pojedynczy zjadacz dysku (env-y Pythona). Decyzja Oskara kiedy/czy czyscic. - **`/opt/anaconda3` 16G** — najwiekszy pojedynczy zjadacz dysku (env-y Pythona). Decyzja Oskara kiedy/czy czyscic.
- Dysk 91% -> 83% ugaszone (docker prune + journal + syslog), ale `/home` zaszyfrowany - Dysk 91% -> 83% ugaszone (docker prune + journal + syslog), ale `/home` zaszyfrowany
i ciasny strukturalnie. SATURN dzwiga dev + drugi control-plane + agent-webui — napiecie. i ciasny strukturalnie. SATURN dzwiga dev + drugi control-plane + agent-webui — napiecie.
## Tech-debt: globalny porządek uid/gid/uprawnień we flocie (2026-07-10)
**Diagnoza.** Flota NIE ma spójnej mapy uid/gid. "oskar" ma różne uid per host
(PIHA: 1004, inne hosty: prawdopodobnie 1000/inne). Kontenery agentów zakładają
uid 1000 (user "homelab"). Bind-mounty przenoszą SUROWE uid (nie nazwy) między
hostem a kontenerem → gdy uid hosta ≠ uid zakładany przez kontener, pliki stają
się "cudze" i wybucha cicha awaria (klucz nieczytelny, rsync nie tworzy plików,
socket permission denied). To NIE są przypadki — to systemowy brak kanonicznej
mapy uid/gid.
**Historia incydentów (dowód że systemowe):**
- 2026-07-10: node-agent PIHA (uid 1000 homelab) montował /home/oskar/.ssh (pliki
uid 1004) → "Load key id_rsa: Permission denied" → rsync padał → 21 dni bez
eventów (wykryte przez shadow-read). Fix: dedykowany /opt/homelab/agent-ssh
chown 1000.
- Wcześniej: oskar spoza grupy `aerbot` na VPS → rsync push nie tworzył plików →
brak cleanup → 8-dniowa cicha awaria floty. Fix: usermod -aG aerbot oskar.
- 2026-07-10 (świeże, PENDING): node-agent PIHA "Docker unavailable: PermissionError(13)"
po recreate — agent nie czyta /var/run/docker.sock (grupa docker/uid). Osobny od
shippingu (nie blokuje eventów), ale ten sam rodzaj problemu — do naprawy
(grupa docker w kontenerze / gid socketu).
- LUSTRO uid pi=1000 vs PIHA oskar=1004 — różne uid "pierwszego usera" per host.
**Kierunek naprawy (do rozważenia, osobny projekt):**
- Ustalić KANONICZNE uid/gid per rola: agent=1000 wszędzie; dedykowane grupy dla
współdzielonych zasobów (aerbot dla events/rsync-sink na VPS, docker dla socketu).
- Audyt `id <user>` na KAŻDYM hoście floty (saturn/solaria/piha/vps/lustro) —
zmapować realne uid/gid, udokumentować rozjazdy.
- Rozważyć deklaratywny zapis oczekiwanych uid/gid w hosts/*/host.yaml lub
capabilities.yaml (żeby deploy mógł weryfikować/wymuszać spójność).
- Agenci NIE powinni montować prywatnego .ssh użytkownika — zawsze dedykowany
katalog z własnym kluczem pod właściwym uid (wzorzec z fixa 2026-07-10).