Files
nexa/docs/13-information-wishlist.md
Claude a8446f8371 Q19 resolved: storage convention is plain host bind-mount, not SMB volume
The Karakeep compose user shared confirms every container in LXC 104
uses host bind-mounts of /mnt/pve/unas/services/<svc>/<vol> directly.
No driver_opts, no CIFS, no per-volume credentials. The earlier
SMB-as-docker-volume proposal in this repo was over-fitting to the
Nextcloud-specific NFS issue and is withdrawn.

The Nextcloud failure was Nextcloud-specific: its setup tooling chowns
the data dir to www-data, which fails against root_squash exports.
Normal containers don't trigger that path, so plain bind-mounts work
fine.

Changes:

- docs/09 §Step 3: compose block dropped from ~30 lines (volume,
  driver_opts, CIFS device, credentials env) to a one-line bind-mount
  + env_file. Added a pre-deploy `mkdir -p` for the UNAS service +
  backup paths. Explanatory note retained for future agents.
- docs/12 #27 marked withdrawn pointing to #31. #31 rewritten with the
  bind-mount pattern (was SMB-default). #36 (UNAS audit) now looks for
  `- /var/lib/docker/...` or anonymous volumes as the non-compliant
  signal.
- CLAUDE.md storage block: bind-mount is the standard, SMB is
  documented escape-hatch only.
- docs/11: Q19 moved into Resolved with the new framing. Q12 + Q20
  grouped under a new "## Backups" section header (the now-empty
  "Verification needed" section removed).
- docs/13 Task 1 struck through with done-marker pointing to docs/09.

Net: Phase-3.1 deployment YAML is now actually deployable as written.
2026-05-05 05:01:48 +00:00

97 lines
4.2 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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~~ ✅ DONE
User pasted the Karakeep compose. Q19 resolved → host bind-mount of `/mnt/pve/unas/services/<svc>/<vol>` is the convention. Nexa stack updated in [docs/09 §Step 3](./09-deployment.md#step-3--self-hosted-embeddings-tei). The `docker ps -a` half (running-container inventory) is still useful when we get to housekeeping #36 (UNAS-integration audit) — but that's not blocking now.
---
## 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.
```bash
# (a) on the Proxmox host (192.168.1.20):
cat /etc/pve/storage.cfg
cat /etc/pve/lxc/104.conf
```
```bash
# (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).
```bash
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_KEY` set:
```bash
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.20` LXC 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](./02-roadmap.md#phase-6--nexa-as-homelab-steward) lands, Nexa runs Tasks 13 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.