Claude
74368100a3
The LXC was originally provisioned with the Dockge helper-script template, but the user moved on to Arcane. Dozzle stays as the log viewer (different role, not redundant). - docs/09 step 3: deployment goes via Arcane UI (not Dockge); reworded the deploy block accordingly. - docs/11 Q19: read the reference compose from Arcane, not Dockge. - docs/12 #33: was "stacks live in Dockge"; now "Arcane manages stacks, Dockge is stale, retire it" with the same tar-then-remove pattern as SiYuan and Open-WebUI. - docs/12 housekeeping campaign + #36: "walk every Arcane stack" rather than Dockge. - docs/13 Task 1: stack inventory comes from the Arcane UI (compose.yaml + .env screenshot/copy) rather than `ls /opt/stacks/` which was the Dockge default. The shell command for `docker ps -a` stays. - docs/02 Phase 6.1: Nexa polls Arcane (not Dockge) for inventory sync. - CLAUDE.md infra block: Arcane is the active manager, Dozzle is the log viewer, Dockge is stale; added services/dockge/ to the stale list alongside siyuan and open-webui.
4.7 KiB
13 — Information Wishlist
What additional system inventory would sharpen future decisions, packaged as the smallest set of paste-and-run tasks that still answers everything material. Each task is independent — run any subset, in any order.
Each task header tells you exactly where to run it (which shell or which UI). Output goes into a Memos draft, a comment in this conversation, or docs/inventory/<NN>-<slug>.txt — whichever is easiest.
Task 1 — Stack inventory + reference compose (highest leverage)
📍 Two halves — the canonical compose lives in the Arcane UI; the running-container view comes from a shell.
Locks Q19 (the SMB share name + driver options Nexa must mirror) and replaces screenshot-derived guesses about what's running.
(a) Reference compose — open Arcane in your browser → pick a clean small stack (Karakeep is a good choice) → screenshot or copy the compose.yaml and the .env (or whatever credential file is referenced). Just the volumes: block + the volume credential pattern is enough; everything else is bonus.
(b) Running-container view — Proxmox UI → Datacenter → nuc → LXC 104 (docker) → Console (or ssh root@192.168.1.40 from your PC):
docker ps -a --format '{{.Names}}\t{{.Image}}\t{{.Status}}' | sort
Unblocks: Q19, the housekeeping migration template (#36), Phase-3.1 deployment YAML.
Task 2 — Storage map (Proxmox + docker)
📍 Where: Two shells — first the Proxmox host (Datacenter → nuc → Shell, or ssh root@192.168.1.20), then back into the LXC 104 console.
Tells us which Proxmox storage backs what, and which docker volumes are local vs. SMB.
# (a) on the Proxmox host (192.168.1.20):
cat /etc/pve/storage.cfg
cat /etc/pve/lxc/104.conf
# (b) on LXC 104 (192.168.1.40):
docker volume ls
ls -l /dev/dri/ # confirms whether iGPU passthrough actually works
Unblocks: optimization #30 (iGPU), #36 (UNAS audit), B6/B7/C17.
Task 3 — Postgres / DB workload inventory
📍 Where: LXC 104 console (same shell as Task 1).
Direct input to housekeeping #35 (consolidate postgres instances).
for c in $(docker ps --format '{{.Names}}' | grep -iE 'postgres|mariadb|mysql|_db$'); do
echo "=== $c ==="
docker exec "$c" sh -c 'psql -U postgres -l 2>/dev/null || mysql -e "show databases" 2>/dev/null'
done
Unblocks: #35 (consolidate vs. migrate-to-SQLite decision).
Task 4 — LiteLLM model list for the Nexa key
📍 Where: Either the LiteLLM admin UI (one screenshot) or any shell with $SAIA_API_KEY exported.
- Screenshot path: open
https://ai.nuclide.systems(Lobehub) → Settings → Model List, filtered to the Nexa virtual key. Screenshot the model rows. - CLI path: any shell on your PC or the LXC, with
SAIA_API_KEYset:curl -sH "Authorization: Bearer $SAIA_API_KEY" \ https://ai.nuclide.systems/v1/models | jq '.data[].id'
Unblocks: Q18 follow-up — which embedding model SAIA proxies and at what dim, so we can decide if any flow can short-circuit TEI.
Task 5 — S3 archive credentials
📍 Where: s3.nuclide.systems admin UI in your browser (it's already proxied via Zoraxy — same login as the rest of the homelab).
Walk to: Buckets → either pick an existing Nexa-suitable bucket or create one called nexa → note the bucket name. Then Access Keys → create a key named nexa-snapshots with read/write on that bucket → drop the access-key + secret into Vaultwarden under "Nexa S3", and reply here with just the bucket name (the secret stays in Vaultwarden).
Unblocks: Q12, housekeeping #37 (S3 archive tier), Phase-3.3.
Task 6 — Reverse-proxy + DNS authority (only if needed)
📍 Where: two browser UIs.
- Zoraxy (
http://192.168.1.4:8000) → HTTP Proxy → either click "Export" if available, or take a full screenshot of the table. - AdGuard (
http://192.168.1.20LXC 102 web UI) → Filters → DNS Rewrites → screenshot.
Skip unless we hit a routing surprise during Phase 1.
When something else is needed
The smaller items (n8n credentials list, Memos webhook config, smartctl, sample of _sortMe/, what cron is failing) only matter when we touch that specific area. The agent will ask for them at the moment they're needed, with the same "📍 Where" framing.
Self-serve once Phase 6 ships
Once Phase 6 — Nexa as homelab steward lands, Nexa runs Tasks 1–3 itself on a schedule and folds the results into a daily drift report. This wishlist becomes a Nexa-managed surface (#nexa:wishlist-status) rather than something the user has to remember.