a8446f8371
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.
97 lines
4.2 KiB
Markdown
97 lines
4.2 KiB
Markdown
# 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 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.
|