8.4 KiB
- 2026-09-11: Projekt založen. Uživatel ho chce jako úložiště pro admin/root poznámky — infrastruktura, servery, provoz, podobně. Záměrně volné zaměření, strukturu a upřesnění odkládá na později. prompt.md naplněn základním homelab kontextem (Proxmox cluster, wood/pivo/nvidia/devlin.hell, Zabbix, zálohy), state.md obsahuje výchozí „kde to je / co dál".
- 2026-09-11: Presun LibreChat podman topicu z projektu ai do devops (tematicky patri sem). Artefakt librechat-podman presunut z projects/ai/artifacts/ do projects/devops/artifacts/ (README + quadlet unity). Kontext: OpenWebUI zakazano (RAM problemy), jako nahraada LibreChat; uzivatel si tema nejdřív nacte sam a rozhodne o pristupu — agent dodava info, nereshi rozhodnuti. Soucasti presunu i souhrn diskuse o podman+systemd (generate systemd deprecated od 4.4, quadlet jako hlediska, ne hotova volba).
- 2026-09-11: Doplneni motivace pro LibreChat: chci neco lite, kde snadno muzu menit LLM modely, testovat tool calling, mit preddefinovane system prompty, vyuzivat skills (LibreChat ma vlastni Skills/Agents system). OpenWebUI odstraneno kvuli RAM; LibreChat ma byt lehci alternativa s temito vlastnostmi.
- 2026-09-13: Research sandbox kontejnerů pro AI harness (LibreChat Code Interpreter). Vybrané řešení: LibreCodeInterpreter (https://github.com/GlydePath/librecodeinterpreter) — komunitní nsjail reimplementace LibreChat Code Interpreter API, Apache 2.0, GHCR image
ghcr.io/usnavy13/librecodeinterpreter(amd64+arm64, pinovat tag, ne main). Stack: 1 API kontejner + Redis + Garage (S3). 13 jazyků (Python, JS, TS, Go, Java, C, C++, PHP, Rust, R, Fortran, D, Bash), Python REPL pool ~20-40ms exec, ostatní jazyky one-shot. Sandbox default bez sítě; ENABLE_SANDBOX_NETWORK=true zapne inline allowlist HTTPS proxy (pip/npm/cargo instally, cache ve skill-deps volume). Autentizace: x-api-key header nebo URL credentials (LibreChat LIBRECHAT_CODE_BASEURL=https://@host/v1 → Basic auth).
Speciální práva kontejneru (klíčové zjištění z researchu):
cap_add: SYS_ADMIN— nsjail potřebuje clone namespaces, mount, cgroups. NEVYJEDNATELNÉ, bez toho nsjail nefunguje. SYS_ADMIN je nejsilnější kontejnerová capa — kontejner s ní je de facto root co umí mountovat.cap_add: NET_ADMIN— pouze pro ENABLE_SANDBOX_NETWORK=true (iptables egress allowlist v sandbox netns). Při offline sandboxech lze vynechat.security_opt: apparmor:unconfined— nutné na hostech s AppArmor (Ubuntu/Debian), jinak mount() v nsjailu padá na EPERM. Na distrubu bez AppArmor (Alpine) no-op.init: true(tini) — reapuje zombie nsjail/python child procesy.
Význam pro nasazení: API kontejner běží jako near-host privilegia (root + SYS_ADMIN + unconfined) na sdíleném kernelu. Nejedná se o „kontejner izoluje nevěřený kód", ale „API proces musí být skoro-host, aby mohl sám izolovat kód pomocí nsjailu". Skutečná sandbox hranice pro LLM kód je nsjail (PID/mount/net namespaces, seccomp, cgroups, rlimits, non-root UID 1001) — sdílený kernel. Únik z nsjailu = kernel hostu = všechno co na něm běží.
Závěry nasazení:
- Proxmox VM > LXC pro tento use case (nevěřený LLM kód + near-host capy kontejneru). V LXC by únik z nsjailu dosáhl PVE host kernelu; VM dává druhou hranici + možnost nested virt pro microsandbox později.
- Alternativa: běží-li Docker VM jako čistý AI stack (LibreChat + interpreter, žádná produkční data), je jeden host logický celek. Na obecném provozním Docker hostu raději dedikovaná malá VM (1.5-2 GB RAM).
- Rootless podman nefunkční out-of-the-box (user namespace v user namespace, cgroup delegace) — projekt to netestuje; rootful podman/quadlet OK.
- Kompromis vs oficiální codeapi: ta řeší stejný problém microVM režimem (libkrun), ale stojí 5 komponent + Redis + MinIO.
- 2026-09-14: Záznam reportu od Claude Code (uživatel ho přinesl 2026-09-13): „Negativní zjištění — nvidia.hell / ollama" — co selhalo a co je slepá ulička z incidentů 12.–13. 9. 2026. Plný report uložen verbatim jako artifact:
projects/devops/artifacts/2026-09-13_ollama-nvidia-negative-findings.md(report odkazuje na history.md a knowledge.md na stroji, ty v workspace nejsou — jen v artifactu).
Shrnutí obsahu:
Pojistky, které selhaly: earlyoom zavržen a odinstalován — killuje llama-server uprostřed CUDA initu, čímž nvidia driver natrvalo ztratí napinovanou host paměť (po ~15 killech −9,27 GiB, kladná zpětná vazba: méně RAM → dřívější killy). Výchozí earlyoom konfigurace by nezasáhla nikdy (obě podmínky mem+swap musí platit současně); SIGKILL práh je polovina zadané hodnoty, musí se psát -s 100,100. MemoryHigh mezi spotřebou a MemoryMax = past (gemma4 host buffer 5901 MiB padl doprostřed → 84k reclaimů, load visel 600 s bez chyby) — při „rychlém selhání" se MemoryHigh nesmí nastavit. systemd-oomd nepoužit (PSI varianta earlyoomu, čekali by týž leak).
Slepé uličky v konfiguraci ollamy: žádný admission control v 0.33.2 (přeteče do CPU vždycky); OLLAMA_NO_MMAP neexistuje (issue #4895, PR #6854 nesloučen); navýšení RAM neřeší nic — podmínka mmap disable je FreeMemory < modelSize + max(8GB, Total/10), headroom konstanta 7,5 GiB, potvrzeno 3 loady při různé volné paměti (uživatel RAM naopak ubral z 11,4 na 9,5 GiB); limitování počtu modelů vyhozeno (stroj shodila host RAM, ne VRAM, a MAX_QUEUE nesahá na sekvenci loadů); upgrade na 0.34.0 nic řeší; OLLAMA_KV_CACHE_TYPE=q4_0 globálně rozbíjí modely s n_embd_head_k=80 (granite-code padl 6×, stále nastaveno, neopraveno); gemma4 se na stroj nevejde nikdy (Per-Layer Embeddings drží embeddingy na CPU záměrně, host drží 5901 MiB i při 16 GB volné VRAM; kontraintuitivně: čím prázdnější karta, tím spíš se mmap vypne).
Chyby v systemd konfiguraci: StartLimit* patří do [Unit] (v [Service] se tiše ignorují); systemctl show property je RestartUSec; MemoryMax nelimituje swap → s 32 GB swapu thrashing místo OOM killu, tvrdý strop až MemorySwapMax; instalátor ollamy bezpodmínečně přepisuje unit soubor (vlastní nastavení do drop-inu, ne kopírování unitu); limity z 12. 9. z override.conf nevysvětleně zmizely (21:10 zapsány, 21:44 pryč) — příčina nezjištěna, proto záloha override.conf.bak-20260913; v drop-inu překlep LLAMA_MAX_LOADED_MODELS (má být OLLAMA_).
Co nástroje neukážou: napinovanou paměť nevidí ps/nvidia-smi/systemd-cgtop/proc-meminfo (AnonPages 135 MiB, ale anon sum 9,4 GiB) — jediný indikátor je nr_foll_pin_acquired − nr_foll_pin_released v /proc/vmstat (skript ~/bin/nvidia-reload na nvidia.hell); sar dopad „unaccounted" paměti z 13:40 vysvětlen jako týž leak; restart ollamy leak neuvolní — paměť uteče z cgroup do system.slice, uvolní jen driver teardown/reboot; Proxmox ballooning nevhodný pro LLM stroje (počítá cíl z volné paměti hostitele, ~10 MB/s navýšení vs 17 s load modelu).
Opravené chybné závěry: spouštěčem nebyl LibreChat (jen zesilovač — retry po timeoutu), ale samotný model; embedding drží nanobot.hell (192.168.4.64), ne LibreChat — nanobot je zdroj dávek desítek requestů přes ~10 modelů; regrese 0.32.10 není jen Vulkan na iGPU (my CUDA + diskrétní karta, jiný spouštěč, stejný --load-mode none, potvrzuje #18373); leak vzniká i při zrušení loadu vlastním schedulerem po odpadnutí klienta (5,19 GiB) — nezáleží na tom, kdo llama-server ukončí, ale že to bylo uprostřed loadu.
Upstream (otevřené/neopravené): #18373 load regrese (2m34s vs 28s), #10104 zavřen bez řešení, #10341 gemma RAM na RTX 4060 Ti 16 GB (stejná karta, duplikát #10040), #8654 memory check vs mmap, #4895+PR#6854 mmap řízení. Problém široce hlášený, upstream neřeší.
Drobnosti k opravě (otevřené): zabbix-agent má defaultní Hostname=Zabbix server (má být nvidia); llama-server --log-verbosity 4 (journald žral 1,9 % CPU, zaplevelený journal); LibreChat titleConvo posílá druhý souběžný požadavek na týž model; earlyoom ve stavu rc — zbývá apt purge (na disku /etc/default/earlyoom a .bak).
Koresponduje s dřívějším zjištěním z projektu ai (2026-09-13): Ollama na nvidia.hell v praxi nepoužitelná, memory watchdog zabíjí llama-server. Tenhle report dodává root cause: kill uprostřed CUDA loadu → leak napinované paměti, kterou neukáží standardní nástroje.