5.1 KiB
CLAUDE.md — bigboy-alma-deploy
This file is read automatically at the start of every Claude Code session in this repo. It captures standing decisions so they don't need to be re-explained or re-litigated each session. If something here conflicts with a task doc you've been handed, the task doc wins for that session — but flag the conflict rather than silently picking one.
What this repo is
Deployment automation for BigBoy — a Ryzen 5 / RTX 5060 Ti (16GB) AI inference server, running AlmaLinux 10.2. BigBoy also serves as the reference/testbed machine for CE's future RHEL + llama.cpp client deployments — meaning decisions made here are expected to generalize, not just work once.
Source of truth for status
plannng/STATUS.md is authoritative for what's actually done vs. pending.
Read it before starting work. Update it when a phase's status changes —
don't leave it stale.
Standing technical decisions (do not re-derive or second-guess these)
- OS: AlmaLinux 10.2, moved from NixOS due to RTX 5060 Ti driver friction on Nix. RHEL-family chosen fleet-wide for AI-server workloads for compliance/audit reasons (EU AI Act relevance), not just this one box.
- Inference engine: llama.cpp, built from source — deliberately not
Ollama. Reasons: full control over CUDA build flags and quantization,
built-in web UI via
llama-serverremoves the need for a separate Open WebUI layer. Ollama also just wraps llama.cpp's ggml engine underneath on NVIDIA/Linux anyway, so switching back would add a layer of indirection without avoiding the dependency. - GPU target:
-DCMAKE_CUDA_ARCHITECTURES=120(Blackwell / sm_120). Requires NVIDIA driver ≥570; target driver is595.84(seegroup_vars/bigboy.yml). - Known hazard: MXFP4-quantized models have open compilation issues on sm_120 as of mid-2026. Stick to standard GGUF quants — Q4_K_M or Q5_K_M — from established quantizers (Bartowski, Unsloth namespaces on Hugging Face). This sidesteps the issue entirely; it is not a performance preference, it's a build-stability one.
- Version discipline: llama.cpp has no semantic versioning — continuous
build-tagged releases only. Never build against
master/HEAD. Every build pins a specific tag, recorded ingroup_vars/bigboy.yml. - Build flags: standard only —
cmake -B build -DGGML_CUDA=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_CUDA_ARCHITECTURES=120. No exotic tuning flags (e.g.-DLLAMA_CUDA_MMV_Y) unless a specific, documented problem requires one. We are already deep in non-standard territory (Blackwell + Alma + sovereignty logging); the inference engine build itself should be as boring and reproducible as possible. - Serving:
llama-serverunder systemd, bound to127.0.0.1, fronted by nginx (reuse the existing CE reverse-proxy pattern from jahnet — don't invent a new one).--api-keyenforced even on LAN-only.--cont-batching --parallel Nfor concurrent chat sessions. - SELinux: stays enforcing. If early bring-up needs a permissive
discovery pass to collect AVC denials via
ausearch/audit2allow, that's a temporary diagnostic state, not a resting state — flip back to enforcing before considering the phase done.
Style requirements for any script in this repo
Follow the CE OS Bash Style Guide (Updated_Bash_Style_Guide in the CE
project knowledge) for every script:
- Attribution header (dwarves first, then John A. Hoeven / Claude AI), licence (Unlicense), version, status
- No
set -e— every operation checked and logged explicitly - Cleanup trap registered before work begins
- Single confirmation prompt before any system-modifying action
- No silent failures — every error path logs and either hard-fails or warns
- Never assume root; invoke
sudoexplicitly for privileged steps only
This repo is a single-purpose ops repo for one Alma server, not part of the
CEOS multi-distro installer framework — so skip the ce_env.conf /
pkg_* / CE_PRIV abstraction layer specifically. Use sudo directly.
Everything else in the style guide applies.
Explicitly deferred — do not build unless a task doc asks for it
An auditable testing/release system for llama.cpp (versioned releases,
btrfs snapshot safety net, promote/rollback via symlink swap, a Forgejo
mirror that only ever receives BigBoy-validated tags so client
deployments never pull raw upstream) was designed in detail on
2026-07-16, but is not yet built or integrated into the phase plan.
Draft, untested scripts from that design may exist under scripts/draft/.
Do not wire them into the active Ansible roles or treat them as
representing current repo state — they're a reference for later, not a
task in progress. Bringing BigBoy up and running is the current priority;
this gets picked up afterward.
Scope discipline
Task docs will name a specific phase or task from STATUS.md. Do the
named task. Don't refactor, "improve," or extend adjacent phases that are
already marked complete or reviewed, even if something nearby looks
improvable — flag it instead and let it be a deliberate decision, not a
side effect.