feat: Phase 9 gaps closed — ApprovalService.Decide convergence, execlog fold, execworker poller

- ApprovalService (core/app/approval.go) + ApprovalRepo (postgres adapter) with
  full decide transaction: HMAC token verify, approval flip, execution un-gate,
  session-scoped window keys (+session suffix matching GovernanceStore gate),
  nomos session flip, audit+event on failure abort. httpapi DecideApproval now
  a thin presenter delegating to the service. ListPending payload format fixed
  (json.Unmarshal not raw-wrap).
- execlog folded into postgres adapter: internal/execlog deleted, NewExecutionLog
  / ReadExecutionLog live in the db package, callers updated (mcp, httpapi).
- execworker poller over ExecutionService.DispatchQueued: advisory lock leak
  fixed (defer/recover per execution), correlation_id preserved via Finalize
  event emission (ExecRunRepo.Finalize now emits execution.{status} with
  correlation_id from the row).
- Phase 8 session export-rename completed: Store, New, and all 53 methods
  exported; cmd/nomos/ agent.go fixed to use session.PendingContinuation etc.
- Coverage gates: ExecutionService.Submit 93.1%, PolicyService.Decide 100%.
- Plans index updated, VERSION bumped to 0.36.0.

.agents/OIKOS.md

@@ -30,9 +30,9 @@ one pass through **Observe → Orient → Decide → Act**:
    - **queue**: informational — console + reports
    The classifier can only *lower* autonomy relative to policy, never raise
    it. When in doubt, escalate.
-4. **Act** — execute through `homelab` commands or runbooks (never ad-hoc
+4. **Act** — execute through MCP `run` or runbooks (never ad-hoc
-   SSH), then **verify** with the action's verification command, write a
+    SSH), then **verify** with the action's verification command, write a
-   **ledger** entry, resolve the Signal, and update docs in the same session.
+    **ledger** entry, resolve the Signal, and update docs in the same session.
 
 ## Primitives
 
@@ -88,7 +88,7 @@ via the API's `/api/v1/graph` endpoint, and the Mermaid export at
 ## Conventions carried forward
 
 - Inventory is the truth; live state wins over narrative docs.
-- Prefer `homelab` CLI and MCP over ad-hoc SSH.
+- Prefer MCP tools over ad-hoc SSH.
 - Meaningful changes update docs in the same session.
 - Secrets are decrypted locally via per-client keys; never into docs/comments.
 - Tracked configs change by commit + push, not local edits.
@@ -141,7 +141,7 @@ in the Go binary.
 - Standalone Nomos MCP client binary (`cmd/nomos`) with gateway mode
   (:8092). Structured queries + natural-language routing to the MCP tool
   list (see AGENTS.md §3). Agent activity logging on every tool call. No SSH keys.
-- `nomos/` directory with config, SOUL.md, homelab-ops skill.
+- `nomos/` directory with config, SOUL.md, `homelab-ops` skill at `nomos/skills/homelab-ops/`.
 - Nomos Docker service in `docker-compose.yml` (profile: full).
 - Go packages: `cmd/nomos/`, `compose/nomos/`.
 

.agents/dev/CONTRIBUTING.md

@@ -14,9 +14,9 @@ cmd/webhook/main.go        Gitea deploy-webhook receiver (push-to-deploy on mac-
 internal/httpapi/           REST + MCP server. Chi router. OpenAPI-generated types from
                              internal/httpapi/gen/api.gen.go. Strict server in impl.go.
 internal/mcp/               MCP tool implementations (get_entity, search_knowledge, etc.)
-internal/db/                Connection pool (pool.go), seed ingestion (seed.go), DB→YAML
+internal/adapters/postgres/  Connection pool (pool.go), seed ingestion (seed.go), DB→YAML
                              export (export.go), type hierarchy (typetree.go)
-internal/db/queries/        SQL query files → sqlc generates internal/db/sqlcgen/
+internal/adapters/postgres/queries/  SQL query files → sqlc generates sqlcgen/ (same dir)
 internal/scheduler/         Observe loop: probes, signals, check_defs
 internal/actuator/          SSH execution with circuit breaker + retry
 internal/learning/          Pattern extraction, anomaly detection
@@ -27,8 +27,6 @@ internal/domain/            Core types: entities, approvals, executions, signals
 internal/ontology/          Type hierarchy validation, relationship checks
 internal/knowledge/         Knowledge YAML seed ingestion
 internal/config/            Config loading from env vars
-web/                         Control-room SPA (Svelte 5) — standalone static build, not
-                             embedded in the oikos binary (plans/2026-07-12-wails-desktop-app.md)
 api/openapi.yaml            REST API contract. Source of truth for endpoints.
 api/codegen.yaml            oapi-codegen config → generates internal/httpapi/gen/
 migrations/                 Forward-only SQL. Format: NNN_name.up.sql. No down migrations.
@@ -93,8 +91,8 @@ current phase status). To add a new capability:
 
 ## SQL conventions
 
-- Queries live in `internal/db/queries/*.sql` with `-- name: FuncName :exec`
+- Queries live in `internal/adapters/postgres/queries/*.sql` with `-- name: FuncName :exec`
-  annotations for sqlc. Generated code in `internal/db/sqlcgen/` — never
+  annotations for sqlc. Generated code in `internal/adapters/postgres/sqlcgen/` — never
   hand-edit. Call via `sqlcgen.New(pool).QueryName(ctx, params)`.
 - **sqlc is the default** for all DB access. Raw `pool.Query/Exec` with inline
   SQL is a documented carve-out for cases sqlc can't express: `LISTEN`/`NOTIFY`,

.agents/domains/knowledge/schema.md

@@ -20,7 +20,7 @@ investigations, runbooks) in the `knowledge_entities` table.
 | Knowledge content — documents, investigations, runbooks | `knowledge_entities` table (rows linked to `entities` via `documents` / `about` edges) | Seeded from `seeds/knowledge.yaml` at deploy; mutated at runtime via the API |
 | Seed manifest (bootstrap + DR) | `seeds/knowledge.yaml` | Hand-edited or regenerated; ingested idempotently (content-hashed via `seed_versions`) |
 | Structured graph — hosts, services, entity types, relationships | `entities`, `relationships`, `entity_types` tables | Seeded from `seeds/{ontology,inventory}.yaml`; mutated via API/MCP |
-| Archived narrative wiki (read-only history) | `archive/knowledge/` | Frozen 2026-07-07 when the DB became source of truth |
+| Archived narrative wiki (read-only history) | `archive/knowledge/` (deleted 2026-08-16) | Frozen 2026-07-07 when the DB became source of truth; no longer in repo |
 
 ### Seed ingest
 
@@ -67,9 +67,9 @@ Agents register or update knowledge through the API, not by editing the seed:
 
 - The per-document **`## Changelog`** records infrastructure changes to that node. Keep the
   `### YYYY-MM-DD — title` shape so the parsed `changelog` field stays structured.
-- **`archive/knowledge/log.md`** is the append-only record of *documentation-maintenance*
+- **`archive/knowledge/log.md` (deleted)** is the append-only record of *documentation-maintenance*
   operations on the legacy wiki (restructures, source ingests, lint sweeps):
-  `## [YYYY-MM-DD] <op> | <summary>`. It is frozen with the rest of `archive/knowledge/`; new
+  `## [YYYY-MM-DD] <op> | <summary>`. It is frozen; new
   doc-maintenance operations are recorded in the DB audit trail instead.
 
 ## Querying knowledge
@@ -82,7 +82,7 @@ Use MCP, not grep:
   entity, in one call.
 - `get_entity(slug)` / `get_relations(entity)` — the structured graph around an entity.
 
-Grep the clone only when MCP is unreachable, and prefer `archive/knowledge/` for historical
+Grep the clone only when MCP is unreachable, and prefer the DB for all queries
 narrative (it is not updated when the DB changes).
 
 ## Same-session update rule
@@ -90,4 +90,4 @@ narrative (it is not updated when the DB changes).
 A change to a node updates the DB in the same session — the entity's attributes, the relationships
 that reference it, and any document whose `at_glance` or changelog should reflect the new state. See
 [page-templates.md](../../shared/page-templates.md#same-session-update-rule) for the legacy wiki
-equivalent (now scoped to `archive/knowledge/` history).
+equivalent (deleted).

.agents/domains/operations/schema.md

@@ -8,7 +8,7 @@ exception.
 Where each kind lives: runbooks are skills under [`.agents/skills/`](../../skills/); operator
 reference (command cheatsheet, enrollment, Nomos agent) lives in
 [`.agents/operations/`](../../operations/); investigations are `investigation` entities in the DB
-(historically `archive/knowledge/sources/investigations/`); plans stay in the repo-root `plans/`
+(historically investigation entities in the DB); plans stay in the repo-root `plans/`
 folder (below).
 
 ## Plans always live in `plans/`
@@ -49,7 +49,7 @@ Incident records are `investigation` entities in the DB, linked to the entities
 `about` edges. They are **evidence sources** — written once at incident time, then back-linked from
 the changelogs of the nodes they implicate. Sections: `## Summary`, `## Timeline`, `## Root cause`,
 `## Mitigations applied`, `## Open questions`. The legacy file-based investigations live at
-`archive/knowledge/sources/investigations/` (frozen 2026-07-07); new investigations go in the DB.
+investigation entities in the DB.
 
 ## The operations log
 

.agents/operations/commands.md

@@ -1,6 +1,6 @@
 # Operations cheatsheet
 
-Run from the [hubris host](../../archive/knowledge/hosts/hubris.md) as root. When working from `/root` on Linux you're already on hubris — don't `ssh hubris` / `ping hubris`.
+Run from the hubris host as root. When working from `/root` on Linux you're already on hubris — don't `ssh hubris` / `ping hubris`.
 
 ## Proxmox CLI
 
@@ -8,13 +8,13 @@ Run from the [hubris host](../../archive/knowledge/hosts/hubris.md) as root. Whe
 | --- | --- |
 | `pct list` / `qm list` | List LXC containers / VMs |
 | `pct config <id>` / `qm config <id>` | Container / VM config |
-| `pct exec <id> -- <cmd>` | Run command inside an LXC without entering it (no initgroups — see [media permissions](../../archive/knowledge/infrastructure/media-permissions.md)) |
+| `pct exec <id> -- <cmd>` | Run command inside an LXC without entering it (no initgroups — see [media permissions](../../../docs/infrastructure/media-permissions.md)) |
 | `pct enter <id>` | Shell into a container |
 | `pct start <id>` / `pct stop <id>` | Boot / halt a container |
 | `pvesm status` | Storage pools status |
 | `pvesh get /nodes --output-format json` | Node summary as JSON |
 | `pvesh get /nodes/hubris/lxc/<id>/status/current` | Live container status |
-| `pvesh get /cluster/resources --type vm --output-format json` | Bulk per-LXC CPU/mem/disk (used by the `homelab-health-watchdog` Nomos cron — see [monitoring](../../archive/knowledge/infrastructure/monitoring.md); the old `claudio-monitor` this once fed is deprecated) |
+| `pvesh get /cluster/resources --type vm --output-format json` | Bulk per-LXC CPU/mem/disk (used by the `homelab-health-watchdog` Nomos cron — see [monitoring](../../../docs/infrastructure/monitoring.md); the old `claudio-monitor` this once fed is deprecated) |
 | `pveversion` | PVE version |
 | `journalctl -u pve-cluster -n 100` | PVE service logs |
 
@@ -22,22 +22,22 @@ Run from the [hubris host](../../archive/knowledge/hosts/hubris.md) as root. Whe
 
 - Shared mount: `/mnt/library` (ext4 on lvmthin `library`).
 - Bind into a container: `pct set <id> -mp<N> /mnt/library/<sub>,mp=/data`
-- For the standard whole-tree mount: `pct set <id> -mp0 /mnt/library,mp=/mnt/library`. See [media permissions](../../archive/knowledge/infrastructure/media-permissions.md) for the GID-10000 onboarding recipe.
+- For the standard whole-tree mount: `pct set <id> -mp0 /mnt/library,mp=/mnt/library`. See [media permissions](../../../docs/infrastructure/media-permissions.md) for the GID-10000 onboarding recipe.
 
 ## Reverse proxy
 
-- Caddyfile: `/etc/caddy/Caddyfile` on [LXC 121](../../archive/knowledge/containers/121-caddy.md).
+- Caddyfile: `/etc/caddy/Caddyfile` on LXC 121.
-- **CRITICAL:** This file is tracked in `dtoro/caddy-conf` (https://git.hubris.network/dtoro/caddy-conf). Never edit it directly on the LXC — commit + push to the repo instead. Caddy auto-deploys on push (see [auto-deploy](../../archive/knowledge/infrastructure/auto-deploy.md)). If you edit directly, the change will be lost on the next pull and agents won't know about it.
+- **CRITICAL:** This file is tracked in `dtoro/caddy-conf` (https://git.hubris.network/dtoro/caddy-conf). Never edit it directly on the LXC — commit + push to the repo instead. Caddy auto-deploys on push (see [auto-deploy](../../../docs/infrastructure/auto-deploy.md)). If you edit directly, the change will be lost on the next pull and agents won't know about it.
 - Hot reload: `pct exec 121 -- systemctl reload caddy`.
 - Validate: `pct exec 121 -- caddy validate --config /etc/caddy/Caddyfile`.
 - Git workflow shortcut: `pct exec 121 -- "cd /etc/caddy && git add Caddyfile && git commit -m '...' && git push"`.
 
 ## DNS
 
-- Split-horizon authority: [Technitium DNS](https://technitium.com) on [dns (107)](../../archive/knowledge/containers/107-dns.md) at `192.168.8.2:53`. Web UI at `http://192.168.8.2`. (Formerly dnsmasq on the now-destroyed LXC 124 — decommissioned 2026-06-04.)
+- Split-horizon authority: [Technitium DNS](https://technitium.com) on dns (107) at `192.168.8.2:53`. Web UI at `http://192.168.8.2`. (Formerly dnsmasq on the now-destroyed LXC 124 — decommissioned 2026-06-04.)
 - Add/edit records in the Technitium UI; the NetBird managed zone sync (`scripts/dns-sync.py` cron on 107) picks changes up within ~10 minutes.
 - Verify: `dig @192.168.8.2 +short <host>.hubris.network`.
-- See [DNS](../../archive/knowledge/infrastructure/dns.md).
+- See [DNS](../../../docs/infrastructure/dns.md).
 
 ## Web access
 
@@ -49,7 +49,7 @@ Run from the [hubris host](../../archive/knowledge/hosts/hubris.md) as root. Whe
 - `ras-mc-ctl --errors` — full event log
 - `cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference` — should be `balance_power`
 - `cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor` — should be `powersave`
-- `ls /sys/fs/pstore/ /var/lib/systemd/pstore/` — panic traces from a previous crash (empty for pure hardware hangs — see [investigation](../../archive/knowledge/investigations/2026-04-21-hubris-crash-loop.md))
+- `ls /sys/fs/pstore/ /var/lib/systemd/pstore/` — panic traces from a previous crash (empty for pure hardware hangs — see investigation)
 
 ## Fleet apt operations
 
@@ -81,13 +81,15 @@ the REST API. Closest current equivalents for what used to live here:
 | `homelab decide <action> <entity>` | No direct equivalent — classification now happens inline inside `run`, not as a separate dry-run call |
 
 There is no separately-deployed "Oikos Console" anymore — the control-room
-SPA (`web/`) is the operator dashboard, served standalone (see
+SPA is the operator dashboard. It lives in its own repo
-[plans/done/2026-07-12-wails-desktop-app.md](../../plans/done/2026-07-12-wails-desktop-app.md)).
+(`dtoro/oikos-web`, local checkout `~/Projects/oikos-web`) with its own
+deploy pipeline, publishing the same host port 8091 as before (Phase 1 of
+[plans/2026-08-15-hexagonal-architecture.md](../../plans/2026-08-15-hexagonal-architecture.md)).
 
 ## Related
-- [Hubris host](../../archive/knowledge/hosts/hubris.md)
+- Hubris host
-- [Containers index](../../archive/knowledge/containers/index.md)
+- Containers index
-- [DNS](../../archive/knowledge/infrastructure/dns.md)
+- [DNS](../../../docs/infrastructure/dns.md)
 - [Monitoring](../../archive/knowledge/infrastructure/monitoring.md)
 - [Auto-deploy](../../archive/knowledge/infrastructure/auto-deploy.md)
 - [Runbook: dpkg-interrupted recovery](../skills/runbook-dpkg-interrupted/SKILL.md) — what to do when apt got killed mid-transaction

.agents/shared/llm-wiki.md

@@ -18,18 +18,18 @@ DB-native model.
   `seed_versions`) and mutated at runtime via the API/MCP. `oikos export` regenerates
   `seeds/{ontology,inventory,policy}.yaml` for version control.
 - **Sources** are immutable raw material: incident records (now `investigation` entities in the DB,
-  historically `archive/knowledge/sources/investigations/`), external reference docs, and the live
+  historically investigation entities in the DB), external reference docs, and the live
   system itself (`pct config`, `docker inspect`). Read them; do not rewrite them into other sources.
 - **Wiki** — the synthesized, authoritative current-state layer. Today this is the set of
   `document` entities in the DB (one per node and per cross-cutting system), queried via MCP
   `search_knowledge` / `get_entity_knowledge`. The legacy file-based wiki is frozen at
-  `archive/knowledge/{hosts,containers,vms,infrastructure}/` for historical reference only.
+  (deleted — DB is sole source of truth).
 - **Index** (`index.md` / folder `README.md`) is a pure listing — every page in scope with a
   one-line summary, and nothing else. Anything the section wants to say up front goes into a page
   the index lists, not into the index.
 - **Log** is append-only, recording *doc-maintenance operations* (restructures, source ingests,
   lint sweeps) in single-line format: `## [YYYY-MM-DD] <op> | <summary>`. The active log is the DB
-  audit trail; `archive/knowledge/log.md` is the frozen legacy equivalent.
+  audit trail; frozen legacy log was deleted with the archive.
 
 ## Two logs, kept distinct
 

.agents/shared/page-templates.md

@@ -118,7 +118,7 @@ What it looks like after.
 Changelog entries to write, index status to update.
 ```
 
-### Investigation (`investigation` entity in the DB; historically `archive/knowledge/sources/investigations/YYYY-MM-DD-slug.md`)
+### Investigation (`investigation` entity in the DB; historically in `archive/knowledge/sources/investigations/`, now deleted)
 
 ```markdown
 # YYYY-MM-DD — <title>

.agents/skills/config-change-deploy/SKILL.md

@@ -20,7 +20,7 @@ own repo) and get it live, safely.
    [OIKOS.md](../../OIKOS.md) conventions).
 3. Make the change, commit, push to `main`.
 4. The Gitea webhook fires the deploy pipeline for that repo (see
-   [infrastructure/auto-deploy.md](../../../archive/knowledge/infrastructure/auto-deploy.md) for
+   [infrastructure/auto-deploy.md](../../../docs/infrastructure/auto-deploy.md) for
    the exact receiver/reload for this service).
 5. Run the preflight's verification command. If it fails, check
    MCP `tail_log` for the reload/restart error.

.agents/skills/docs-lint/SKILL.md

@@ -14,12 +14,11 @@ links. Prose-voice rules are not machine-checkable — those stay a review respo
 
 Run from the repo root:
 
-    python3 .agents/skills/docs-lint/lint.py            # default: knowledge/ .agents/ operations/ investigations/ plans/
+    python3 .agents/skills/docs-lint/lint.py            # default: .agents/ operations/ plans/
-    python3 .agents/skills/docs-lint/lint.py archive/knowledge/containers/104-gitea.md
 
 Exit code is non-zero when any violation is found, so it can gate a commit. The banned-vocabulary
 list mirrors `writing-style.md`; update both together if the standard changes.
 
-> **Known baseline.** `archive/knowledge/archive/knowledge/containers/101-jellyfin.md` links into a sibling repo
+> **Known baseline.** The sibling repo `dtoro/caddy-conf` is not part of this checkout,
-> (`devops/homelab-authentik-admin`) that this checkout does not contain — expected, not a bug.
+> so links into it produce false positives — expected, not a bug.
 > Any other broken link is a real regression; investigate before dismissing it as baseline noise.

.agents/skills/knowledge-graph-audit/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: knowledge-graph-audit
+risk_class: read_only
+inputs: []
+verification: "audit_knowledge_graph returns a report with summary.total_findings"
+docs_update_checklist: []
+---
+
+# Knowledge-graph audit
+
+Goal: validate that the knowledge graph (entities, relationships, checks) and
+the monitoring built on it reflect live reality — without mutating anything.
+Read-only. Run this before trusting health, blast-radius, or coverage answers,
+and whenever something feels off (a healthy host reports `down`, a retired
+service still alarms, the graph looks thin).
+
+## 1. Run the drift report
+
+Call MCP `audit_knowledge_graph` (or `GET /api/v1/audit/drift`). It returns a
+ranked list of findings, each with `{category, severity, count, entities,
+evidence, suggested_runbook}`, plus a `summary` with totals by category.
+
+The DB-side categories:
+
+- **orphan_checks** — check entities with truncated/random slugs left by the
+  old `shortSlug()` collision bug. Remediation: `scripts/cleanup-orphan-checks.sh`.
+- **dead_checks** — enabled `check_defs` whose target entity is `deprecated`/
+  `destroyed`. Remediation: `lifecycle-deprecate-node` / `lifecycle-destroy-node`
+  (the scheduler already skips these, but the rows should be retired).
+- **down_checks** — enabled probes reporting `down`. Remediation:
+  `service-health-check` (then check whether the failure is real or a
+  probe-config/routing problem — see step 3).
+- **unknown_checks** — probes that ran but reported `unknown` (usually a
+  misconfigured or not-yet-deployed probe script).
+- **unmonitored** — active entities whose type declares monitoring but have no
+  enabled `check_def`.
+- **dangling_edges** — live `hosts`/`provides`/`mounts` edges still pointing at
+  destroyed/deprecated targets. Remediation: `lifecycle-destroy-node`.
+
+## 2. Triage
+
+`severity: critical` (down_checks) first. For each finding, read `evidence` and
+open the entities with `get_entity` / `get_relations` to confirm the diagnosis
+before acting — the report is a pointer, not a verdict.
+
+## 3. Common probe-failure causes
+
+A `down_checks` finding that is NOT a real outage is usually one of:
+
+- **Guest reached wrong** — an LXC/VM check SSHed the guest directly instead of
+  routing through its Proxmox host. Confirm with `get_relations` that a `hosts`
+  edge exists and the guest has `pve_id`; checks route via `pct exec`/`qm guest
+  exec` automatically when both are present.
+- **Script not deployed** — the probe script is absent at `/opt/oikos/checks/`
+  inside the target. Remediation: redeploy via `tools/deploy-checks.sh`.
+- **macOS host** — a workstation check used the wrong SSH user or a Linux-only
+  script flag. The scheduler resolves `user: dtoro` from the entity attribute.
+
+## 4. What this audit does NOT cover (follow-ups)
+
+Live-infrastructure discovery has its own tool — run **`discover_infra_drift`**
+alongside this one. It compares running Proxmox guests (`pct`/`qm list` on every
+proxmox host) against the DB graph and returns:
+
+- **missing entities** — a guest running in Proxmox with no DB entity.
+- **ghost entities** — a DB lxc/vm whose `pve_id` is no longer live.
+
+Still manual until that machinery lands:
+
+- **Misplaced parent** — compare each guest's actual Proxmox host against its
+  `hosts` edge (migrations leave these stale).
+- **Undeployed scripts** — per-guest `/opt/oikos/checks/` presence.
+- **Unmodeled certs** — now modeled; verify with `audit_knowledge_graph` /
+  the cert-expiry checks.
+- **Seed drift** — run `oikos export` and `git diff seeds/` to find
+  runtime-created entities not in version control.
+
+## 5. Acting on findings
+
+This skill is read-only — make no changes here. Route each confirmed finding to
+its `suggested_runbook`, classify the action against `seeds/policy.yaml`, and
+proceed through the normal lifecycle/approval flow. Re-run the audit afterward
+to confirm the finding cleared.
+
+Docs-update checklist: none — the audit reads state; it changes nothing. If a
+finding reveals stale `risk_notes` or a wrong `doc_page`, fix `inventory.yaml`
+in that remediation session.

.agents/skills/lifecycle-destroy-node/SKILL.md

@@ -36,8 +36,9 @@ ledger entry.
 6. Update the entity's `state` to `destroyed` in `seeds/inventory.yaml`
    (or move it to an `archaeology:`-style section if the schema still has
    one) — `pve_id`, `destroyed` date, `reason` — then `oikos seed` to
-   ingest. Add a row to `containers/index.md` "Recently destroyed" table
+ingest. Add a row to the legacy `archive/knowledge/containers/index.md`
-   (kept for human-readable browsing alongside the structured data).
+    "Recently destroyed" table (kept for human-readable browsing
+    alongside the structured data in the DB).
 7. No manual ledger step — mutations through the API are recorded
    automatically in the `audit_log` table (MCP `get_audit_trail`,
    `get_change_history`). The old `oikos/ledger.py append` was retired

.agents/skills/lifecycle-migrate-node/SKILL.md

@@ -10,7 +10,7 @@ transition: "active -> migrating -> active"
 # Lifecycle: migrate a node
 
 Modeled on the strong Phase 1+2 migration
-([archive/hermes-plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md](../../../archive/hermes-plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md)).
+(the strong Phase 1+2 migration).
 Requires (ontology): preflight + backup-verified before migrating;
 post-verify + Caddy backends checked + mounts checked + docs updated
 before returning to `active`.
@@ -32,7 +32,7 @@ before returning to `active`.
 7. MCP `get_service_status` for every service the node hosts.
 8. Set `state: active`. Add a migration note to the node's doc page
    (old host/IP → new, date, phase reference) — this repo's convention
-   for every past migration (see `archive/knowledge/containers/101-jellyfin.md`,
+   for every past migration (see archived container docs,
    `containers/129-house.md`).
 
 Regenerate: `oikos seed` (re-ingests `seeds/inventory.yaml` into the DB —

.agents/skills/lifecycle-provision-node/SKILL.md

@@ -27,9 +27,10 @@ chosen, doc page stub.
    will self-enroll as a client afterward (see
    [CLIENTS.md](../../../CLIENTS.md#enrollment)), the entity must exist in
    `planned`/`provisioning` state before `bootstrap.sh` runs there.
-3. Stub the doc page (`containers/<pve_id>-<name>.md` or
+3. Stub a document entity via MCP `upsert_knowledge` with
-   `vms/<pve_id>-<name>.md`) — even a one-line "provisioning, see plan X"
+    `kind: document` and about set to the new entity slug — even a
-   is enough to satisfy the transition requirement.
+    one-line "provisioning, see plan X" is enough to satisfy the
+    transition requirement.
 4. Reserve the IP in DNS/DHCP notes if it's a fixed LAN address.
 
 Next: [lifecycle-activate-node.md](../lifecycle-activate-node/SKILL.md).

.agents/skills/runbook-dpkg-interrupted/SKILL.md

@@ -106,8 +106,8 @@ Then `systemctl status apt-recovery` from a fresh ssh to check progress.
 ## Related
 
 - [Operations cheatsheet](../../operations/commands.md)
-- [Auto-deploy pipelines](../../../archive/knowledge/infrastructure/auto-deploy.md)
+- [Auto-deploy pipelines](../../../docs/infrastructure/auto-deploy.md)
-- [Hubris host page](../../../archive/knowledge/hosts/hubris.md)
+- Hubris host page
 
 ## Changelog
 

.agents/skills/session-review/SKILL.md

@@ -77,6 +77,8 @@ Session: {id[:8]} — "{title[:60]}"
 - `cmd/nomos/store.go` — session + message persistence
 - `internal/mcp/server.go` — all tool implementations (`run`, `list_lxcs`, …)
 - `web/src/lib/components/ToolCallGroup.svelte` — tool result display
+  (in the `dtoro/oikos-web` repo, `~/Projects/oikos-web`, since the
+  Phase 1 client extraction)
 - `nomos/SOUL.md` — agent persona and tool selection rules
-- `plans/2026-07-09-chat-sessions-improvements.md` — prior session findings
+- `plans/done/2026-07-09-chat-sessions-improvements.md` — prior session findings
-- `plans/2026-07-09-session-execution-and-ux-fixes.md` — latest plan
+- `plans/done/2026-07-09-session-execution-and-ux-fixes.md` — latest plan

.claude/launch.json

@@ -1,12 +0,0 @@
-{
-  "version": "0.0.1",
-  "configurations": [
-    {
-      "name": "web",
-      "runtimeExecutable": "sh",
-      "runtimeArgs": ["-c", "export OIKOS_API_TOKEN=$(docker inspect -f '{{range .Config.Env}}{{println .}}{{end}}' oikos-api-1 | sed -n 's/^OIKOS_MCP_BEARER_TOKEN=//p'); exec npm --prefix web run dev"],
-      "port": 5173,
-      "autoPort": true
-    }
-  ]
-}

.dockerignore

@@ -0,0 +1,12 @@
+# Every docker build in this repo previously sent the whole directory as
+# build context — including every OTHER git worktree under .claude/worktrees/
+# (each with its own web/node_modules, ~200-300MB apiece). That's what
+# starved the mac-mini's disk mid-build on 2026-07-27 (SHA 873b00a): the
+# context alone crossed 390MB of pure worktree cruft before the host ran out
+# of space. None of this ever belonged in an image.
+.claude/worktrees/
+.git/
+**/node_modules/
+**/dist/
+**/build/
+*.log

.gitea/workflows/ci.yml

@@ -70,30 +70,3 @@ jobs:
       - uses: actions/checkout@v4
       - name: docker build (verify image builds; no push)
         run: docker build -f compose/oikos/Dockerfile -t oikos:ci .
-
-  web:
-    runs-on: ubuntu-latest
-    defaults:
-      run:
-        working-directory: web
-    steps:
-      - uses: actions/checkout@v4
-      - uses: actions/setup-node@v4
-        with:
-          node-version: '22'
-          cache: npm
-          cache-dependency-path: web/package-lock.json
-      - run: npm ci
-      - name: svelte-check (advisory — baseline not yet clean)
-        run: npm run check
-        continue-on-error: true
-      - name: eslint (advisory — baseline not yet clean)
-        run: npm run lint
-        continue-on-error: true
-      - name: prettier format check (advisory — baseline not yet clean)
-        run: npm run format:check
-        continue-on-error: true
-      - name: test
-        run: npm run test
-      - name: build
-        run: npm run build

.gitea/workflows/desktop.yml

@@ -1,70 +0,0 @@
-name: Desktop App
-on:
-  push:
-    branches:
-      - main
-    tags:
-      - 'desktop-*'
-      - 'v[0-9]+.[0-9]+.[0-9]*'
-
-jobs:
-  build:
-    name: Build Linux (amd64)
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/checkout@v4
-
-      - uses: actions/setup-node@v4
-        with:
-          node-version: '22'
-
-      - run: npm ci
-        working-directory: web
-
-      - run: npm run build
-        working-directory: web
-
-      - run: |
-          rm -rf cmd/desktop/frontend/dist
-          mkdir -p cmd/desktop/frontend/dist
-          cp -r web/dist/* cmd/desktop/frontend/dist/
-
-      - uses: actions/setup-go@v5
-        with:
-          go-version: '1.26'
-
-      - run: |
-          sudo apt-get update
-          sudo apt-get install -y libgtk-3-dev libwebkit2gtk-4.1-dev
-
-      - run: CGO_ENABLED=1 go build -o build/bin/Oikos .
-        working-directory: cmd/desktop
-
-      - run: |
-          cd cmd/desktop/build/bin
-          tar czf oikos-desktop-linux-amd64.tar.gz Oikos
-          sha256sum oikos-desktop-linux-amd64.tar.gz > oikos-desktop-linux-amd64.tar.gz.sha256
-
-      - uses: actions/upload-artifact@v4
-        with:
-          name: oikos-desktop-linux-amd64
-          path: |
-            cmd/desktop/build/bin/oikos-desktop-linux-amd64.tar.gz
-            cmd/desktop/build/bin/oikos-desktop-linux-amd64.tar.gz.sha256
-
-  release:
-    name: Attach to Release
-    needs: build
-    runs-on: ubuntu-latest
-    if: startsWith(github.ref, 'refs/tags/')
-    steps:
-      - uses: actions/download-artifact@v4
-        with:
-          name: oikos-desktop-linux-amd64
-
-      - uses: https://gitea.com/actions/release-action@v1
-        with:
-          files: |
-            oikos-desktop-linux-amd64.tar.gz
-            oikos-desktop-linux-amd64.tar.gz.sha256
-          api_key: ${{ secrets.GITEA_TOKEN }}

.gitignore

@@ -12,15 +12,8 @@ backups/
 .env
 .infisical-credentials
 
-# Web UI (Svelte 5) — build artifacts. The SPA is a standalone static build,
+# Local tooling artifacts (agent worktrees, Playwright MCP logs, screenshots)
-# deployed separately from the oikos binary (plans/2026-07-12-wails-desktop-app.md
+.claude/
-# 0.1), so the output dir is just a build artifact.
+.playwright-mcp/
-web/dist/
+config-screen.png
-web/node_modules/
 
-# Wails desktop app — frontend copy for embedding
-cmd/desktop/frontend/dist/
-cmd/desktop/build/
-cmd/desktop/Oikos
-desktop
-/eval

.golangci.yml

@@ -1,41 +1,89 @@
-# golangci-lint configuration for Oikos
+# golangci-lint v2 configuration for Oikos
 # Docs: https://golangci-lint.run/usage/configuration/
+# Default-enabled linters (errcheck, govet, ineffassign, staticcheck, unused)
+# are not listed below. gosimple/typecheck were absorbed into staticcheck in v2.
+version: "2"
 run:
-  timeout: 5m
   tests: true
-
 linters:
   enable:
-    - govet        # go vet
+    - depguard
-    - staticcheck  # advanced static analysis
+    - misspell
-    - ineffassign  # detect ineffectual assignments
+    - revive
-    - unused       # find unused identifiers
+  settings:
-    - errcheck     # check for unchecked errors
+    depguard:
-    - gosimple     # simplifications
+      # ADR 0016 dependency rules. Rules only constrain files that exist:
-    - typecheck    # standard type checking
+      # internal/core is live since Phase 0 (domain moved); internal/nomos
-    - misspell     # find commonly misspelled English words in comments
+      # and its bans activate in Phase 8; full audit at Phase 9.
-    - revive       # fast, configurable linter (replaces golint)
+      rules:
-
+        core-no-agent-tech:
-linters-settings:
+          files:
-  errcheck:
+            - "**/internal/core/**"
-    # Allow unchecked errors on common Close/Flush patterns (deferred cleanup)
+          deny:
-    exclude-functions:
+            - pkg: github.com/dtoro/oikos/internal/nomos
-      - (io.Closer).Close
+              desc: core never links agent-client packages (ADR 0016 §3.1 rule 3)
-      - (*os.File).Close
+            - pkg: github.com/dtoro/oikos/internal/nomos/**
-
+              desc: core never links agent-client packages (ADR 0016 §3.1 rule 3)
+            - pkg: github.com/openai/openai-go
+              desc: core never links the LLM SDK — nomos is an external client
+            - pkg: github.com/openai/openai-go/**
+              desc: core never links the LLM SDK — nomos is an external client
+            - pkg: github.com/modelcontextprotocol/go-sdk
+              desc: core never links MCP packages — mcpserver is a driving adapter
+            - pkg: github.com/modelcontextprotocol/go-sdk/**
+              desc: core never links MCP packages — mcpserver is a driving adapter
+        core-purity:
+          files:
+            - "**/internal/core/**"
+          deny:
+            - pkg: github.com/dtoro/oikos/internal/adapters
+              desc: core must not import adapters — depend on core/ports instead
+            - pkg: github.com/dtoro/oikos/internal/adapters/**
+              desc: core must not import adapters — depend on core/ports instead
+            - pkg: github.com/dtoro/oikos/cmd
+              desc: core must not import composition roots
+            - pkg: github.com/dtoro/oikos/cmd/**
+              desc: core must not import composition roots
+        nomos-isolation:
+          files:
+            - "**/internal/nomos/**"
+          deny:
+            - pkg: github.com/dtoro/oikos/internal/core
+              desc: nomos must not import core — consume oikos via MCP/REST
+            - pkg: github.com/dtoro/oikos/internal/core/**
+              desc: nomos must not import core — consume oikos via MCP/REST
+            - pkg: github.com/dtoro/oikos/internal/adapters
+              desc: nomos must not import adapters — consume oikos via MCP/REST
+            - pkg: github.com/dtoro/oikos/internal/adapters/**
+              desc: nomos must not import adapters — consume oikos via MCP/REST
+    errcheck:
+      # Allow unchecked errors on common Close/Flush patterns (deferred cleanup)
+      exclude-functions:
+        - (io.Closer).Close
+        - (*os.File).Close
+  exclusions:
+    generated: lax
+    rules:
+      - linters:
+          - errcheck
+        path: _test\.go
+      - linters:
+          - all
+        path: internal/httpapi/gen/
+      - linters:
+          - all
+        path: internal/adapters/postgres/sqlcgen/
+    paths:
+      - third_party$
+      - builtin$
+      - examples$
 issues:
-  # Exclude generated code
-  exclude-rules:
-    - path: _test\.go
-      linters:
-        - errcheck
-    - path: internal/httpapi/gen/
-      linters:
-        - all
-    - path: internal/db/sqlcgen/
-      linters:
-        - all
-  # Don't auto-exclude common patterns
-  exclude-use-default: false
   max-issues-per-linter: 0
   max-same-issues: 0
+formatters:
+  exclusions:
+    generated: lax
+    paths:
+      - third_party$
+      - builtin$
+      - examples$

AGENTS.md

@@ -24,7 +24,8 @@ structured data and knowledge. It is bootstrapped from `seeds/` at deploy time:
 `seeds/ontology.yaml` (entity types, relationships, lifecycles), `seeds/inventory.yaml`
 (hosts, services, entities), `seeds/policy.yaml` (risk classes, approval rules), and
 `seeds/knowledge.yaml` (documents, investigations, runbooks). The old narrative wiki
-is archived at `archive/knowledge/` for historical reference.
+was archived at `archive/knowledge/` for historical reference (since deleted — the DB is
+the sole source of truth).
 
 ## 1. Who you are
 
@@ -56,67 +57,88 @@ Endpoint: `https://mcp.hubris.network/mcp`. Every call needs
 enrollment and `/healthz` (see "Authentication" below for where the token
 comes from).
 
-Available tools (the authoritative list — count them below if a number is
+Available tools (67 total — the authoritative list; do not hardcode the count
-needed; do not hardcode the count elsewhere):
+elsewhere; regenerate from `internal/mcp/` when tools change):
 
-  Context — observe + orient:
+  💡 Slug param alias: all entity-lookup tools now accept `slug` in addition to
-    get_entity(slug), list_entities(type, limit, cursor),
+     their declared param name (e.g. `get_entity(slug="lxc:seanime")` works).
-    get_relations(entity), get_blast_radius(entity),
-    search_knowledge(query) — ILIKE search over documents, investigations,
-      runbooks in the knowledge_entities table
-    get_entity_knowledge(entity_slug) — every document, investigation, and
-      runbook linked to one entity, in one call
-    get_patterns(status, entity_type, action) — learned action patterns
-    get_skills(status) — available automation skills
-    http_get(url) — fetch a public page/raw file (e.g. researching how to
-      deploy something before provisioning it); HTTP/HTTPS only, ~16KB cap
 
-  Management — live state:
+  Entity Tools — knowledge graph, discovery, and lifecycle:
-    get_service_status(service_slug) — systemctl is-active on target host
+    ping — lightweight connectivity check
-    tail_log(service_slug, lines=200) — journalctl
+    get_entity(slug_or_id) — get an entity by slug or UUID
-    list_lxcs() — all LXC containers with ID, host, IP, health
+    list_entities(type, state, q, limit) — entities filtered by type, state, or search
-    get_lxc_state(lxc_slug) — pct status from Proxmox host
+    get_relations(entity_id, types) — list inbound/outbound edges for one entity
-    ping_service(service_slug) — HTTP reachability from entity_status
+    get_blast_radius(entity_id, depth=3) — entities affected if this one goes down
-    list_my_secrets(caller_pubkey) — secrets accessible to this client by
+    create_entity(type, name, slug, attributes, state) — create a new entity in the graph
-      age public key
+    update_entity_attributes(slug, attributes) — merge discovered facts into an entity
-
+    set_entity_state(slug, state) — transition entity to a new lifecycle state
-  Oikos — decisions:
+    create_relationship(source, target, type) — record a discovered edge
+    end_relationship(source, target, type) — soft-delete an active edge
+    whoami(hostname) — entity record, peers, and health for a host
     explain(service_slug) — compact context card (type, state, health, relations)
     preflight(service_slug, action) — risk class + approval requirement
-    whoami(hostname) — entity record, peers, health for a client
     get_change_history(entity_slug, limit=20) — last audit-log entries per entity
-    get_state_snapshot() — fleet health, disk, drift count
+    get_state_snapshot() — last scheduler Observe-pass: fleet health, disk, drift
+    audit_knowledge_graph() — read-only drift report over the graph and checks
+    discover_infra_drift() — running guests vs DB: missing/ghost entities
+    find_entities_by(key, value, limit=25) — search entities by attribute values
 
-  Operations — observe + act:
+  Ops Tools — live state, signals, checks, and execution:
-    get_health_summary() — fleet health counts (healthy/degraded/down/unknown)
+    run(target, command, purpose, declared_risk) — general execution primitive; read-only auto-acts, mutations queue for approval, destructive always needs explicit confirmation
-    get_signal_history(entity_slug, state, limit) — open + recent signals
+    inspect_path(path, targets) — bulk mount/df/ls/stat across multiple hosts/LXCs
-    get_audit_trail(entity_id) — audit log filter + browse
+    get_execution_status(execution_id) — poll execution progress
-    get_agent_activity(limit) — agent self-inspection
+    tail_log(service_slug, lines=50) — journalctl for a service
-    query_metrics(hours=24) — time-series metric bucketed averages
+    get_service_status(service_slug) — systemctl is-active/is-enabled
-    get_trend(entity_id, days=7) — metric slope over time
+    get_lxc_state(lxc_slug) — pct status from Proxmox host
-    get_event_timeline(severity, entity_slug, limit) — recent events
+    ping_service(service_slug) — HTTP reachability + scheduler health state
+    list_lxcs(state) — all LXC containers with ID, host, IP, last-audited hint
+    restart_service(target, service) — restart a systemd service (config_mutation, requires approval)
+    docker_exec(lxc_slug, container, command, purpose) — run a command inside a Docker container on an LXC; handles escaping, resolves target from entity graph; read-only auto-runs, mutations require approval
+    push_file(target, source_path, dest_path, backup=true) — push a file into an LXC from the Proxmox host (config_mutation, requires approval)
+    ack_signal(signal_id) — acknowledge an open signal
+    resolve_signal(signal_id, resolution) — resolve a signal with optional note
+    mute_signal(signal_id, duration_s=3600) — temporarily mute a signal
+    cancel_execution(execution_id, reason) — cancel a queued/running execution
+    update_check(check_id, enabled) — enable or disable a health check
+    list_checks(entity_slug, enabled) — list health checks with verdict, probe kind
+    list_executions(entity_slug, status, limit=25) — cursor-paginated execution history
+    list_entity_sessions(entity_slug) — active Nomos sessions linked to an entity
+    get_dashboard_summary() — fleet overview: counts, health, signals, approvals
+    list_approvals(status, entity_slug, limit) — list pending/recent approvals; filter by status (pending, approved, denied) or entity
+    decide_approval(approval_id, decision) — approve or deny a pending execution; calls the same API endpoint as the Approve button in the UI
+    get_secret(key, path, environment) — retrieve a secret from the Infisical vault
+    list_secrets(path_prefix) — list secret keys in the Infisical vault
+    set_secret(key, value, path, environment) — store/update a secret (requires approval)
 
-  Knowledge — keep the graph current (none require approval; this updates
+  Knowledge Tools — search, read, and maintain the knowledge base:
-  the knowledge graph, not live infrastructure):
+    search_knowledge(query) — full-text search across docs (snippets, not full body)
-    upsert_knowledge(title, content) — record what you learned after solving
+    get_entity_knowledge(entity_slug) — all docs/investigations/runbooks linked to a slug
-      a non-obvious problem; the only way anything persists past a session
+    get_knowledge_content(slug) — full markdown body of one knowledge entry
-    update_entity_attributes(slug, attributes) — merge a discovered fact
+    upsert_knowledge(title, content, about, tags, kind) — write what you learned
-      (IP, version, port, ...) into an entity so a future task doesn't
+    upsert_session_summary(session_id, summary, entities_touched, discoveries) — batch-write session findings into the graph; creates knowledge entries, links entities, records a session-audit entry
-      rediscover it from scratch
+    delete_knowledge(knowledge_slug) — soft-delete a knowledge entry
-    create_relationship(source, target, type) — record a discovered edge
+    restore_knowledge(knowledge_slug) — restore a soft-deleted entry
-      (depends-on, hosts, routes-to, ...) between two entities
+    merge_knowledge(target_slug, source_slugs) — fold entries into a target
+    rename_knowledge_tag(from, to) — bulk-rename tags across all entries
+    get_knowledge_revisions(knowledge_slug) — version history for a knowledge entry
+    get_knowledge_duplicates(threshold=0.6) — near-duplicate detection via trigram similarity
+    get_knowledge_orphans(stale_days=90) — unlinked, untagged, or stale entries
+    list_knowledge_tags() — all tags with usage counts and casing variants
+    list_my_secrets(caller_pubkey) — secrets accessible to a client by age public key
 
-  Execution — mutating the live infrastructure:
+  Analysis Tools — fleet health, metrics, and introspection:
-    run(target, command) — the general execution primitive. Run any shell
+    get_health_summary(health) — fleet health per entity, optionally filtered
-      command against a host or LXC; every command is auto-classified —
+    get_audit_trail(entity_id) — query the audit log
-      read-only inspection runs immediately, anything state-changing needs
+    query_metrics(hours=24) — time-series with bucketed avg/min/max
-      operator approval, and destructive patterns (rm -rf, dd, mkfs,
+    get_signal_history(entity_slug, state, limit=50) — open and recent signals
-      pct/qm destroy, DROP TABLE, reboot, curl-pipe-to-shell, ...) always
+    get_patterns(status, entity_type, action) — learned action patterns
-      need approval regardless of what you declare. This is the ONLY
+    get_skills(status) — available automation skills
-      mutation tool — `request_execution` was retired 2026-07-14; the
+    get_trend(entity_id, days=7) — metric slope, variance, and averages
-      former enum actions (restart, systemctl, pct_exec, apt_upgrade,
+    get_event_timeline(severity, entity_slug, limit=50) — recent events
-      pct_create) are all expressed as `run(target, command)` now.
+    get_agent_activity(limit=50) — agent self-inspection log
-    get_execution_status(execution_id) — poll progress
+    classify_command(command, declared_risk) — pre-flight risk classification before `run`
+    get_ontology() — entity types, relationship types, and lifecycle definitions
+    http_get(url) — fetch a public web page/raw file; ~16KB cap
 
 **When to prefer MCP over grepping the clone:** always for knowledge queries.
 `search_knowledge("jellyfin hardware acceleration")` returns ranked results from
@@ -133,7 +155,9 @@ API/MCP bearer token — there is one shared
 secret (`OIKOS_MCP_BEARER_TOKEN`, validated in `internal/httpapi/server.go`'s
 `combinedAuth`); get it from the operator until per-client token issuance
 exists. The SPA has its own flow instead: a first-launch Config screen that
-stores a token in `localStorage` (see `web/src/pages/Config.svelte`).
+stores a token in `localStorage` (the SPA lives in the `dtoro/oikos-web`
+repo — `web/src/pages/Config.svelte` there — since the Phase 1 client
+extraction).
 
 ## 5. Knowledge conventions
 
@@ -146,8 +170,8 @@ POST /api/v1/knowledge/{entity_slug}
 {"title": "...", "content": "...", "tags": ["..."]}
 ```
 
-The DB is the truth. The old wiki files are archived at `archive/knowledge/`
+The DB is the truth. The old wiki files were archived at `archive/knowledge/`
-(historical reference only — use MCP `search_knowledge` for live queries).
+(historical reference only — since deleted; use MCP `search_knowledge` for live queries).
 
 - **Runbook procedures** live as `runbook` entities in the DB and as SKILL.md
   files under `.agents/skills/<name>/`. They carry `risk_class`, `procedure`
@@ -168,13 +192,14 @@ The DB is the truth. The old wiki files are archived at `archive/knowledge/`
 - **Actions** (restart, logs, apt, pct exec, or anything else): Nomos calls
   `run` (the general execution primitive) via MCP. `reversible_low`/read-only actions execute
   immediately; `config_mutation` and `destructive` actions are queued for
-  operator approval via Matrix or the control-room UI's Operations page.
+  operator approval via the App button in the control-room UI or via
+  `list_approvals`/`decide_approval` MCP tools from any agent.
 - **Secrets**: managed by Infisical (`oikos secret` subcommand for
   migration). Never hardcode secrets — use env vars from `.env`.
 - **Mutations** (restart, edit configs, etc.): classified against
   `seeds/policy.yaml`. `reversible_low` actions auto-execute;
   `config_mutation`/`destructive` actions require approval — granted by
-  the operator via Matrix reply or the control-room UI, not a CLI flag.
+  the operator via the App button or `decide_approval` MCP tool call.
   See OIKOS.md.
 
 ## 7. Communication mode

CLIENTS.md

@@ -23,7 +23,7 @@ Docker stack on mac-mini and exposes an MCP server + REST API.
 | Change history | MCP `get_change_history` |
 | State snapshot (health, disk, drift) | MCP `get_state_snapshot` |
 | Secrets (Infisical) | REST API + `oikos secret` CLI |
-| Approval tokens | Matrix via notifier |
+| Approve/deny pending executions | MCP `list_approvals`, `decide_approval` (chat-native, works on any platform) |
 | Run a command on a host/LXC (policy-gated) | MCP `run` |
 | Record a discovered fact/relationship | MCP `update_entity_attributes`, `create_relationship`, `upsert_knowledge` |
 

CONTRIBUTING.md

@@ -9,8 +9,9 @@ repo, see [.agents/dev/CONTRIBUTING.md](.agents/dev/CONTRIBUTING.md).
 - **Go 1.26+** (see `go.mod` for pinned version)
 - **PostgreSQL with TimescaleDB** — the compose stack includes `timescale/timescaledb:2.17.2-pg16`
 - **Docker** for the full dev stack
-- **Node 22+** for `web/` (the control-room SPA — standalone, not part of the
+- The control-room SPA and desktop app live in their own repo —
-  compose stack or the `oikos` binary)
+  [dtoro/oikos-web](https://git.hubris.network/dtoro/oikos-web) (Node 22+
+  there); this repo is backend-only since the hexagonal refactor Phase 1
 
 ```bash
 # Start dependencies (Postgres + Redis). api/nomos require a shared bearer
@@ -26,62 +27,51 @@ make test-db
 # Build the binary
 make build
 
-# SPA dev server (proxies to api/nomos, injecting the same token)
+# SPA dev server (own repo — dtoro/oikos-web)
-cd web && OIKOS_API_TOKEN=dev-token npm run dev
+cd ~/Projects/oikos-web/web && OIKOS_API_TOKEN=dev-token npm run dev
 
-# Desktop app (macOS)
+# Desktop app (macOS — also in the oikos-web repo)
-make desktop                  # build .app bundle
+cd ~/Projects/oikos-web && make install
-make install                  # build + install to /Applications
-./cmd/desktop/build/bin/oikos-desktop.app/Contents/MacOS/oikos-desktop  # run from terminal to see logs
 ```
 
-### Desktop app auth
+### Desktop app
 
-The desktop app uses the same API as the browser SPA. First launch:
+The desktop app's auth (Authentik login → keychain-persisted token) and
-
+auto-update (Gitea releases every 6 hours) moved with it to
-1. Enter `https://oikos.hubris.network` as Server URL
+[dtoro/oikos-web](https://git.hubris.network/dtoro/oikos-web) — see that
-2. **Login with Authentik** tab → opens system browser → authenticate
+repo's README. Auto-update now tracks oikos-web releases; builds installed
-3. Callback page shows token → copy → paste into Token tab → Connect
+before the split need one manual reinstall.
-4. Token is persisted to the macOS keychain — subsequent launches skip setup
-
-The app stores credentials via `github.com/zalando/go-keyring` (service: `com.hubris.oikos-desktop`).
-
-### Desktop app auto-update
-
-- Checks Gitea releases every 6 hours
-- System tray → **Check for Updates** triggers an immediate check
-- Download, extract, replace the app in `/Applications`, and relaunch
-- Versions are compared against the `version` var in `main.go`, injected from the repo `VERSION` file at link time (`make desktop` passes `-ldflags "-X main.version=$(cat VERSION)"`)
 
 ## Project structure
 
 ```
-cmd/desktop/        Wails v3 desktop app (macOS + Linux)
-  main.go            Thin shell: webview, system tray, notifications, auto-update
-  wails.json         Wails project config
-  entitlements.plist macOS code-signing entitlements
-  icon.png           System tray icon (embedded)
-  icon.icns          App bundle icon (white logo on black rounded rect)
-  Taskfile.yml       Wails v3 build tasks
-  Info.plist.template macOS bundle metadata
 cmd/oikos/          Single-binary entry point
 cmd/nomos/          Nomos MCP client gateway
 cmd/webhook/        Gitea deploy-webhook receiver (push-to-deploy on mac-mini)
 internal/           All Go packages
-  httpapi/          REST + MCP server (OpenAPI-generated)
+  core/             Hexagon core ([ADR 0016](docs/adr/0016-hexagonal-ports-adapters.md)):
-  mcp/              MCP tool implementations
+                    domain/ (pure model, stdlib only), ports/ (driven-port
-  db/               Connection pool, migrations, seeds, sqlc queries
+                    interfaces), app/ (use-case services — EntityService,
-  scheduler/        Observe loop, probes, signals
+                    RelationshipService, SignalService, ObservationService,
-  actuator/         SSH execution
+                    KnowledgeService, LearningService, etc.) — populated by
-  learning/         Pattern recognition, anomaly detection
+                    the phased refactor; core may not import adapters,
-  notifier/         Matrix notifications, approval tokens
+                    enforced by depguard (verified Phase 9 audit)
-  policy/           Risk classifier
+  adapters/         Ports' implementations: postgres/ (pool, migrations, seeds,
-  secrets/          Infisical + SOPS backend
+                    incl. knowledge seed ingest, sqlcgen, repos — EntityRepo,
-  domain/           Core types: entities, approvals, signals, patterns
+                    RelRepo, OntologyRepo, SeedRepo, EntityReader, SignalRepo,
-  ontology/         Type hierarchy, relationship validation
+                    MetricsRepo, etc.), ssh/ (CommandExecutor via actuator +
-  knowledge/        Knowledge YAML seed ingestion
+                    Provisioner for pct/qm), remote/ (TargetResolver via
-web/                Control-room SPA (Svelte 5) — standalone, not embedded
+                    internal/remote), probes/ (Checker implementations per
-                    in the oikos binary; see plans/2026-07-12-wails-desktop-app.md
+                    probe kind: HTTP, TCP, ping, DNS, SSH)
+  httpapi/          REST server (OpenAPI-generated) — driving adapter
+  mcp/              MCP tool implementations — driving adapter
+  scheduler/        Observe loop, coverage sweep — driving adapter (moves
+                    to ObservationService/SignalService in Phase 5)
+  execworker/       Execution worker — driving adapter
+  actuator/         SSH execution — consumed by adapters/ssh
+  remote/           Target resolution — consumed by adapters/remote
+  audit/            Audit report helpers
+  observability/    Event/Audit recorder helpers
 api/openapi.yaml    API contract — the source of truth for endpoints
 migrations/         Forward-only SQL migrations (TimescaleDB)
 seeds/              Bootstrap YAML: ontology, inventory, policy, knowledge
@@ -111,11 +101,6 @@ docs/operations/    Runbooks (rollback, etc.)
 | `make export` | Export DB state to YAML seeds |
 | `make dev` | Start compose dev stack |
 | `make clean` | Remove binary + test cache |
-| `make ui` | Build the SPA (`web/dist/`) |
-| `make deploy-ui` | Build + deploy the SPA to the Caddy host |
-| `make desktop` | Build the Wails desktop app for the current platform |
-| `make desktop-package` | Build + package (zip on macOS, tar.gz on Linux) |
-| `make install` | Build + install to `/Applications` (macOS) |
 | `make webhook` | Build `cmd/webhook` (deploy-webhook receiver) |
 | `make tidy` | `go mod tidy` |
 
@@ -135,8 +120,8 @@ Never hand-edit `internal/httpapi/gen/api.gen.go`.
 
 ### Database access is sqlc-first
 
-SQL queries live in `internal/db/queries/*.sql`. Go code is generated with
+SQL queries live in `internal/adapters/postgres/queries/*.sql`. Go code is generated with
-`sqlc` into `internal/db/sqlcgen/`. Config in `sqlc.yaml`.
+`sqlc` into `internal/adapters/postgres/sqlcgen/`. Config in `sqlc.yaml`.
 
 - Queries target pgx/v5 with UUID + timestamptz overrides
 - Never hand-edit generated sqlc code

Makefile

@@ -1,4 +1,4 @@
-.PHONY: build webhook test test-db lint generate generate-check dev migrate seed export clean tidy ui desktop desktop-package install
+.PHONY: build webhook test test-db lint generate generate-check dev migrate seed export clean tidy
 
 BINARY := bin/oikos
 GO ?= go
@@ -18,7 +18,7 @@ test-db:
 	docker compose up -d postgres
 	@sleep 3
 	OIKOS_TEST_DATABASE_URL="postgres://oikos:$${OIKOS_DB_PASSWORD:-oikos_dev}@localhost:5432/oikos?sslmode=disable" \
-		$(GO) test -race -count=1 ./internal/db/ ./internal/httpapi/ ./internal/mcp/
+		$(GO) test -race -count=1 ./internal/adapters/postgres/ ./internal/httpapi/ ./internal/mcp/
 
 lint: vet golangci govulncheck
 
@@ -40,7 +40,7 @@ generate:
 
 # CI drift guard: regenerate and fail if the committed output changed.
 generate-check: generate
-	@git diff --exit-code -- internal/httpapi/gen internal/db/sqlcgen \
+	@git diff --exit-code -- internal/httpapi/gen internal/adapters/postgres/sqlcgen \
 		|| (echo "generated code is stale — run 'make generate' and commit" && exit 1)
 
 migrate:
@@ -55,45 +55,9 @@ export:
 dev:
 	docker compose --profile dev up -d
 
-# Local sanity-check build of the SPA. Not embedded in the oikos binary
-# (plans/2026-07-12-wails-desktop-app.md 0.1) — deploys as its own
-# container (compose/web/Dockerfile) via `docker compose --profile full
-# up -d web`, same push-to-main pipeline as everything else.
-ui:
-	cd web && npm run build
-
-desktop: ui   ## Build the Wails desktop app for the current platform
-	rm -rf cmd/desktop/frontend/dist
-	mkdir -p cmd/desktop/frontend/dist
-	cp -r web/dist/* cmd/desktop/frontend/dist/
-	cd cmd/desktop && CGO_ENABLED=1 go build -ldflags "-X main.version=$$(cat ../VERSION)" -o build/bin/Oikos .
-
-desktop-package: desktop   ## Build + package the desktop app (zip on macOS, tar.gz on Linux)
-	@case $$(uname -s) in \
-		Darwin) \
-			APP="cmd/desktop/build/bin/Oikos.app"; \
-			rm -rf "$$APP"; \
-			mkdir -p "$$APP/Contents/MacOS"; \
-			mkdir -p "$$APP/Contents/Resources"; \
-			cp cmd/desktop/build/bin/Oikos "$$APP/Contents/MacOS/Oikos"; \
-			cp cmd/desktop/icon.icns "$$APP/Contents/Resources/icon.icns"; \
-			sed "s/\$$(VERSION)/$$(cat VERSION)/" cmd/desktop/Info.plist.template > "$$APP/Contents/Info.plist"; \
-			cd cmd/desktop/build/bin && zip -r oikos-desktop-darwin-$$(uname -m).zip Oikos.app ;; \
-		Linux) \
-			cd cmd/desktop/build/bin && tar czf oikos-desktop-linux-$$(uname -m).tar.gz Oikos ;; \
-	esac
-	@echo "Package: cmd/desktop/build/bin/"
-
-install: desktop-package   ## Install to /Applications
-	rm -rf /Applications/Oikos.app
-	cp -r cmd/desktop/build/bin/Oikos.app /Applications/
-	@echo "Installed to /Applications/Oikos.app"
-
 clean:
 	rm -f $(BINARY)
 	rm -rf bin
-	rm -rf cmd/desktop/build
-	rm -rf cmd/desktop/frontend/dist
 	$(GO) clean -testcache
 
 tidy:

README.md

@@ -13,7 +13,7 @@ learns from outcomes, and escalates when uncertain.
 ## Quick start
 
 ```bash
-# Dev stack (postgres + api + scheduler + notifier). The api/nomos
+# Dev stack (postgres + api + scheduler). The api/nomos
 # services need a shared token — every route requires a real bearer
 # credential, there's no dev-open bypass.
 OIKOS_MCP_BEARER_TOKEN=dev-token docker compose --profile dev up -d
@@ -29,8 +29,8 @@ OIKOS_DATABASE_URL="postgres://oikos:oikos_dev@localhost:5432/oikos?sslmode=disa
   OIKOS_API_TOKEN=dev-token \
   go run ./cmd/oikos all
 
-# Control-room SPA (separate from the Go binary — see web/)
+# Control-room SPA + desktop app: own repo — dtoro/oikos-web
-cd web && OIKOS_API_TOKEN=dev-token npm run dev   # http://localhost:5173
+# (~/Projects/oikos-web; cd web && OIKOS_API_TOKEN=dev-token npm run dev)
 ```
 
 ## Architecture
@@ -42,8 +42,8 @@ cd web && OIKOS_API_TOKEN=dev-token npm run dev   # http://localhost:5173
   Workstation ─── │  nomos (8092) ──MCP── api (8090) │
   (mesh)          │    MCP gateway      REST + MCP    │
                   │                                   │
-                  │  scheduler ── notifier ── postgres │
+                  │  scheduler ─── postgres             │
-                  │  (observe)    (Matrix)   (Timescale)│
+                  │  (observe)    (Timescale)          │
                   └──────────────────────────────────┘
 ```
 
@@ -51,7 +51,6 @@ cd web && OIKOS_API_TOKEN=dev-token npm run dev   # http://localhost:5173
 |-----------|------|------|
 | `oikos api` | 8090 | REST API + MCP server (tool list in [AGENTS.md §3](AGENTS.md#3-the-mcp-server)) |
 | `oikos scheduler` | — | Probe runner, signal lifecycle, metrics |
-| `oikos notifier` | — | Approval tokens, Matrix alerts |
 | `nomos serve` | 8092 | MCP client gateway, query routing |
 
 ## Phases
@@ -60,7 +59,7 @@ cd web && OIKOS_API_TOKEN=dev-token npm run dev   # http://localhost:5173
 |-------|--------|-------------|
 | 1 — Ontology + DB | ✅ | TimescaleDB, migrations, seeds, blast_radius |
 | 2 — API | ✅ | OpenAPI-first REST + MCP, auth, SSE, audit |
-| 3 — Control loop | ✅ | Scheduler, actuator, learning, classifier, notifier |
+| 3 — Control loop | ✅ | Scheduler, actuator, learning, classifier |
 | 4 — Nomos agent | ✅ | Standalone MCP client gateway, agent activity |
 | 5 — Secrets | ✅ | Infisical backend + SOPS fallback, rotation runbooks |
 | 6 — Deploy | ✅ | CI pipeline, cutover checklist, watchdog, rollback |
@@ -100,7 +99,6 @@ oikos seed        # ingest ontology/inventory/policy seeds
 oikos export      # export DB state to YAML
 oikos api         # serve REST + MCP
 oikos scheduler   # run observe loop
-oikos notifier    # run notification loop
 oikos all         # all roles in one process
 oikos secret list # enumerate SOPS secrets
 oikos secret migrate  # SOPS → Infisical
@@ -108,12 +106,14 @@ oikos secret migrate  # SOPS → Infisical
 
 ### Web UI
 
-`web/` is a standalone Svelte 5 SPA — not embedded in the `oikos` binary, not
+The control-room SPA and the Wails desktop wrapper live in their own repo,
-part of `docker-compose.yml`. It talks to `api`/`nomos` over HTTP with a
+[dtoro/oikos-web](https://git.hubris.network/dtoro/oikos-web) (local
-bearer token entered on first launch (see `web/src/pages/Config.svelte`).
+checkout `~/Projects/oikos-web`) — extracted in Phase 1 of
-Build with `make ui`, deploy with `make deploy-ui` (Caddy serves the static
+[plans/2026-08-15-hexagonal-architecture.md](plans/2026-08-15-hexagonal-architecture.md).
-output). A native desktop wrapper exists at `cmd/desktop/` — see
+The SPA talks to `api`/`nomos` over HTTP with a bearer token entered on
-[plans/done/2026-07-12-wails-desktop-app.md](plans/done/2026-07-12-wails-desktop-app.md).
+first launch. It deploys as its own compose project publishing `8091:80`;
+the outer Caddy (LXC 121) targets that published port, so serving and auth
+are unchanged from the pre-split stack.
 
 ## Repo layout
 
@@ -121,11 +121,9 @@ output). A native desktop wrapper exists at `cmd/desktop/` — see
 cmd/oikos/          Go entry point — single binary
 cmd/nomos/          Nomos MCP client gateway
 cmd/webhook/        Gitea deploy-webhook receiver (push-to-deploy on mac-mini)
-cmd/desktop/        Wails desktop wrapper around the SPA
+internal/           Go packages (actuator, checkdefaults, config, core, db,
-internal/           Go packages (actuator, checkdefaults, config, db, domain,
+                    domain, httpapi, knowledge, learning, mcp, observability,
-                    httpapi, knowledge, learning, mcp, notifier, observability,
                     ontology, policy, safego, scheduler, secrets)
-web/                Control-room SPA (Svelte 5) — standalone, not embedded
 api/openapi.yaml    API contract (OpenAPI 3.1)
 migrations/         Forward-only SQL migrations (TimescaleDB)
 seeds/              Bootstrap YAML (ontology, inventory, policy, knowledge)
@@ -137,18 +135,20 @@ ssh/                Deploy keys + authorized_keys management
 vps/                Caddy/TURN config templates for the netbird VPS
 nomos/              Nomos config, persona, skills
 .agents/            Agent instruction files, shared conventions, skills
-archive/            Historical reference (legacy wiki, plans, SOPS backups)
 plans/              Design documents (active + done)
 docs/adr/           Architecture decision records
 docs/operations/    Runbooks (rollback, etc.)
+docs/infrastructure/ Homelab infrastructure architecture
+docs/secrets/       Secret management procedures
+docs/GLOSSARY.md    Term definitions
 ```
 
 ## For agents
 
 See [AGENTS.md](AGENTS.md) for the full orientation. Quick reference:
 
-- **Source of truth:** DB (runtime) then seeds (bootstrap). Old wiki is
+- **Source of truth:** DB (runtime) then seeds (bootstrap). Old wiki was
-  archived at `archive/knowledge/` — use MCP `search_knowledge` instead.
+  archived at `archive/knowledge/` (since deleted) — use MCP `search_knowledge` instead.
 - **Mutations:** classify against policy, request approval for
   `destructive`/`config_mutation`
 - **Secrets:** Infisical (primary) or SOPS (fallback) — never hardcode

VERSION

@@ -1 +1 @@
-0.7.12
+0.36.0

api/openapi.yaml

@@ -2284,6 +2284,23 @@ components:
           type: boolean
         version:
           type: integer
+        last_health:
+          type: string
+          description: >-
+            This check's own most recent verdict. An entity's health is the
+            worst of these across its enabled checks, so this is what explains
+            *why* an entity is degraded. Null until the check first runs.
+          nullable: true
+          enum:
+          - healthy
+          - degraded
+          - down
+          - unknown
+        last_run_at:
+          type: string
+          format: date-time
+          description: When this check last executed. Null = never run.
+          nullable: true
     CheckCreate:
       type: object
       required:
@@ -3168,8 +3185,6 @@ components:
       required:
       - age_public_key
       - age_private_key
-      - infisical_client_id
-      - infisical_client_secret
       properties:
         age_public_key:
           type: string
@@ -3183,9 +3198,6 @@ components:
         infisical_client_secret:
           type: string
           description: Infisical UniversalAuth client secret
-        machine_identity_token:
-          type: string
-          description: Infisical machine identity access token
     ClientContext:
       type: object
       required:

archive/hermes-plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md

@@ -1,277 +0,0 @@
-# Plan: Migrate library SSD to ludo-mini + Proxmox gaming/media server
-
-## Goal
-
-Split the homelab into two Proxmox hosts:
-
-| Host | Role | Storage |
-|------|------|---------|
-| **hubris** | Core services (reverse-proxy, SSO, Matrix, git, documents, HA) | SSD 1 — boot + LXC rootfs (unchanged) |
-| **ludo-mini** | Gaming server + media/library services | SSD 2 — Samsung 990 EVO Plus 4 TB (moved from hubris) |
-
-The library SSD physically moves from hubris to ludo-mini. hubris LXCs that still need `/mnt/library` access it over NFS from ludo-mini.
-
-## Current state
-
-### hubris hardware
-- GMKtec NucBox M6 Ultra — AMD Ryzen 5 7640HS, 12 vCPU, ~28 GiB RAM
-- 2× Samsung 990 EVO Plus NVMe:
-  - nvme0: `local` (95G) + `local-lvm` (856G) — boot, ISOs, LXC rootfs
-  - nvme1: `library` LVM (3.7T) — `/mnt/library` ext4 via `/dev/mapper/library-library`
-
-### LXCs binding `/mnt/library` (host-level bind-mount)
-| ID | Name | Role | I/O profile |
-|----|------|------|-------------|
-| 101 | jellyfin | Media streaming | Read-heavy, sequential |
-| 103 | paperless | Document archive | Mixed, OCR writes |
-| 104 | gitea | Git server | Mixed, lots of small files |
-| 105 | apps | Docker (booklore, audiobookshelf, artifacto, MCP) | Mixed, depends on container |
-| 114 | nextcloud | File sync | Mixed, WebDAV |
-| 119 | sophia | Workshop | Low I/O |
-| 120 | mule-images | Photo management | Write-heavy (processing), iGPU |
-| 122 | arriman | *arr stack + downloads | Write-heavy (downloads) |
-| 126 | plato | App (sub-mount: `/mnt/library/documents/plato`) | Light |
-
-### NFS export chain (for VM 100 zimaos)
-```
-/mnt/library (ext4, host) → bind-mount → LXC 102 (nfs-export) → NFSv4 → VM 100 (zimaos)
-```
-
-### ludo-mini current
-- Linux workstation, wired Ethernet 2.5 Gbps, `192.168.178.181` (household LAN)
-- Runs Sunshine for game streaming
-- No Proxmox, no LVM config
-- Connected to SODOLA switch (same switch as hubris eno1)
-
-### Network topology
-```
-Fritz!Box 7590 (192.168.178.1)
-  └── SODOLA 2.5G switch
-       ├── hubris eno1 → vmbr1 (192.168.178.10)
-       │     └── routes to vmbr0 (192.168.8.0/24) — all LXCs
-       └── ludo-mini (192.168.178.181)
-```
-
-hubris routes between `192.168.8.0/24` (vmbr0) and `192.168.178.0/24` (vmbr1). So LXCs can reach ludo-mini via hubris as a router.
-
-## Key decisions
-
-### 1. Service split — what moves, what stays
-
-**Move to ludo-mini** (high I/O, benefits from data locality + GPU):
-- 101 jellyfin — media streaming, GPU transcoding
-- 120 mule-images — photo processing, iGPU passthrough
-- 122 arriman — *arr stack, downloads write to library
-
-**Stay on hubris, NFS-mount library from ludo-mini:**
-- 103 paperless — documents, moderate I/O
-- 104 gitea — git repos (small files, some I/O sensitivity but acceptable over NFS)
-- 105 apps — Docker apps, mixed workloads
-- 114 nextcloud — file sync
-- 119 sophia — workshop, light use
-- 126 plato — app, light use
-- 100 zimaos — NAS frontend, already NFS-mounted
-
-### 2. NFS architecture
-
-Instead of changing every LXC's mount config, keep the bind-mount pattern on hubris:
-
-```
-ludo-mini: /mnt/library (ext4, local NVMe)
-    │
-    └── NFSv4 export to 192.168.8.0/24
-              │
-              └── hubris host: NFS-mount at /mnt/library
-                        │
-                        └── LXCs: bind-mount /mnt/library (unchanged!)
-```
-
-This is transparent to all hubris LXCs — no container config changes needed. Only the hubris host changes from ext4 local mount to NFS mount. The LXC bind-mounts "just work" because `/mnt/library` is still at the same path on the host.
-
-### 3. Network — ludo-mini reachability from hubris LXCs
-
-LXCs on `192.168.8.0/24` reach ludo-mini (`192.168.178.181`) through hubris routing:
-- `vmbr0` → hubris kernel routing → `vmbr1` → SODOLA → ludo-mini
-- Already works (IP forwarding enabled on hubris)
-
-**Alternative (cleaner):** Add a secondary IP `192.168.8.x` on ludo-mini's physical interface so it's directly on the homelab subnet. This avoids the router hop and keeps NFS traffic off kernel forwarding path. Worth considering but not required.
-
-### 4. Gaming on ludo-mini with Proxmox
-
-ludo-mini runs Sunshine (game streaming). Under Proxmox:
-- **Option A:** Gaming VM with GPU passthrough — Sunshine + games in a VM, full GPU access
-- **Option B:** LXC with GPU device passthrough (`/dev/dri`) — lighter, shares kernel
-- **Option C:** Keep Sunshine on the Proxmox host itself (not recommended, but simplest)
-
-Option A is the cleanest for isolation. Games need a full desktop environment and GPU drivers; a VM with GPU passthrough gives them that.
-
-### 5. What about nfs-export (LXC 102)?
-
-Currently exports `/mnt/library` to zimaos. After migration:
-- If zimaos stays on hubris and accesses library via host NFS → bind-mount → LXC 102, that's triple-hop (ludo-mini → NFS → hubris → bind-mount → LXC 102 → NFS → zimaos). Terrible.
-- Better: zimaos NFS-mounts directly from ludo-mini.
-- So LXC 102 gets decommissioned (or repurposed).
-- zimaos gets a new NFS mount pointing directly at ludo-mini.
-
-## Migration phases
-
-### Phase 1 — Preparation (no downtime)
-
-1. **Document current state** on hubris:
-   - `pct list` — full container inventory
-   - `pct config <id>` for every library-mounting LXC
-   - `cat /etc/fstab` — capture the library mount line
-   - `df -h /mnt/library` — confirm space usage
-   - `lsblk -f` — UUID, filesystem
-   - Identify the exact NVMe device (`nvme1n1`)
-
-2. **Pre-flight on ludo-mini:**
-   - Confirm hardware: CPU, RAM, available M.2 slots, GPU model
-   - Confirm it can take the Samsung 990 EVO Plus (M.2 NVMe, PCIe 4.0 x4)
-   - Verify BIOS supports virtualization (VT-d/AMD-Vi for PCIe passthrough)
-   - Check: does ludo-mini have a second drive for Proxmox OS? If not, we need to partition the library SSD for Proxmox boot + library LVM, which complicates things significantly
-
-3. **Install Proxmox on ludo-mini:**
-   - Download Proxmox VE 9.x ISO
-   - Install to ludo-mini's system drive (NOT the library SSD)
-   - Configure networking: bridge for Proxmox, IP on 192.168.178.x
-   - Test: web UI accessible
-
-4. **Prepare NFS server on ludo-mini Proxmox:**
-   - Create NFS-export LXC (or serve from host — simpler for now)
-   - Prepare `/etc/exports`: `192.168.8.0/24(rw,all_squash,anonuid=33,anongid=10000,no_subtree_check,sec=sys)`
-   - Same squash params as current nfs-export LXC 102
-
-### Phase 2 — Physical SSD move (planned downtime)
-
-1. **Graceful shutdown on hubris:**
-   - Stop all library-mounting LXCs (101, 103, 104, 105, 114, 119, 120, 122, 126)
-   - Unmount `/mnt/library` on hubris host
-   - Edit `/etc/fstab` to comment out the library mount line
-   - Power off hubris
-
-2. **Physical drive swap:**
-   - Remove Samsung 990 EVO Plus (library SSD) from hubris
-   - Install into ludo-mini M.2 slot
-   - Power on ludo-mini
-
-3. **Bring library online on ludo-mini:**
-   - Detect the new NVMe device
-   - If it's the whole device with LVM, activate the VG:
-     ```
-     vgscan && vgchange -ay library
-     mount /dev/mapper/library-library /mnt/library
-     ```
-   - Add to `/etc/fstab` for auto-mount
-   - Verify content: `ls /mnt/library` — same tree as before
-
-4. **Start NFS export on ludo-mini:**
-   - `exportfs -ra`
-   - Verify: `showmount -e <ludo-mini-ip>`
-
-### Phase 3 — Reconnect hubris LXCs
-
-1. **Power on hubris** (without library SSD — it'll boot fine, just won't mount library)
-
-2. **Mount NFS on hubris host:**
-   - Install `nfs-common` if not present
-   - Add to `/etc/fstab`:
-     ```
-     192.168.178.181:/mnt/library /mnt/library nfs rw,vers=4,soft,timeo=30,retrans=3 0 0
-     ```
-     Use `soft` to prevent hangs if ludo-mini is down; `hard` with `intr` is safer for data integrity but can block processes.
-   - `mount /mnt/library`
-   - **Verify permissions:** `ls -la /mnt/library` — should show `www-data:media` ownership for shared subtrees (same uid 33, gid 10000). The NFS all_squash guarantees this.
-
-3. **Start LXCs:**
-   - Start the LXCs that stayed on hubris (103, 104, 105, 114, 119, 126)
-   - Their bind-mounts should work — `/mnt/library` is populated via NFS
-   - Verify each service: web UIs, git clone, document access
-
-4. **Update DNS/Caddy** for services that moved:
-   - If jellyfin, arr services moved to ludo-mini, update Caddyfile to point to ludo-mini IPs
-   - Update DNS entries if needed
-
-### Phase 4 — Migrate services to ludo-mini
-
-1. **Create LXCs/VM on ludo-mini Proxmox:**
-   - 101 jellyfin — privileged LXC, mount `/mnt/library`, add `media` group
-   - 120 mule-images — privileged LXC, mount `/mnt/library` + `/dev/dri` passthrough
-   - 122 arriman — privileged LXC, mount `/mnt/library`
-
-2. **Migrate configs:**
-   - Copy LXC configs from hubris (`/etc/pve/lxc/<id>.conf`) as templates
-   - Adjust network (IPs on household subnet or Proxmox bridge)
-   - Restore app data from backups or copy over NFS
-
-3. **Gaming VM:**
-   - Create VM with GPU passthrough
-   - Pass through the dGPU for gaming performance
-   - Install Sunshine + game libraries
-   - Storage: VM disk on Proxmox storage, games on library SSD
-
-4. **Update reverse proxy:**
-   - Caddy on hubris (121): update backend IPs for jellyfin, jellyseerr, qbit, sab, mule-images → point to ludo-mini
-   - Test: `media.hubris.network` serves from ludo-mini jellyfin
-
-### Phase 5 — Cleanup
-
-1. **Decommission nfs-export LXC 102** on hubris (no longer needed)
-2. **Update zimaos (100)** — change NFS mount from `192.168.8.200` → `192.168.178.181`
-3. **Remove old LXCs** from hubris (101, 120, 122) after confirming migration works
-4. **Update inventory.yaml:**
-   - ludo-mini: `kind: proxmox-host`, add mounts/storage, add LXCs
-   - Move services from hubris to ludo-mini
-   - Remove nfs-export
-5. **Update DNS:** `nfs-export.hubris.network` → ludo-mini IP (or remove)
-6. **Run `homelab sync`** to propagate changes
-
-## Open questions / unknowns
-
-1. **Does ludo-mini have a second drive for Proxmox OS?** If not, we'd need to repartition the library SSD — carve out ~100 GB for Proxmox, then the rest for library LVM. This is risky (data loss if partitioning goes wrong) and requires a full backup first. **Alternative:** Buy a small SSD for ludo-mini's OS.
-
-2. **What GPU does ludo-mini have?** Proxmox GPU passthrough requires IOMMU support and a GPU that doesn't have the reset bug. Need to check the exact GPU model.
-
-3. **NFS performance for git (gitea)?** Git operations over NFS can be problematic (locking, stat() storms). Gitea bare repos at `/mnt/library/repos/*.git` might need testing. Worst case: move gitea's repo storage to local disk and keep `/mnt/library` for large file/LFS storage only.
-
-4. **Media permission drift.** NFS `all_squash,anonuid=33,anongid=10000` ensures all writes from hubris LXCs (over NFS) and ludo-mini LXCs (local) land as `www-data:media`. This is the same squash currently used by nfs-export (102). Should be fine.
-
-5. **ludo-mini network — add 192.168.8.x address?** Adding a secondary IP on ludo-mini's interface directly on the homelab subnet avoids routing through hubris for NFS traffic. Cleaner, but requires Proxmox bridge setup. Worth doing during Proxmox install.
-
-6. **Sunshine migration.** Currently runs on ludo-mini bare metal. After Proxmox install, it needs to run in a VM. What happens to existing Sunshine configs, game libraries, save files? Need to preserve these during the Proxmox install.
-
-7. **Backup before moving.** The library SSD holds 3.7 TB of irreplaceable data (documents, photos, repos). Restic backups are currently disabled. **Before physically moving the drive, verify the data is readable and consider doing one backup** — or at minimum, `rsync` critical directories.
-
-## Files affected
-
-| File | Change |
-|------|--------|
-| `/opt/homelab-context/inventory.yaml` | ludo-mini: workstation → proxmox-host; add LXCs, mounts; remove nfs-export; move service backends |
-| `/opt/homelab-context/hosts/hubris.md` | Remove library storage, add NFS mount note |
-| `/opt/homelab-context/hosts/ludo-mini.yaml` | Complete rewrite — Proxmox host, storage, tenants |
-| `/opt/homelab-context/containers/102-nfs-export.md` | Mark decommissioned |
-| `/opt/homelab-context/containers/index.md` | Move 101, 120, 122 to ludo-mini; remove 102 |
-| `/opt/homelab-context/infrastructure/dns.md` | Update nfs-export entry |
-| `/opt/homelab-context/infrastructure/media-permissions.md` | Note NFS squash from ludo-mini, not hubris |
-| hubris `/etc/fstab` | Replace ext4 mount with NFS mount |
-| ludo-mini `/etc/fstab` | Add library ext4 mount |
-| ludo-mini `/etc/exports` | Add NFS export config |
-| caddy (LXC 121) Caddyfile | Backend IPs for moved services |
-| DNS (LXC 107 Technitium) | Update entries for moved services |
-
-## Validation checklist
-
-- [ ] ludo-mini Proxmox web UI accessible
-- [ ] Library SSD detected and mountable on ludo-mini
-- [ ] NFS export from ludo-mini: `showmount -e <ip>` shows `/mnt/library`
-- [ ] hubris host NFS mount: `df -h /mnt/library` shows NFS, not ext4
-- [ ] hubris LXCs start and bind-mount /mnt/library (content visible)
-- [ ] gitea: `git clone` over SSH works, repos readable
-- [ ] paperless: document ingestion works, OCR processing
-- [ ] nextcloud: file sync, WebDAV
-- [ ] jellyfin: media plays from ludo-mini, transcoding works
-- [ ] arriman: downloads write to library, jellyfin picks up new media
-- [ ] mule-images: photo import and processing
-- [ ] zimaos: NFS mount from ludo-mini works, Files UI shows library
-- [ ] Sunshine: game streaming from ludo-mini VM works
-- [ ] All `*.hubris.network` services resolve and load through Caddy

archive/hermes-plans/2026-06-03_150000-homelab-structure-revision.md

@@ -1,271 +0,0 @@
-# Homelab structure revision & improvement plan
-
-## Goal
-
-Identify structural issues in the current hubris homelab topology and propose an
-actionable improvement roadmap — DNS consolidation, monitoring gaps, backup
-recovery, mesh completion, resource rightsizing, and operational hygiene.
-
----
-
-## Current state summary
-
-| Dimension | Status |
-|-----------|--------|
-| Hypervisor | hubris (single-node Proxmox) — also does subnet routing (192.168.8.0/24) |
-| LXCs | 14 active, 1 retired (124), 1 new (107 dns) |
-| VMs | HAOS (108), ZimaOS (100) |
-| Workstations | mac-mini (macOS), republic-laptop, ludo-mini |
-| VPS | 1 IONOS box — netbird mgmt+signal+relay, traefik, authentik, coturn |
-| Switch | SODOLA 5-Port 2.5Gbit (L2, flat) |
-| Networking | 192.168.8.0/24 internal, fr!tz box main LAN via vmbr0→vmbr1 routing |
-| Mesh | Netbird + Tailscale (migrating), ~mixed state |
-| DNS | 3 sources: Technitium (CT 107), NetBird managed zone, public IONOS |
-| Backups | DISABLED since 2026-04-22 |
-| Monitoring | claudio-monitor (host health only, no apt/docker checks yet) |
-| Agent enrollment | 3/19 hosts enrolled (hubris, apps, republic-laptop) |
-
----
-
-## Issues identified
-
-### 1. Three overlapping DNS sources (highest risk)
-
-**Problem:** Technitium on CT 107, NetBird managed DNS zone, and the public
-IONOS wildcard all answer `*.hubris.network` queries. The dns.md doc still
-references the old dnsmasq on LXC 124 (though the change log says it moved).
-NetBird's managed DNS bypasses Technitium entirely for some app names — there
-is no single source of truth for DNS.
-
-**Risk:** Mismatched answers → services unreachable → "works on some clients
-but not others" debugging sessions. Already cost time when `auth.hubris.network`
-re-pointed to the VPS.
-
-**Proposal:**
-- Phase out NetBird managed DNS zone for `hubris.network` — Technitium is the
-  authoritative answerer for mesh & LAN clients
-- Set Technitium as the sole DNS for all LXCs (remove router DNS / Tailscale
-  MagicDNS fallbacks)
-- Document the full authoritative chain: Technitium → upstream forwarders → public
-- Track Technitium config in git (dtoro/technitium-config or equivalent)
-
-### 2. Backups disabled with no alternative (data loss risk)
-
-**Problem:** The only backup was restic to an external USB that caused host
-crashes. It was disabled 2026-04-22 as an A/B test — host stability was
-confirmed by the SODOLA migration (no more Slate AX double-NAT hangs). The
-drive is still removed.
-
-**Risk:** `/mnt/library` (~429 GB of irreplaceable data: photos, documents,
-git repos, gitea data) has no off-host copy. Single-disk failure = total loss.
-
-**Proposal:**
-- Re-evaluate the USB drive stability with the new SODOLA switch topology
-  (direct rear USB 3.0 port, no hub chain)
-- OR adopt a cloud-backed strategy: `rclone`-to-Hetzner Storage Box or
-  Backblaze B2 for the irreplaceable subset (docs, photos, gitea data)
-- OR use hubris's own `zfs send` to a second host/disk if ZFS is feasible
-- Minimum viable: at minimum restore gitea backups + sops-encrypted secrets
-  via an off-site cron (cheap B2 bucket)
-
-### 3. Mesh migration still incomplete
-
-**Problem:** Most LXCs still use Tailscale. This forces per-LXC DNS workarounds
-(/etc/hosts overrides, local dnsmasq) and runs two VPN stacks in parallel.
-Mesh migration doc (mesh.md) is comprehensive but execution stalled.
-
-**Proposal:**
-- Batch-migrate all LXCs from Tailscale to Netbird in one maintenance window
-- Remove Tailscale from the PVE host
-- Ensure all LXCs resolve `*.hubris.network` via Technitium (no more /etc/hosts
-  overrides)
-- Document Netbird client on each LXC (netbird version, setup key rotation)
-
-### 4. LXC resource imbalance & disk pressure
-
-**Problem:**
-| LXC | Cores | RAM | Rootfs | Disk usage |
-|-----|-------|-----|--------|------------|
-| mule-images (120) | 6 | 12 GiB | 60 GiB | photo AI, reasonable |
-| arriman (122) | 4 | 8 GiB | 24 GiB | media stack, OK |
-| nextcloud (114) | 4 | 6 GiB | 25 GiB | file sync, OK |
-| apps (105) | 2 | 4 GiB | 30 GiB | 6+ services, tight |
-| paperless (103) | 2 | 3 GiB | 8 GiB | 86.9% disk |
-| elementsynapse (118) | 1 | 2 GiB | 8 GiB | 86.8% disk |
-| gitea (104) | 1 | 1 GiB | 8 GiB | git server, adequate |
-| caddy (121) | 1 | 512 MiB | 6 GiB | fine for reverse proxy |
-
-Paperless (103) and elementsynapse (118) are at critical disk levels. apps (105)
-is undersized for 6+ services.
-
-**Proposal:**
-- Resize rootfs on paperless (8→16 GiB) and elementsynapse (8→16 GiB)
-- Bump apps (105) to 4 cores / 6 GiB RAM / 40 GiB rootfs
-- Enable claudio-monitor's disk check to alert before next crisis
-
-### 5. VPS is a single point of failure
-
-**Problem:** One IONOS VM runs netbird management (control plane), traefik
-(public ingress), authentik (identity), and coturn (TURN relay). If it goes
-down: no remote mesh, no public services, no auth.
-
-**Proposal:**
-- Document a VPS recovery runbook (how to restore from a known-working backup)
-- Consider splitting authentik into a separate host or at minimum having a
-  standby configuration
-- Not a high priority (the VPS has been stable) but worth documenting the
-  blast radius and recovery path
-
-### 6. No centralized logging
-
-**Problem:** Each LXC has independent journald. Cross-service debugging
-involves hopping between `pct exec <id> -- journalctl -u <service>`. There is
-no aggregation or retention.
-
-**Proposal:**
-- Deploy a lightweight log shipper (Loki + promtail, or vector.dev) on each LXC
-- Ship logs to a central Loki instance on apps (105) or a new small LXC
-- Grafana dashboard optional — even a simple `logcli` query saves time
-
-### 7. Agent enrollment incomplete
-
-**Problem:** Only hubris, apps, and republic-laptop are enrolled in the
-homelab-context system (age keys, sync timers, MCP access). mac-mini,
-ludo-mini, claudio-bot, and all other LXCs are not.
-
-**Proposal:**
-- Batch-enroll remaining LXCs (jellyfin, paperless, gitea, nextcloud, etc.)
-- Enroll mac-mini (macOS — exercises the launchd timer path)
-- Enroll ludo-mini (needs SSH user config in inventory first)
-- Wire claudio-bot into inventory-aware queries
-
-### 8. Configuration drift on untracked configs
-
-**Problem:** Technitium config, dnsmasq (legacy), and several service-specific
-configs are not git-tracked.
-
-**Proposal:**
-- Track Technitium zone backup + compose config in a git repo
-- Apply the same pattern as caddy-conf: dtoro/technitium-conf with auto-deploy
-
-### 9. No capacity planning / resource monitoring
-
-**Problem:** No trend data on CPU, RAM, or disk growth. The 86% disk alerts
-were discovered reactively. Rootfs resize is painful (requires Proxmox stop +
-resize + growfs inside).
-
-**Proposal:**
-- Enable the missing claudio-monitor checks (disk growth trend, apt upgradable
-  counts, docker image drift)
-- Set up a simple Prometheus + node_exporter on hubris or use the PVE API
-  directly
-- At minimum, surface disk usage in the existing homelab-mcp management tools
-
-### 10. No standard deploy / orchestration for bare-metal LXCs
-
-**Problem:** Some services are bare-metal CLI apps (sophia, claudio-bot),
-some are Docker on apps (105), some are Portainer-managed. No consistent
-deploy pattern means every new service reinvents the deployment.
-
-**Proposal:**
-- Don't over-engineer this — the current pragmatism works
-- Just document the decision tree:
-  - Needs `/mnt/library` mount + heavy I/O → dedicated LXC
-  - Small stateless web service → Docker on apps (105)
-  - Media stack → dedicated LXC (arriman, jellyfin)
-  - Everything else → judge by complexity
-
----
-
-## Phased implementation plan
-
-### Phase 1 — Critical fixes (this week)
-1. Resize rootfs on paperless (103) 8→16 GiB, elementsynapse (118) 8→16 GiB
-2. Enable claudio-monitor disk check + disk-growth alerting
-3. Pick one backup strategy and implement minimum viable (e.g. nightly
-   gitea dump + sops-encrypted secrets to B2 via rclone)
-4. Verify Technitium is the sole DNS for all LXCs (remove NetBird managed zone
-   for hubris.network)
-
-### Phase 2 — Mesh consolidation (next week)
-5. Batch-migrate remaining LXCs from Tailscale to Netbird
-6. Remove Tailscale from PVE host
-7. Remove all per-LXC /etc/hosts DNS overrides
-8. Update DNS documentation to reflect Technitium as single source
-
-### Phase 3 — Agent enrollment & logging (next 2 weeks)
-9. Enroll all LXCs in homelab-context (age keys, sync timers)
-10. Enroll mac-mini (macOS launchd path — exercises untested code path)
-11. Enroll ludo-mini
-12. Deploy log shipper (Loki + promtail) on apps (105) + all LXCs
-
-### Phase 4 — Resource & monitoring hardening (next month)
-13. Resize apps (105) rootfs, bump RAM
-14. Deploy Prometheus + node_exporter or equivalent for trend data
-15. Track Technitium config in git with auto-deploy
-16. Write VPS recovery runbook
-
-### Phase 5 — Drive re-evaluation (optional, behind host-stability gate)
-17. Re-attach USB backup drive with the new SODOLA topology (direct port)
-18. If stable for 7 days, re-enable restic backup schedule (chunked)
-19. If not stable, finalize cloud backup as permanent strategy
-
----
-
-## Files likely to change
-
-| Path | Change |
-|------|--------|
-| `/opt/homelab-context/inventory.yaml` | LXCs enrolled, resource updates |
-| `/opt/homelab-context/secrets/*.yaml` | New recipients for enrolled LXCs |
-| `/opt/homelab-context/infrastructure/dns.md` | Reflect Technitium as sole source |
-| `/opt/homelab-context/infrastructure/mesh.md` | Remove Tailscale references post-migration |
-| `/opt/homelab-context/infrastructure/backups.md` | New strategy |
-| `/opt/homelab-context/infrastructure/monitoring.md` | Enable missing checks |
-| `/opt/homelab-context/containers/103-paperless.md` | Rootfs resize |
-| `/opt/homelab-context/containers/118-elementsynapse.md` | Rootfs resize |
-| `/opt/homelab-context/containers/105-apps.md` | Resource bump, logging addition |
-| `/opt/homelab-context/containers/index.md` | Updated resource table |
-| `.sops.yaml` | New age pubkeys for enrolled LXCs |
-
-## Verification
-
-Each phase ends with a verification milestone:
-- Phase 1: `claudio-monitor` triggers on paperless disk → confirmed alert. Backup
-  of gitea data lands in B2 (or equivalent). DNS query from any LXC returns
-  Technitium answer.
-- Phase 2: `netbird status` shows all LXCs connected. Tailscale not running on
-  PVE host. `curl auth.hubris.network` from any LXC resolves correctly without
-  /etc/hosts.
-- Phase 3: Every LXC has `/opt/homelab-context/` + `/etc/age/key.txt`. MCP
-  tools return valid host info for all enrolled LXC names. `journalctl` shows
-  promtail shipping to Loki.
-- Phase 4: `claudio-monitor` shows disk growth trend. apps (105) can run all
-  6+ services without OOM.
-
-## Risks & tradeoffs
-
-- **Netbird migration window:** All LXCs will briefly lose mesh connectivity
-  during the Tailscale→Netbird cutover. Schedule in off-hours.
-- **Backup cost:** B2/e2 costs ~$5/month for ~500 GB. The USB drive was free
-  but unstable — trade money for reliability.
-- **DNS consolidation:** Removing the NetBird managed DNS zone means any
-  NetBird-specific names stop resolving for hubris.network — verify nothing
-  depends on that path.
-- **Loki on apps (105):** Adds another container to an already-loaded host.
-  May need to bump resources before deploying.
-- **Agent enrollment on every LXC:** Each enrollment creates an age keypair
-  and commits a pubkey to inventory. Process is scriptable via `homelab client
-  add` but still takes ~2 min per host for verification.
-
-## Open questions
-
-1. Is the USB backup drive still physically attached to hubris? If not, the
-   simplest "re-enable" path requires physically re-attaching it.
-2. Authentik is now on the VPS — is LXC 124 (old Authentik) still running or
-   was it fully decommissioned? The dns.md changelog says "shut down" but
-   index.md lists it as "running".
-3. What's the actual disk layout on hubris? nvme0n1, ZFS pool, mount structure
-   — needed to plan rootfs resizes safely.
-4. Does the user want to keep Tailscale on any host for a specific reason, or
-   is full Netbird migration the clear goal?

archive/hermes-plans/2026-06-03_223218-dhcp-pool-exclude-static-ips.md

@@ -1,246 +0,0 @@
-# Plan: Narrow Technitium DHCP Pool to Avoid Static-IP Conflicts
-
-> **For Hermes:** Use subagent-driven-development skill to implement this plan task-by-task.
-
-**Goal:** Eliminate the IP conflict risk created by the Technitium DHCP pool (`.100–.240`) overlapping with all static LXC/VM IPs (`.101–.239`).
-
-**Architecture:** Shrink the DHCP pool range on Technitium so it only covers IPs that no static host uses. No LXC/VM IPs change. Single server-side change (Technitium API), plus documentation updates.
-
-**Tech Stack:** Technitium DNS API (`/api/dhcp/scopes/set`), bash/curl, homelab-context repo for docs.
-
----
-
-## Problem statement
-
-The Technitium DHCP server on [CT 107](../../knowledge/wiki/containers/107-dns.md) serves `192.168.8.100–192.168.8.240`. **Every static homelab IP except hubris (`.77`) sits inside that range:**
-
-| Host | IP | Inside pool? |
-|---|---|---|
-| hubris (Proxmox) | .77 | No — below `.100` |
-| haos (VM 108) | .101 | YES |
-| gitea (104) | .121 | YES |
-| paperless (103) | .130 | YES |
-| arriman (122) | .132 | YES |
-| mule-images (120) | .136 | YES |
-| sophia (119) | .157 | YES |
-| mac-mini | .174 | YES |
-| caddy (121) | .175 | YES |
-| authentik (124) | .180 | YES |
-| plato (126) | .190 | YES |
-| zimaos (VM 100) | .195 | YES |
-| nfs-export (102) | .200 | YES |
-| apps (105) | .205 | YES |
-| jellyfin (101) | .206 | YES |
-| nextcloud (114) | .224 | YES |
-| claudio-bot (123) | .230 | YES |
-| elementsynapse (118) | .239 | YES |
-
-The docs claim "Static-IP LXCs (below `.100`) are unaffected" — this is **false**. Static IPs span `.101–.239`, the DHCP pool spans `.100–.240`. They overlap almost entirely.
-
-If the DHCP server hands out `.121/.136/.224` (or any of the above) to a new dynamic client before the static LXC claims it on boot, the static service will fail to bind and the service goes dark.
-
----
-
-## Proposed approach: Shrink the pool
-
-**Move the DHCP pool start from `.100` to `.241`**, resulting in:
-- **New pool:** `192.168.8.241 – 192.168.8.254` (14 dynamic IPs)
-- **Reserved:** `.100–.240` stays for static hosts, `.2` for Technitium, `.1` for gateway
-- **Zero changes to any LXC, VM, Caddy, or Proxmox config.**
-
-Why `.241–.254`:
-- Highest static IP is `.239` (elementsynapse) — `.241` gives a 1-IP gap
-- `.255` is the broadcast address (unusable)
-- 14 IPs is plenty for truly dynamic clients (new transient containers, test VMs)
-- If more are ever needed, the pool can easily be widened back down
-
----
-
-## Tasks
-
-### Task 1: Verify current Technitium DHCP scope from the API
-
-**Objective:** Confirm the active pool range matches what's documented.
-
-**Step 1: Log in to Technitium API and get a token**
-
-```bash
-TOKEN=$(curl -sk -X POST http://192.168.8.2:5380/api/user/login \
-  -H "Content-Type: application/json" \
-  -d '{"user":"admin","pass":"'$(cat /opt/technitium/admin_password.txt)'","includeInfo":false}' \
-  | jq -r '.token')
-echo "Token: ${TOKEN:0:10}..."
-```
-
-**Step 2: Fetch current DHCP scopes**
-
-```bash
-curl -sk "http://192.168.8.2:5380/api/dhcp/scopes/list?token=$TOKEN" | jq .
-```
-
-**Expected:** One scope named `homelab` with `startingAddress: "192.168.8.100"` and `endingAddress: "192.168.8.240"`.
-
-**Verification:** If the scope is NOT `.100–.240`, note the actual range and adjust the plan.
-
----
-
-### Task 2: Update the DHCP scope to `.241–.254`
-
-**Objective:** Shrink the pool so it no longer overlaps static IPs.
-
-**Step 1: Update the scope via API**
-
-```bash
-curl -sk -X POST "http://192.168.8.2:5380/api/dhcp/scopes/set?token=$TOKEN" \
-  -H "Content-Type: application/json" \
-  -d '{
-    "name": "homelab",
-    "startingAddress": "192.168.8.241",
-    "endingAddress": "192.168.8.254",
-    "subnetMask": "255.255.255.0",
-    "gatewayAddress": "192.168.8.1",
-    "dnsServerAddresses": ["192.168.8.2"],
-    "leaseTime": 86400
-  }'
-```
-
-**Step 2: Verify the change took effect**
-
-```bash
-curl -sk "http://192.168.8.2:5380/api/dhcp/scopes/list?token=$TOKEN" | jq '.response.scopes[0] | {startingAddress, endingAddress}'
-```
-
-**Expected:**
-```json
-{
-  "startingAddress": "192.168.8.241",
-  "endingAddress": "192.168.8.254"
-}
-```
-
-**Pitfall:** If the API returns `{"status":"error"}`, the scope name or parameter format may differ. Inspect the response body. Technitium's API might use `rangeStart`/`rangeEnd` instead of `startingAddress`/`endingAddress`. Adjust if needed (check the full scope object from Task 1 step 2 for exact key names).
-
----
-
-### Task 3: Check for active DHCP leases in the old pool that would be stranded
-
-**Objective:** Ensure no DHCP client is currently holding an IP in `.100–.240` that it will lose when its lease expires.
-
-**Step 1: List active DHCP leases**
-
-```bash
-curl -sk "http://192.168.8.2:5380/api/dhcp/leases/list?token=$TOKEN" | jq '.response.leases[] | {ip: .ipAddress, client: .clientHostname, mac: .hardwareAddress, expires: .leaseExpires}'
-```
-
-**Step 2: Interpret results**
-
-- If the only leases are from static LXCs that configured themselves before the DHCP move (e.g., old leases from before the 2026-06-02 static-IP migration), these leases are stale and harmless.
-- If a *dynamic* client (e.g., a test laptop, transient VM) holds `.195` or similar, note it — it will lose its IP on next renew and should be moved to a static assignment or into the `.241+` pool.
-- **ZimaOS (VM 100) at `.195` is a DHCP lease, not static** — this is the one host that needs attention. Either:
-  - Set a static IP inside ZimaOS (preferred), or
-  - Add a DHCP reservation for MAC in Technitium to pin `.195`
-
-**Verification:** No "surprise" dynamic clients that would break on lease expiry.
-
----
-
-### Task 4: Fix ZimaOS IP stability (if needed)
-
-**Objective:** Ensure ZimaOS at `.195` won't float or break when the pool shrinks.
-
-**If ZimaOS already has a static IP configured inside the VM:** Nothing to do.
-
-**If ZimaOS is DHCP-only (likely — doc says "DHCP lease, not a reservation"):**
-
-Option A (preferred): Set a static IP inside ZimaOS via its web UI at `http://192.168.8.195` → Settings → Network → Static IP → `192.168.8.195/24`, gateway `192.168.8.1`, DNS `192.168.8.2`.
-
-Option B: Add a DHCP reservation in Technitium for ZimaOS's MAC address:
-```bash
-ZIMAMAC=$(ssh root@hubris "qm config 100 | grep net0 | grep -oE '([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}'")
-curl -sk -X POST "http://192.168.8.2:5380/api/dhcp/reservations/add?token=$TOKEN" \
-  -H "Content-Type: application/json" \
-  -d "{\"hardwareAddress\":\"$ZIMAMAC\",\"ipAddress\":\"192.168.8.195\"}"
-```
-
-**Pitfall:** The `/api/dhcp/reservations/add` endpoint signature is unverified — confirm the exact endpoint name from Technitium's API docs or the web UI before running it. The web console at `http://192.168.8.2:5380` → DHCP → Reservations can be used as a manual fallback.
-
----
-
-### Task 5: Update documentation in homelab-context
-
-**Objective:** Fix the now-wrong claims about static IPs being "below .100".
-
-**Files to edit:**
-
-1. **`infrastructure/network.md`** — Line 53
-   - Old: `Most homelab LXCs use static IPs below \`.100\`. DHCP only covers new/transient containers.`
-   - New: `Static IPs span \`.101–.239\` (all LXCs + VMs + workstations). DHCP pool narrowed to \`.241–.254\` to avoid overlap.`
-
-2. **`containers/107-dns.md`** — Lines 37, 42, 55
-   - Line 37: Update pool range: `192.168.8.241 – 192.168.8.254`
-   - Line 42: `Static-IP LXCs (below \`.100\`)` → `Static-IP LXCs (\`.101–.239\`) are excluded from the pool.`
-   - Line 55: Add changelog entry for the pool shrink
-
-3. **`containers/107-dns.md`** — Add changelog entry:
-   ```markdown
-   ### 2026-06-03 — DHCP pool narrowed to `.241–.254` to exclude static IPs
-   Previous pool `.100–.240` overlapped with all static LXCs/VMs (\`.101–.239\`), creating IP conflict risk. Shrunk pool to `.241–.254`. No services re-IP'd. See [plan](../plans/2026-06-03-dhcp-pool-exclude-static-ips.md).
-   ```
-
-4. **`infrastructure/network.md`** — Line 51: Update pool range in the DHCP table row.
-
-5. **`plans/2026-06-01-slate-ax-to-sodola-migration.md`** — Line 60: Optionally update the pool range in the config table (or add a post-migration note). This is the historical migration plan, so a footnote rather than an edit may be better.
-
-**Commit:**
-```bash
-cd /opt/homelab-context
-git add infrastructure/network.md containers/107-dns.md plans/
-git commit -m "docs: DHCP pool narrowed to .241-.254 to exclude static IPs"
-git push
-```
-
----
-
-### Task 6: Verify no regressions
-
-**Objective:** Smoke-test that DNS and key services still work after the scope change.
-
-```bash
-# 1. DNS resolution via Technitium
-dig @192.168.8.2 +short git.hubris.network
-# Expected: 192.168.8.175
-
-# 2. Caddy reverse-proxy chain
-curl -sI https://git.hubris.network | head -1
-# Expected: HTTP/2 200
-
-# 3. All app names resolve
-for name in git cloud media paperless photos matrix auth plato artifacto; do
-  result=$(dig @192.168.8.2 +short ${name}.hubris.network)
-  printf "%-20s → %s\n" "${name}.hubris.network" "$result"
-done
-
-# 4. Technitium DHCP scope is correct
-curl -sk "http://192.168.8.2:5380/api/dhcp/scopes/list?token=$TOKEN" | jq '.response.scopes[0] | {startingAddress, endingAddress}'
-```
-
----
-
-## Risk assessment
-
-| Risk | Likelihood | Impact | Mitigation |
-|---|---|---|---|
-| API call fails (wrong field names) | Medium | Low | Inspect live scope object first (Task 1); adjust payload |
-| ZimaOS loses IP on next boot | Low | Medium | Task 4 makes ZimaOS static or reserved |
-| Active DHCP client in `.100–.240` gets stranded | Low | Low | Task 3 surfaces this; client just requests a new IP from `.241+` |
-| Technitium admin password file missing | Low | Medium | `/opt/technitium/admin_password.txt` was created during setup; verify existence |
-
-## Open questions
-
-1. Is zimaos (VM 100) currently DHCP or static? The doc says DHCP lease, but it's listed as `lan_ip: 192.168.8.195` in inventory. If it's actually DHCP, it's the one host that needs a static assignment before the pool shrinks.
-2. Are there any transient DHCP clients (test laptops, phones) on the homelab subnet that hold `.100–.240` addresses? Check leases before cutting over.
-3. Should we widen the pool slightly (e.g., `.230–.254`) for more headroom? Currently 14 IPs. If 3+ transient devices are expected, `.230–.254` = 25 IPs — still safe since the highest static is `.239` and `.230–.239` could be excluded.
-
-## Execution preference
-
-All changes are on the Technitium API + homelab-context repo. No LXC/VM restarts needed. The pool shrink takes effect immediately for NEW DHCP requests; existing leases in the old range continue until expiry (24h max).

archive/hermes-plans/2026-06-05_170000-prevent-dhcp-ip-drift.md

@@ -1,129 +0,0 @@
-# Plan: Prevent DHCP IP drift from breaking Caddy backends
-
-**Date:** 2026-06-05  
-**Slug:** prevent-dhcp-ip-drift
-
----
-
-## Goal
-
-Eliminate the root cause of services becoming unreachable when DHCP lease renewals change backend IPs that Caddy's `reverse_proxy` directives hardcode.
-
-**Triggering incident:** Paperless (LXC 103) and HAOS (VM 108) had DHCP-assigned IPs change from `.130→.243` and `.101→.241` respectively. Caddyfile still pointed at the old IPs → services unreachable from iPhone on Netbird.
-
-## Current context
-
-### DHCP vs static IP inventory
-
-| Machine | Type | PVE ID | Current IP | Allocation method | Status |
-|---------|------|--------|-----------|-------------------|--------|
-| **jellyfin** | LXC | 101 | 192.168.8.206 | Static (`ip=.../24`) | ✅ |
-| **paperless** | LXC | 103 | 192.168.8.243 | **DHCP** (`ip=dhcp`) | ❌ broken, hotfixed to .243 |
-| **gitea** | LXC | 104 | 192.168.8.121 | Static | ✅ |
-| **apps** | LXC | 105 | 192.168.8.205 | Static | ✅ |
-| **nextcloud** | LXC | 114 | 192.168.8.224 | Static | ✅ |
-| **elementsynapse** | LXC | 118 | 192.168.8.239 | Static | ✅ |
-| **mule-images** | LXC | 120 | 192.168.8.136 | Static | ✅ |
-| **caddy** | LXC | 121 | 192.168.8.175 | Static | ✅ |
-| **arriman** | LXC | 122 | 192.168.8.132 | Static | ✅ |
-| **sophia** | LXC | 119 | 192.168.8.157 | Static? | ? (not in 2026-06-02 list) |
-| **nfs-export** | LXC | 102 | 192.168.8.200 | Static? | ? |
-| **plato** | LXC | 126 | 192.168.8.190 | Static? | ? |
-| **HAOS** | VM | 108 | 192.168.8.241 | **DHCP** (VM — OS-managed) | ❌ broken, hotfixed to .241 |
-| **zimaos** | VM | 100 | 192.168.8.195 | DHCP (known stale lease, see note) | ⚠️ open issue |
-| **authentik** | — | — | — | migrated to VPS (external) | N/A |
-
-### Infrastructure facts
-
-- **DHCP server:** Technitium on CT 107 (192.168.8.2), pool `.241–.254`
-- **Static IP range:** `.101–.239`
-- **DNS:** Split-horizon on Technitium — `*.hubris.network → 192.168.8.175` (Caddy itself)
-- **Caddyfile:** Has 29 `reverse_proxy` directives, all using **hardcoded IP:port**
-- **Caddy reload:** Auto-deployed via webhook on git push to `dtoro/caddy-conf`
-- **Documentation:** `inventory.yaml` updated, `hosts/*.yaml` stale-before-regenerate
-
-### Why it happened
-
-1. Paperless LXC 103 was **missed** during the 2026-06-02 static-IP migration (Proxmox config still shows `ip=dhcp`)
-2. HAOS VM 108 uses DHCP internally (HAOS manages its own network — can't just `pct set`)
-3. Both got new IPs from the Technitium `.241–.254` pool after a lease renewal
-4. Caddyfile still pointed at the old static-range IPs → connection refused
-
----
-
-## Proposed approach
-
-Three-layer solution:
-
-### Layer 1: Fix the immediate offenders (static assignment)
-
-**Paperless LXC 103:**
-- `pct set 103 --net0 name=eth0,bridge=vmbr0,gw=192.168.8.1,hwaddr=BC:24:11:0A:8D:C2,ip=192.168.8.130/24,ip6=auto,type=veth`
-- Inside the LXC, update `/etc/network/interfaces` to match
-- Reboot/restart networking
-
-**HAOS VM 108:**
-- Set a **DHCP reservation** in Technitium for the VM's MAC address, pinning it to `192.168.8.101`
-- This avoids needing to reconfigure HAOS internally (which is tedious)
-- Alternatively: use `ha network update` from the HAOS console to set a static IP
-
-### Layer 2: Audit and fix all remaining DHCP hosts
-
-Check every LXC/VM hosted on hubris:
-```bash
-for ct in $(pct list | awk 'NR>1{print $1}'); do
-  echo "=== CT $ct ==="
-  pct config $ct | grep "^net0"
-done
-```
-Any with `ip=dhcp` that Caddy reverse-proxies to → convert to static.
-
-**Known candidates to check:**
-- CT 102 (nfs-export) — `.200` but not in Caddy. May not need static.
-- CT 119 (sophia) — `.157` — is this static or DHCP? Not sure.
-- CT 126 (plato) — `.190` — same question.
-- VM 100 (zimaos) — `.195` but known to have a stale lease (see 2026-06-03 changelog)
-
-### Layer 3: Add validation
-
-Create a script that runs periodically (cron or homelab cronjob):
-
-**`/opt/homelab-context/scripts/check-caddy-backends.sh`:**
-1. Parse `/etc/caddy/Caddyfile` on CT 121 to extract all `reverse_proxy IP:port` targets
-2. For each `IP:port`, attempt a TCP connect (timeout 3s)
-3. Report any that fail
-
-Could also run as a homelab cron job that notifies dtoro on Matrix if a backend is unreachable.
-
-This catches any future drift proactively (before a user reports it).
-
-### Files likely to change
-
-| File | Change |
-|------|--------|
-| `inventory.yaml` | May update paperless/HAOS IPs if we choose different static IPs |
-| LXC 103 Proxmux config (via `pct set`) | Set static IP |
-| Technitium DHCP reservations | Add HAOS reservation |
-| `/etc/caddy/Caddyfile` on CT 121 | Already fixed — only changes again if we re-assign paperless IP to `.130` |
-| `scripts/check-caddy-backends.sh` | New validation script (new file in homelab-context) |
-
-### Risks / Tradeoffs
-
-- **Pinning paperless to `.130`** — if the LXC was reinstalled since then, `.130` may already be in use. Verify first with `arp-scan` or `nmap`.
-- **HAOS static IP via Technitium reservation** vs **inside HAOS**: Technitium reservation is simpler (no HA config changes), but if HAOS's DHCP lease expires and the Technitium server is down, the reservation won't help. A static IP inside HAOS is more robust but requires poking the HA console.
-- **Validation script false positives** — a service might be legitimately down for maintenance. The script should be a warning, not an alert.
-- **Caddy reload** — each Caddyfile edit triggers an auto-reload via webhook. If the backend is down during reload, Caddy itself stays up (it's just a reverse_proxy target).
-
-### Verification
-
-1. After setting paperless static: `ssh root@192.168.8.175 "curl -s -o /dev/null -w '%{http_code}' http://192.168.8.130:8000"` → 302
-2. After Technitium HAOS reservation: `curl -s -o /dev/null -w '%{http_code}' http://192.168.8.101:8123` → 200
-3. Run validation script → all targets reachable
-4. Confirm from iPhone: both `paperless.hubris.network` and `home.hubris.network` load
-
-### Open questions
-
-1. Should paperless go back to `.130` (its original), or stay at `.243` (current)? Going back to `.130` means updating the Caddyfile again, but keeps the static range allocation consistent.
-2. HAOS: Technitium reservation or HAOS-internal static config? Reservation is easier; HAOS-internal is more robust.
-3. Should the Caddyfile validation script run as a homelab cron job, or as a cron on the caddy LXC itself?
-4. ZimaOS (VM 100) — should we also pin its IP while we're at it?

archive/hermes-plans/2026-06-06_232200-authentik-frequent-login-fix.md

@@ -1,130 +0,0 @@
-# Plan: Fix Frequent Authentik Login Prompts
-
-## Goal
-
-Stop requiring repeated login to Authentik (several times per day) by fixing session and cookie expiry settings so the user stays logged in for longer periods (e.g., 7–30 days, or until explicit logout).
-
-## Current Context
-
-Authentik runs on the VPS (`82.165.190.79`) in Docker Compose. Traffic flows:
-
-```
-Browser → Caddy (LXC 121) → VPS Traefik → Authentik
-```
-
-Caddy's `forward_auth` uses the `(authentik)` snippet which proxies to `auth.hubris.network/outpost.goauthentik.io/auth/caddy`. The Authentik server version is **2026.5.2**.
-
-## Root Cause Found
-
-### Primary: `SESSION_EXPIRE_AT_BROWSER_CLOSE = True`
-
-The Authentik Django session (`authentik_session` cookie) is configured to **expire on browser close**. Every time the user closes and reopens their browser, the session cookie is cleared. The next visit to a service that requires OAuth2 authorization (Gitea, Jellyfin, etc.) will redirect to the Authentik login page.
-
-### Secondary: `SESSION_COOKIE_AGE = 86400` (24 hours)
-
-Even with the browser left open continuously, the session expires after 24 hours. Combined with `SESSION_SAVE_EVERY_REQUEST = False`, activity does NOT extend the session.
-
-### Session configuration (from Docker Python environment):
-
-| Setting | Current Value | Default in Django |
-|---------|---------------|-------------------|
-| `SESSION_EXPIRE_AT_BROWSER_CLOSE` | `True` | `False` |
-| `SESSION_COOKIE_AGE` | `86400` (24h) | `1209600` (14d) |
-| `SESSION_SAVE_EVERY_REQUEST` | `False` | `False` |
-| `SESSION_COOKIE_SAMESITE` | `Lax` | `Lax` |
-
-### What ISN'T the problem:
-
-- **Proxy cookie validity** — `hubris-forward-auth` has `access_token_validity = hours=24`, which is reasonable for the forward-auth token.
-- **Server-side session duration** — The `user_login` stage has `session_duration = seconds=0` (indefinite).
-- **Refresh tokens** — All OAuth2 providers have `refresh_token_validity = days=30`, which is fine.
-- **Caddy configuration** — The forward-auth chain is correctly set up.
-- **Outpost health** — All containers healthy, up for 6 days.
-
-## Proposed Approach
-
-Change two Django session settings via Authentik environment variables:
-
-1. **`AUTHENTIK_SESSION_COOKIE_AGE` = 604800** (7 days) — extends session cookie lifetime from 24h to 7 days
-2. **`AUTHENTIK_SESSION_EXPIRE_AT_BROWSER_CLOSE` = false** — prevents session cookie from being cleared on browser close
-
-This keeps users logged in for up to 7 days with normal browser use (close/reopen, daily usage). The session still expires after 7 days of inactivity (`SESSION_SAVE_EVERY_REQUEST` stays False).
-
-## Step-by-step Plan
-
-### Step 1: Add environment variables to Docker compose
-
-Edit `/opt/docker-compose.yml` on the VPS to add these env vars to the `authentik-server` service:
-
-```yaml
-authentik-server:
-  environment:
-    # ... existing vars ...
-    AUTHENTIK_SESSION_COOKIE_AGE: "604800"      # 7 days (was 86400 / 24h)
-    AUTHENTIK_SESSION_EXPIRE_AT_BROWSER_CLOSE: "false"  # was true
-```
-
-Note: the Authentik config system uses `__` (double underscore) for nesting. The env vars map to the Django settings via the config YAML path. The correct Authentik env var for `SESSION_COOKIE_AGE` would be `AUTHENTIK_SESSION__COOKIE_AGE` if it goes through the config system, or just `SESSION_COOKIE_AGE` if it's passed directly. Need to verify the exact variable name Authentik expects.
-
-### Step 2: Verify variable naming
-
-Check the Authentik config YAML (`/authentik/lib/default.yml` inside the container) to confirm the exact env var name mapping. Authentik uses a custom config layer that maps env vars to settings.
-
-**Alternative if env vars don't work:** Some Authentik settings need to be set via the admin UI (under System Settings or Tenant settings). The Django session settings might need to be configured differently in this version.
-
-### Step 3: Restart Authentik server
-
-```bash
-ssh root@82.165.190.79
-docker compose -f /opt/docker-compose.yml restart authentik-server
-```
-
-### Step 4: Verify the fix
-
-```bash
-# Check session settings took effect
-ssh root@82.165.190.79 'docker exec -i authentik-server python3 << "PYEOF"
-import os
-os.environ.setdefault("DJANGO_SETTINGS_MODULE", "authentik.root.settings")
-import django
-django.setup()
-from django.conf import settings
-print("SESSION_EXPIRE_AT_BROWSER_CLOSE:", settings.SESSION_EXPIRE_AT_BROWSER_CLOSE)
-print("SESSION_COOKIE_AGE:", settings.SESSION_COOKIE_AGE)
-PYEOF'
-```
-
-### Step 5: Functional test
-
-1. Login to Authentik at `auth.hubris.network`
-2. Close the browser completely
-3. Re-open browser, navigate to a forward-auth-gated service (e.g., paperless.hubris.network)
-4. Verify you're NOT redirected to login
-5. Verify OAuth2 services (Gitea) also maintain the session
-
-## Files Likely to Change
-
-| File | Change |
-|------|--------|
-| `/opt/docker-compose.yml` | Add `AUTHENTIK_SESSION_COOKIE_AGE` and `AUTHENTIK_SESSION_EXPIRE_AT_BROWSER_CLOSE` env vars |
-
-## Tests / Validation
-
-1. **Config verification** — Run Python snippet inside container to confirm Django settings changed
-2. **Browser test** — Close/reopen browser, verify session persists (Step 5 above)
-3. **24-hour test** — Check session is still alive after 24h of normal use
-
-## Risks, Tradeoffs, and Open Questions
-
-| Risk | Mitigation |
-|------|------------|
-| Env var names don't match Authentik's config schema | First verify in the container's `default.yml` config file |
-| 7-day persistent cookie is a security concern (stolen cookie = 7 days of access) | This is the same risk as any "Remember Me" feature on any web app. The tradeoff is convenience vs. security. |
-| The proxy cookie (`authentik_proxy_*`) may still have its own 24h limit | That's managed separately via the OAuth2 provider's `access_token_validity` setting. If we also want to extend that, we can update `hubris-forward-auth` provider's `access_token_validity` from `hours=24` to `days=7`. |
-| `SESSION_COOKIE_SECURE = False` | Should be `True` since Authentik is served behind HTTPS. However, the forward-auth subrequest from Caddy to the outpost is HTTP internally (`http://127.0.0.1:8099`), so `False` may be intentional for the outpost check. |
-
-## Open Questions
-
-1. **What environment variable name does Authentik use for Django session settings?** Need to check `default.yml`. The config layer may use `AUTHENTIK_SESSION__COOKIE_AGE` (double underscore) or the raw Django setting name.
-2. **Should we also extend the proxy token validity?** The `hubris-forward-auth` provider has `access_token_validity = hours=24`. If we want users to not need re-login for more than 24h, we should also bump this to match the session cookie age.
-3. **Which specific service triggers the most login prompts?** The forward-auth (Caddy-gated) services use proxy cookies. OAuth2 services (Gitea, Jellyfin) use the Django session. Understanding which one the user is hitting most could narrow the fix scope.

archive/hermes-plans/2026-06-06_234500-caddyfile-truncation-permanent-fix.md

@@ -1,149 +0,0 @@
-# Plan: Fix Caddyfile truncation + prevent recurring outages
-
-**Date:** 2026-06-06
-**Slug:** caddyfile-truncation-permanent-fix
-
----
-
-## Goal
-
-Restore all `*.hubris.network` services that went offline when the Caddyfile on LXC 121 was truncated to only 3 photo-related site blocks, and implement automated safeguards to prevent this class of outage from recurring.
-
-## Root cause
-
-The Caddyfile at `/etc/caddy/Caddyfile` on LXC 121 was manually edited locally (not via the `dtoro/caddy-conf` git repo), overwriting ~260 lines (30+ site blocks + forward-auth infrastructure) with only 43 lines covering `photos.hubris.network`, `prism.hubris.network`, and a manually-added `photos2.hubris.network`.
-
-**Evidence:**
-- `git diff HEAD -- Caddyfile` shows `+3 / -159` lines diff — all other blocks deleted
-- Git reflog shows HEAD at `32575ce` (`fix: sab... port 8081→8082`), but working tree diverges
-- Deploy webhook log: Jun 06 12:39 — `deploy failed: git pull` (dirty tree blocks merge)
-- Backup file `Caddyfile.bak.1780263919` (225 lines) confirms the full original was intact before truncation
-- `origin/master` at `1b977aa` is the authoritative source — 260 lines, all blocks present
-
-**Why "third time this week":**
-| Incident | Date | Cause |
-|---|---|---|
-| 1 | Jun 02 | DHCP IP drift — paperless (130→243), HAOS (101→241) |
-| 2 | Jun 05 | More DHCP drift — apps (205), mule-images (136 overridden by dhclient) |
-| 3 | Jun 06 | **Caddyfile truncated** — unrelated to IPs, much worse |
-
-The Caddyfile truncation is the most severe: it took down **all LAN services** except `photos.hubris.network` and `auth.hubris.network` (VPS-hosted).
-
-## Immediate fix
-
-### Step 1: Restore Caddyfile from origin/master and reload
-
-On LXC 121:
-
-```bash
-cd /etc/caddy
-# Stash any local changes
-git stash
-# Reset to origin/master
-git checkout --force origin/master -- Caddyfile
-# Caddyfile now has all 30+ sites
-caddy validate --config /etc/caddy/Caddyfile
-systemctl reload caddy
-```
-
-This restores all service blocks including: media, git, paperless, books, home, cloud, matrix, proxmox, docker, jellyseerr, qbit, sab, blog, auth, artifacto, plato, zimaos, mcp, secrets, sso + authentik forward-auth infrastructure.
-
-### Step 2: Add `photos2.hubris.network` via git (if still needed)
-
-The `photos2.hubris.network` block was manually added locally and is NOT in origin/master. If the user wants to keep it, submit a PR/commit to the `dtoro/caddy-conf` repo.
-
-### Step 3: Verify
-
-- From any LAN/mesh client: `curl -sk https://media.hubris.network/` → 200
-- Run `bash /opt/homelab-context/scripts/check-caddy-backends.sh` from hubris → all targets reachable
-- Flush mac-mini DNS: `sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder`
-
-## Permanent safeguards
-
-### Layer 1: Caddyfile integrity check (deploy hook)
-
-Add a site-count validation to the deploy script (`/etc/caddy/scripts/deploy.sh`):
-
-```bash
-# Count site blocks (lines matching *.hubris.network {)
-SITE_COUNT=$(grep -c '^[a-z].*hubris.network {' Caddyfile)
-if [ "$SITE_COUNT" -lt 20 ]; then
-  echo "[deploy] ERROR: Only $SITE_COUNT sites found (expected 20+). Refusing to reload."
-  exit 1
-fi
-```
-
-This catches any future truncation before `caddy reload` runs.
-
-### Layer 2: Caddyfile backup on deploy
-
-Add to deploy script before git pull:
-
-```bash
-cp Caddyfile "Caddyfile.bak.$(date +%s)"
-```
-
-Keep last 3 backups, auto-rotate.
-
-### Layer 3: Dirty-tree handling in deploy webhook
-
-The deploy webhook currently hard-fails when the working tree is dirty. Change the receiver script to handle this gracefully:
-
-```bash
-cd /etc/caddy
-# If dirty, stash local changes
-if ! git diff --quiet; then
-  echo "[deploy] Working tree dirty — stashing"
-  git stash push -m "auto-stash by deploy webhook $(date)"
-fi
-git pull --ff-only
-```
-
-This prevents the webhook from blocking on future local edits.
-
-### Layer 4: Scheduled Caddyfile health check
-
-Add a homelab cron job that runs `check-caddy-backends.sh` every 10 minutes and notifies if any Caddy backend is unreachable.
-
-```yaml
-# In homelab context: cronjob
-schedule: "*/10 * * * *"
-script: /opt/homelab-context/scripts/check-caddy-backends.sh
-```
-
-### Layer 5: DNS sync cron (fix already-deployed sync)
-
-The `dns-sync.py` on LXC 107 at `/opt/dns-sync/sync.py` is installed but has **no crontab** — the sync never runs automatically. The NetBird managed DNS zone has drifted from Technitium. Add a systemd timer or crontab:
-
-```bash
-echo "*/10 * * * * root python3 /opt/dns-sync/sync.py >> /var/log/dns-sync.log 2>&1" > /etc/cron.d/dns-sync
-```
-
-## Files likely to change
-
-| File | Change |
-|------|--------|
-| `/etc/caddy/Caddyfile` on LXC 121 | Restore from origin/master |
-| `/etc/caddy/scripts/deploy.sh` on LXC 121 | Add site-count validation + backup + dirty-tree handling |
-| `caddy-conf` git repo | PR with deploy.sh improvements + photos2 (if wanted) |
-| `cronjob` in Hermes | Schedule `check-caddy-backends.sh` |
-| `/etc/cron.d/dns-sync` on LXC 107 | New — add dns-sync cron |
-
-## Verification
-
-1. All `*.hubris.network` URLs load from mac-mini: `media`, `git`, `paperless`, `cloud`, `home`, `proxmox`, etc.
-2. `check-caddy-backends.sh` exits 0 on hubris
-3. `systemctl status caddy` shows active on LXC 121
-4. `dns-sync` runs and writes to `/var/log/dns-sync.log`
-
-## Risks / Tradeoffs
-
-- **Restoring from origin/master overwrites photos2.hubris.network** — recreate it via proper git commit
-- **Caddy staging ACME certs for prism/photos2**: The `tls dns ionos` directive uses staging env (`acme-staging-v02.api.letsencrypt.org`), which fails DNS propagation check (VPS port 53 unreachable from LXC). Once restored, these two subdomains will have the same issue. Move them to production IONOS DNS-01 by removing the staging CA directive or setting the correct `acme_issuer` in Caddyfile.
-- **Dirty-tree stash could lose edits** — mitigated by `git stash push --message` + backup file creation before stash
-
-## Open questions
-
-1. Keep `photos2.hubris.network`? If yes, add via proper git push.
-2. `prism.hubris.network` and `photos2` certs fail on staging ACME — set production `acme_issuer` in Caddyfile?
-3. Should `check-caddy-backends.sh` run as a homelab cron job or as a regular cron on LXC 121?

archive/hermes-plans/2026-07-05_strong-migration-assessment.md

@@ -1,358 +0,0 @@
-# Assessment: Which nodes can move to `strong`
-
-## Executive summary
-
-hubris is **memory-starved**: 28 GiB RAM, 71.9 GiB allocated across 18 LXC + 2 VM
-(2.5× overcommit), 10 GiB swap in active use. strong sits **completely empty** —
-28 GiB RAM, 25 GiB free, 0 guests, 2.7 TiB unused storage. The single most
-effective decongestion move is to shift guests off hubris onto strong.
-
-This document assesses every guest for move-readiness, grouped by constraints
-(library dependency, GPU, core-infra status), and proposes a phased migration
-that does **not** require the physical library-SSD move (the blocker of the
-original plan) — library access from strong is provided via NFS from hubris.
-
----
-
-## Current resource state (live, 2026-07-05)
-
-### hubris — overloaded
-
-| Resource | Capacity | Allocated (all guests) | Actual use | Status |
-|----------|----------|----------------------|------------|--------|
-| RAM | 28 GiB | 70.2 GiB (2.5× overcommit) | 18 GiB used + 10 GiB swap | ⚠️ heavy swap pressure |
-| CPU | 12 vCPU (6c/12t) | 43 vCPU (3.6× overcommit) | ~43% scaling MHz | OK (shares) |
-| local-lvm | 856 GiB | 582 GiB allocated (29% thin) | — | OK |
-| library (lvmthin) | 3.7 TiB | — | 1.2 TiB used (34%) | OK, 2.3 TiB free |
-
-### strong — empty, ready
-
-| Resource | Capacity | Used | Status |
-|----------|----------|------|--------|
-| RAM | 28 GiB | 2.3 GiB (host only) | 25 GiB free |
-| CPU | 16 vCPU (8c/16t) | idle (0.08 load) | 100% free |
-| local-lvm | 856 GiB | 0 | empty |
-| ludo-lvm | 1.8 TiB | 0 | empty |
-| Guests | — | 0 LXC, 0 VM | nothing running |
-
-### Network topology constraint
-
-```
-Fritz!Box (192.168.178.1)
-  └── SODOLA 2.5G switch
-       ├── hubris eno1 → vmbr1 (192.168.178.10) → vmbr0 (192.168.8.0/24)
-       │     └── all 20 guests on 192.168.8.x
-       └── strong vmbr0 (192.168.178.181)
-             └── no internal bridge yet, guests would be on 192.168.178.x
-```
-
-strong reaches `192.168.8.0/24` via the Fritz static route through hubris.
-Guests on strong get `192.168.178.x` IPs unless we add an internal bridge
-on strong (Phase 0 prerequisite — see below).
-
----
-
-## Per-guest assessment
-
-### Tier 1 — Move immediately (no library dependency, no core-infra)
-
-These guests mount **no** `/mnt/library` and are not part of the core
-infrastructure spine (caddy/dns/auth/mcp). They are the easiest wins.
-
-| ID | Name | Cores | RAM | Library? | GPU? | Notes |
-|----|------|-------|-----|----------|------|-------|
-| 118 | elementsynapse | 2 | 4 GiB | ❌ | ❌ | Matrix homeserver. Public via Caddy (`matrix.hubris.network`). Only change: Caddy backend IP. **Easiest move in the fleet.** |
-| 129 | house | 2 | 3 GiB | ❌ | ❌ | Yuvomi family planner (Docker). No public Caddy route yet (uses VPS traefik directly). Self-contained. |
-
-**Combined RAM freed from hubris: 7 GiB.** No NFS, no library, no GPU.
-
-### Tier 2 — Move with library NFS (high resource consumers)
-
-These are the heaviest guests and the original migration plan's primary
-targets. They mount `/mnt/library` and two use the iGPU. Moving them
-requires an NFS export from hubris → strong (reverse of the original
-plan's direction, since the physical SSD hasn't moved).
-
-| ID | Name | Cores | RAM | Library? | GPU? | I/O profile | Notes |
-|----|------|-------|-----|----------|------|-------------|-------|
-| 120 | mule-images | 6 | 12 GiB | ✅ mp0 | ✅ iGPU | Write-heavy (photo processing) | **#1 RAM consumer.** Strong has Radeon 680M iGPU (VAAPI works). |
-| 122 | arriman | 4 | 8 GiB | ✅ mp0 | ❌ | Write-heavy (downloads) | *arr stack + qbit + sab. Mounts library for download writes. |
-| 101 | jellyfin | 4 | 8 GiB | ✅ mp0 | ✅ iGPU | Read-heavy sequential | Media streaming + transcode. Strong 680M handles VAAPI. |
-
-**Combined RAM freed: 28 GiB.** This alone would eliminate hubris's swap
-pressure entirely.
-
-### Tier 3 — Could move, low urgency
-
-| ID | Name | Cores | RAM | Library? | Notes |
-|----|------|-------|-----|----------|-------|
-| 130 | grimmory | 1 | 2 GiB | ✅ mp0 | Book library (Docker). Migrated from apps LXC recently. |
-| 131 | teddycloud | 1 | 1 GiB | ✅ mp0 | New (not in inventory.yaml yet). |
-| 132 | rclone | 1 | 2 GiB | ✅ mp0 (ro) | Backup container. Read-only library mount. |
-| 128 | trmnl | 1 | 768 MiB | ❌ | TRMNL middleware. No library. Could move but tiny. |
-| 119 | sophia | 2 | 1 GiB | ✅ mp0 | Workshop. Light use. |
-
-### Stay on hubris (core infrastructure)
-
-| ID | Name | Cores | RAM | Why it stays |
-|----|------|-------|-----|--------------|
-| 121 | caddy | 1 | 512 MiB | Reverse proxy — terminates all `*.hubris.network`. Must stay on hubris for LAN-side reachability. **Needs backend IP updates** when guests move. |
-| 107 | dns | 1 | 1 GiB | Technitium DNS, split-horizon. Core. |
-| 106 | auth-outpost | 1 | 512 MiB | Authentik SSO enforcement. Core. |
-| 105 | apps | 2 | 4 GiB | homelab MCP + secrets-issuance + artifacto. Core infra. Mounts library. |
-| 104 | gitea | 1 | 1 GiB | Git server. NFS would hurt git lock/stat perf. Mounts library (bare repos). |
-| 103 | paperless | 2 | 3 GiB | Document archive. Moderate I/O, OCR writes. Mounts library. |
-| 102 | nfs-export | 1 | 512 MiB | Exports library to zimaos via NFS. Must stay with the physical library. |
-| 100 | zimaos | 4 | 8 GiB (VM) | NAS frontend eval. Already NFS-mounts library from 102. |
-| 108 | haos | 2 | 4 GiB (VM) | Home Assistant OS. Hardware access, low latency. |
-
----
-
-## Constraints & prerequisites
-
-### 1. Network — strong needs an internal bridge (Phase 0)
-
-strong currently has only `vmbr0` on `192.168.178.0/24`. Guests created there
-get household-LAN IPs, not homelab-subnet IPs. Two options:
-
-- **Option A (recommended):** Add `vmbr1` on strong as a portless internal
-  bridge with a `192.168.8.x/24` address (e.g. `192.168.8.3`). Route between
-  strong's `vmbr0` and `vmbr1` the same way hubris does. Guests go on `vmbr1`
-  and get `192.168.8.x` IPs — transparent to Caddy, DNS, and inter-LXC refs.
-  Requires adding a static route on Fritz (or relying on hubris's existing
-  route — strong would need IP forwarding + a route to 192.168.8.0/24 via vmbr1).
-
-- **Option B (simpler, messier):** Put guests on `192.168.178.x` directly.
-  Caddy can still reach them (hubris routes to 192.168.178.0/24). But DNS
-  records, inter-LXC references, and firewall rules all assume `192.168.8.x`.
-  More config churn per guest.
-
-### 2. Storage — rootfs migration (no shared storage)
-
-`local-lvm` is per-node (not shared). Moving an LXC requires either:
-- `vzdump` → restore on strong (clean, but needs temp disk space + downtime)
-- `rsync` the rootfs to a new LXC on strong (faster for large rootfs like 120's 100G)
-- `pct migrate` only works with shared storage — **not applicable here**
-
-For VMs (100, 108): `qm migrate` also needs shared storage. Not moving VMs.
-
-### 3. Library access — NFS from hubris to strong
-
-Since the physical library SSD is still on hubris, strong's guests that need
-`/mnt/library` must NFS-mount it from hubris. Options:
-
-- **Export from hubris host directly** (simplest): add `/mnt/library` to
-  `/etc/exports` on hubris with the same squash params as LXC 102
-  (`rw,all_squash,anonuid=33,anongid=10000,no_subtree_check`). Mount on strong
-  at `/mnt/library`. Strong's guests bind-mount it just like hubris's guests do.
-
-- **Use existing nfs-export LXC 102**: strong NFS-mounts from `192.168.8.200`
-  (LXC 102). This already has the right squash config. Less host-level change.
-  **This is the path of least resistance.**
-
-### 4. GPU — iGPU passthrough on strong
-
-strong has a Ryzen 7 PRO 6850U with Radeon 680M iGPU. For jellyfin (VAAPI
-transcoding) and mule-images (photo processing), we need:
-- `/dev/dri/renderD128` passed to the LXC (`lxc.cgroup2.devices.allow` +
-  `lxc.mount.entry` or Proxmox's `dev0:` passthrough)
-- `video` / `render` group membership inside the container
-- Confirm `amdgpu` driver loads on strong's host kernel (it should — same APU family)
-
-### 5. Quorum — 2-node cluster, no QDevice
-
-Moving guests to strong does NOT fix the quorum issue but **reduces blast
-radius**: if hubris reboots (its known thermal instability), the guests on
-strong keep running independently. Consider adding a QDevice as a separate
-follow-up — it's orthogonal to this migration.
-
----
-
-## Revised migration phases
-
-The original plan's NFS-over-LAN approach has been superseded. Instead,
-**media library data moves to ludo-lvm** on strong so migrated guests access
-it as a local ext4 mount. Data is split by origin:
-
-```
-hubris (stays):   library SSD (3.7T, 1.2T used)
-                     └── /mnt/library/{documents,images,cloud,homecloud,notes,repos,sophia}
-                         ↑ user-generated content (docs, photos, cloud sync, notes, repos, workshop)
-
-strong (moves):   ludo-lvm (1.8T, 0 used at start)
-                     └── /mnt/media_local ← 1.5T thin volume
-                            └── {downloads,movies,music,tv,anime,books}
-                            ↑ non-user-generated content (media arr stack, book library)
-```
-
-| Category | Stays on hubris | Moves to strong |
-|----------|----------------|-----------------|
-| Media | — | downloads (25G), movies (51G), music (29G), tv (30G), anime (206G) |
-| Books | — | books (2.6G) |
-| Docs/Photos | documents (249M), images (4K) | — |
-| Cloud sync | cloud (287G), homecloud (367G) | — |
-| Personal | notes (6.7M), repos (84M), sophia (151G) | — |
-| **Total** | **~805G** | **~344G** |
-
-ludo-lvm (1.8T) fits all media + books with ~1.15T headroom for growth.
-hubris library SSD (3.7T, 1.2T used) retains the user-generated content.
-Both sides keep their data local — no cross-node NFS needed for daily I/O.
-
----
-
-### Phase 2a — Prepare ludo-lvm on strong
-
-1. Create a ext4 filesystem on ludo-lvm for media:
-   ```bash
-   lvcreate -n media -L 1.5T ludo-lvm
-   mkfs.ext4 /dev/ludo-lvm/media
-   ```
-2. Mount at `/mnt/media_local` on strong, add to `/etc/fstab`
-3. rsync media directories from hubris → strong:
-   ```bash
-   rsync -av --progress /mnt/library/{movies,tv,anime,downloads,music,books} strong:/mnt/media_local/
-   ```
-
-### Phase 2b — Migrate arriman (122) to strong
-
-1. Stop arriman on hubris, dump rootfs (24G)
-2. Restore on strong with IP `192.168.8.245/28` on vmbr1
-3. Mount `/mnt/media_local` → `/mnt/library` via mp0 (downloads land locally)
-4. Update Caddy: jellyseerr/qbit/sab backends → new IP
-5. Update inventory.yaml
-
-### Phase 2c — Migrate jellyfin (101) to strong
-
-1. Stop jellyfin on hubris, dump rootfs (16G)
-2. Restore on strong with IP `192.168.8.246/28` on vmbr1
-3. Pass `/dev/dri/renderD128` + `/dev/dri/card0` (Radeon 680M + RX 7600)
-4. Mount `/mnt/media_local` → `/mnt/library` via mp0 (media reads locally)
-5. Update Caddy: `media.hubris.network` → new IP
-6. Reinstall `sso-inject.js` in web dir (lost on every apt upgrade)
-7. Test VAAPI transcoding, SSO login, media playback
-
-### Phase 2d — Migrate grimmory (130) to strong
-
-1. Stop grimmory on hubris, dump rootfs (16G)
-2. Restore on strong with IP `192.168.8.247/28` on vmbr1
-3. Mount `/mnt/media_local` → `/mnt/library` via mp0 (books read locally)
-4. Update Caddy: `books.hubris.network` → new IP
-5. Update inventory.yaml
-6. Test: book browsing, calibre-web access
-
-### No NFS export needed
-
-With the data split by origin, hubris guests that only need user-generated
-content (documents, images, cloud, repos, sophia) still access them from the
-original library SSD — no cross-node NFS required. The two sides are
-independent.
-
-**Result after Phase 2: hubris frees 26 GiB RAM (4 migrated guests) + 344G of
-library I/O burden. Strong becomes the media/books powerhouse.**
-
----
-
-### Phase 3 — Migrate mule-images (120) to strong
-
-Move photo management (12 GiB RAM, 6 cores, iGPU) last because it needs:
-- `/mnt/library` access (now NFS from strong — already set up in Phase 2d)
-- `/dev/dri/renderD128` (Radeon 680M — confirm VAAPI compatibility first)
-
-Steps:
-1. Stop mule-images on hubris, rsync the 100G rootfs to strong (faster than vzdump)
-2. Restore on strong with IP on vmbr1
-3. Pass Radeon 680M iGPU
-4. Reconfigure library paths → `/mnt/media_local` (or keep NFS mount)
-5. Update Caddy: `photos.hubris.network` → new IP
-6. Test photo import + processing pipeline
-
----
-
-### Phase 4 — Tier 3 moves (optional)
-
-Migrate grimmory (130), teddycloud (131), rclone (132), trmnl (128), sophia (119)
-as needed — each frees 1–2 GiB. Not urgent; do when convenient.
-
----
-
-### Phase 5 — Follow-up
-
-- **QDevice**: add a tiebreaker for 2-node quorum
-- **Gaming VM**: strong's 6850U has enough cores alongside migrated LXCs
-- **Hubris library cleanup**: after all guests are confirmed working, decide
-  whether to keep the original library SSD as backup or repurpose it
-
----
-
-## Resource math after Phase 3 (all Tier 1 + 2 moved)
-
-| | hubris | strong |
-|---|--------|--------|
-| Guests | 11 LXC + 2 VM | 5 LXC |
-| RAM allocated | ~25 GiB | ~45 GiB |
-| RAM capacity | 28 GiB | 28 GiB |
-| Overcommit | 0.9× (under-committed) | 1.6× (manageable) |
-| Library disk | Local ext4 (3.7T) → NFS client | Local ext4 on ludo-lvm (1.8T) |
-| GPU | Radeon 760M (idle) | Radeon 680M (jellyfin + mule-images) |
-
-strong becomes the media/library powerhouse. hubris becomes a lean core-infra
-node (DNS, auth, git, docs, caddy, HA).
-
----
-
----
-
-## Risk register
-
-| Risk | Impact | Mitigation |
-|------|--------|------------|
-| NFS latency for library reads (jellyfin, arriman) | Media playback stutter, slow downloads | Test iperf between strong↔hubris first. If 2.5G link, NFS throughput is fine (~1 Gbit/s). |
-| GPU passthrough on strong (680M vs 760M) | Transcode quality/compat differences | Both are AMD VAAPI — same driver stack. Test `vainfo` inside LXC before going live. |
-| Caddy backend IP churn | Service outage if IP wrong | Update Caddyfile in git repo (caddy-conf), test each route before destroying old LXC. |
-| vzdump/restore downtime | Service unavailable during migration | Schedule off-hours. Use rsync for large rootfs (120's 100G) to minimize freeze window. |
-| 2-node quorum still fragile | If hubris goes down, strong /etc/pve goes read-only | Guests keep running. Add QDevice as follow-up. |
-| Library data integrity during NFS transition | Permission drift | NFS `all_squash,anonuid=33,anongid=10000` matches existing LXC 102 config. Verify with `ls -la /mnt/library` after mount. |
-
----
-
-## Open questions for operator
-
-1. **Internal bridge on strong**: proceed with `vmbr1` on `192.168.8.3/24`
-   (Option A), or use `192.168.178.x` guest IPs (Option B)?
-2. **Migration method**: `vzdump`/restore (clean, downtime) vs `rsync` rootfs
-   (faster for large disks, needs manual config copy)?
-3. **Phase 1 priority**: move elementsynapse + house first (quick wins), or
-   go straight to Phase 2 (mule-images/jellyfin/arriman) for maximum relief?
-4. **Should we add a QDevice now** before moving anything, to protect
-   management plane during the migration?
-
----
-
-## Changelog
-
-### 2026-07-05 — Phase 2d complete (grimmory migrated; media NFS to zimaos)
-grimmory (130) → 192.168.8.247 on strong. Rsync'd /books (2.6G) to ludo-lvm.
-LXC 102 (nfs-export) now mounts strong's NFS at /mnt/media and exports it as
-a second share alongside /mnt/library. Zimaos mounts both: /media/library
-(hubris user-generated) and /media/media (strong media+books).
-See hosts/strong.md changelog.
-
-### 2026-07-05 — Phase 2 complete (arriman + jellyfin migrated; library on ludo-lvm)
-arriman (122) → 192.168.8.245, jellyfin (101) → 192.168.8.246. Created 1.5T
-thin volume on ludo-lvm, rsync'd 363G of media data. Both containers use local
-ext4 mount — no NFS. Jellyfin has 680M + RX 7600 GPU passthrough.
-Caddy backends updated. See hosts/strong.md changelog.
-
-### 2026-07-05 — Phase 1 complete (elementsynapse + house migrated to strong)
-Both Tier 1 guests moved: elementsynapse (118) → 192.168.8.242, house (129) → 192.168.8.244.
-Strong now has vmbr1 at 192.168.8.241/28. Hubris has proxy ARP + /32 routes for strong
-guest range. DHCP scope narrowed to 192.168.8.100-239 to avoid conflicts.
-Teddycloud (LXC 131) given static IP 192.168.8.150 due to IP conflict with
-previous DHCP allocation at 192.168.8.243.
-See hosts/strong.md changelog for full steps.
-
-### 2026-07-05 — assessment created
-Built from live `pct config` + `pvesm status` + `free -h` data pulled from
-both nodes. Supersedes the storage-migration framing of the original
-library-SSD plan — this assessment treats the SSD move as optional and
-focuses on guest relocation via NFS.

archive/knowledge/containers/101-jellyfin.md

@@ -1,160 +0,0 @@
-# 101 — `jellyfin`
-
-Media server: serves the movies / TV / anime / music libraries from `/mnt/media_local` to LAN clients. Hardware transcoding via AMD Radeon 680M + RX 7600 VAAPI. Authentik SSO via OIDC.
-
-## At a glance
-- **Host:** **strong** (migrated from hubris 2026-07-05)
-- **IP:** `192.168.8.246`
-- **Privilege:** privileged (recreated on strong as priv)
-- **Resources:** 4 cores / 8 GiB RAM / 1 GiB swap / 16 GiB rootfs
-- **GPU:** `/dev/dri/renderD128` + `/dev/dri/card0` (AMD Radeon 680M iGPU + RX 7600 dGPU) passed via `dev0` / `dev1` in LXC config
-- **Mounts:** `/mnt/media_local` ↔ `/mnt/library`
-- **Public hostname:** [`media.hubris.network`](../infrastructure/dns.md) → [caddy](121-caddy.md) → `:8096`
-- **Version:** Jellyfin 10.11.11 (apt package, Ubuntu 24.04 noble repo)
-- **FFmpeg:** jellyfin-ffmpeg7 7.1.4
-
-## Service / port map
-
-| Service  | Listen | Notes |
-| -------- | ------ | ----- |
-| jellyfin | `:8096` | HTTP (caddy terminates TLS) |
-
-## Hardware acceleration (VAAPI)
-
-GPU is passed through to the LXC via `dev0: /dev/dri/renderD128,gid=993` and
-`dev1: /dev/dri/card0,gid=44` in
-`/etc/pve/lxc/101.conf` (strong). The `jellyfin` user is in the `render` (GID 993) and
-`video` groups inside the container.
-
-| GPU | Model | Role |
-|-----|-------|------|
-| Radeon 680M | iGPU (AMD Ryzen 7 PRO 6850U) | Primary VAAPI encoder/decoder |
-| RX 7600 | dGPU (add-in) | Secondary transcode, HEVC/AV1 encoding |
-
-Encoding settings (`/etc/jellyfin/encoding.xml`):
-- `HardwareAccelerationType`: `vaapi`
-- `VaapiDevice`: `/dev/dri/renderD128`
-- `EnableHardwareEncoding`: `true`
-- `AllowHevcEncoding`: `true`
-- `AllowAv1Encoding`: `true`
-- `EnableTonemapping`: `true`
-- `HardwareDecodingCodecs`: h264, hevc, vc1, vp9, av1
-- `EnableThrottling`: `true`
-- `EnableSegmentDeletion`: `true`
-
-Trickplay (`/etc/jellyfin/system.xml`):
-- `EnableHwAcceleration`: `true`
-- `EnableHwEncoding`: `true`
-
-## Authentik SSO (OIDC)
-
-Jellyfin uses the [SSO-Auth plugin](https://github.com/9p4/jellyfin-plugin-sso)
-v4.0.0.4 for Authentik OIDC login. No Caddy forward-auth gate — the SSO plugin
-handles auth directly via OIDC redirect flow.
-
-### Architecture
-
-```
-User → media.hubris.network → Caddy (TLS, no forward-auth) → Jellyfin :8096
-                                                                ↓
-                                                    Login page with "Sign in with Authentik" button
-                                                                ↓ (click)
-                                                    /sso/OID/start/Authentik
-                                                                ↓ (302 redirect)
-                                                    auth.hubris.network OIDC
-                                                                ↓ (login)
-                                                    /sso/OID/redirect/Authentik?code=...&state=...
-                                                                ↓
-                                                    Jellyfin SSO plugin validates token → logged in
-```
-
-### Components
-
-1. **SSO-Auth plugin** — installed at `/var/lib/jellyfin/plugins/SSO-Auth_4.0.0.4/`
-   - Config: `/var/lib/jellyfin/plugins/configurations/SSO-Auth.xml`
-   - Provider name: `Authentik`
-   - OIDC endpoint: `https://auth.hubris.network/application/o/jellyfin/`
-   - `SchemeOverride`: `https` (required — without it, plugin generates
-     `http://` redirect URIs that Authentik rejects)
-   - `EnableAuthorization`: `false` (prevents plugin from overwriting admin
-     permissions on each SSO login — see
-     [jellyfin-sso-plugin](../../../devops/homelab-authentik-admin/references/jellyfin-sso-plugin.md))
-   - `OidScopes`: `["email"]` (openid+profile added by default by the plugin;
-     must be non-null or `OidChallenge()` throws `ArgumentNullException`)
-
-2. **Authentik OIDC provider** — `Provider for Jellyfin` (PK 6)
-   - Client ID: `vt61t5Y2ZVtN6l3QjitkBvwUJjFKvSyl4TDBXcJx`
-   - Redirect URI: `https://media.hubris.network/sso/OID/redirect/Authentik`
-   - Application slug: `jellyfin`
-
-3. **SSO button injection** — `/usr/share/jellyfin/web/sso-inject.js`
-   - Injected via `<script defer src="sso-inject.js?v=3">` in `index.html`
-   - Polls for `.readOnlyContent` div on the login page, adds "Sign in with
-     Authentik" button linking to `/sso/OID/start/Authentik`
-   - Cache-busted with `?v=N` parameter (bump on changes)
-   - **Lost on apt upgrade** — re-inject the script tag and copy the JS file
-     after `apt-get upgrade jellyfin*`
-
-4. **Caddy config** — no forward-auth gate for media.hubris.network:
-   ```caddy
-   media.hubris.network {
-       tls { dns ionos {env.IONOS_AUTH_API_TOKEN} }
-       reverse_proxy 192.168.8.206:8096
-   }
-   ```
-
-### Known issues / pitfalls
-
-- **`OidScopes` must be non-null** — if the field is missing from the plugin
-  config XML, `OidChallenge()` throws `System.ArgumentNullException`. Always
-  include `OidScopes` in the provider config (even if empty array).
-- **`SchemeOverride: "https"` is required** — without it, the plugin generates
-  `http://` redirect URIs (from the internal HTTP listener). Authentik rejects
-  them with "Redirect URI Error".
-- **SSO button JS is not served by the plugin** — the `__plugin/SSO-Auth.js`
-  endpoint returns 404 on Jellyfin 10.11.x when the plugin is installed
-  manually (not via Jellyfin's plugin manager). The `sso-inject.js` workaround
-  in `index.html` is the fallback.
-- **No Caddy forward-auth gate** — the SSO plugin's OIDC redirect flow is
-  incompatible with Caddy's `import authentik` forward-auth. If both are
-  enabled, the forward-auth intercepts the OIDC callback and breaks the flow.
-  Use one or the other, not both. SSO plugin (OIDC redirect) is preferred.
-- **API key for setup** — a temp API key can be inserted directly into the
-  `ApiKeys` SQLite table for automated configuration:
-  ```sql
-  INSERT INTO ApiKeys VALUES (1, '2026-07-04', '2026-07-04', 'setup', 'jf-setup-key-...');
-  ```
-
-## Permissions
-Member of the [media GID 10000](../infrastructure/media-permissions.md) standard. Service user `jellyfin` is in the `media` group inside the container; `/mnt/media_local` on strong's ludo-lvm is owned `root:media` with mode `2775`.
-
-## Related
-- [Caddy reverse proxy](121-caddy.md)
-- [Media permissions](../infrastructure/media-permissions.md)
-- [arriman](122-arriman.md) — \*arr stack writes the libraries jellyfin reads
-- [DNS split-horizon](../infrastructure/dns.md)
-- [Authentik admin](../../../devops/homelab-authentik-admin/SKILL.md) — OIDC provider creation, SSO plugin config
-
-## Changelog
-
-### 2026-07-06 — wiki: IP, host, GPU, mount path updated for strong migration
-Updated At-a-glance: IP 206→246, host hubris→strong, mount /mnt/library→/mnt/media_local, GPU Radeon 760M→680M+RX7600, privilege unpriv→priv. Permissions section updated. Changelog entry in 122-arriman.md updated similarly.
-
-### 2026-07-04 — VAAPI hardware acceleration + Authentik SSO + resource bump
-- Upgraded Jellyfin 10.11.8 → 10.11.11 (purge + reinstall to fix DB migration bug)
-- Enabled VAAPI hardware acceleration (Radeon 760M): h264/hevc/vc1/vp9/av1 decode + encode
-- Bumped resources: 2→4 cores, 4→8 GiB RAM, 512→1024 MiB swap
-- Enabled trickplay HW acceleration + throttling + segment deletion
-- Installed SSO-Auth plugin v4.0.0.4 with Authentik OIDC provider
-- Configured `SchemeOverride: https`, `OidScopes: ["email"]`, `EnableAuthorization: false`
-- Injected SSO button via `sso-inject.js` in web `index.html`
-- Removed Caddy forward-auth gate (incompatible with SSO plugin OIDC flow)
-- **Database was wiped** during cache relocation attempt — no LVM snapshot
-  existed. All watch states, user accounts, and library configs lost.
-  Libraries re-added via setup wizard.
-
-### 2026-04-28 — wiki entry created
-Initial documentation. No config changes.
-
-### 2026-04-20 — joined the `media` GID 10000 standard
-Idmap block applied; in-container `media` group at GID 10000 mapped to host GID 10000. See [media permissions](../infrastructure/media-permissions.md). Config backup: `/root/101.conf.bak.*`.

archive/knowledge/containers/102-nfs-export.md

@@ -1,89 +0,0 @@
-# 102 — `nfs-export`
-
-Dedicated, single-purpose LXC that re-exports `/mnt/library` over NFSv4 to clients that can't use the host's PVE virtiofs path — currently only [100-zimaos](../vms/100-zimaos.md), which ships a kernel without virtiofs support.
-
-## At a glance
-- **Hostname:** `nfs-export`
-- **IP:** `192.168.8.200` (static; LAN-only, no Caddy in front because NFS is L4)
-- **LAN DNS:** `nfs-export.hubris.network` → `192.168.8.200` (direct, no Caddy)
-- **Privilege:** privileged (`unprivileged: 0`) + `lxc.apparmor.profile: unconfined` — required for `nfs-kernel-server`
-- **Resources:** 1 core / 512 MiB RAM / 2 GiB rootfs / 256 MiB swap
-- **Mounts:** host `/mnt/library` ↔ container `/mnt/library` (same path on both sides — matches the bind-mount convention used by jellyfin, paperless, arriman, nextcloud, mule-images, apps)
-
-## What it does
-
-```
-/mnt/library (host ext4 on nvme1n1)
-        │
-        ├── bind-mounted into 7 other LXCs (jellyfin, paperless, …)
-        └── bind-mounted into LXC 102
-                    │
-                    └── nfs-kernel-server exports /mnt/library
-                          │
-                          └── consumed by VM 100 (ZimaOS)
-```
-
-Same inodes, same page cache. The NFS server is just one more access path on top of a tree that 8 other consumers already share — see [media permissions](../infrastructure/media-permissions.md).
-
-## Export config
-
-`/etc/exports`:
-
-```
-/mnt/library  192.168.8.0/24(rw,all_squash,anonuid=33,anongid=10000,no_subtree_check,sec=sys)
-```
-
-Initially started as `ro`; promoted to `rw` on 2026-05-14 after the Files-UI evaluation confirmed (a) the library renders correctly as a folder under `/DATA`, (b) thumbnails are generated, (c) the squash works — a write from ZimaOS appears on `/mnt/library` as `www-data:media` (uid 33, gid 10000), matching the existing tree convention used by Nextcloud and mule-images.
-
-### Guardrails (in order of importance)
-
-1. **`all_squash,anonuid=33,anongid=10000`.** Every write from ZimaOS records on disk as `www-data:media` (uid 33, gid 10000), the same identity Nextcloud and mule-images use. Keeps the existing tree convention from drifting. See [`project_media_perms`](../infrastructure/media-permissions.md).
-3. **Subnet restriction `192.168.8.0/24`.** No public/mesh access; LAN only.
-4. **`no_subtree_check`** + **`sec=sys`** — standard performance/auth pair for a homelab.
-5. **No `crossmnt`** because `/mnt/library` is a single ext4 filesystem on the host (no nested mounts to traverse).
-
-### What we're *not* doing yet
-
-- No per-subdir export. ZimaOS sees the whole tree; access is controlled by filesystem permissions (`drwxr-x---` private dirs like `documents/`, `notes/`, `heaper/` aren't readable by `media` group, so ZimaOS-as-squashed-uid won't see them either).
-- No write-back. Until we promote to `rw`, ZimaOS can't write — eliminates the lock-domain split concern between NFS clients (NLM/v4) and local LXCs (POSIX flock).
-- No Authentik / forward-auth. NFS doesn't sit behind HTTP, so the standard caddy+authentik path doesn't apply. Subnet ACL is the only auth.
-
-## Why this LXC exists (vs serving from host)
-
-We considered three options before building this:
-
-| Option | Outcome |
-|---|---|
-| **NFS on hubris bare-metal host** | Best performance, but adds long-lived NFS/RPC daemons to a host with a recent crash episode ([hubris crash 2026-04-21/22](../../sources/investigations/index.md)). Rejected. |
-| **SMB on host** | Same host-blast-radius problem, plus 30–50% lower throughput than NFS on Linux↔Linux. Rejected. |
-| **NFS in a dedicated LXC** ← this | Within ~2% of host performance (LXC is namespace isolation; IO path is unchanged), zero new daemons on hubris, matches the existing fleet pattern. Selected. |
-
-Rationale lives in [the install plan](https://git.hubris.network/dtoro/Homelab-Docs) `/root/.claude/plans/i-wannt-you-to-nifty-muffin.md` on hubris.
-
-## Operations
-
-- **Reload exports** after editing `/etc/exports`: `pct exec 102 -- exportfs -ra`
-- **List active exports:** `pct exec 102 -- exportfs -v`
-- **Watch from outside:** `showmount -e 192.168.8.200`
-- **Service health:** `pct exec 102 -- systemctl is-active nfs-server rpcbind`
-- **Restart cleanly:** `pct restart 102` (ZimaOS will retry the mount via `nofail`)
-- **Destroy + rebuild:** `pct stop 102 && pct destroy 102 --purge` — reversible in seconds; only ZimaOS notices
-
-## Open items
-- Consider tightening the export to subdirs (e.g. `movies`, `tv`, `music`, `audiobooks`, `books`, `images`, `podcasts`, `roms`) if you don't want ZimaOS reachable into `documents/`, `notes/`, `heaper/`, etc. — though those private subdirs are already invisible to `media`-group perms.
-- ZimaOS architecture finding: the Drives panel only enumerates physical/block devices via `GET /v2/local_storage/storages` (read-only API, no POST). Network shares **cannot** appear as Drives — they show up as folders in Files. This is intentional in CasaOS's design; don't try to work around it. Library-as-folder is the supported model.
-- Consider adding Samba to this LXC if a future Mac/iOS client needs SMB on the same tree — same LXC, no host changes.
-- No PBS backup (no PBS configured on hubris); the container is fully described in this page + `pct config 102`, rebuild from scratch in <2 min if lost.
-
-## Related
-- [100-zimaos](../vms/100-zimaos.md) — the only consumer today
-- [media permissions](../infrastructure/media-permissions.md) — uid 33 / gid 10000 standard
-- [DNS](../infrastructure/dns.md) — `nfs-export.hubris.network` entry (direct, no Caddy)
-
-## Changelog
-
-### 2026-05-14 — Promoted to rw; squash behaviour verified
-After ZimaOS Files UI evaluation passed (library renders as folder under `/DATA`, thumbnails work, ZimaOS Drives panel ignores NFS by design), flipped export to `rw`. Tested: writing `/DATA/library/.zimaos-rw-test` from ZimaOS appears on hubris's `/mnt/library` owned `www-data:media` (uid 33, gid 10000), confirming `all_squash,anonuid=33,anongid=10000` works as designed. Also discovered the dead end: ZimaOS's `GET /v2/local_storage/storages` is the source of the Drives panel; it returns only physical storage and rejects POST/PUT — network shares cannot be promoted to Drives.
-
-### 2026-05-14 — LXC built; NFS export live (read-only)
-Privileged Debian 13 container created with bind-mount `/mnt/library`. `nfs-kernel-server` installed and enabled; export `/mnt/library` to `192.168.8.0/24` with `ro,all_squash,anonuid=33,anongid=10000`. Smoke-tested from hubris host (mounted, listed library tree, confirmed RO). `nfs-export.hubris.network` added to LXC 124 dnsmasq.

archive/knowledge/containers/103-paperless.md

@@ -1,41 +0,0 @@
-# 103 — `paperless`
-
-Paperless-ngx for document management. Ingests scans / PDFs from `/mnt/library/documents` and serves OCR'd indexed copies.
-
-## At a glance
-- **Hostname:** `paperless`
-- **IP:** `192.168.8.130`
-- **Privilege:** privileged
-- **Resources:** 2 cores / 3 GiB RAM / 8 GiB rootfs
-- **Mounts:** `/mnt/library` ↔ `/mnt/library` (consumes `documents/`)
-- **Public hostname:** [`paperless.hubris.network`](../infrastructure/dns.md) → [caddy](121-caddy.md) → `:8000`
-
-## Service / port map
-
-| Service             | Listen  | Notes                            |
-| ------------------- | ------- | -------------------------------- |
-| paperless-webserver | `:8000` | HTTP                             |
-| paperless-task-queue, paperless-scheduler, paperless-consumer | — | systemd workers |
-
-## Auth
-Behind [Authentik forward-auth](106-auth-outpost.md). API path `/api/*` bypasses forward-auth (mobile clients can't follow the browser login redirect; bearer token still enforces auth on `/api`). Header propagation: `PAPERLESS_ENABLE_HTTP_REMOTE_USER=true` and `PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME=HTTP_X_AUTHENTIK_USERNAME` in `/opt/paperless/paperless.conf`. Django auto-creates matching users on first SSO login.
-
-## Storage
-- Documents at `/mnt/library/documents` (owner `www-data:www-data`, mode 750 — *not* on the `media` group, by design).
-
-## Known issues
-- ~~Disk usage was 86.9% at last legacy monitor reading on 2026-04-21~~ — resolved by growing rootfs to 16 GiB on 2026-05-15.
-
-## Related
-- [Authentik](106-auth-outpost.md)
-- [Caddy](121-caddy.md)
-- [DNS](../infrastructure/dns.md)
-- [Monitoring](../infrastructure/monitoring.md)
-
-## Changelog
-
-### 2026-04-28 — wiki entry created
-Initial documentation.
-
-### 2026-04-21 — wired into Authentik forward-auth
-Cookie-domain-level proxy provider, embedded outpost binding. `/api/*` bypass added in Caddy site block to keep mobile clients working.

archive/knowledge/containers/104-gitea.md

@@ -1,61 +0,0 @@
-# 104 — `gitea`
-
-Self-hosted git server. Source of truth for all `dtoro/*` repositories that auto-deploy across the lab.
-
-## At a glance
-- **Hostname:** `gitea`
-- **IP:** `192.168.8.121`
-- **Privilege:** privileged
-- **Resources:** 1 core / 1 GiB RAM / 8 GiB rootfs
-- **Mounts:** `/mnt/library` ↔ `/mnt/library` (under `/mnt/library/repos`, owner UID 102 / GID 105 — don't touch from other containers)
-- **Public hostname:** [`git.hubris.network`](../infrastructure/dns.md) → [caddy](121-caddy.md) → `:3000`
-- **Version:** 1.25.4 (last verified)
-
-## Service / port map
-
-| Service | Listen   | Notes                          |
-| ------- | -------- | ------------------------------ |
-| gitea   | `:3000`  | HTTP web + git over HTTP       |
-| gitea SSH | `:22`  | git over SSH                   |
-| `gitea-deploy-webhook` | `127.0.0.1:9797` | Receives push events for the customizations repo |
-
-## Customizations
-`/var/lib/gitea/custom` is a checkout of [`dtoro/gitea-customizations`](https://git.hubris.network/dtoro/gitea-customizations).
-- `templates/custom/footer.tmpl` injects:
-  - **Online3DViewer** v0.18.0 (vendored under `public/assets/o3dv/`) for inline 3D preview of CAD raw-file links: 3dm, 3ds, 3mf, amf, bim, brep, dae, fbx, fcstd, glb, gltf, ifc, igs, iges, stp, step, stl, obj, off, ply, wrl.
-  - **PlantUML client JS** (vanilla, vendored from `gitea.com/davidsvantesson/plantuml-code-highlight`). Browser calls `https://git.hubris.network/_plantuml/img/<encoded>` — caddy `handle_path /_plantuml/*` rewrites and proxies to the PlantUML server on [apps (105)](105-apps.md) `:8079`.
-- `home.tmpl` is the anonymous landing page (Homesauce hero + sign-in/explore buttons).
-- O3DV binary assets are *not* tracked — `deploy.sh` fetches them on first run.
-
-## Auto-deploy
-Push to `dtoro/gitea-customizations` master → gitea webhook → `http://127.0.0.1:9797/deploy` (loopback) → `gitea-deploy-webhook.service` validates HMAC against `/etc/gitea-deploy/secret` → runs `/opt/gitea-customizations/deploy.sh`. Then `systemctl restart gitea` if templates changed.
-
-`app.ini` `[webhook] ALLOWED_HOST_LIST` includes `127.0.0.1`, `192.168.8.175`, `192.168.8.205`, `192.168.8.230`, `192.168.8.136`, `192.168.8.77` — every webhook target across the lab. **Don't strip these when editing app.ini.** See [auto-deploy](../infrastructure/auto-deploy.md) for the full list.
-
-Git creds for the deploy service: `/etc/gitea-deploy/git-credentials` (mode 600), referenced via `credential.helper = store --file=/etc/gitea-deploy/git-credentials` in the repo's `.git/config` (because `ProtectHome=true` blocks `/root`).
-
-## DNS workaround
-LXC has `/etc/hosts` override mapping `auth.hubris.network → 192.168.8.175` (router DNS resolves the public IONOS A record, which is a dead end for LAN clients — see [DNS](../infrastructure/dns.md)). Belt-and-suspenders systemd unit `hubris-hosts-override.service` re-applies it idempotently. Override line is **outside** the `# --- BEGIN PVE ---` markers (Proxmox rewrites inside).
-
-## Related
-- [Caddy](121-caddy.md)
-- [DNS](../infrastructure/dns.md)
-- [Auto-deploy pipelines](../infrastructure/auto-deploy.md)
-- [PlantUML server lives on apps (105)](105-apps.md)
-
-## Changelog
-
-### 2026-06-24 — terminalito deploy webhook (id 12)
-Push webhook on `dtoro/terminalito` → `http://192.168.8.211:9797/deploy` ([trmnl (128)](128-trmnl.md)); `app.ini` `ALLOWED_HOST_LIST` extended with `192.168.8.211`. See [auto-deploy](../infrastructure/auto-deploy.md).
-
-### 2026-04-28 — wiki entry created
-Initial documentation.
-
-### 2026-04-22 — `app.ini` ALLOWED_HOST_LIST extended for Artifacto webhook
-Added `192.168.8.205`. See [Artifacto auto-deploy on apps (105)](105-apps.md).
-
-### 2026-04-21 — `/etc/hosts` override for `auth.hubris.network` added
-For OIDC integration with [authentik (124)](106-auth-outpost.md). Outside the PVE markers, with a hubris-hosts-override.service for idempotency.
-
-### 2026-04-20 — gitea customizations + auto-deploy pipeline shipped
-`dtoro/gitea-customizations` repo created; webhook receiver at loopback `:9797` validates HMAC and runs `deploy.sh`. CAD and PlantUML loaders live in `footer.tmpl`.

archive/knowledge/containers/105-apps.md

@@ -1,154 +0,0 @@
-# 105 — `apps`
-
-Docker host for everything that doesn't justify its own LXC. Currently runs Artifacto, PlantUML server, Portainer (and historically WriteFreely / blog), plus the [homelab-context distribution services](../infrastructure/homelab-context.md) (MCP + secrets-issuance) since 2026-05-20. Booklore migrated to [grimmory (130)](130-grimmory.md) on 2026-06-29.
-
-## At a glance
-- **Hostname:** `apps`
-- **IP:** `192.168.8.205`
-- **Privilege:** privileged (so container UID = host UID for bind-mount sanity)
-- **Resources:** 2 cores / 4 GiB RAM / 30 GiB rootfs
-- **Mounts:** `/mnt/library` ↔ `/mnt/library`
-- **Public hostnames:** see table below
-
-## Public hostname → service map
-
-| Hostname                          | Container        | Backend port | Notes |
-| --------------------------------- | ---------------- | ------------ | ----- |
-| `docker.hubris.network`           | Portainer        | `:9443`      | Native OAuth2 via Authentik. Trusted-origins requires hostname only (no scheme/port). |
-| `artifacto.hubris.network`        | Artifacto        | `:3100`      | Public `/p/*`, `/static/*`, `/healthz` exposed via [VPS traefik](../infrastructure/ingress.md). |
-| `blog.hubris.network`             | WriteFreely      | `:8080`      | Native OIDC via `[oauth.generic]`. |
-| `git.hubris.network/_plantuml/*`  | PlantUML server  | `:8079`      | Same-origin route from [gitea (104)](104-gitea.md). |
-| `mcp.hubris.network`              | homelab-mcp      | `:9810`      | MCP server over SSE. No SSO — agent-facing, gated at source-IP layer. See [homelab-context](../infrastructure/homelab-context.md). |
-| `secrets.hubris.network`          | secrets-issuance | `:9820`      | Per-client age-key issuance. Mesh+LAN source-IP gated (`MESH_SUBNETS`). |
-
-## Stacks
-
-### Artifacto (`/opt/artifacto/`)
-Self-hosted HTML-artifact share (Go + SQLite). Repo `dtoro/Artifacto` is the working tree itself — `git push origin main` triggers rebuild.
-- Compose: tracked `docker-compose.yml` binds `./data:/data` and `127.0.0.1:3100:3000`. `docker-compose.override.yml` uses the `!override` YAML tag on `volumes:` and `ports:` to redirect `data` to `/mnt/library/documents/artifacts`.
-- Data dir: `/mnt/library/documents/artifacts` — owner **UID 10001 : GID 10001** (matches the `app` user baked into the Dockerfile), mode 750. Parent `/mnt/library/documents` stays `www-data:www-data 750`; bind targets the child directly so no traversal needed.
-- `.env` (untracked) holds `ADMIN_PASSWORD`, `SESSION_SECRET` (`openssl rand -hex 32`), `BASE_URL=https://artifacto.hubris.network`, `SSO_GATEWAY_SECRET` (must match `ARTIFACTO_GATEWAY_SECRET` in `/etc/caddy/caddy.env` on [caddy](121-caddy.md)). Don't `git checkout .env`.
-- Auth: Authentik forward-auth on the admin surface (`/`, `/login`, `/a/*`, `/api/*`). `X-Authentik-Username` is honored only when the `X-Artifacto-Gateway` header matches `SSO_GATEWAY_SECRET` — prevents direct LAN connections from spoofing identity.
-- Public exposure: VPS traefik gates path scope to share URLs; admin surface returns 404 at the edge. See [ingress](../infrastructure/ingress.md).
-
-#### Auto-deploy pipeline (Artifacto)
-Receiver at `/opt/artifacto-deploy/` (outside the app repo): `deploy.sh` + `webhook.py`, secret in `/etc/artifacto-deploy/secret`, systemd unit `artifacto-deploy-webhook.service`. Listens on `0.0.0.0:9798`, validates `X-Gitea-Signature` HMAC-SHA256, filters to `refs/heads/main`, runs deploy in a daemon thread (returns 202 immediately). Gitea webhook id 7 on `dtoro/Artifacto`.
-
-- Logs: `pct exec 105 -- journalctl -u artifacto-deploy-webhook -f`
-- Manual deploy: `pct exec 105 -- /opt/artifacto-deploy/deploy.sh`
-- Health: `pct exec 105 -- curl -s http://127.0.0.1:9798/health` → `ok`
-- Slug length bumped 5 → 8 chars (in `internal/store/artifacts.go:41`) once the endpoint went public.
-
-### PlantUML (`/opt/plantuml/`)
-`plantuml/plantuml-server:jetty` listening on `192.168.8.205:8079`, context path `/plantuml` (`BASE_URL=plantuml`). Reached only via [gitea](104-gitea.md)'s caddy `handle_path /_plantuml/*` rewrite — no DNS record of its own. Same-origin from gitea so the embedded markdown previewer can call it without CORS.
-
-### Portainer
-Native OAuth2 (Settings → Authentication → OAuth → Custom). Manual endpoints (no OIDC discovery). Uses `portainer-uid` custom-claim scope from Authentik. Container is **not** compose-managed — safe to `docker run` recreate; data lives in named volume `portainer_data`. CLI flag: `--trusted-origins docker.hubris.network` (hostname only — `IsTrustedOrigin` rejects strings containing `://`).
-
-### homelab-mcp (`/opt/homelab-mcp/`) — DEPRECATED (Go rewrite, Phase 6)
-
-> **Status:** This Python MCP server is being replaced by the Go `oikos api` binary
-> running in Docker on mac-mini. Cutover pending — see
-> [scripts/cutover-checklist.md](../../scripts/cutover-checklist.md) for the
-> execution plan. The Go MCP uses the official MCP Go SDK (Streamable HTTP, not
-> FastMCP) with 15 tools including `get_blast_radius`, `request_execution`, and
-> `get_agent_activity`. Source: `internal/mcp/server.go`.
-
-**Current (Python) implementation — DO NOT MODIFY, awaiting cutover:**
-FastMCP server (Python venv at `/opt/homelab-mcp/.venv`). Reads from
-`/opt/homelab-context/` (this LXC is itself an enrolled
-[homelab-context](../infrastructure/homelab-context.md) client). Source
-is `dtoro/Homelab-Docs/mcp/server.py`; service unit
-`homelab-mcp.service` binds `0.0.0.0:9810`. DNS-rebinding protection
-disabled at the FastMCP layer because mesh+LAN gating is the actual
-trust boundary.
-
-- Endpoint: `https://mcp.hubris.network/mcp` (Caddy → `:9810`). StreamableHTTP transport (POST `/mcp`).
-- 14 tools registered: `get_host`, `list_services`, `find_service`,
-  `get_topology`, `search_docs`, `get_page`, `get_changelog`, `whoami`,
-  `list_my_secrets` (context); `get_service_status`, `tail_log`,
-  `list_lxcs`, `get_lxc_state`, `ping_service` (read-only management).
-- Management tools shell out via SSH using a dedicated `mcp-reader` key
-  (planned; not provisioned yet — management tools fail until then).
-
-#### Auto-deploy pipeline (homelab-mcp)
-Receiver at `/opt/homelab-mcp/mcp/deploy/webhook/` (in-tree alongside
-the server code). Listens on `0.0.0.0:9811`, secret in
-`/etc/homelab-mcp-deploy/secret`, systemd unit
-`homelab-mcp-deploy.service`. Gitea webhook id 10 on
-`dtoro/Homelab-Docs`. Deploy script reinstalls the service unit and
-restarts on push.
-
-### secrets-issuance (`/opt/secrets-issuance/`) — DEPRECATED (Go Phase 5)
-
-> **Status:** Replaced by `internal/secrets/` in the Go rewrite. Machine identities
-> are now managed via Infisical (`docker compose --profile infisical up`).
-Tiny HTTP service that issues per-client age keypairs the first time
-each client calls `/issue`. Idempotent: subsequent calls return the
-same key. Mesh+LAN source-IP gated via the `MESH_SUBNETS` env in
-`secrets-issuance.service`. State (per-client keys + denylist) lives at
-`/var/lib/secrets-issuance/` (NOT in the repo).
-
-- Endpoint: `https://secrets.hubris.network/issue` (Caddy → `:9820`).
-- `/revoke` is admin-token-gated by `/etc/secrets-issuance/admin-token`;
-  shreds the local key file and adds the hostname to the denylist.
-  Called by `homelab client remove`.
-- Trust subnets today: `100.122.0.0/16` (Netbird), `100.64.0.0/10`
-  (Tailscale), `192.168.8.0/24` (LAN). Tighten if the LAN gets
-  untrusted devices.
-
-#### Auto-deploy pipeline (secrets-issuance)
-Receiver at `/opt/secrets-issuance/secrets-issuance/deploy/webhook/`,
-port `9821`, secret in `/etc/secrets-issuance-deploy/secret`, unit
-`secrets-issuance-deploy.service`. Gitea webhook id 11.
-
-### WriteFreely (`/opt/writefreely-docker/`)
-Native OIDC via `[oauth.generic]` in `config/config.ini`. `host = https://auth.hubris.network`, scope `openid profile email`, `map_user_id = sub`. Redirect URI in Authentik: `https://blog.hubris.network/oauth/callback/generic`. Container has `extra_hosts: auth.hubris.network:192.168.8.175`. First-time users with a local WF account must connect SSO via Customize/Settings → Linked Accounts.
-
-## Permissions
-- LXC is privileged → in-container UID == host UID.
-- Member of [media GID 10000](../infrastructure/media-permissions.md). Adding `media` to the LXC alone is *not* enough for inner Docker containers — each container needs `--group-add 10000` or `user: "<uid>:10000"` to write into `/mnt/library`.
-
-## Related
-- [Gitea (104)](104-gitea.md) — uses the PlantUML server
-- [Caddy (121)](121-caddy.md)
-- [Authentik (124)](106-auth-outpost.md)
-- [DNS](../infrastructure/dns.md)
-- [Auto-deploy](../infrastructure/auto-deploy.md)
-- [Public ingress (Artifacto + blog)](../infrastructure/ingress.md)
-
-## Changelog
-
-### 2026-06-29 — Booklore migrated to Grimmory on LXC 130
-Booklore stack removed from Portainer. MariaDB dump taken first, then restored into [grimmory (130)](130-grimmory.md)'s fresh MariaDB. `books.hubris.network` Caddy backend updated to `192.168.8.213:6060`. Authentik OIDC provider updated to Public client type (PKCE) for Grimmory compatibility.
-
-### 2026-05-20 — homelab-mcp + secrets-issuance live
-Two new services from the [homelab-context distribution plan](../infrastructure/homelab-context.md):
-`homelab-mcp.service` on `:9810` (MCP read+management surface) and
-`secrets-issuance.service` on `:9820` (per-client age-key provisioning).
-Caddy fronts both with Let's Encrypt; new vhosts on
-[caddy](121-caddy.md), split-horizon DNS entries on
-[authentik (124)](106-auth-outpost.md). Gitea webhook ids 10 + 11 wire
-auto-deploy. LXC is itself an enrolled context client
-(`/opt/homelab-context/`).
-
-### 2026-04-28 — wiki entry created
-Initial documentation.
-
-### 2026-04-22 — Artifacto deployed + Authentik gateway-secret auto-login wired
-Repo `dtoro/Artifacto`. Compose, data dir, `.env`, webhook (id 7), Caddyfile site block, gateway-secret pattern, public-internet share exposure on the VPS — all set up that day. Slug length bumped 5 → 8 for brute-force resistance.
-
-### 2026-04-22 — Booklore mariadb data wiped (lesson, not a feature)
-`docker compose up -d` from the host shell on a Portainer-managed stack recreated services and re-initialized the bind-mounted `./mariadb/config`. Recovered by reseeding from snapshot. Rule recorded: edit Portainer-managed stacks via the Portainer UI.
-
-### 2026-04-22 — Portainer wired into Authentik (native OAuth2)
-Custom-claim `portainer_uid` scope. CLI added `--trusted-origins docker.hubris.network`.
-
-### 2026-04-22 — `app.ini` host whitelist on gitea extended
-Added `192.168.8.205` so the Artifacto webhook delivery wouldn't be rejected. See [gitea (104)](104-gitea.md).
-
-### 2026-04-21 — Booklore + WriteFreely wired into Authentik OIDC
-Native OIDC for both. `extra_hosts` override added inside each container so DNS resolves `auth.hubris.network` to the Caddy IP.
-
-### 2026-04-20 — PlantUML server deployed
-Used by [gitea (104)](104-gitea.md)'s footer.tmpl injection. Same-origin via caddy `handle_path /_plantuml/*` rewrite — no separate hostname.

archive/knowledge/containers/106-auth-outpost.md

@@ -1,56 +0,0 @@
-# 106 — `auth-outpost`
-
-Authentik **forward-auth outpost** for LAN-gated apps. A stateless proxy that connects outbound to the [VPS Authentik core](../../sources/investigations/archive/2026-05-31-authentik-vps-migration.md) and serves forward-auth locally, so [Caddy (121)](121-caddy.md) never hairpins auth through VPS Traefik.
-
-## At a glance
-- **Hostname:** `auth-outpost`
-- **IP:** `192.168.8.6` (static)
-- **Privilege:** privileged (Docker-in-LXC, `features: nesting=1`)
-- **Resources:** 1 core / 512 MiB / 4 GiB rootfs
-- **Mounts:** none
-- **Created:** 2026-06-01, Debian 13, replacing the embedded outpost on [124](106-auth-outpost.md)
-
-## Role
-
-Runs one container — `ghcr.io/goauthentik/proxy` — that opens an outbound websocket to `https://auth.hubris.network` (the VPS core), pulls its proxy-provider config, and answers Caddy's `forward_auth` subrequests on `192.168.8.6:9000` (LAN-only bind). Because the call path is **Caddy → outpost (LAN)**, with no Traefik in between, `X-Forwarded-Host` is preserved — the failure that 404s when Caddy is pointed at `https://auth.hubris.network` directly (Traefik rewrites the header). See the [migration investigation](../../sources/investigations/archive/2026-05-31-authentik-vps-migration.md).
-
-## Service / port map
-| Service | Listen | Notes |
-| --- | --- | --- |
-| authentik proxy outpost | `192.168.8.6:9000` | `/outpost.goauthentik.io/*` (ping, auth/caddy) |
-
-## Config paths
-- `/opt/authentik-outpost/docker-compose.yml` — `ghcr.io/goauthentik/proxy:2026.5.2`, `AUTHENTIK_HOST=https://auth.hubris.network`, `AUTHENTIK_INSECURE=false`, port bound `192.168.8.6:9000`.
-- `/opt/authentik-outpost/.env` (mode 600, **untracked**) — `AUTHENTIK_TOKEN` for outpost `hubris-lan-outpost` (sops-encrypt into `secrets/` — TODO Phase 5).
-
-## The outpost object (VPS Authentik)
-- Outpost **`hubris-lan-outpost`** (type proxy), providers: `hubris-forward-auth` (domain, Paperless + domain-level apps), `Provider for Torrent` (qBittorrent), `Provider for Artifacto` (single).
-- Health: VPS admin → Applications → Outposts → last-seen current; `curl http://192.168.8.6:9000/outpost.goauthentik.io/ping` → `204`; container log `Successfully connected websocket`.
-
-## Caddy wiring
-[Caddy (121)](121-caddy.md) `(authentik)` snippet `reverse_proxy`/`forward_auth` → `http://192.168.8.6:9000` (was `192.168.8.180:9000` on LXC 124). Tracked in `dtoro/caddy-conf`.
-
-## `sso.hubris.network` — the callback domain (critical)
-Domain-level (`forward_domain`) providers redirect the browser to `{external_host}/outpost.goauthentik.io/callback` after login. On LXC 124 that `external_host` was `auth.hubris.network`, which resolved (LAN) to Caddy → the 124 outpost — same box, so it worked. Post-migration `auth.hubris.network` points to the **VPS core**, so the callback hit the wrong outpost → **400 / redirect-uri mismatch**.
-
-Fix: the LAN outpost gets its **own** domain.
-- DNS: `sso.hubris.network → 192.168.8.175` (Caddy). *(in dnsmasq today — must be carried into Technitium in DNS Phase 2.)*
-- Caddy: site `sso.hubris.network { tls dns ionos; reverse_proxy 192.168.8.6:9000 }` (in `caddy-conf`).
-- Authentik: `hubris-forward-auth` and `Provider for Torrent` have `external_host=https://sso.hubris.network`; their `redirect_uris` must match (`set_oauth_defaults()` regenerates them from `external_host` — changing `external_host` alone does NOT update them).
-- `Provider for Artifacto` is `forward_single` on its own domain, so it was unaffected.
-
-**Lesson:** when the IdP core and the forward-auth outpost live on different hosts, the outpost needs a dedicated domain distinct from the core's — and proxy-provider `redirect_uris` must be regenerated, not just `external_host`.
-
-## Related
-- [124 — authentik](106-auth-outpost.md) — old embedded-outpost host (now DNS-only)
-- [Caddy (121)](121-caddy.md) — forward-auth consumer
-- [Ingress (VPS traefik)](../infrastructure/ingress.md)
-- [Authentik VPS migration](../../sources/investigations/archive/2026-05-31-authentik-vps-migration.md)
-
-## Changelog
-
-### 2026-06-06 — Authentik session lifetime extended to 30 days
-VPS Authentik core `user_login` stage updated: `session_duration` changed from `seconds=0` (session cookie, cleared on browser close) to `days=30` (persistent 30-day cookie). Also set `AUTHENTIK_SESSIONS__UNAUTHENTICATED_AGE=days=30` in `/opt/authentik.env` on the VPS. See [investigation](../../sources/investigations/2026-06-06-authentik-session-lifetime.md).
-
-### 2026-06-01 — created; forward-auth cut over from LXC 124
-New dedicated LXC for the LAN forward-auth outpost (Phase 1 of the [architecture migration](../../sources/investigations/archive/2026-05-31-authentik-vps-migration.md)). Deployed `goauthentik/proxy:2026.5.2` pointed at the VPS core; repointed Caddy `(authentik)` from `192.168.8.180:9000` → `192.168.8.6:9000`. Verified Paperless/qBittorrent/Artifacto return the SSO redirect with **124-Authentik stopped**, confirming the frozen instance is out of the path. dnsmasq stays on 124 until [DNS is relocated](106-auth-outpost.md).

archive/knowledge/containers/107-dns.md

@@ -1,67 +0,0 @@
-# 107 — `dns`
-
-Homelab DNS server (Technitium). Replaces the dnsmasq that lived on [124 — authentik](106-auth-outpost.md); single-purpose, one job.
-
-## At a glance
-- **Hostname:** `dns`
-- **IP:** `192.168.8.2` (static — stable, decoupled from any app)
-- **Privilege:** privileged (Docker-in-LXC, `features: nesting=1`)
-- **Resources:** 1 core / 1 GiB / 8 GiB rootfs
-- **Created:** 2026-06-01, Debian 13. Its own resolver is `1.1.1.1` (no circular dependency on the DNS it serves).
-
-## Role
-Authoritative split-horizon DNS for `hubris.network` on the LAN/mesh, plus recursive forwarding (`1.1.1.1`, `8.8.8.8`) for everything else. Technitium runs in Docker (`technitium/dns-server:latest`, `network_mode: host`), web console on `:5380`.
-
-## The `hubris.network` zone
-- Specific A overrides: app names → `192.168.8.175` (Caddy), `nfs-export → 192.168.8.200`, `auth/sso/...` as needed.
-- `auth.hubris.network → 82.165.190.79` (VPS Authentik), `sso.hubris.network → 192.168.8.175` (LAN forward-auth outpost).
-- **Wildcard** `*.hubris.network → 82.165.190.79` — mirrors the public IONOS wildcard so undefined names (e.g. `netbird`) resolve to the VPS, matching public behaviour.
-- **MX / SPF-TXT / CAA replicated from public** so an authoritative zone doesn't shadow `hubris.network` email/cert records.
-
-## Config / access
-- `/opt/technitium/docker-compose.yml`; admin password in `/opt/technitium/admin_password.txt` (mode 600 — sops-encrypt in Phase 5).
-- Console: `http://192.168.8.2:5380` (user `admin`).
-- API: `http://192.168.8.2:5380/api/...` (token via `/api/user/login`). Zone was built via the API.
-
-## Who points here
-- **NetBird mesh peers:** resolve via the **NetBird managed DNS zone**, kept in sync *from* this Technitium (see dns-sync below). The `home-lab-dns` nameserver group (`→ 192.168.8.2`) is a thin fallback forwarder.
-- **Homelab DHCP clients:** Technitium's own DHCP scope hands out `192.168.8.2` as the DNS server for `192.168.8.x` leases (see DHCP section below).
-- **Plain LAN clients (`192.168.178.x`):** Fritz!Box DHCP still hands out Fritz!Box itself (`192.168.178.1`) as DNS — no split-horizon for non-mesh clients. Changing this requires a secondary DNS fallback, which Fritz!OS 8.x doesn't expose in a single DHCP field.
-
-## dns-sync (Technitium = authoring source)
-`/opt/dns-sync/sync.py` (cron `*/10`, logs `/var/log/dns-sync.log`) reconciles this zone's named A-records → the NetBird managed DNS zone via the NetBird API (`/api/dns/zones/{id}/records`). Token at `/opt/dns-sync/netbird-token` (mode 600; source of truth in sops `secrets/netbird-pat.yaml`). **Edit DNS only here**; the sync propagates to the mesh. It deletes NetBird records absent from Technitium. Tracked: [scripts/dns-sync.py](../../../scripts/dns-sync.py). *Why this exists:* NetBird won't forward to Technitium for mesh peers (self-IP / nameserver-group quirks), so we sync into the managed zone instead — see [dns.md](../infrastructure/dns.md).
-
-## DHCP
-
-Technitium also runs a DHCP server for the homelab subnet (enabled 2026-06-02):
-- **Scope:** `homelab` — `192.168.8.241 – 192.168.8.254`
-- **Gateway:** `192.168.8.1` (Proxmox `vmbr0` alias)
-- **DNS:** `192.168.8.2` (self)
-- **Lease time:** 24 h
-
-Replaces the DHCP that was previously served by the Slate AX router. Static-IP LXCs (`.101–.239`) are excluded from the pool. Pool narrowed from `.100–.240` to `.241–.254` on 2026-06-03 to eliminate IP conflict risk.
-
-## Related
-- [124 — authentik](106-auth-outpost.md) — retired host of the old dnsmasq
-- [DNS split-horizon](../infrastructure/dns.md)
-- [Mesh](../infrastructure/mesh.md)
-
-## Changelog
-
-### 2026-06-24 — A record `trmnl.hubris.network → 192.168.8.175`
-Added for [trmnl (128)](128-trmnl.md) (LAN path via [Caddy (121)](121-caddy.md)); propagated to the NetBird managed zone by `dns-sync`.
-
-### 2026-06-06 — dns-sync cron installed (had been missing since deployment)
-Although the 2026-06-03 changelog claimed "cron */10", **no crontab was actually configured** on the LXC. The sync was running only via ad-hoc manual invocations during incident debugging. Fixed by adding `/etc/cron.d/dns-sync`.
-
-### 2026-06-03 — DHCP pool narrowed to `.241–.254`
-Previous pool `.100–.240` overlapped with all static LXCs/VMs (`.101–.239`). Shrunk via API (`/api/dhcp/scopes/set`). 11 stale DHCP leases in `.101–.110` remain until natural expiry (2026-06-04). See [plan](../../../.hermes/plans/2026-06-03_223218-dhcp-pool-exclude-static-ips.md).
-
-### 2026-06-03 — dns-sync added (Technitium → NetBird managed zone)
-This Technitium became the single DNS authoring source; `/opt/dns-sync/sync.py` (cron */10) reconciles named A-records into the NetBird managed zone via the API. Fixed previously-broken mesh names (`sso`, `nfs-export`, `mcp`, `secrets`) by adding them to the managed zone; reaped obsolete `files`/`photos-new`. See [dns.md](../infrastructure/dns.md).
-
-### 2026-06-02 — DHCP server enabled; replaces Slate AX DHCP
-Enabled Technitium's built-in DHCP server for `192.168.8.0/24` (scope `homelab`, range `.100–.240`, gateway `192.168.8.1`, DNS self). Previously the Slate AX sub-router served DHCP for the homelab subnet. With the Slate AX retired and Proxmox now the subnet router, Technitium takes over DHCP. Configured via the Technitium API (`/api/dhcp/scopes/set`). DHCP LXCs kept their Slate AX leases until expiry, then renewed from Technitium.
-
-### 2026-06-01 — created; replaced dnsmasq on 124
-Stood up Technitium at `192.168.8.2`, imported the split-horizon zone (specific A + wildcard + MX/SPF/CAA), made it the primary nameserver in the NetBird `home-lab-dns` group. Verified all names resolve with dnsmasq/124 stopped; [LXC 124 retired](106-auth-outpost.md).

archive/knowledge/containers/114-nextcloud.md

@@ -1,111 +0,0 @@
-# 114 — `nextcloud`
-
-Personal cloud / file collaboration. Source-of-truth for the photo libraries surfaced by [mulita (120)](120-mule-images.md).
-
-## At a glance
-- **Hostname:** `nextcloud`
-- **IP:** `192.168.8.224`
-- **Privilege:** privileged
-- **Resources:** 4 cores / 6 GiB RAM / 25 GiB rootfs
-- **Mounts:** `/mnt/library` ↔ `/mnt/library` (Nextcloud user files under `/mnt/library/homecloud`)
-- **Public hostname:** [`cloud.hubris.network`](../infrastructure/dns.md) → [caddy](121-caddy.md)
-
-## Auth
-Native OIDC via `user_oidc` app. **Username override pattern**: Authentik user `dtoro` maps to local Nextcloud user `admin` via the `nc_uid` custom-claim scope. Configured via `occ user_oidc:provider <name> --mapping-uid=nc_uid` and `--scope="openid profile email <app>-uid"`. See [Authentik](106-auth-outpost.md#per-app-username-override-pattern-authentik) for the full pattern.
-
-Redirect URI: `/index.php/apps/user_oidc/code` (NOT `/apps/...` — pretty URLs aren't on).
-
-## DNS workaround (load-bearing)
-Nextcloud's PHP HTTP client (`OC\Http\Client\DnsPinMiddleware`) calls `dns_get_record()` directly — it bypasses `/etc/hosts`. So the Authentik OIDC discovery URL needs **real DNS** answering with `192.168.8.175` for `auth.hubris.network`. Recipe applied:
-- Local `dnsmasq` listening on `127.0.0.1:53`, `/etc/dnsmasq.d/hubris-internal.conf` with `address=/auth.hubris.network/192.168.8.175`, `server=192.168.8.1`, `server=1.1.1.1`, `interface=lo`, `bind-interfaces`, `no-hosts`, `no-resolv`.
-- `pct set 114 --nameserver "127.0.0.1 192.168.8.1 1.1.1.1"` so the LXC starts with the right resolver order.
-- `/etc/hosts` override kept as belt-and-suspenders.
-
-Also needs `allow_local_remote_servers=true` in `config.php`.
-
-> Once internal DNS at the router level handles `*.hubris.network`, this LXC-local dnsmasq can go away. See [DNS](../infrastructure/dns.md).
-
-## Storage
-Files at `/mnt/library/homecloud`. Owned by Nextcloud's own permission model — **deliberately not on the `media` group**, NC manages it itself and would complain. See [media permissions](../infrastructure/media-permissions.md).
-
-## Web stack (Apache event MPM + php-fpm)
-Apache 2.4 with **`mpm_event`** as the MPM and PHP served via **php-fpm 8.4** over the Unix socket `/run/php/php8.4-fpm.sock` (mod_php disabled). Routing to FPM is via the distro's `/etc/apache2/conf-available/php8.4-fpm.conf` (gated by `<IfModule !mod_php8.c>`, so just `a2dismod php8.4` flips Apache onto FPM).
-
-Why this matters: with mod_php every Apache worker is forced onto `mpm_prefork` (one heavy process per connection, full PHP interpreter loaded in each). On FPM + event, Apache workers are ~5–8 MB and async; PHP work is done by a separate FPM pool that keeps opcache hot. Concurrent upload throughput jumps significantly because Apache no longer blocks per-connection on a heavy PHP process.
-
-### PHP-FPM pool
-- Socket: `/run/php/php8.4-fpm.sock` (owner/group `www-data`)
-- `pm = dynamic`, `pm.max_children = 30`, `pm.start_servers = 6`, `pm.min/max_spare_servers = 4/12`, `pm.max_requests = 500`
-- Steady-state ~6 idle workers at ~80 MB each — bump `max_children` only if peak concurrency exceeds 30.
-
-### PHP limits (FPM + CLI both)
-Set in `/etc/php/8.4/fpm/php.ini` **and** `/etc/php/8.4/cli/php.ini` (the latter so `occ`/cron see the same ceilings):
-
-| key | value |
-|---|---|
-| `upload_max_filesize` | `16G` |
-| `post_max_size` | `16G` |
-| `memory_limit` | `512M` |
-| `max_execution_time` | `3600` |
-| `max_input_time` | `3600` |
-| `output_buffering` | `Off` |
-
-After edits: `systemctl reload php8.4-fpm`. Caddy in front (`cloud.hubris.network`) imposes no body-size limit, so these are the effective ceiling.
-
-### Opcache + JIT
-`/etc/php/8.4/mods-available/opcache.ini` — full config maintained, not commented stubs:
-- `opcache.enable=1`, `opcache.memory_consumption=256`, `opcache.interned_strings_buffer=32`, `opcache.max_accelerated_files=20000`
-- `opcache.jit=tracing`, `opcache.jit_buffer_size=64M`
-
-### Apache mod_reqtimeout
-`/etc/apache2/mods-available/reqtimeout.conf` — relaxed body trickle so slow-WAN uploads don't get killed:
-- `RequestReadTimeout header=20-40,MinRate=500`
-- `RequestReadTimeout body=20,MinRate=100` (was `body=10,MinRate=500`)
-
-## MariaDB tuning
-Overrides in `/etc/mysql/mariadb.conf.d/99-nextcloud-tuning.cnf`:
-- `innodb_buffer_pool_size = 1G` (default was 128M)
-- `innodb_log_file_size = 256M`
-- `innodb_flush_log_at_trx_commit = 2` (group-commit; trades a few ms of durability for write throughput — acceptable for NC)
-- `innodb_flush_method = O_DIRECT`, `innodb_io_capacity = 2000` / `..._max = 4000`
-- `max_allowed_packet = 256M`, `tmp_table_size = 64M`, `max_heap_table_size = 64M`
-
-Apply with `systemctl restart mariadb` (not reload — `innodb_log_file_size` needs a clean restart).
-
-## Related
-- [mulita (120)](120-mule-images.md) — reads NC user trees + writes back via WebDAV
-- [Authentik (124)](106-auth-outpost.md)
-- [Caddy (121)](121-caddy.md)
-- [DNS](../infrastructure/dns.md)
-- [Mesh migration (DNS overrides explained)](../infrastructure/mesh.md)
-- [Media permissions](../infrastructure/media-permissions.md)
-
-## Changelog
-
-### 2026-05-13 — Apache keepalive bumped (and TCP BBR on host)
-Follow-up to the FPM/MPM/MariaDB round earlier the same day. After a WiFi-bound Linux client kept seeing ~2 MB/s downloads despite a 152 Mbps speed test (so the WiFi medium wasn't the cap), bumped Apache `KeepAliveTimeout 5 → 60` and `MaxKeepAliveRequests 100 → 1000` so the mirall desktop client reuses one TLS+TCP connection across many sequential file fetches instead of paying handshake + slow-start each time. Paired with TCP BBR + `fq` qdisc enabled on the [hubris host](../hosts/hubris.md#2026-05-13--tcp-bbr--fq-qdisc-enabled), which directly addresses single-stream throughput on jittery links. Server-side loopback baseline post-BBR is ~404 MB/s for a single 23 MB CR2 download via Caddy. Client-side diagnosis pending (curl single-stream + parallel tests) to determine if the remaining gap is mirall config (bandwidth limit / `parallelNetworkRequests`) or path shaping.
-
-### 2026-05-13 — throughput tuning: FPM + event MPM + opcache JIT + MariaDB
-Investigated upload/download speed. Bottlenecks were inside this LXC — LAN (33.9 Gbit/s caddy→NC iperf3) and `/mnt/library` NVMe (714 MB/s sustained) were not the limit. Changes:
-- **Apache mod_php → php-fpm 8.4** (`a2dismod php8.4`). Flips PHP from in-process to FPM-over-Unix-socket. Apache workers now ~5–8 MB instead of ~80 MB each.
-- **MPM prefork → event** (`a2dismod mpm_prefork && a2enmod mpm_event`). Async I/O, far better concurrency for parallel uploads.
-- **opcache JIT enabled** (`tracing`, 64M buffer), `memory_consumption=256`, `interned_strings_buffer=32`, `max_accelerated_files=20000`.
-- **MariaDB**: `innodb_buffer_pool_size 128M → 1G`, `innodb_log_file_size 96M → 256M`, `flush_log_at_trx_commit 1 → 2`, `O_DIRECT`, higher I/O capacity. New file `99-nextcloud-tuning.cnf`.
-- **Apache mod_reqtimeout**: body trickle relaxed from `body=10,MinRate=500` → `body=20,MinRate=100` so slow-WAN uploads aren't killed.
-- **PHP-FPM ini** synced to match what the apache2/cli inis already had (FPM was stuck at 2M/8M because FPM wasn't serving traffic before, but now it does).
-
-Backups: `/etc/php/8.4/fpm/php.ini.bak.20260513`, `/etc/apache2/mods-available/reqtimeout.conf.bak.20260513`, `/etc/php/8.4/mods-available/opcache.ini.bak.20260513`. MariaDB tuning is a new file (rollback = `rm`).
-
-Verified: `apache2ctl configtest` Syntax OK, `occ status` clean, `occ setupchecks` shows ✓ on memory_limit / output_buffering / DB indices, `status.php` returns 200 in <40 ms via Caddy with HTTP/2.
-
-### 2026-05-10 — PHP upload limits raised
-Apache + CLI php.ini bumped from distro defaults (`upload_max_filesize=2M`, `post_max_size=8M`, `memory_limit=128M`, `max_execution_time=30`) to NC-recommended (`16G/16G/512M/3600`). Backups at `/etc/php/8.4/{apache2,cli}/php.ini.bak-20260510-*`. Was causing slow/failing uploads via web UI.
-
-### 2026-04-28 — wiki entry created
-Initial documentation.
-
-### 2026-04-26 — Nextcloud-rooted libraries shipped (mulita)
-[mulita (120)](120-mule-images.md) now reads photos from `/nextcloud-users/<nc_user>/files/...` and writes mutations back via WebDAV. Pre-migration DB dump kept at `/root/snapshots/mulita-pre-nc-migration-20260426-075132.dump`.
-
-### 2026-04-21 — wired into Authentik (native OIDC + nc_uid override)
-Local `dnsmasq` added on this LXC because Guzzle bypasses `/etc/hosts`. Resolver order set to `127.0.0.1 192.168.8.1 1.1.1.1`. Username override `dtoro → admin`.

archive/knowledge/containers/118-elementsynapse.md

@@ -1,83 +0,0 @@
-# 118 — `elementsynapse`
-
-Matrix homeserver (Synapse). Backs `@dtoro:avispero`.
-
-## At a glance
-- **Hostname:** `elementsynapse`
-- **IP:** `192.168.8.242`
-- **Host:** **strong** (migrated from hubris 2026-07-05)
-- **Privilege:** **unprivileged**
-- **Resources:** 1 core / 2 GiB RAM / **16 GiB rootfs** (grown from 8 GiB on 2026-05-15 after disk-full incident)
-- **Mounts:** none from `/mnt/library`
-- **Public hostname:** [`matrix.hubris.network`](../infrastructure/dns.md) → [caddy](121-caddy.md) → `:8008`
-- **`server_name`:** `avispero` (intentionally different from the public URL).
-- **Database:** Synapse runs on **SQLite** (`/var/lib/matrix-synapse/homeserver.db`, ~90 MiB). PostgreSQL on `127.0.0.1:5432` is dedicated to the mautrix bridge databases (one per bridge), not Synapse itself.
-
-## Service / port map
-
-| Service        | Listen  | Notes                            |
-| -------------- | ------- | -------------------------------- |
-| synapse        | `:8008` | Matrix client-server / federation HTTP. Caddy terminates TLS for `matrix.hubris.network`. |
-| synapse-admin  | `:5173` | Web UI (vite dev server) for Synapse admin API. |
-| mautrix-whatsapp | `:29318` | Docker, `network_mode: host`, compose in `/root/mautrix-whatsapp/`. |
-| mautrix-meta     | `127.0.0.1:29319` | Facebook/Instagram bridge, `/root/mautrix-meta/`. |
-| mautrix-signal   | `127.0.0.1:29328` | `/root/mautrix-signal/`. |
-| mautrix-slack    | `127.0.0.1:29335` | `/root/mautrix-slack/`. |
-| mautrix-linkedin | `127.0.0.1:29341` | `/root/mautrix-linkedin/`. |
-
-## Bridges (mautrix)
-
-All five bridges run as plain `docker compose` stacks under `/root/mautrix-<name>/` — no systemd unit, `restart: unless-stopped`. Their appservice registration YAMLs live in `/etc/matrix-synapse/` and are listed in `homeserver.yaml` under `app_service_config_files`. If a bridge daemon is down, Synapse logs `push_bulk … ConnectionRefusedError` and retries every 512 s; restart the bridge with `cd /root/mautrix-<name> && docker compose up -d`.
-
-## Operational notes
-- Rootfs is on `pve` LVM-thin, grow with `pct resize 118 rootfs +<N>G` from the host — resize2fs runs automatically.
-- `/var/lib/matrix-synapse/media_store` is the dominant grower (~2 GiB at last check). If disk pressure returns, purge remote media via the Synapse admin API before resizing further.
-
-## Known issues
-- ~~Disk usage was 86.8% at last legacy monitor reading on 2026-04-21~~ — resolved by growing rootfs to 16 GiB on 2026-05-15.
-
-## Related
-- ~~[claudio-bot (123)](archive/123-claudio-bot.md)~~ — decommissioned 2026-06-04, replaced by Hermes Agent
-- [Caddy](121-caddy.md)
-- [DNS](../infrastructure/dns.md)
-- [Monitoring](../infrastructure/monitoring.md)
-
-## Changelog
-
-### 2026-06-06 — DHCP drift fixed: internal `/etc/network/interfaces` was `dhcp` despite Proxmox static config
-**Symptom:** Matrix was down. Caddy at `192.168.8.175` couldn't reach `192.168.8.239:8008` — the LXC was actually at `192.168.8.244` because the guest-side dhclient had overridden the PVE-assigned static IP.
-
-**Root cause:** During the 2026-06-02 static-IP migration, `pct set 118 --net0 ... ip=192.168.8.239/24` was applied to the Proxmox config, but the internal `/etc/network/interfaces` still had `iface eth0 inet dhcp`. On every DHCP lease renewal, dhclient grabbed `.244` from Technitium's pool.
-
-**Fix:**
-- Replaced `iface eth0 inet dhcp` with `iface eth0 inet static` + `address 192.168.8.239/24` + `gateway 192.168.8.1`
-- `ifdown eth0 && ifup eth0` applied the static IP
-- Killed lingering dhclient process
-- Verified: `curl http://192.168.8.239:8008` returns 302 from Caddy's LXC
-
-**Prevention:** The `check-caddy-backends.sh` cron on hubris now runs every 10 minutes, which would have caught this drift within 10 minutes of occurrence.
-
-### 2026-05-15 — phantom-notification cleanup for `@admin`
-After the disk-full incident, the mobile (Element X) badge showed ~125 unread but every room read clean in the UI. Root cause: stale rows in `event_push_actions` that were never reaped — Synapse's read-receipt-driven cleanup didn't catch up. Two contributors:
-1. **8 of 12 affected rooms** had read receipts past the "unread" stream_ordering — pure stale state, likely from the disk-full window stalling rotation/cleanup.
-2. **The noisiest room** (a Signal-bridged DM) was flooded with `m.room.redaction` events from `@signalbot:avispero` (disappearing messages being deleted). Synapse counts redactions as notifications by default, but Element X doesn't render them — so they were invisible "ghosts".
-
-Fix (after stopping Synapse and backing up `homeserver.db`):
-- `DELETE FROM event_push_actions WHERE stream_ordering <= max(receipt_stream)` per (user, room) — clears receipt-superseded rows.
-- `DELETE FROM event_push_actions WHERE event_id IN (SELECT event_id FROM events WHERE type='m.room.redaction')` — removes redaction-driven notifications.
-- Rebuild `event_push_summary` from the remaining rows (preserve `thread_id='main'` to satisfy the NOT-NULL check constraint).
-
-Result: 125 → 4 (legitimate WhatsApp unreads).
-
-Then, to stop this recurring, an **override push-rule** was installed for `@admin` via the client API:
-```
-PUT /_matrix/client/v3/pushrules/global/override/suppress_redactions
-{ "actions": [], "conditions": [{ "kind": "event_match", "key": "type", "pattern": "m.room.redaction" }] }
-```
-With empty `actions`, all `m.room.redaction` events are silently ignored by the push system. Inspect/remove via the same endpoint. (Note: rule ids beginning with `.` are reserved for server defaults — custom ids cannot start with a dot.)
-
-### 2026-05-15 — disk-full incident, rootfs grown to 16 GiB, bridges restarted
-Element/Synapse was unreliable for ~2 days: messages dropping, sync requests stalling, mautrix bridges (slack/signal/meta/linkedin/whatsapp) all exited around 2026-05-13. Root cause: rootfs reached 100% (19 MB free of 7.8 G); Synapse logs showed `OSError: [Errno 28] No space left on device` during flush. Fix: `pct resize 118 rootfs +8G` (host `pve` VG had plenty of headroom), `journalctl --vacuum-size=50M` to recover ~200 M, `systemctl restart matrix-synapse`, then `docker compose up -d` in each `/root/mautrix-*` directory. Also expanded this wiki page to document the bridges, synapse-admin, and the actual DB backend (Postgres, not the SQLite leftover).
-
-### 2026-04-28 — wiki entry created
-Initial documentation.

archive/knowledge/containers/119-sophia.md

@@ -1,23 +0,0 @@
-# 119 — `sophia`
-
-Single-container workload "sophia". Reads/writes under `/mnt/library/sophia`.
-
-## At a glance
-- **Hostname:** `sophia`
-- **IP:** `192.168.8.157`
-- **Privilege:** privileged
-- **Resources:** 2 cores / 1 GiB RAM / 10 GiB rootfs
-- **Mounts:** `/mnt/library` ↔ `/mnt/library`
-- **Public hostname:** none
-
-## Permissions
-LXC has `www-data` in the [media GID 10000 group](../infrastructure/media-permissions.md). The `/mnt/library/sophia` subtree itself is single-container and not on the setgid shared group.
-
-## Related
-- [Hubris host](../hosts/hubris.md)
-- [Media permissions](../infrastructure/media-permissions.md)
-
-## Changelog
-
-### 2026-04-28 — wiki entry created
-Stub. Document what runs inside next time we work on this LXC.

archive/knowledge/containers/120-mule-images.md

@@ -1,330 +0,0 @@
-# 120 — `mule-images`
-
-Hosts `mule-image` — the photos app at `photos.hubris.network`. PhotoPrism + Go sidecar + SvelteKit, replacing the legacy FastAPI/Celery stack as of 2026-05-22 (see Changelog). Auto-deploys from `dtoro/mule-image` on `git push origin main`.
-
-## At a glance
-- **Hostname:** `mule-images`
-- **IP:** `192.168.8.136`
-- **Privilege:** privileged
-- **Resources:** 6 cores / 12 GiB RAM / 60 GiB rootfs / 2 GiB swap
-- **Mounts:** `/mnt/library` ↔ `/mnt/library`; `/dev/dri/{card0,renderD128}` passed through for VA-API video accel on the AMD Phoenix1 iGPU.
-- **Public hostname:** [`photos.hubris.network`](../infrastructure/dns.md) → [caddy](121-caddy.md) → path-routed to PhotoPrism `:2342` / sidecar `:8000` / nginx-static `:3000`.
-
-## Stack (`/opt/mule-image`)
-
-`/opt/mule-image` IS the working tree of `dtoro/mule-image`. Compose stack: base `docker-compose.yml` + LAN-port-rebind `docker-compose.override.yml` (untracked) + VA-API `docker-compose.gpu.yml`. The SvelteKit frontend is built on the host and served as a static bundle by nginx — no `vite dev` in prod.
-
-| Service / process        | Port (LAN)            | Notes |
-| ------------------------ | --------------------- | ----- |
-| pp-mariadb               | (internal 3306)       | MariaDB 11; holds PhotoPrism's `photoprism` DB + sidecar's `mule_sidecar.*` |
-| pp-app                   | `0.0.0.0:2342`        | PhotoPrism `:latest`; `PHOTOPRISM_FFMPEG_ENCODER=h264_vaapi` |
-| pp-sidecar               | `0.0.0.0:8000`        | Go service (file rename / folder ops / heap convert / dup scan / per-photo marks); also reconciles `USER_BASEPATHS` into PhotoPrism's `auth_users` every 60 s |
-| nginx (host process)     | `0.0.0.0:3000`        | Serves the SvelteKit static bundle from `web/build/` |
-
-**Per-user scoping** is driven by `USER_BASEPATHS=admin:admin/files, muli:muli/files` in `.env`. Sidecar applies it to PhotoPrism's `auth_users` table on boot + every 60s, `mkdir -p`s each target so PhotoPrism's ACL filter has somewhere to point.
-
-`.env` is **untracked** — `git reset --hard` won't touch it, but `git clean -fdx` would. Holds PP_*, MariaDB passwords, SIDECAR_DB_PASSWORD, OIDC_* (existing `mule-image` Authentik app, redirect URI now `/api/v1/oidc/redirect`), `USER_BASEPATHS`, and `PP_FFMPEG_ENCODER=vaapi`.
-
-`docker-compose.override.yml` is also untracked — it `!override`s the upstream `127.0.0.1:port` mappings to `0.0.0.0:port` so cross-host Caddy on [LXC 121](121-caddy.md) can reach pp-app + sidecar.
-
-## Library access
-
-PhotoPrism reads the library **directly off the bind-mounted filesystem** — no Nextcloud webhook integration in the new stack. The base path is `/mnt/library/homecloud` and per-user scoping comes from `USER_BASEPATHS` (see Stack section above).
-
-- `dtoro` is mapped to NC user `admin` → `/mnt/library/homecloud/admin/files/`
-- `muli` is mapped to NC user `muli` → `/mnt/library/homecloud/muli/files/`
-
-PhotoPrism's container user is `33:10000` (`www-data:media`), matching the host ownership of the NC tree. The legacy `oc_webhook_listeners` rows + `NEXTCLOUD_WEBHOOK_SECRET` are gone — when NC writes via WebDAV (still its own primary surface), PhotoPrism picks up the new file on its next index pass.
-
-## Authentication
-
-OIDC via Authentik. App slug `mule-image`, redirect URI `https://photos.hubris.network/api/v1/oidc/redirect` (PhotoPrism's auto-derived path; PhotoPrism builds it from `PHOTOPRISM_SITE_URL`). `OIDC_REGISTER=true` auto-creates a PhotoPrism user at role `user` on first SSO login. The sidecar's basepath reconciler then assigns their scoped folder.
-
-The `mule-image` Authentik app's redirect URI was migrated from the legacy FastAPI `/api/v1/auth/oidc/callback` path on 2026-05-22 — same client ID/secret were reused. The separate `mule-photos-new` Authentik app was deleted in the same operation.
-
-## Auto-deploy
-
-Push to `dtoro/mule-image` `main` → gitea webhook → `http://192.168.8.136:9797/deploy` → `mule-deploy-webhook.service`:
-- Validates HMAC against `/etc/mule-deploy/secret`
-- Filters to `refs/heads/main`
-- Runs `/opt/mule-deploy/deploy.sh` in a daemon thread (returns 202 immediately — docker builds exceed gitea's request timeout)
-- `git fetch && git reset --hard origin/main`, force-recreates **only the sidecar** image (so PhotoPrism's `Session` HMAC key in `pp/storage/config/hub.yml` doesn't rotate and invalidate every in-flight OIDC state cookie), reconciles `pp-app` + `mariadb` in place, `cd web && npm ci && npm run build`, `systemctl reload nginx`.
-- Conditionally layers `docker-compose.gpu.yml` when `/dev/dri/renderD128` exists, and always layers `docker-compose.override.yml` (the LAN-port rebind) when present.
-
-Deploy tooling is **outside** the app repo: `/opt/mule-deploy/{deploy.sh,webhook.py}`, secret at `/etc/mule-deploy/secret`. Gitea webhook id 6. `app.ini` `ALLOWED_HOST_LIST` on [gitea](104-gitea.md) includes `192.168.8.136`.
-
-Logs: `pct exec 120 -- journalctl -u mule-deploy-webhook -f`.
-Manual deploy: `pct exec 120 -- /opt/mule-deploy/deploy.sh`.
-
-For pushes from inside the LXC, gitea creds at `/etc/mule-deploy/git-credentials` (mode 600) — same token as `/etc/caddy-deploy/git-credentials` on [caddy](121-caddy.md).
-
-## Related
-- [Nextcloud (114)](114-nextcloud.md) — source of truth for photo libraries
-- [Authentik (124)](106-auth-outpost.md)
-- [Caddy (121)](121-caddy.md)
-- [DNS](../infrastructure/dns.md)
-- [Auto-deploy](../infrastructure/auto-deploy.md)
-- [Gitea (104)](104-gitea.md)
-
-## Changelog
-
-### 2026-05-22 — Cutover to PhotoPrism stack (Mulimage 2.0)
-
-The `new` branch of `dtoro/mule-image` was merged into `main` as commit
-`70dc1b6`. The merge replaces the legacy FastAPI + PostgreSQL + Celery
-+ React stack with PhotoPrism + Go sidecar + MariaDB + SvelteKit, lifted
-in from the M0 evaluation on (now-destroyed) [LXC 127](#).
-
-Cutover on 120 (this session):
-- Bumped to 6 cores / 2 GB swap. `/dev/dri/{card0,renderD128}` already
-  passed through; added an opt-in `docker-compose.gpu.yml` overlay that
-  the deploy script layers in when the device is present. PhotoPrism now
-  uses `h264_vaapi` instead of `libx264`.
-- Installed host nginx + a small `photos.conf` vhost serving the SvelteKit
-  static bundle from `/opt/mule-image/web/build/` on `:3000` — no Vite
-  dev server in prod. SvelteKit's `adapter-static` produces a real SPA
-  bundle.
-- Replaced `/opt/mule-deploy/deploy.sh` with the 127-style multi-compose
-  deploy (force-recreates only sidecar to preserve PhotoPrism's Session
-  HMAC key; reconciles pp-app + mariadb in place; rebuilds web/ and
-  reloads nginx).
-- `/opt/mule-image/.env` was rewritten to the PhotoPrism shape. Reused
-  passwords from `/root/mule-photos-new-secrets.txt`. `USER_BASEPATHS=
-  admin:admin/files, muli:muli/files` exposes both libraries.
-- `docker-compose.override.yml` (untracked) `!override`s pp-app +
-  sidecar ports to `0.0.0.0` so cross-LXC caddy on [121](121-caddy.md)
-  can reach them.
-- Authentik: `mule-image` app's redirect URI updated to `/api/v1/oidc/redirect`;
-  the separate `mule-photos-new` app deleted.
-- Caddyfile (`dtoro/caddy-conf`): `photos.hubris.network` switched from
-  plain passthrough to path-matchers (PhotoPrism API + sidecar API +
-  nginx static catch-all), and `photos-new.hubris.network` was removed
-  entirely.
-- Cleanups: 4 Nextcloud `oc_webhook_listeners` rows for the legacy
-  `/api/v1/internal/nc-webhook` endpoint deleted; gitea webhook id 9
-  (the `refs/heads/new` deploy hook for 127) deleted; `192.168.8.181`
-  removed from gitea's `ALLOWED_HOST_LIST`; `photos-new.hubris.network`
-  removed from dnsmasq.
-- LXC 127 destroyed via `pct destroy 127` after the new stack passed
-  curl verification end-to-end (PP `/api/v1/status` returns
-  `{"status":"operational"}` through caddy; sidecar `/api/sidecar/healthz`
-  returns `{"ok":true,...}`).
-- Rollback safety net: legacy `mulita` postgres dump at
-  `/root/backups/mulita-legacy-final-20260521-212036.sql.gz` on hubris
-  (10 MB, 16,155 photo rows). The `mule-image_mule_db_data` docker
-  volume on 120 retains the on-disk postgres data for at least 24 h
-  before housekeeping removes it.
-
-### 2026-05-14 — Drop AI/vision pipeline, plain Postgres, DB↔FS refresh
-
-**AI removal (commits `a27267f` + `423a73a`).** The OpenCLIP-on-ONNX
-binary classifier (photography vs other) and all its scaffolding gone:
-
-- Backend: `app/services/vision/`, `app/tasks/vision.py`,
-  `app/services/feature_flags.py`, `app/routers/features.py` deleted.
-  Admin `/admin/feature-flags`, `/admin/ai/{backfill,rescan}` endpoints
-  removed. `Photo.needs_review` column + `ix_photos_needs_review`
-  index dropped (alembic `0019_drop_ai_remnants`).
-- Frontend: AI Settings tab, `useFeaturesQuery`, "Needs Review" sidebar
-  entry + filter, `needs_review` URL param plumbing, FeatureFlag types
-  all gone.
-- Infra: `worker-vision` compose service + `models_data` volume
-  deleted. `worker-light` no longer runs `python -m
-  app.services.vision.bootstrap_models` before celery. Backend
-  Dockerfile drops the dedicated torch RUN layer. `requirements.txt`
-  drops `torch`, `torchvision`, `open-clip-torch`, `onnxruntime`.
-
-**Postgres image swap.** `pgvector/pgvector:pg16` → `postgres:16`. The
-0019 migration drops the (now-unused) `vector` extension first; the
-SQL was pre-applied via `psql` against the still-pgvector container
-and `alembic_version` stamped to `0019` so the new backend's
-`bootstrap.py` upgrade-head was a no-op. After the swap surfaced a
-collation-version mismatch (Bookworm glibc 2.36 → Trixie glibc 2.41),
-the fix was `REINDEX DATABASE mulita` + `ALTER DATABASE … REFRESH
-COLLATION VERSION` on `mulita`, `postgres`, `template1`. The data
-volume was preserved across the image change.
-
-**One-shot DB ↔ filesystem refresh.** New script
-`backend/scripts/full_refresh.py` (run as
-`docker exec -w /app mulita-backend python -m scripts.full_refresh
-[--dry-run]`). Phases: `cleanup_data_integrity` → inline scan of every
-active SourceRoot → `prune_missing_photos(dry_run=False)` → new
-`prune_orphan_thumbnails` helper that removes
-`/data/thumbs/{user}/{photo}/` dirs for photo_ids that left the DB.
-First run: 0 missing photos, 1 stale folder row, **7982 orphan
-thumbnail dirs** reaped.
-
-**Manual cleanup post-deploy.** `docker compose up -d --build
---force-recreate` doesn't reap services removed from the YAML, so
-`mulita-worker-vision` had to be `docker rm -f`'d by hand. The
-`mule-image_models_data` volume was likewise removed manually.
-
-### 2026-05-11 — Stop duplicating Nextcloud's indexing (Phase 1 + 2)
-
-Two big architectural shifts in one session, both aimed at killing work mule was doing that NC already does for the same source files.
-
-**Phase 1 — thumbnail proxy (commits `576b0c2`, `28738ac`).** Photos table gains `nextcloud_fileid` (migration `0018`). `GET /api/v1/photos/{id}/thumb/{size}` proxies NC's `/index.php/core/preview` keyed by that fileid, authenticated with the owner's encrypted app password (small=240, medium=640, large=1280). Worker now only writes the `medium` size to `/data/thumbs` (the vision worker still loads it from disk); `small` + `large` no longer touch disk. Disk fallback stays wired for legacy rows and the rare 404 from NC (iPhone JPEGs mis-extensioned as `.DNG` — verified). Existing 17,591 photos backfilled via `backend/scripts/backfill_nextcloud_fileid.py`. Tested with real CR2, real DNG, fake DNG, JPEG, HEIC — all green.
-
-**Range support for `/original` (commit `18dce33`).** Pre-existing bug surfaced by Phase 1 testing: `<video>` couldn't play `.mov` because `FileResponse` was returning 200 with the whole body and no `Accept-Ranges` header, so browsers reported "format not supported." Now parses `Range: bytes=START-END`, returns 206 with `Content-Range`, streams in 1 MB chunks.
-
-**Fix: backfill_gps was the actual CPU drain, not the watcher (commit `d24c64e`).** `_scan_all_source_roots_async` auto-queued `backfill_gps` 30 s after every container boot, which then re-queued `extract_metadata` for every photo with `latitude IS NULL` — ~60k pointless tasks per deploy, pinning worker-light at 180+% CPU for ~30 min. Killed the auto-trigger; manual `POST /api/v1/library/backfill-gps` still works.
-
-**Phase 2 — webhook receiver replaces watchfiles (commits `362fbc6`, `f657e2c`).** New endpoint `POST /api/v1/internal/nc-webhook` (auth via `Authorization: Bearer $NEXTCLOUD_WEBHOOK_SECRET`, `hmac.compare_digest`) handles `NodeCreated|NodeWritten|NodeDeleted|NodeRenamed`. Maps NC's `/admin/files/...` path to the bind-mounted `/nextcloud-users/admin/files/...` and dispatches the same `scan_folder` / `handle_file_deletion` machinery the watcher used. Registered against NC via `backend/scripts/register_nc_webhooks.py` (idempotent: deletes existing webhooks targeting the same URL first). `mulita-worker-watcher` container retired; celery `--beat` folded into `worker-light` so `discard_missing_photos_beat` still fires. End-to-end verified by uploading a test JPEG through WebDAV — both `NodeCreated` and `NodeWritten` fire, mule receives + dispatches, 200 OK.
-
-**NC cron tightened to `*/1` so webhook delivery latency drops from up to 5 min to ~60 s** (`crontab -u www-data` on LXC 114). NC dispatches webhook calls through its background-job queue; the cron interval = the worst-case latency. `*/5` was the default; `*/1` is the upstream recommendation anyway.
-
-**Post-Phase-2 delete-roundtrip patches (commit `9408825`).** End-to-end testing of the NC↔mule deletion paths surfaced two real gaps:
-
-1. *Folder delete* — NC fires one `NodeDeletedEvent` for the folder, not one per child. The webhook handler bailed with "unsupported extension" and photos under the deleted folder kept `is_discarded=false` until the 30-min reconcile sweep. Fix: `handle_directory_deletion()` does a single `UPDATE photos SET is_discarded=true WHERE filepath LIKE 'dir/%'` when the deleted path has no supported image extension.
-2. *Resurrect on rewrite* — PUT-overwrite of a previously-discarded file fired `NodeWrittenEvent` → `scan_folder`, but scan_folder's "photo exists, skip" branch left `is_discarded=true`. Fix: when the existing row is discarded, flip `is_discarded=false`, clear `discarded_at`, re-queue `extract_metadata`.
-
-Verified end-to-end on `Photos/MuleTestFolder/{test1,test2,nested/test3}.jpg`: `DELETE Photos/MuleTestFolder/` discarded all 3 in one shot; `PUT test1.jpg` back resurrected only that one.
-
-**Known remaining gap — trashbin restore.** Moving a file out of `/dav/trashbin/.../trash/foo.jpg.dXXXX` back to `/files/...` via WebDAV MOVE fires **no event mule subscribes to**. NC's trashbin app emits its own internal event class that isn't in the `OCP\Files\Events\Node\*` set we registered with `webhook_listeners`. Workaround: re-upload via PUT (covered by the resurrect-on-rewrite fix above) or wait for the 30-min reconcile sweep.
-
-**Folder rename round-trip (commits `f4a03b6` + `f27f3cb`).** Both directions now work:
-
-- *NC-side rename → mule:* webhook's "renamed" branch detects directory rename (neither path has a supported extension) and calls new `handle_directory_rename(old, new)` in `scan.py`. The helper iterates matching rows in Python and prefix-rewrites `Photo.filepath`, `Folder.path`, `SourceRoot.path` in one transaction. Cross-source-root case (rare) discards the old subtree and lets scan_folder add fresh rows under the new root.
-- *Mule-side rename → NC:* the existing `PATCH /api/v1/folders/{id}` endpoint (`folders.py:202`) already does WebDAV MOVE via `nextcloud_dav.move_for_user` and rewrites mule's DB inline. The NodeRenamedEvent that bounces back through the webhook hits `handle_directory_rename`, which finds 0 rows under the old prefix and is a no-op — feedback loop is idempotent.
-
-**asyncpg gotcha**: the original implementation of `handle_directory_rename` used raw SQL with `SUBSTRING(filepath FROM LENGTH(:old_prefix) + 1)` so the offset would be computed server-side. asyncpg's type inference miscategorises the `LENGTH()` result and rejects the parameter as "$2: int (expected str)". The fix iterates in Python (same pattern as the existing PATCH endpoint). Lesson: avoid passing `LENGTH(:x)+1` as an argument to `SUBSTRING(...)` via asyncpg + sqlalchemy `text()`.
-
-**Phase 3 — Memories-backed `extract_metadata` (commit `2a5759c`).** Memories app re-enabled on NC. `extract_metadata` now tries `GET /index.php/apps/memories/api/image/info/{fileid}` (auth: Basic + `OCS-APIRequest: true` header to bypass CSRF) before falling back to ExifTool. Replaces ~80 ms of subprocess with ~1-2 ms HTTP for ongoing imports. New helpers: `nextcloud_dav.fetch_memories_info_async()` + `metadata._apply_memories_metadata()`. We kept mule's full date-fallback chain (SubSec → DateTimeOriginal → CreateDate → MediaCreateDate → TrackCreateDate → filename heuristic → mtime) because 35% of the library (`taken_at_source='path'`) depends on the filename heuristic, and Memories alone would silently mis-date those photos to mtime. PhotoInfoPanel reads `exif.Make/Model/ISO/FNumber` from `photos.exif_json` — Memories' `exif` blob uses those exact plain key names, so no frontend adapter was needed. ExifTool subprocess is still in place as the fallback for brand-new photos racing the NC scan, non-NC photos, and any NC HTTP failure.
-
-**Phase 4 — retire `/data/thumbs` (commits `5a67ed7` + `7a1c6b6`).** Vision worker now fetches NC's 640px preview via a new sync helper `nextcloud_dav.get_preview_bytes()` instead of reading `/data/thumbs/{id}/medium.webp`. `thumbs.WORKER_THUMB_SIZES = set()` — `generate_thumbnails` still computes pHash on the original-res pixels (perceptual dedup is mule-only) but stops writing files. All ~22k `medium.webp` purged after verification; `/data/thumbs` shrank from 4.1 GB → 94 MB residual.
-
-**SECRET_KEY bug found mid-deploy (commit `7a1c6b6`).** `docker-compose.yml` only set `SECRET_KEY` on the `backend` service, not on the workers. Workers' Fernet-based `decrypt(nextcloud_app_password_enc)` silently returned empty and `_credentials_for()` raised `NextcloudCredentialsMissing`. This meant Phase 3's `extract_metadata` in worker-light had been silently falling back to ExifTool *the entire time*, and Phase 4's vision worker couldn't fetch NC previews at all. Fix replicates `SECRET_KEY=${SECRET_KEY:-...}` to all worker services. After any compose edit, run `docker exec mulita-<svc> env | grep SECRET_KEY` to confirm propagation.
-
-**Caveats worth knowing for Phase 4:**
-- Vision is `disabled` in production (`redis GET mulita:flags:vision.enabled == "false"`). The Phase 4 vision-from-NC path is correct but unexercised by live traffic; it'll matter whenever vision is re-enabled.
-- NC's preview generator hasn't covered the whole library at the 640px+ tier. A sample of 6 photos: 4 with proper sizes, 1 stuck at 160px (`IMG_4954.DNG`), 1 unfetchable (`IMG_0193.DNG`). If vision re-enables and quality matters, run `pct exec 114 -- sudo -u www-data php occ preview:generate-all` to backfill.
-- The HTTP `/thumb/{size}` endpoint's inline-regen disk fallback still writes one WebP per NC-404 event (mis-extensioned RAW etc). `/data/thumbs` will grow back very slowly from that path.
-
-### 2026-05-11 — Duplicates view shows parent folder + full-path tooltip
-
-`GET /api/v1/library/duplicates/groups` now includes `filepath` in each member payload. `DuplicatesView` renders a dark bottom-strip on every thumbnail showing the last two folder segments — `…/<grandparent>/<parent>` (e.g. `…/files/Phone Photos starting 01-26`) via a `duplicatePathLabel` helper. Going up two levels avoids the failure mode where two copies sit under matching parent names (e.g. duplicate `2023/` subfolders under different archives) and the label would collapse. Full filepath surfaces through the native `title` tooltip on hover. Dimensions chip moves from bottom-left to top-left so the path strip can run edge-to-edge. `memberToPhoto` finally stops faking `filepath = filename` — the synthetic Photo it hands to `PhotoThumbnail` now carries the real path.
-
-**Infra side-effect during the deploy:** two consecutive `--force-recreate` cycles (deploy.sh and a manual `down/up`) raced and left **orphan duplicate worker containers** (`<id>_mulita-worker-light` + the named `mulita-worker-light`, same for vision) both pulling from the same Redis queue. Worker concurrency was effectively doubled, host load climbed past 120, and `pct exec` into LXC 120 hung for several minutes. Recovery: `docker rm -f` on both orphan IDs. The deploy-gotcha entry below covers the pattern; the new contribution from this session is "look for renamed `<id>_<service>` containers and remove them if you ever see load spike + pct hang after a deploy".
-
-### 2026-05-11 — Drop Title field, add bulk Notes editor
-
-- Removed the `Title` (user_title) row from `PhotoInfoPanel.tsx`: the form field, its `titleDraft`/`setTitleDraft` state, the `commitTitle` handler, and the `photo?.user_title` watcher in the draft-sync `useEffect`. Column stays on `photos` and on the backend model — only the UI affordance went away.
-- New bulk action `set_notes` in `backend/app/routers/photos.py` `bulk_action`: validates the value is a string (or null/empty to clear), then sets `user_notes` on every photo in the selection in one transaction.
-- Frontend wiring: `bulkSetNotes` in `services/api.ts`, `bulkNotes` mutation in `hooks/useBulkPhotoMutations.ts` (optimistic patch with empty-string → null collapse, full rollback on error), surfaced in `RightSidebar.tsx`'s multi-photo bulk panel as a 2-row Textarea + Clear + Apply pair below the Tags section. Doesn't auto-fire on every keystroke — clicking Apply is the explicit commit (otherwise every keystroke would PATCH N rows).
-- Shared `Photo` interface in `types/photo.ts` now includes `user_notes?: string | null` so the optimistic-patch typing accepts the field; previously it only existed on `PhotoInfoPanel`'s local `PhotoDetails` shape.
-
-### 2026-05-10 — Right sidebar compact rebuild
-
-Right sidebar previously had `<ActiveHeapCard />` + `<Header />` + a scroll region holding two parallel collapsibles ("Edit" + "Metadata"), with three nested `<Section>` sub-collapsibles (Basic Info / Camera / Location) inside Metadata. A lot of chrome for a per-photo form.
-
-- **Removed** `frontend/src/components/heaps/ActiveHeapCard.tsx` entirely (no remaining importers; active-heap state stays in the store, Select/Discard buttons still consult it).
-- `RightSidebar.tsx` single-photo branch also drops its `<Header />` strip — the new "METADATA" collapsible trigger inside `PhotoInfoPanel` is the visible title. Multi-photo branch keeps the Header for "N Photos Selected".
-- `PhotoInfoPanel.tsx` is now two stacked collapsibles:
-  - **Metadata** (default expanded): readonly fields (Size / Dimensions grid, Path, GPS inlined when present), a thin `<hr>`, then editable form (Filename, Title, Date Taken, Notes, Tags, Rating + Color on one row, Flag).
-  - **Camera** (default expanded): isolated EXIF block (make+model, lens, 2×2 ISO/Aperture/Shutter/Focal grid).
-- Compact density: Notes `rows=3 → 2`, stars/swatches `h-5 → h-4`, `space-y-2.5 → 2`, Flag buttons `text-sm → text-xs`, grid `gap-2 → gap-x-2 gap-y-1`, empty "No GPS data" chip dropped (now hidden when there are no coordinates).
-- Local `Section` helper deleted from `PhotoInfoPanel.tsx` (no longer used).
-
-`PreviewView` reuses `RightSidebar` inside its overlay aside, so the change applies in both grid and preview.
-
-### 2026-05-10 — Timeline scroll-anchor on section switch
-
-Clicking a folder in the left sidebar (or any other navigation that changed `currentSection` — All Photos, Rated, Discarded, etc.) didn't reset the timeline's scroll position. If the user was deep in All Photos and clicked a folder with fewer rows, the new section loaded with the previous scroll offset preserved, often landing on empty space below the last row.
-
-`Timeline.tsx` already had a section-change effect that cleared selection and reset the auto-focus guard, and a separate auto-focus effect that selects `photos[0]` once the new query resolves. The latter has an "ensure visible" scrollTo, but it only fires if the cell is out of view AND only after the next render — by then the user has already seen the wrong scroll position. Added `parentRef.current.scrollTop = 0` synchronously inside the section-change effect so the first paint of the new section anchors at the top; the auto-focus selectPhoto then highlights photo[0] as before.
-
-### 2026-05-10 — Filter bar 422-on-date-from
-
-User reported "all filters broken, no photos shown" right after the metadata-extraction overhaul shipped. Tracing actual API traffic on a fresh session showed `GET /api/v1/photos?per_page=100&date_from=2026-04-10&sort=taken_at&order=desc` returning **422 Unprocessable Entity**: pydantic v2's `datetime` parser rejects bare-date strings (`"2026-04-10"`) for `Optional[datetime]` query params.
-
-The frontend's `filtersToParams` in `store/filterStore.ts` had been padding `date_to` with `T23:59:59` for inclusive end-of-day, but `date_from` went out as a bare `YYYY-MM-DD` — so every date-range filter request 422'd, and TanStack Query's failure-state shows an empty grid. From the user's perspective it looked like "filters return nothing across the board"; from the backend it was a single endpoint signature problem.
-
-Fix on both sides:
-- **Frontend**: pad `date_from` with `T00:00:00` symmetric to `date_to`'s `T23:59:59`.
-- **Backend**: switch `date_from` / `date_to` to `Optional[str]` and parse with `datetime.fromisoformat` inside the handler. `fromisoformat` accepts both bare dates (→ midnight) and full ISO strings, so any older client / curl that sends a date-only value still works. Tz-aware values get coerced to naive UTC, matching the `taken_at` column shape and the same fix applied to `PATCH /photos/{id}` earlier in the session. Bad input now returns 400 with a clear message instead of pydantic's 422.
-
-### 2026-05-10 — Date extraction overhaul
-
-User reported wrong "Date Taken" on stills (JPEG / HEIC / DNG). Tracing the pipeline showed the trusted-EXIF list at `services/metadata.py:230-244` ended in `EXIF:ModifyDate`, which is set every time a file is re-saved (Lightroom export, batch resize, EXIF strip), so any photo that lost its original capture metadata during editing was being labeled `taken_at_source='exif'` with the *edit* timestamp.
-
-Pipeline rewrite:
-
-- New trusted-EXIF priority: `SubSecDateTimeOriginal` → `DateTimeOriginal` → `CreateDate` → `QuickTime:MediaCreateDate` → `QuickTime:CreateDate`. **`ModifyDate` removed entirely.**
-- Fall back to `guess_date_from_path()` (the same heuristic that already powers `has_date_warning`) when no trusted EXIF date is found. New `taken_at_source='path'` value with a "PATH" badge in the info panel; tooltip explains the date came from filename / folder rather than real EXIF.
-- Skip the date-write block entirely when `photo.taken_at_source == 'manual'` so a rescan can't clobber a user correction. (Previous behavior overwrote manual edits.)
-- `parse_exif_datetime` accepts tz-aware variants (`%z`), normalizes to naive UTC, and rejects the `0000:00:00` placeholder.
-
-Backfill: new `backfill_taken_at` celery task + `POST /api/v1/library/maintenance/backfill-taken-at` endpoint. Re-enqueues `extract_metadata` for every non-manual, non-trashed photo so the new rules apply across the existing library. Snapshot before the sweep started: 11,223 `exif` + 6,039 `filesystem` + 10 `path`. Will reshape over the next ~45 min.
-
-Side note: the default celery queue had ~209k pending tasks at the time we fired the backfill — the watcher's 5-minute restart loop (since fixed) had been re-enqueuing scans, and tasks for the 4,158 photos we hard-deleted earlier today were still sitting around. Most fail fast (`Photo not found`, ~24ms each); real work runs at ~100ms. Decided to let it drain instead of flushing — safer.
-
-### 2026-05-10 — Two cascade-delete + datetime fixes after the hard-remove shipped
-
-The first cut of `delete_nextcloud_source_root` blew up with `folders_parent_id_fkey` violations on the first real test (`Taco and Muli - 2024 onward`, 35 folders / 4,158 photos). Two iterations to get it right:
-
-1. **NULL `parent_id` before deleting Folders.** Folders have a self-referential `parent_id` FK with no `ON DELETE` rule; postgres checks the constraint per row regardless of insertion order, so a flat `DELETE FROM folders WHERE id IN (...)` of the whole subtree fails on the parents whose children appear later in the same statement. Fixed with an `UPDATE folders SET parent_id = NULL WHERE id IN (folder_ids)` first.
-2. **Widen the NULL UPDATE to cross-source-root children.** A "Leóns 1st Year" SourceRoot at `.../Taco and Muli - 2024 onward/Leóns 1st Year` had its own folder rows whose `parent_id` pointed into the Taco SourceRoot's hierarchy. The first patch only NULLed `parent_id` for folders whose `id` was in the delete set; the Leóns folders weren't in that set so they kept their references and the FK still tripped. Fix: `UPDATE folders SET parent_id = NULL WHERE parent_id IN (folder_ids)` — kills any incoming reference into the delete set, internal or external.
-
-After both fixes: `DELETE /api/v1/nextcloud/source-roots/{id}` for `Taco and Muli - 2024 onward` cleared 4,158 photos and 35 folders in a single request and returned 200. UI swaps the trash icon for a `Loader2` spinner while the request is in flight (`removeRoot.isPending && removeRoot.variables === r.id`) so the multi-second cascade is visible.
-
-Separate fix in the same session: `PATCH /api/v1/photos/{id}` returned 500 with `can't subtract offset-naive and offset-aware datetimes` when the frontend sent a tz-aware ISO string for `taken_at` (the datetime-local input is supposed to be naive but real-world locales / paste flows occasionally include `+02:00`). The DB column is `timestamp without time zone`, so asyncpg refused to bind. Normalize on the server with `astimezone(timezone.utc).replace(tzinfo=None)` if `tzinfo is not None`.
-
-Deploy infra learning: the new `--force-recreate` in `deploy.sh` does NOT reliably recreate containers on every push — saw two consecutive deploys leave the backend at the previous `StartedAt` despite a fresh image. Manual `docker compose up -d --no-deps --force-recreate <svc>` after deploy still races with whatever compose state the auto-deploy left mid-flight, twice landing the stack in a half-broken state (orphaned `<id>_mulita-backend` rename containers, db / redis stopped). Recovery: `docker compose down && docker compose up -d`. Open question — `--force-recreate` may need to be replaced with something more explicit.
-
-### 2026-05-10 — Hard-remove Nextcloud SourceRoot + reliable delete sync
-
-`DELETE /api/v1/nextcloud/source-roots/{id}` was a soft-deactivate (`is_active=false`) — the trash icon in Settings only hid the SourceRoot from active queries while leaving every Folder + Photo row in the DB forever. Re-adding the same path resurrected ghosts; `prune-missing` reported zero deletes for the soft-removed entry because the cleanup code skipped inactive source roots.
-
-Endpoint now hard-deletes the SourceRoot, every Folder under it (chunked at 500), and every Photo in those folders. `photo_tags` and `heap_photos` cascade automatically via `ON DELETE CASCADE` on the join tables. `FolderShare` uses a stringly-typed `folder_id` (no FK) so cleaned manually for both `folder_type='folder'` and `folder_type='source_root'`. Returns `{deleted_photos, deleted_folders}` so the UI can toast a count. Files in Nextcloud are untouched.
-
-Sync side: the `watch_folders` celery task in `backend/app/tasks/scan.py` already detected filesystem deletions and soft-marked photos `is_discarded=true`, but the global `task_soft_time_limit=300` in `app/tasks/celery.py` was killing the watcher every five minutes and dropping every FS event during the restart window. The `soft_time_limit=None` on the decorator was being interpreted as "use worker default" rather than "unlimited". Override to `soft_time_limit=0, time_limit=0` (Celery convention for unbounded). Backstop: a new `discard_missing_photos()` in `app/services/cleanup.py` — soft variant of `prune_missing_photos`, walks every `_sr_state == 'present'` source root and flips `is_discarded=true` on Photo rows whose file is gone. Wired as `discard_missing_photos_beat` celery task scheduled every 30 minutes via `beat_schedule` on the celery app. Beat runs in-process on `worker-watcher` (`--beat` flag in `docker-compose.yml`) — the watcher is already a Redis-locked singleton so no need for a separate beat container.
-
-Manual `POST /api/v1/library/maintenance/prune-missing` remains the hard-delete path for when the user wants to permanently drop orphan rows; the new beat job only soft-discards (file gone → mule-image trash, restorable).
-
-### 2026-05-10 — OIDC auto-redirect on LoginPage
-
-`OIDC_ENABLED=true` was already set in `.env`, so the LoginPage rendered a "Sign in with Authentik" button next to the password form. With a single trusted IdP and a logged-in Authentik session, that extra click was friction without upside.
-
-`LoginPage.tsx` now reads `/auth/config` on mount and, if OIDC is on, immediately navigates to the OIDC login URL. Authentik recognizes the existing session and bounces back through the callback with no user interaction. Two escape hatches: `?password=1` in the URL forces the password form, and a `skipAutoSso` sessionStorage flag (set by `AuthContext.logout` and by the OIDC callback's error branch) suppresses the next auto-redirect so logouts actually log out and OIDC failures surface their error instead of looping. While the redirect is in flight the page shows "Signing in with Authentik..." plus a "Use password instead" link.
-
-### 2026-05-10 — right sidebar restructure (heap pinned, single scroll, collapsible Metadata)
-
-The right sidepanel had three stacked flex regions: `<ActiveHeapCard />`, `<Header />`, and `<PhotoInfoPanel />` — with `PhotoInfoPanel` carrying its own internal scroll. That left the editable fields (filename, title, notes, rating, color, flag) stuck above the readonly metadata scroll, effectively two scroll boundaries on one sidebar.
-
-- Moved the scroll boundary up to `RightSidebar.tsx`: only `ActiveHeapCard` and `Header` stay pinned now. Editable + readonly content scroll together in one `flex-1 overflow-y-auto` region beneath them.
-- `PhotoInfoPanel.tsx` dropped its `h-full` / inner `flex-1 overflow-y-auto`.
-- The four readonly sections (Tags / Basic Info / Camera / Location) are now wrapped in a single outer "Metadata" `Collapsible`. Default expanded, one click hides the whole block. Sub-sections stay individually collapsible.
-- Second pass: the editable form (filename / title / notes / rating / color / flag) got the same treatment under an outer "Edit" `Collapsible` so the panel is now two equal collapsible groups below the title strip. Dropped the X (clear-selection) button from the Header; Esc and grid-empty-area-click still clear.
-- Third pass: split editable vs read-only between the two groups consistently. `TagsEditor` and `TakenAtEditor` had been buried inside the readonly Metadata sub-sections — `Tags` as its own Section, taken-at wedged into `Basic Info` between size/dims and the filepath. Moved both into the Edit collapsible, ordered identification → description → categorization: Filename · Title · Date Taken · Notes · Tags · Rating · Color · Flag. Metadata now holds only readonly: `Basic Info` (size, dims, path), `Camera`, `Location`.
-
-`PreviewView` reuses `RightSidebar` under an `<aside class="overflow-hidden">`, so the change applies in both the grid sidebar and the preview overlay.
-
-### 2026-05-10 — `photos.hubris.network` perf sweep
-
-User reported slow load. Five fixes shipped, in order:
-
-1. **Backend out of dev mode.** `docker-compose.yml` `command:` was running `uvicorn … --reload` (single worker, file-watcher). Page loads fan out ~15 parallel API calls; they all serialized on one event loop. → `--workers 2 --proxy-headers`. Two uvicorn worker procs now.
-2. **iPhone Apple ProRAW / Linear DNG decode fixed.** rawpy 0.26.1 + LibRaw 0.22 rejects Apple Linear DNG (`Photometric Interpretation: Linear Raw`, 8-bit) as "Unsupported file format or not RAW file". Those files are TIFF containers with developed RGB inside and have no embedded preview to fall back to. Added PIL `Image.open(src_path)` as the last fallback in both `_generate_proxy_webp` (routers/photos.py) and `process_raw_image` (tasks/thumbs.py). ~1,300 iPhone DNGs were 415-ing on every detail view; now decode in <1s via PIL.
-3. **Reconcile DB with disk (renamed-folder case).** `prune_missing_photos` was skipping all 4,154 orphaned photo rows under SourceRoot `Taco and Muli - 2024 onward` (renamed in Nextcloud to `Photo Archive 2004-2024`) because the leaf path didn't resolve and the code assumed "drive unmounted → must skip". Added `_sr_state()` to classify as `present` / `renamed` (parent mount fine, leaf gone) / `unmounted` (parent inaccessible). Only `unmounted` still skips. Two stale source roots logged with a clearer hint pointing at `POST /api/v1/library/maintenance/prune-missing`. User has not yet been asked to run that — endpoint is ready when they are.
-4. **Frontend page size + idle polling.** `usePhotosQuery.ts` was first-fetching `per_page=500` (slow paint + 500 thumb requests at once). Split into `PER_PAGE_INITIAL=100` for first paint, `PER_PAGE_BACKGROUND=500` for the cursor-chain prefetch. Idle polling for `scan-status` and `worker-status` (`useScanActivity.ts`, `ScanProgress.tsx`) bumped from 10s/15s to 30s/30s while idle; active cadence (2s/3s) unchanged.
-5. **Partial index on `photos`.** Default list query `WHERE NOT is_trashed AND NOT is_hidden ORDER BY taken_at DESC NULLS LAST, id DESC LIMIT N` was doing a seq-scan + top-N heapsort (~25ms standalone, worse under concurrency). Added migration `0017_photos_list_index` creating `ix_photos_list_visible` (partial index on the sort key, restricted to visible rows). EXPLAIN now shows an Index Only Scan → **24.7ms → 0.097ms**, ~250× speedup.
-
-**Deploy gotcha — fixed (with caveat).** The original `docker compose up -d --build` in `deploy.sh` did not reliably recreate containers when only runtime config (`command:`, env-only) or migration files changed; image hash would change but compose treated the existing container as "current enough". Bit three times this session before `/opt/mule-deploy/deploy.sh` was updated to `docker compose up -d --build --force-recreate`. Trade-off accepted: an extra restart cycle on deploys where nothing user-visible changed.
-
-**Caveat:** the first auto-deploy after the flag flip raced with my own earlier manual `docker compose up -d --no-deps --force-recreate frontend` and landed the stack in a half-broken state — `mulita-frontend` got stuck under a renamed temp container, several services dropped off `mule-image_mulita-network`, frontend nginx restarted in a loop with `host not found in upstream "backend"`. Fixed by `docker compose down && docker compose up -d`. Don't issue a manual `--force-recreate` on a single service while the auto-deploy webhook is also expected to fire — let the deploy own the lifecycle.
-
-**Data drift still outstanding.** 4,154 photo rows + 1 unregistered folder (`Photo Archive 2004-2024`) on disk that's not a SourceRoot. The reconcile endpoints now work — user decides when to call them. The new folder needs to be added as a SourceRoot via the Settings UI before its files will be indexed.
-
-**Proxy cache still empty** (`mule-image_proxies_data` volume is 4 KB). Pre-generating ~500–1,500 WebP proxies for non-web-safe formats would make first-open of every RAW/HEIC photo instant. Deferred — needs a one-shot script and the disk-space tradeoff isn't worth it until the data-drift reconcile happens first.
-
-### 2026-04-28 — wiki entry created
-Initial documentation.
-
-### 2026-04-26 — Nextcloud-rooted libraries shipped
-Bind `/mnt/library/homecloud` into the workers, reads via filesystem, writes via WebDAV. `users.nextcloud_username` override field added; `dtoro → admin` mapping. Surviving SourceRoots cleaned up to NC paths.
-
-### 2026-04-22 — native OIDC via Authentik
-Authlib-based code in `backend/app/auth_oidc.py`. `extra_hosts` override for `auth.hubris.network` in compose override (gitignored).
-
-### 2026-04-21 — auto-deploy pipeline shipped
-Webhook receiver at `:9797`, async deploy returning 202. Mirrors caddy-conf / gitea-customizations.

archive/knowledge/containers/121-caddy.md

@@ -1,106 +0,0 @@
-# 121 — `caddy`
-
-The reverse proxy. Terminates TLS for every `*.hubris.network` hostname on the LAN/mesh and forwards to the right backend.
-
-## At a glance
-- **Hostname:** `caddy`
-- **IP:** `192.168.8.175`
-- **Privilege:** **unprivileged**
-- **Resources:** 1 core / 512 MiB RAM / 6 GiB rootfs
-- **Mounts:** none from `/mnt/library`
-- **Config:** `/etc/caddy/Caddyfile` is a [git checkout of `dtoro/caddy-conf`](#auto-deploy)
-- **Cert source:** Let's Encrypt **DNS-01** via IONOS API (`IONOS_AUTH_API_TOKEN`).
-
-## Sites currently served (live as of 2026-07-06)
-
-- `artifacto.hubris.network` → [apps (105)](105-apps.md) `:3100`
-- `blog.hubris.network` → [apps (105)](105-apps.md) `:8080`
-- `books.hubris.network` → [grimmory (130)](130-grimmory.md) `:6060`
-- `cloud.hubris.network` → [nextcloud (114)](114-nextcloud.md) `:443`
-- `docker.hubris.network` → [apps (105)](105-apps.md) `:9443`
-- `git.hubris.network` → [gitea (104)](104-gitea.md) `:3000` (+ `handle_path /_plantuml/*` → apps `:8079`)
-- `home.hubris.network` → [haos VM (108)](../vms/108-haos.md) `192.168.8.101:8123`
-- `house.hubris.network` → [house (129)](129-house.md) `:3000`
-- `jellyseerr.hubris.network` → [arriman (122)](122-arriman.md) `:5056`
-- `matrix.hubris.network` → [elementsynapse (118)](118-elementsynapse.md) `:8008`
-- `media.hubris.network` → [jellyfin (101)](101-jellyfin.md) `:8096`
-- `paperless.hubris.network` → [paperless (103)](103-paperless.md) `:8000`
-- `photos.hubris.network` → [mule-images (120)](120-mule-images.md) `:3000`
-- `proxmox.hubris.network` → [hubris host](../hosts/hubris.md) `:8006`
-- `qbit.hubris.network` → [arriman (122)](122-arriman.md) `:8080`
-- `roms.hubris.network` → [romm (134)](134-romm.md) `:80`
-- `sab.hubris.network` → [arriman (122)](122-arriman.md) `:8082` (Authentik forward-auth)
-- `teddy.hubris.network` → LXC 131 `192.168.8.150:8443`
-- `trmnl.hubris.network` → [trmnl (128)](128-trmnl.md) `:9851`
-
-> **Reminder:** Caddy alone isn't enough to make a new subdomain reachable on the LAN. Each one needs an entry in [DNS split-horizon](../infrastructure/dns.md) too.
-
-## Snippet: `(authentik)` forward-auth
-
-A snippet at the top of the Caddyfile (used as `import authentik` in any site block) wires forward-auth to the embedded Authentik outpost. It points at `http://192.168.8.180:9000` directly (NOT `https://auth.hubris.network`) to avoid Caddy-to-self round-tripping that strips `X-Forwarded-Host`. The forward-auth block must explicitly set `header_up X-Forwarded-Host {host}`. See [Authentik](106-auth-outpost.md#forward-auth-domain-level-setup).
-
-For apps with mobile clients, `/api/*` (or equivalent) bypasses forward-auth — see the per-app gotchas in [Authentik](106-auth-outpost.md).
-
-## Caddy environment
-
-Untracked secrets in `/etc/caddy/caddy.env`:
-- `IONOS_AUTH_API_TOKEN` — DNS-01 ACME
-- `ARTIFACTO_GATEWAY_SECRET` — must match `SSO_GATEWAY_SECRET` on [apps (105)](105-apps.md). Rotate together.
-
-## Auto-deploy
-
-Push to `dtoro/caddy-conf` master → gitea webhook → `http://192.168.8.175:9797/deploy` → `caddy-deploy-webhook.service` validates HMAC against `/etc/caddy-deploy/secret` → runs `/etc/caddy/scripts/deploy.sh`:
-1. `git pull`
-2. `caddy validate`
-3. `systemctl reload caddy`
-
-Gitea webhook id 2 on `dtoro/caddy-conf`. Receiver, deploy script, install scripts, systemd unit all live in the repo under `scripts/`. The unit has `ReadWritePaths=/etc/caddy` — load-bearing (`ProtectSystem=full` would otherwise block `git pull`). Git credentials for the root-run service are at `/etc/caddy-deploy/git-credentials` (mode 600).
-
-> **Systemd unit changes inside the repo do NOT auto-reinstall** — you have to re-run `scripts/webhook/install.sh` manually after editing the unit.
-
-## Related
-- [DNS split-horizon](../infrastructure/dns.md) — must add entry for every new subdomain
-- [Authentik (124)](106-auth-outpost.md) — forward-auth + IdP
-- [Auto-deploy](../infrastructure/auto-deploy.md)
-- [Public ingress (VPS traefik)](../infrastructure/ingress.md) — mirrors Caddy's certs to the VPS for public exposure
-- [Gitea (104)](104-gitea.md) — webhook source
-- All container pages list their Caddy backend.
-
-## Changelog
-
-### 2026-06-13 — sab.hubris.network gated with Authentik forward-auth; port fixed :8081→:8082
-`sab.hubris.network` now uses `import authentik` inside a `handle` block. SABnzbd own auth disabled, `local_ranges` set for transparent proxy. Port bumped from `:8081` to `:8082` (fix from 2026-06-04) now documented.
-
-### 2026-06-06 — Caddyfile truncated to 43 lines; restored from origin/master + safeguards added
-**Symptom:** All `*.hubris.network` hosts except `photos` and `auth` (VPS-hosted) returned `tlsv1 alert internal error` or timeout. Only 3 site blocks (`photos`, `prism`, `photos2`) remained in the Caddyfile.
-
-**Root cause:** The Caddyfile was manually edited directly on LXC 121 (not via the `dtoro/caddy-conf` git repo), overwriting 260 lines / 30+ site blocks with 43 lines of photo-only config.
-
-**Fix:**
-- Restored Caddyfile from `origin/master` (`git checkout --force origin/master -- Caddyfile`)
-- `systemctl reload caddy`
-
-**Permanent safeguards added to `/etc/caddy/scripts/deploy.sh`:**
-- **Site-count guard:** refuses to reload if fewer than 20 `*.hubris.network` blocks detected
-- **Dirty-tree auto-stash:** stashes local changes before `git pull --ff-only` so the webhook doesn't fail on local edits
-- **Auto-backup:** saves `Caddyfile.bak.<timestamp>` before any modifications, keeps last 5
-
-Also: [elementsynapse LXC 118](118-elementsynapse.md) found to have DHCP-overridden static IP (actual `.244` vs config `.239`) during incident investigation — fixed.
-
-### 2026-06-02 — caddy.service unit missing; recreated
-After the Slate AX → SODOLA network migration, Caddy was not listening (ports 80/443 dead). Root cause: the custom hubris1 Debian package (`caddy_1:2.11.3-hubris1_amd64`) does not ship a systemd service unit file. The unit had previously existed but was lost (likely on a package reinstall). Recreated at `/lib/systemd/system/caddy.service` with standard Caddy service config + `EnvironmentFile=/etc/caddy/caddy.env` (already present in `caddy.service.d/override.conf`). **Risk:** the unit will be lost again if the package is reinstalled without the file being tracked. Fix: add the service unit to the `caddy-conf` repo or rebuild the hubris1 package to include it.
-
-### 2026-04-28 — wiki entry created
-Initial documentation. 16 active sites at this date.
-
-### 2026-04-22 — Artifacto + Authentik gateway-secret pattern wired
-Caddy site `artifacto.hubris.network`: forward-auth on admin paths, `header_up X-Artifacto-Gateway {env.ARTIFACTO_GATEWAY_SECRET}`, public matchers `/p/*`, `/static/*`, `/healthz`. `caddy.env` extended with the gateway secret.
-
-### 2026-04-21 — `(authentik)` snippet added
-Top-of-file snippet used by every gated site. Targets `http://192.168.8.180:9000` directly to dodge hairpin TLS round-trip.
-
-### 2026-04-21 — three new sites added (jellyseerr, qbit, sab → 192.168.8.132)
-For the [arriman (122)](122-arriman.md) docker stack. Caddy + certs work; needed corresponding [DNS split-horizon](../infrastructure/dns.md) entries to be added to land cleanly.
-
-### 2026-04-20 — auto-deploy pipeline shipped
-Repo `dtoro/caddy-conf`. Webhook receiver at `:9797`, validate + reload on push to master.

archive/knowledge/containers/122-arriman.md

@@ -1,158 +0,0 @@
-# 122 — `arriman`
-
-Docker host running the \*arr stack via [`ezarr`](https://github.com/ezarr/ezarr) compose. Replaced the old yunohost-based [LXC 100](index.md#recently-destroyed-kept-for-archaeology) on 2026-04-21.
-
-## At a glance
-- **Hostname:** `arriman`
-- **IP:** `192.168.8.245`
-- **Host:** **strong** (migrated from hubris 2026-07-05)
-- **Privilege:** privileged
-- **Resources:** 4 cores / 8 GiB RAM / 24 GiB rootfs
-- **Mounts:** `/mnt/media_local` ↔ `/mnt/library`
-- **Public hostnames:** `jellyseerr` / `qbit` / `sab` (see below)
-
-## Compose
-
-`/home/arr/ezarr/docker-compose.yml`. Network `ezarr_default` `172.18.0.0/16`. Service users all run with primary GID 10000 (host `media` group) inside their containers — see [media permissions](../infrastructure/media-permissions.md). Per-app `/config/<app>-config/` dirs bind to `/config` inside.
-
-`.env` contents:
-- `DOWNLOADS_DIR=/mnt/library/downloads/`
-- `MEDIA_DIR=/mnt/library/`
-- `MEDIACENTER_GID=10000` ← **must be 10000, not 13000.** s6-setuidgid only honors the primary PGID; `group_add:` doesn't propagate. Without this, qBit errors every torrent with "Permission denied".
-- `SONARR_UID=13001`, `RADARR_UID=13002`, `LIDARR_UID=13003`, `PROWLARR_UID=13006`, `JELLYSEERR_UID=13012`, `BAZARR_UID=13013`, `QBITTORRENT_UID`, `SABNZBD_UID`
-
-## Service / port map
-
-All services route through gluetun's network namespace. Ports are exposed via
-the gluetun container:
-
-| Service       | Host:Container | Public hostname                      |
-| ------------- | -------------- | ------------------------------------ |
-| gluetun (VPN) | —              | —                                    |
-| sonarr        | `8989:8989`    | direct only (via gluetun)            |
-| radarr        | `7878:7878`    | direct only (via gluetun)            |
-| lidarr        | `8686:8686`    | direct only (via gluetun)            |
-| prowlarr      | `9696:9696`    | direct only (via gluetun)            |
-| bazarr        | `6767:6767`    | direct only (via gluetun)            |
-| jellyseerr    | `5056:5055`    | [`jellyseerr.hubris.network`](../infrastructure/dns.md) |
-| qbittorrent   | `8080:8080`    | [`qbit.hubris.network`](../infrastructure/dns.md)       |
-| sabnzbd       | `8082:8082` HTTP, `9090:9090` HTTPS | [`sab.hubris.network`](../infrastructure/dns.md)        |
-| flaresolverr  | `8191:8191`    | internal only                        |
-| homarr        | `7575:7575`    | internal only                        |
-
-Internal *arr ↔ *arr / *arr ↔ qBit/SAB/flaresolverr comms run on `localhost:<port>`
-(services share gluetun's shared network namespace). External services reach them
-via `gluetun:<port>` (e.g. Sonarr → qBittorrent at `localhost:8080` or
-`gluetun:8080`).
-
-## Categories (qBit + SAB + *arr)
-
-| Category | qBit savePath               | SAB dir | Consumer                          |
-| -------- | --------------------------- | ------- | --------------------------------- |
-| tv       | `/data/torrents/tv`         | tv      | Sonarr                            |
-| movies   | `/data/torrents/movies`     | movies  | Radarr                            |
-| music    | `/data/torrents/music`      | music   | Lidarr                            |
-| anime    | `/data/torrents/anime`      | anime   | Sonarr (2nd download client, root `/data/media/anime`) |
-| books / audiobooks / comics / podcasts | `/data/torrents/<cat>` | `<cat>` | (reserved, none in use yet) |
-
-Path mapping: host `/mnt/library/<cat>` ↔ container `/data/media/<cat>`. Downloads: host `/mnt/library/downloads/<torrents|usenet>/<cat>` ↔ container `/data/torrents/<cat>` and `/data/usenet/<cat>`.
-
-## Auth (reverse-proxy + Authentik forward-auth)
-
-### qBit
-
-Auto-login behind forward-auth via IP whitelist. `qBittorrent.conf` lines:
-- `WebUI\\AuthSubnetWhitelist=172.18.0.0/16, 172.17.0.0/16, 192.168.8.175/32`
-- `WebUI\\ReverseProxySupportEnabled=true`
-- `WebUI\\TrustedReverseProxiesList=192.168.8.175, 172.18.0.0/16`
-
-> **Stop the container before editing `qBittorrent.conf`.** qBit writes its in-memory config on graceful shutdown and clobbers any live edits. Recipe: `docker stop qbittorrent && sed -i ... && docker start qbittorrent`.
-
-Mobile/desktop clients keep working via `/api/v2/*` path bypass on Caddy.
-
-### SABnzbd
-
-Gated with Authentik forward-auth (applied 2026-06-13). Caddy `sab.hubris.network` block uses `import authentik` inside a `handle` block. SABnzbd's own web auth is disabled:
-
-- `html_login = 0` → no HTML login form
-- `username` / `password` cleared → CherryPy Basic Auth not activated
-- `local_ranges = 172.18.0.0/16, 192.168.8.0/24, 127.0.0.0/8` → proxied requests from Caddy (192.168.8.x) and Docker-proxy (172.18.x) pass without auth
-
-**API key** (`67ef5a45e4e04157994e977005a33878`) still works for internal service-to-service calls (Sonarr/Radarr/Lidarr via Docker internal networking — they talk to SAB at `localhost:8082`, not through Caddy).
-
-`host_whitelist`: `sabnzbd, localhost, 127.0.0.1, 192.168.8.132, sab.hubris.network` — extend before accessing SAB from a new host.
-
-## Credentials
-
-Backups of all migration-time secrets at `/mnt/library/backup/arr-migration-2026-04-21/state/`:
-- `lxc100-apikey-{sonarr,radarr,prowlarr,lidarr}.txt`
-- `qbit-creds.txt`, `sab-creds.txt`
-- `lxc100-jellyseerr-settings.json`
-
-\*arr API keys were preserved from the yunohost DB — don't rotate unless needed.
-
-qBittorrent: `admin` / `CDyjxMKvjfGupCKzXFkjsKw4nRrXMRL`.
-
-## Migration gotchas (apply if ever re-importing)
-
-- Imported \*arr `config.xml`: must have `<BindAddress>*</BindAddress>`, `<Port>{ezarr-port}</Port>`, `<UrlBase></UrlBase>`. Otherwise app listens only on 127.0.0.1, wrong port, wrong path.
-- Imported DB paths must be rewritten `/mnt/library/` → `/data/media/` (RootFolders / Series / Movies / Artists tables). Without this, scans and imports fail silently.
-- Bazarr `config/config.yaml` (yaml, not ini) — `ip: 0.0.0.0`, `port: 6767`, empty top-level `base_url`; sonarr/radarr connection sections normalized to docker service names.
-- Staging dir for migrations: `/mnt/library/backup/stage/<app>/` (visible to both old LXC 100 and arriman because both bind-mount the same host path).
-
-## Permissions
-
-Member of [media GID 10000](../infrastructure/media-permissions.md). The LXC has `www-data, audiobookshelf, radarr, sonarr, lidarr, prowlarr, qbittorrent, bazarr, jellyseerr, mylar, jackett, overseerr, plex, arr` in the `media` group. Each docker container also receives GID 10000 as its primary group via `MEDIACENTER_GID=10000`.
-
-## Rollback material (kept until 2026-04-28+)
-
-`/mnt/library/backup/arr-migration-2026-04-21/`:
-- `tars/` — per-subtree tars of yunohost app data (granular restore)
-- `snapshots/` — vzdumps of LXC 100 (pre-migration) and LXC 122 (pre-import), plus post-stop vzdumps of LXC 100 + 106
-- `stage/<app>-preimport.tar.gz` — original empty ezarr `/config/<app>-config/` dirs
-- `state/` — service dumps, listening ports, API keys, jellyseerr settings at migration time
-- `DESTROY_AFTER_2026-04-28.md` — destroy checklist + post-destroy restore commands
-
-## Related
-- [Caddy (121)](121-caddy.md)
-- [Authentik (124)](106-auth-outpost.md) — forward-auth wiring + per-app `/api/*` bypass
-- [DNS](../infrastructure/dns.md)
-- [Media permissions](../infrastructure/media-permissions.md)
-- [Hubris host](../hosts/hubris.md)
-
-## Changelog
-
-### 2026-06-13 — SABnzbd gated with Authentik forward-auth
-SABnzbd now uses Authentik forward-auth (same `import authentik` Caddy pattern as qBit). SABnzbd's own web auth disabled: `html_login=0`, credentials cleared, `local_ranges` extended to cover Docker bridge + homelab LAN. API key still works for internal *arr service calls. See [Auth section](#auth-reverse-proxy--authentik-forward-auth) above.
-
-### 2026-06-04 — all arr services moved behind gluetun VPN; SAB port conflict fixed
-
-- All services (sonarr, radarr, lidarr, bazarr, prowlarr, jellyseerr, homarr,
-  flaresolverr) now use `network_mode: service:gluetun` — whole stack routes
-  through the VPN
-- Port mappings moved from individual services to gluetun container
-- **Fixed SABnzbd port conflict**: was crashing in a restart loop because
-  qBittorrent held port 8080 inside the shared gluetun namespace. Changed
-  SAB internal port to 8082 (config at `/config/sabnzbd-config/sabnzbd.ini`)
-- Caddy `sab.hubris.network` updated to point to `:8082`
-- Jellyseerr's `extra_hosts` (auth.hubris.network) moved to gluetun since
-  `extra_hosts` conflicts with `network_mode`
-
-### 2026-06-02 — ProtonVPN added (gluetun); LXC IP set static
-- Added `gluetun` container to compose as a WireGuard VPN sidecar (ProtonVPN, server AL#57, located in Tirana, Albania)
-- **qbittorrent** and **sabnzbd** now use `network_mode: service:gluetun` — all traffic routes through the VPN
-- Ports 8080 (qBit WebUI), 6881 tcp/udp (qBit BT), 8081 (SAB WebUI) exposed through gluetun
-- gluetun config at `gluetun-config/wireguard/wg0.conf` (read-only mount)
-- Healthcheck on gluetun; qBit/SAB wait for `service_healthy` before starting
-- LXC IP changed from DHCP to static (`192.168.8.132`) via `pct set` + `/etc/network/interfaces`
-- **After first start:** Sonarr/Radarr/Lidarr download client host needs updating from `qbittorrent` → `gluetun` (SAB similarly `sabnzbd` → `gluetun`)
-- **Also fixed:** 7 other DHCP LXCs (101 jellyfin, 103 paperless, 104 gitea, 105 apps, 114 nextcloud, 118 elementsynapse, 120 mule-images, 121 caddy) set to static IPs to prevent floating on reboot. See infrastructure/dns.md.
-
-### 2026-04-28 — wiki entry created
-Initial documentation.
-
-### 2026-04-26 — `MEDIACENTER_GID` flipped 13000 → 10000
-qBit was erroring every torrent with "Permission denied" because s6-setuidgid only honors the primary PGID and `group_add:` doesn't propagate. Setting the primary GID to 10000 (the host `media` group) fixed it.
-
-### 2026-04-21 — \*arr stack migrated yunohost → docker-compose
-Old LXC 100 stopped; ezarr stack stood up here; data and DBs imported with path rewrites. flaresolverr folded in from old LXC 106. Three Caddy sites added (jellyseerr, qbit, sab) → see [caddy](121-caddy.md). Rollback artifacts under `/mnt/library/backup/arr-migration-2026-04-21/`.

archive/knowledge/containers/128-trmnl.md

@@ -1,48 +0,0 @@
-# 128 — `trmnl`
-
-Self-hosted middleware for TRMNL e-ink plugins. TRMNL cloud polls it; it fetches/shapes live data into JSON the plugin's Liquid template renders.
-
-## At a glance
-- **Hostname:** `trmnl`
-- **IP:** `192.168.8.211`
-- **Privilege:** unprivileged
-- **Resources:** 1 core / 768 MiB RAM / 8 GiB rootfs (Debian 13)
-- **Mounts:** none
-- **Public hostname:** `trmnl.hubris.network` (via [VPS ingress](../infrastructure/ingress.md))
-
-## Role
-Runs one FastAPI aggregator (`server.app:app`, port 9851) that mounts a router per plugin from the `dtoro/terminalito` repo. First consumer: `munich-home` (`/munich-home/dashboard`) — weather (Open-Meteo), MVG transit, Google Calendar, plus server-side Kita/quote logic. Talks out to the public internet for those APIs; TRMNL cloud polls it inbound every 15 min. Bearer-token gated (`TRMNL_POLL_TOKEN`); `/health` is open.
-
-## Service / port map
-| Service | Listen | Notes |
-|---------|--------|-------|
-| `trmnl-plugins` | `0.0.0.0:9851` | uvicorn aggregator; `EnvironmentFile=/etc/trmnl-plugins/env` |
-
-## Storage / config paths
-- `/opt/terminalito` — git checkout (origin = internal gitea `http://192.168.8.121:3000/dtoro/terminalito.git`)
-- `/opt/terminalito/server/.venv` — venv
-- `/etc/trmnl-plugins/env` — `TRMNL_POLL_TOKEN` (+ Google/MVG creds once enrolled)
-- `/etc/systemd/system/trmnl-plugins.service`
-
-## Auto-deploy
-Wired — [auto-deploy](../infrastructure/auto-deploy.md) Shape B, webhook id 12 on `dtoro/terminalito` → `http://192.168.8.211:9797/deploy` (`terminalito-deploy.service`). Push to `main` → `server/deploy/deploy.sh` (`git pull` + pip + reinstall units + restart `trmnl-plugins`). Secret `/etc/terminalito-deploy/secret`; git creds `/etc/terminalito-deploy/git-credentials` wired as a repo-local `credential.helper`. Manual: `pct exec 128 -- /opt/terminalito/server/deploy/deploy.sh`.
-
-## Secrets
-Not yet SOPS-enrolled. The poll token is set directly in `/etc/trmnl-plugins/env`. Google Calendar + MVG creds are pending: enroll via `homelab client add trmnl` + bootstrap, add `secrets/trmnl-oauth.yaml`, then `server/deploy/render-env.sh` builds the env from `homelab secret trmnl-oauth`. Until then calendar/transit cards degrade to empty; weather works.
-
-## Related
-- [Caddy (121)](121-caddy.md) — LAN reverse proxy (`trmnl.hubris.network → 192.168.8.211:9851`)
-- [VPS ingress](../infrastructure/ingress.md) — public edge (cert mirror + traefik router)
-- [DNS (107)](107-dns.md) — Technitium A record `trmnl → 192.168.8.175` (LAN path via Caddy)
-- [Gitea (104)](104-gitea.md) — source repo `dtoro/terminalito`
-- [Plan: 2026-06-24 TRMNL plugins LXC](../../../plans/2026-06-24-trmnl-plugins-lxc.md)
-
-## Changelog
-### 2026-06-24 — auto-deploy + LAN DNS wired
-Gitea Shape-B deploy pipeline (webhook id 12, `:9797`) — push to `dtoro/terminalito` redeploys; verified end-to-end. Technitium A record `trmnl.hubris.network → 192.168.8.175` added on [dns (107)](107-dns.md) (propagated to the NetBird managed zone via dns-sync), so LAN clients take the short path through [Caddy (121)](121-caddy.md). See [auto-deploy](../infrastructure/auto-deploy.md).
-
-### 2026-06-24 — public path live
-Verified end-to-end from the internet: `https://trmnl.hubris.network/munich-home/dashboard` → 200 with token, 401 without; `/health` 200. The provision-time outage was the netbird `home-lab-network` (192.168.8.0/24) route having no active routing peer — the **mac-mini routing peer's netbird daemon was down** (artifacto/blog were 504 too). Bringing netbird up on mac-mini restored the route; the edge recovered with no config change. See [ingress](../infrastructure/ingress.md) / [mesh](../infrastructure/mesh.md).
-
-### 2026-06-24 — provisioned
-LXC 128 created (Debian 13, unprivileged, `192.168.8.211`). Deployed `trmnl-plugins.service` on :9851 from `dtoro/terminalito`. Caddy block added (`dtoro/caddy-conf`) + LE cert via IONOS DNS-01; verified `/health` 200 and `/munich-home/dashboard` (live weather) through Caddy. Cert mirrored to VPS (`trmnl.fullchain.crt`/`trmnl.privkey.key`) + traefik router `trmnl-public` → `192.168.8.211:9851` added to `/opt/traefik-dynamic.yaml`. **Public path pending**: VPS↔home netbird route was down at provision time (`No networks available`, 3/6 peers — artifacto/blog also 504); resolves when the mesh route recovers. **LAN pending**: Technitium A record not yet added. Not SOPS-enrolled; Google/MVG creds pending.

archive/knowledge/containers/129-house.md

@@ -1,52 +0,0 @@
-# 129 — `house`
-
-Yuvomi family planner (formerly Oikos). Self-hosted family planner with 14 modules: calendar, tasks, meals, groceries, budget, documents, notes, contacts, birthdays, housekeeping, recipes, reminders.
-
-## At a glance
-
-- **Hostname:** `house`
-- **IP:** `192.168.8.244`
-- **Host:** **strong** (migrated from hubris 2026-07-05)
-- **Privilege:** unprivileged
-- **Resources:** 1 core / 1344 MiB RAM / 8 GiB rootfs (Debian 13)
-- **Mounts:** none
-- **Public hostname:** [`house.hubris.network`](../infrastructure/ingress.md) → VPS traefik → Caddy
-
-## Service / port map
-
-| Service | Listen | Notes |
-|---------|--------|-------|
-| `oikos` (Yuvomi) | `0.0.0.0:3000` | Docker Compose at `/opt/yuvomi/`, image `ghcr.io/ulsklyc/yuvomi` |
-
-## Integrations
-
-- **Authentik SSO (OIDC):** Provider `Provider for Yuvomi` (PK 31) in Authentik on VPS. Env vars in `/opt/yuvomi/.env`: `OIDC_ISSUER`, `OIDC_CLIENT_ID`, `OIDC_CLIENT_SECRET`. Redirect URI: `https://house.hubris.network/auth/oidc/callback`.
-- **Paperless DMS connector (native):** Yuvomi connects directly to Paperless-ngx API at `http://192.168.8.130:8000/`. API token stored in SQLite `dms_accounts` table. Search, link, and upload documents from Yuvomi to Paperless via Settings → Documents → DMS.
-- **Weather widget:** Open-Meteo (free, no API key). Munich coordinates set.
-- **Google Calendar:** OAuth configured via env vars (`GOOGLE_CLIENT_ID`, `GOOGLE_CLIENT_SECRET`, `GOOGLE_REDIRECT_URI`). Redirect URI: `https://house.hubris.network/api/v1/calendar/google/callback`. Authorize in Settings → Calendar → Connect Google Calendar.
-
-## Config paths
-
-- `/opt/yuvomi/docker-compose.yml` — downloaded from upstream
-- `/opt/yuvomi/.env` — config including secrets (untracked)
-- `/opt/yuvomi/data/` — SQLCipher SQLite DB (`oikos.db`)
-- `/opt/yuvomi/backups/` — auto backups
-- `/opt/yuvomi/modules/` — Yuvomi modules (empty for now)
-
-## Related
-
-- [Caddy (121)](121-caddy.md) — LAN reverse proxy (`house.hubris.network → 192.168.8.212:3000`)
-- [VPS ingress](../infrastructure/ingress.md) — public edge (cert mirror + traefik router)
-- [DNS (107)](107-dns.md) — Technitium A record `house → 192.168.8.175` (LAN path via Caddy)
-- [Paperless (103)](103-paperless.md) — native DMS connector (API at `:8000`)
-- [TRMNL (128)](128-trmnl.md) — Google Calendar tokens source
-- [Deployment plan](../../../plans/done/2026-06-25-yuvomi-deployment.md)
-
-## Changelog
-
-### 2026-06-27 — Google Calendar OAuth env vars configured
-`GOOGLE_CLIENT_ID`, `GOOGLE_CLIENT_SECRET`, `GOOGLE_REDIRECT_URI` set in `.env`. New OAuth client ID (`-bho4iq..`).
-
-### 2026-06-26 — provisioned
-
-LXC 129 created (Debian 13, unprivileged, `192.168.8.212`). Docker installed. Yuvomi container running on `:3000` from `ghcr.io/ulsklyc/yuvomi:latest`. Caddy block + DNS A record + VPS traefik router `house-public` for public access. Authentik OIDC provider created (PK 31). WebDAV document bridge on paperless LXC (103) at `:8088` for Paperless auto-import.

archive/knowledge/containers/130-grimmory.md

@@ -1,66 +0,0 @@
-# 130 — `grimmory`
-
-Self-hosted digital library (eBooks, comics, audiobooks). Community fork/successor of Booklore, with smart shelves, metadata enrichment, Kobo/KOReader sync, OPDS, and a built-in EPUB/PDF reader. Migrated from [apps (105)](105-apps.md) on 2026-06-29.
-
-## At a glance
-
-- **Hostname:** `grimmory`
-- **IP:** `192.168.8.247`
-- **Host:** **strong** (migrated from hubris 2026-07-05)
-- **Privilege:** privileged (UID = host UID for `/mnt/library` media GID)
-- **Resources:** 1 core / 2 GiB RAM / 16 GiB rootfs (Debian 13)
-- **Mounts:** `/mnt/media_local` ↔ `/mnt/library`
-- **Public hostname:** `books.hubris.network`
-
-## Service / port map
-
-| Service | Listen | Notes |
-|---------|--------|-------|
-| Grimmory | `192.168.8.247:6060` | Docker Compose at `/opt/grimmory/` |
-| MariaDB | internal only | Sidecar in the same compose stack |
-
-## Compose
-
-Located at `/opt/grimmory/docker-compose.yml`. Key points:
-
-- Image: `ghcr.io/grimmory-tools/grimmory:latest`
-- Books library: `/mnt/library/books` → `/books` (read-write; media GID 10000 via `GROUP_ID=10000`)
-- Bookdrop (watched folder for auto-import): `/opt/grimmory/bookdrop` → `/bookdrop`
-- App data (covers, DB config): `/opt/grimmory/data` → `/app/data`
-- MariaDB config: `/opt/grimmory/mariadb/config` → `/config` (linuxserver/mariadb image)
-- `extra_hosts: auth.hubris.network:192.168.8.175` — routes Authentik OIDC discovery to Caddy from inside the container
-- `FORCE_DISABLE_OIDC=false` — OIDC stays enabled; provider configured via Grimmory admin UI
-
-Credentials live in `/opt/grimmory/.env` (untracked):
-- `DATABASE_PASSWORD` / `MYSQL_PASSWORD` — MariaDB Grimmory user password
-- `MYSQL_ROOT_PASSWORD` — MariaDB root password
-
-## Authentik OIDC
-
-Uses Confidential client (client secret stored in Grimmory's DB — migrated from Booklore). The OIDC config carried over in the database dump; no manual re-entry needed.
-
-- **Authentik provider:** `Provider for Grimmory` (renamed from `Provider for Booklore` on migration)
-- **Client ID:** `L1u0eFsNhbKgiIvvFeIr2mvZdbtFyzidCq2h6thL`
-- **Client type:** Confidential (client secret in `oidc_provider_details` in MariaDB `app_settings`)
-- **Redirect URI:** `https://books.hubris.network/oauth2-callback`
-- **Scopes:** openid, profile, email, offline_access
-- **Back-channel logout:** `http://192.168.8.247:6060/api/v1/auth/oidc/backchannel-logout`
-- **Application slug:** `booklore` → Issuer URI: `https://auth.hubris.network/application/o/booklore/`
-
-## Media permissions
-
-LXC is privileged → in-container UID = host UID. Docker container gets media GID via `GROUP_ID=10000` env var (Grimmory/linuxserver pattern). The `/mnt/library/books` subtree is owned `:media` mode `2775` (setgid). See [media-permissions](../infrastructure/media-permissions.md).
-
-## Related
-
-- [apps (105)](105-apps.md) — previous host (Booklore)
-- [Caddy (121)](121-caddy.md) — `books.hubris.network → 192.168.8.247:6060`
-- [Authentik (124)](106-auth-outpost.md) — OIDC provider `Grimmory`
-- [DNS (107)](107-dns.md) — `books.hubris.network → 192.168.8.175` (unchanged from Booklore)
-- [Media permissions](../infrastructure/media-permissions.md)
-
-## Changelog
-
-### 2026-06-29 — provisioned; Booklore migrated
-
-LXC 130 created (Debian 13, privileged, `192.168.8.213`). Docker installed. Grimmory compose deployed at `/opt/grimmory/`. MariaDB dump from Booklore (LXC 105) restored — schema-compatible since Grimmory is a direct fork. Caddy `books.hubris.network` backend updated from `192.168.8.205:6060` to `192.168.8.213:6060`. Authentik provider updated: Booklore → Grimmory, Confidential → Public (PKCE). Booklore stack removed from Portainer on LXC 105.

archive/knowledge/containers/131-teddycloud.md

@@ -1,62 +0,0 @@
-# 131 — `teddycloud`
-
-Self-hosted [TeddyCloud](https://github.com/toniebox-reverse-engineering/teddycloud), a
-reimplementation of the Toniebox cloud backend — lets Tonie figurines play custom/ripped
-audio content against a local server instead of the official cloud.
-
-Predates the client-enrollment convention entirely; nobody wrote it down. Found and
-documented on 2026-07-06 after Oikos's drift detector (`oikos/drift.py`) flagged
-`pve_id 131` as live on hubris (via `pct list`) with no `inventory.yaml` entry — see
-[OIKOS.md](../../../.agents/OIKOS.md)'s Week 3 build-status note. `containers/132-rclone.md` had already
-mentioned it in passing ("LXC 131 was already taken by an undocumented `teddycloud`
-container"), and `hosts/strong.md`'s 2026-07-05 migration changelog fixed a DHCP conflict
-for it — but it never got its own inventory entry or doc page until now.
-
-## At a glance
-
-- **Hostname:** `teddycloud`
-- **Host:** hubris (confirmed via `pct config 131` run directly on hubris — the original
-  drift finding's `pct list` source)
-- **IP:** `192.168.8.150` (static; was briefly `192.168.8.243` via DHCP until the
-  2026-07-05 strong-migration work assigned it a fixed address — see hosts/strong.md)
-- **Privilege:** unconfirmed (not checked — read-only investigation didn't need it)
-- **Resources:** 1 core / 1 GiB RAM / 512 MiB swap / 16 GiB rootfs (`local-lvm`), Debian 12
-  (bookworm)
-- **Mounts:** `/mnt/library` (`mp0`)
-- **Public hostname:** `teddy.hubris.network` → `192.168.8.150:8443` (see
-  [caddy (121)](121-caddy.md))
-- **Enrollment:** none — no `age_pubkey`, not a `homelab` CLI client. It's a plain
-  docker-compose app container, not a fleet-managed host. No action needed unless it starts
-  needing secrets.
-
-## Service
-
-Runs via `docker compose` at `/opt/teddycloud` — container `teddycloud-teddycloud-1`,
-image `ghcr.io/toniebox-reverse-engineering/teddycloud:latest`, publishing `80`, `443`,
-`8080`, and `8443`. Caddy routes `teddy.hubris.network` to the `:8443` port.
-
-## Risk notes
-
-**No Caddy forward-auth gate** — unlike `sab.hubris.network` on the same Caddyfile (which
-is explicitly annotated `(Authentik forward-auth)`), `teddy.hubris.network` has no auth
-annotation. It's reachable to anyone on the LAN/mesh who can resolve the hostname. Not
-addressed as part of this doc pass — flagging it here since it's now visible in one place
-for the first time.
-
-## Related
-
-- [Hubris host](../hosts/hubris.md)
-- [Caddy (121)](121-caddy.md) — terminates `teddy.hubris.network`
-- [rclone (132)](132-rclone.md) — landed on pve_id 132 specifically because 131 was already
-  taken by this container
-- [Containers index](index.md)
-- [OIKOS.md](../../../.agents/OIKOS.md) — drift detector that caught this
-
-## Changelog
-
-### 2026-07-06 — documented for the first time (drift-caught)
-
-Added to `inventory.yaml` and given this page. Verified live via read-only `pct config 131`
-+ `pct exec 131 -- ...` on hubris: hostname, IP, resources, and that it runs via
-`docker compose` (not a raw binary or systemd unit). No changes made to the running
-container — this is pure documentation catch-up.

archive/knowledge/containers/132-rclone.md

@@ -1,199 +0,0 @@
-# 132 — `rclone`
-
-Off-host backup appliance. Mirrors selected `/mnt/library` folders to **Proton Drive**
-with a plain `rclone sync` (monthly), and serves rclone's Web GUI on the LAN for browsing
-and ad-hoc runs. **Replaces** the disabled restic-on-USB job — see [backups](../infrastructure/backups.md).
-
-Provisioned 2026-07-01. (LXC 131 was already taken by an undocumented `teddycloud` container,
-so this landed on **132**.)
-
-## At a glance
-
-- **Hostname:** `rclone`
-- **IP:** `192.168.8.214` (static, set in PVE `net0` config — same pattern as grimmory/authentik)
-- **Privilege:** privileged (root in-container = host root → reads every `/mnt/library` subtree,
-  incl. `homecloud/` and `documents/`, regardless of owner)
-- **Resources:** 1 core / 2 GiB RAM / 8 GiB rootfs (Debian 13) — bumped from 1 GiB on 2026-07-03
-  after `rclone-rcd.service` was OOM-killed under real load (see "Known issue" below)
-- **Mounts:** `/mnt/library` **read-only** (`mp0: /mnt/library,mp=/mnt/library,ro=1`) — a backup
-  job must never be able to write into the library
-- **Public hostname:** none — the UI is **LAN-only, no auth** (by design)
-
-## Service / port map
-
-| Service | Listen | Notes |
-|---------|--------|-------|
-| rclone Web GUI (`rcd`) | `192.168.8.214:5572` | `rclone-rcd.service`, **`--rc-no-auth`**, LAN-only. Browse `/mnt/library` + `proton:`, run ad-hoc syncs, live job status |
-| monthly mirror | — | `rclone-backup.service` + `.timer` (`OnCalendar=*-*-01 03:00`) |
-
-## Backup design
-
-- **Mode:** plain mirror — `rclone sync` (Proton mirrors local; deletions propagate; **no versioning**).
-- **Encryption:** Proton Drive's built-in E2E only (no rclone `crypt` overlay → files stay
-  browsable in Proton's web UI).
-- **Selected set:** `/etc/rclone-backup/folders.list` — one absolute source path per line
-  (`#`/blank ignored). This file *is* the picked set the monthly timer mirrors. Extensible to other
-  disks once bind-mounted into this LXC.
-- **Path mapping:** source `S` → `proton:library-backup/<S without leading slash>`
-  (e.g. `/mnt/library/notes` → `proton:library-backup/mnt/library/notes`).
-- **Runner:** `/usr/local/sbin/rclone-backup.sh [folder ...]` (Python, despite the `.sh` name — kept
-  the path stable) — no arg = every enabled line. Submits each folder as an **async job through the
-  rclone rc API** served by `rclone-rcd.service` (the same daemon backing the Web GUI on `:5572`),
-  so scheduled/ad-hoc runs show up live in the GUI's **Jobs panel**, not just in logs. Gentle on
-  Proton's rate limits (`Transfers=4, TPSLimit=8, FastList=true` via the rc `_config` payload). The
-  rc API here requires **POST for every call** including `job/status` and `core/stats` — GET with
-  query params 404s.
-- **Logs / "past runs":** per-run logs in `/var/log/rclone-backup/<safe>-<ts>.log`; one-line
-  JSON summary per run appended to `/var/log/rclone-backup/runs.jsonl`.
-- **Failure notify:** `OnFailure=rclone-backup-notify@%n.service` → logs to journal today;
-  **TODO** wire to Hermes `send_message` (Matrix) per [backups](../infrastructure/backups.md).
-
-## rclone + Proton Drive
-
-- **rclone** installed from the official binary (not apt) so the `protondrive` backend is present
-  (`rclone v1.74.3`).
-- Remote **`proton:`** (type `protondrive`). Config at `/root/.config/rclone/rclone.conf`, mode 600.
-  **This file is a secret** (holds the obscured Proton password + TOTP secret + session) — **never
-  commit it.** Escrow the Proton account creds in the password manager.
-- **Config gotchas** (from rclone docs/forum):
-  - Log into Proton via a **browser at least once** first, or key generation fails.
-  - For unattended runs, store the **TOTP _secret_** (not a 6-digit code) so rclone self-generates
-    codes; obscure with `rclone obscure`.
-  - Passwords with **extended-ASCII** characters are known to break auth.
-  - Proton's API is rate-limited → keep `--transfers`/`--tpslimit` conservative (baked into the runner).
-- **DR escrow (pending):** store the Proton creds as sops secret `secrets/protondrive.yaml`, granted
-  to this LXC's age key, so the remote can be rebuilt after a re-provision.
-
-## The UI (rclone Web GUI)
-
-`rclone rcd --rc-web-gui --rc-no-auth --rc-addr 0.0.0.0:5572` (assets auto-downloaded on first
-start). Reach it at **http://192.168.8.214:5572** on the LAN.
-
-> **Security note:** `--rc-no-auth` exposes *full* rclone control — including deleting remote data —
-> to anyone on the LAN (accepted per the design choice). The container has only a LAN NIC, so it is
-> not publicly reachable. Harden later by adding `--rc-user/--rc-pass` or fronting it with Authentik.
-
-## Tracked config (deferred)
-
-**Not yet tracked.** The runner, systemd units, and `folders.list` currently live as plain files
-directly on the LXC — fully functional, just not version-controlled or auto-deployed. A
-`dtoro/rclone` gitea repo package (runner, units, `install.sh`, webhook receiver) is pre-built and
-staged at `/root/rclone-repo` on the LXC for whenever this gets tracked (Shape A, like
-[caddy](121-caddy.md)). Gitea `ALLOWED_HOST_LIST` already includes `192.168.8.214` in anticipation.
-See [auto-deploy](../infrastructure/auto-deploy.md).
-
-**Selected folders (live in `/etc/rclone-backup/folders.list`):** `/mnt/library/cloud` (287G),
-`/mnt/library/documents` (249M), `/mnt/library/repos` (83M). `/mnt/library/notes` was synced once as
-a connectivity test (not in the recurring set). Proton quota checked: 2 TiB plan, ~1.65 TiB free
-after this set.
-
-## Enrollment gotcha: `pct exec` PATH
-
-`pct exec` (lxc-attach) does **not** source `/etc/environment` or run a login shell, so
-`/usr/local/bin` (where bootstrap installs `sops`) isn't on `$PATH` by default — bootstrap's own
-`command -v sops` post-install check failed under `pct exec` even though the binary installed fine.
-Fixed by symlinking `/usr/local/bin/{sops,homelab}` into `/usr/bin` (always on the minimal PATH),
-rather than relying on `/etc/environment`. Same category as the documented [`pct exec` no-initgroups
-gotcha](../infrastructure/media-permissions.md#gotchas) — worth adding to
-[agent-enrollment.md troubleshooting](../../../.agents/operations/agent-enrollment.md#troubleshooting) if it recurs
-on future LXC bootstraps.
-
-## Known issue: `rclone-rcd.service` OOM-killed under 1 GiB RAM (root cause, resolved)
-
-What looked like repeated "protondrive silently stalls" was actually **`rclone-rcd.service` (the rc
-API daemon backing the Web GUI and, since the rc-API redesign, all actual sync work) getting
-OOM-killed** under the original 1 GiB RAM allocation — `journalctl` confirms
-`A process of this unit has been killed by the OOM killer` at the exact moment a transfer had
-"frozen." systemd's own `Restart=on-failure` (5s) auto-respawns it, but every in-flight job's state
-is lost on the kill, which looked identical to a silent backend hang from the outside (frozen
-`core/stats`, no new log lines). **Fix: bumped the LXC's memory to 2 GiB** (`pct set 132 -memory
-2048` — applies live via the host cgroup, confirmed via `cat /sys/fs/cgroup/lxc/132/memory.max` on
-hubris, no container reboot needed). After the bump, the full folder set (`cloud` 287G, `documents`
-249M, `repos` 83M) completed cleanly with no further kills.
-
-**`rclone-backup-watchdog.timer`** (every 5 min) → `rclone-backup-watchdog.sh`: if
-`rclone-backup.service` is active but total transferred bytes (global `core/stats` on the rc API)
-haven't moved for 15 minutes, it restarts both `rclone-rcd.service` (clears any stuck/orphaned job —
-this is the actual daemon holding the work, not the thin wrapper) and then `rclone-backup.service`
-(`--no-block`, load-bearing — see below). Kept as a safety net even after the RAM fix, in case
-memory pressure returns under a larger folder set later. State kept in
-`/var/lib/rclone-backup/watchdog-state.json`, cleared whenever the service isn't running.
-
-**Two watchdog design bugs found and fixed while chasing this (2026-07-03):**
-1. **Wrong stats-group key.** Per-job progress polling queried `core/stats` under `job/<jobid>`,
-   but rclone tracks stats under whatever `_group` name the job was submitted with. Made a perfectly
-   healthy sync look stalled at 0 bytes for 22+ hours in its own log. Fixed by using the same
-   `group` variable consistently. **Lesson: distrust the per-run log's "progress bytes=" line during
-   an incident; cross-check with unfiltered `core/stats` first.**
-2. **Watchdog restarted only the thin wrapper, and blocked doing it.** The actual `rclone sync` work
-   runs inside `rclone-rcd.service`, not `rclone-backup.service` — restarting the wrapper alone left
-   any stuck job orphaned inside `rcd` while a new wrapper submitted a duplicate job on top. Worse,
-   `systemctl restart rclone-backup.service` (no `--no-block`) blocks until the *new* invocation's
-   long-running `ExecStart` exits — which could be hours — so the watchdog's own oneshot service
-   never logged "Finished," and `OnUnitActiveSec` (which schedules relative to the previous run
-   *finishing*) never fired again. The watchdog silently disabled itself after exactly one use.
-   Fixed: restart `rclone-rcd.service` first, then `rclone-backup.service` with `--no-block`.
-
-## Related
-
-- [Backups](../infrastructure/backups.md) — this job supersedes the disabled restic-on-USB backup
-- [Hubris host](../hosts/hubris.md) — owns `/mnt/library`
-- [Media permissions](../infrastructure/media-permissions.md) — read-only consumer of `/mnt/library`
-- [Containers index](index.md)
-
-## Changelog
-
-### 2026-07-03 — root cause found (OOM, not Proton); RAM bumped to 2 GiB; full folder set completed
-
-What looked like repeated silent "protondrive stalls" turned out to be **`rclone-rcd.service`
-getting OOM-killed** under the original 1 GiB RAM allocation — confirmed via
-`journalctl -u rclone-rcd.service` showing `killed by the OOM killer` at the exact freeze point.
-Bumped the LXC to 2 GiB RAM (live, no reboot). After the bump: `cloud` (287G) completed cleanly
-(exit 0), `documents` (249M) completed with 1 minor error (259.7 MB transferred), `repos` (83M)
-completing as of this entry. Also fixed two real watchdog bugs found while chasing this (wrong
-stats-group key making a healthy sync look frozen; watchdog restarting only the wrapper with a
-blocking `systemctl restart`, causing it to silently disable itself after one use) — see "Known
-issue" above for full detail. The watchdog is kept as a safety net going forward even though the RAM
-bump addresses the actual root cause.
-
-### 2026-07-02 — runner rewritten to submit jobs via the rc API (GUI job visibility)
-
-The original runner (`rclone sync` invoked as a standalone CLI subprocess) was invisible to the Web
-GUI's Jobs panel — the GUI only tracks work submitted through its own `rcd` process. Rewrote
-`/usr/local/sbin/rclone-backup.sh` in Python, submitting each folder via `POST /sync/sync` with
-`_async: true` against `http://127.0.0.1:5572` (the running `rclone-rcd.service`), then polling
-`POST /job/status` + `POST /core/stats` (both **must be POST** — GET-with-querystring 404s on this
-rc API) until finished, logging periodic progress snapshots and the same `runs.jsonl` summary line
-as before. Verified live: submitted job visible in `POST /job/list`'s `runningIds` while running,
-completed cleanly (`success: true`) once done. Deployed via atomic rename (write-then-`mv`) rather
-than truncating in place, specifically so it wouldn't risk corrupting the still-running original
-`cloud`+`documents`+`repos` sync mid-flight (verified after the fact: that sync's bash process was
-unaffected, kept running to completion under the old in-memory script content). The already-running
-scheduled sync from before this change is a standalone process and won't retroactively appear in the
-GUI; every run after this point will.
-
-### 2026-07-02 — Proton Drive auth fixed; real folder set enabled; first live sync
-
-Initial `rclone config` failed 2FA (`422 ... auth/v4/2fa`) because a live 6-digit TOTP code was
-entered instead of the TOTP secret — reconfigured with the secret, auth now works
-(`rclone lsd proton:` lists the Drive). Verified end-to-end with a real sync of `/mnt/library/notes`
-(219 objects, 5.964 MiB, exit 0) — confirmed files land as plain, browsable objects on Proton (not
-an opaque archive), matching the plain-mirror + Proton-E2E design. Checked Proton quota (2 TiB
-plan, 1.945 TiB free) before enabling a large folder. `folders.list` set to the real selection:
-`cloud` (287G), `documents` (249M), `repos` (83M); a full sync of that set was kicked off via the
-actual `rclone-backup.service` unit (not an ad-hoc call) to validate the real monthly path early
-rather than waiting for the Aug 1 timer. Tracked-repo step (`dtoro/rclone` on gitea) deferred by
-choice — runner/units/`folders.list` remain plain files on the LXC for now; the repo package stays
-staged at `/root/rclone-repo` for later.
-
-### 2026-07-01 — provisioned; enrolled
-
-LXC 132 created (Debian 13, privileged, `192.168.8.214`, `/mnt/library` read-only). rclone v1.74.3
-installed from the official binary (`protondrive` backend present). Runner + monthly timer +
-`folders.list` deployed; rclone Web GUI (`rcd`, LAN-only no-auth) live on `:5572`. Enrolled into
-homelab-context (`--no-mesh`, LAN-only issuance): age key issued, inventory finalized, shared
-secrets granted, `homelab whoami` + `homelab secret hello` verified. Gitea `ALLOWED_HOST_LIST`
-updated to include `192.168.8.214`. Hit and fixed a `pct exec` PATH gotcha (see below). Proton Drive
-remote, `dtoro/rclone` tracked repo + webhook, and the `secrets/protondrive.yaml` escrow remain
-operator-run follow-ups (credentialed steps — Proton password/2FA, repo creation). Restic-on-USB
-backup deprecated in the same change.

archive/knowledge/containers/133-seanime.md

@@ -1,61 +0,0 @@
-# seanime (LXC 133) — Seanime anime media server
-
-## Summary
-
-| Field | Value |
-|-------|-------|
-| VMID | 133 |
-| Host | strong |
-| Role | Anime media server (online streaming + torrent client) |
-| LAN IP | 192.168.8.248/28 (vmbr1) |
-| Public URL | https://seanime.hubris.network |
-| Backend | Seanime v3.9.0, systemd service |
-| Port | 43211 |
-
-## Mounts
-
-- `/anime` → `/mnt/media_local/anime` (ludo-lvm, bind mount) — existing anime collection
-
-## Services
-
-### Seanime (native binary)
-
-- Binary: `/opt/seanime/bin/seanime`
-- Data: `/opt/seanime/data/`
-- Config: `/opt/seanime/data/config.toml`
-- Service: `systemctl status seanime`
-- Flags: `--host 0.0.0.0 --port 43211 --datadir /opt/seanime/data --disable-password`
-- Config highlights:
-  - `secureMode = 'lax'` (allows non-local Caddy proxy)
-  - `trustedProxies = ['192.168.8.0/24']`
-
-### Torrent client (qBittorrent on arriman)
-
-- Host: `192.168.8.245:8080`
-- Auth: subnet whitelist (no password needed from homelab LAN)
-- qBittorrent config updated: `AuthSubnetWhitelist=192.168.8.0/24`
-
-### Extensions installed
-
-**Online streaming (8):**
-HiAnime, AniWatch, KickAssAnime, Anicrush, Animo, AniNeko, Senshi, Sudatchi
-
-## Caddy
-
-- Config: `seanime.hubris.network` block in `/etc/caddy/Caddyfile` (dtoro/caddy-conf repo)
-- TLS: Let's Encrypt DNS-01 via IONOS API
-- Backend: `192.168.8.248:43211`
-
-## DNS
-
-- `seanime.hubris.network` A record → `192.168.8.175` (Caddy)
-
-## Changelog
-
-### 2026-07-05 — initial creation
-- LXC 133 created on strong (Debian 13, 2 cores / 2 GiB)
-- Seanime v3.9.0 installed as native binary + systemd service
-- /anime bind mount from ludo-lvm
-- qBittorrent on arriman configured as torrent client
-- Caddy reverse proxy + DNS records set up
-- Online streaming extensions installed

archive/knowledge/containers/134-romm.md

@@ -1,82 +0,0 @@
-# 134 — `romm`
-
-Self-hosted ROM manager ([RomM](https://romm.app)). Browse, search, and play
-your retro game library from the browser. Runs on Docker Compose with a
-MariaDB sidecar.
-
-## At a glance
-
-- **Hostname:** `romm`
-- **IP:** `192.168.8.249/28` (static, vmbr1 on strong)
-- **Privilege:** privileged
-- **Resources:** 1 core / 2 GiB RAM / 16 GiB rootfs (Debian 13, ludo-lvm)
-- **Mounts:** `/mnt/media_local` → `/mnt/library`
-- **Public hostname:** `roms.hubris.network`
-
-## Service / port map
-
-| Service | Listen | Notes |
-|---------|--------|-------|
-| RomM    | `192.168.8.249:80` | HTTP (Caddy terminates TLS) |
-| MariaDB | internal only       | Sidecar in the same compose stack |
-
-## Compose
-
-Located at `/opt/romm/docker-compose.yml`. Key points:
-
-- Image: `rommapp/romm:latest`
-- DB sidecar: `mariadb:latest` with healthcheck
-- ROM library: `/mnt/library/roms` → `/romm/library` (writable)
-- Resources (covers, etc.): Docker named volume `romm_resources` → `/romm/resources`
-- Saves/states: `/opt/romm/assets` → `/romm/assets`
-- Config: `/opt/romm/config` → `/romm/config`
-- Auth key: auto-generated, stored in `/opt/romm/.env`
-
-Environment (`/opt/romm/.env`):
-- `DB_ROOT_PASSWD` / `DB_PASSWD` — MariaDB credentials
-- `DB_USER=romm-user` / `DB_NAME=romm`
-- `ROMM_AUTH_SECRET_KEY` — auto-generated
-
-## ROM library structure
-
-RomM expects `/mnt/library/roms/<platform>/<game>/<rom>`. Create platform
-directories as needed:
-
-```
-/mnt/media_local/roms/
-├── gba/
-│   └── Pokemon - Emerald/
-│       └── Pokemon Emerald.gba
-├── snes/
-│   └── Super Mario World/
-│       └── Super Mario World.sfc
-└── psx/
-    └── Final Fantasy VII/
-        └── Final Fantasy VII.bin
-```
-
-## Media permissions
-
-The `/mnt/media_local/roms` directory is owned `root:media` with mode `2775`
-(setgid). New files inherit the `media` GID (10000). The LXC is privileged so
-no idmap block is needed — in-container UID/GID matches the host. Docker
-containers within the LXC run as-is (read-only mount).
-
-## Related
-
-- [Strong host](../hosts/strong.md)
-- [Caddy (121)](121-caddy.md) — `roms.hubris.network → 192.168.8.249:80`
-- [DNS (107)](107-dns.md) — `roms.hubris.network A 192.168.8.175`
-- [Media permissions](../infrastructure/media-permissions.md)
-- [RomM docs](https://docs.romm.app)
-
-## Changelog
-
-### 2026-07-05 — provisioned
-
-LXC 134 created on strong (Debian 13, privileged, `192.168.8.249/28`).
-Docker + Compose installed. RomM stack deployed at `/opt/romm/`.
-Created `/mnt/media_local/roms` with setgid `media:GID=10000` mode `2775`.
-Caddy `roms.hubris.network` → `192.168.8.249:80`.
-DNS `roms A 192.168.8.175` added to Technitium.
-Hubris /32 route for `.249` added to `50-strong-route`.

archive/knowledge/containers/index.md

@@ -1,57 +0,0 @@
-# LXC containers — index
-
-Most containers live on [`hubris`](../hosts/hubris.md). Some have been
-[migrated to `strong`](../hosts/strong.md) (Phase 1+2, 2026-07-05).
-
-| ID  | Name             | Host    | IP              | Priv | Cores | RAM   | Disk  | Mounts                | Public hostname                       | Status   |
-| --- | ---------------- | ------- | --------------- | ---- | ----- | ----- | ----- | --------------------- | ------------------------------------- | -------- |
-| 101 | [jellyfin](101-jellyfin.md)             | **strong** | 192.168.8.246 | priv | 4 | 8 GiB  | 16 GiB | `/mnt/media_local` (via mp0) | `media.hubris.network`         | running  |
-| 103 | [paperless](103-paperless.md)           | hubris  | 192.168.8.130 | priv | 2 | 3 GiB  | 8 GiB  | `/mnt/library`        | `paperless.hubris.network`            | running  |
-| 104 | [gitea](104-gitea.md)                   | hubris  | 192.168.8.121 | priv | 1 | 1 GiB  | 8 GiB  | `/mnt/library`        | `git.hubris.network`                  | running  |
-| 105 | [apps](105-apps.md)                     | hubris  | 192.168.8.205 | priv | 2 | 4 GiB  | 30 GiB | `/mnt/library`        | `docker` / `artifacto` / `blog`       | running |
-| 114 | [nextcloud](114-nextcloud.md)           | hubris  | 192.168.8.224 | priv | 4 | 6 GiB  | 25 GiB | `/mnt/library`        | `cloud.hubris.network`                | running  |
-| 118 | [elementsynapse](118-elementsynapse.md) | **strong** | 192.168.8.242 | unpriv | 2 | 4 GiB  | 32 GiB | —                     | `matrix.hubris.network`               | running  |
-| 119 | [sophia](119-sophia.md)                 | hubris  | 192.168.8.157 | priv | 2 | 1 GiB  | 10 GiB | `/mnt/library`        | —                                     | running  |
-| 120 | [mule-images](120-mule-images.md)       | hubris  | 192.168.8.136 | priv | 6 | 12 GiB | 60 GiB | `/mnt/library` + `/dev/dri` (iGPU) | `photos.hubris.network` | running  |
-| 121 | [caddy](121-caddy.md)                   | hubris  | 192.168.8.175 | unpriv | 1 | 512 MiB | 6 GiB  | —                     | (terminates all `*.hubris.network`)   | running  |
-| 122 | [arriman](122-arriman.md)               | **strong** | 192.168.8.245 | priv | 4 | 8 GiB  | 24 GiB | `/mnt/media_local` (via mp0) | `jellyseerr` / `qbit` / `sab` | running  |
-| 124 | [authentik](106-auth-outpost.md)           | hubris  | 192.168.8.180 | priv | 2 | 4 GiB  | 20 GiB | —                     | `auth.hubris.network`                 | running  |
-| 128 | [trmnl](128-trmnl.md)                   | hubris  | 192.168.8.211 | unpriv | 1 | 768 MiB | 8 GiB  | —                     | `trmnl.hubris.network`                | running  |
-| 129 | [house](129-house.md)                   | **strong** | 192.168.8.244 | unpriv | 2 | 3 GiB  | 8 GiB  | —                     | `house.hubris.network`                | running  |
-| 130 | [grimmory](130-grimmory.md)             | **strong** | 192.168.8.247 | priv | 1 | 2 GiB  | 16 GiB | `/mnt/media_local` (via mp0) | `books.hubris.network`         | running  |
-| 131 | [teddycloud](131-teddycloud.md)         | hubris  | 192.168.8.150 | — | 1 | 1 GiB  | 16 GiB | `/mnt/library` | `teddy.hubris.network` (no auth gate) | running  |
-|| 132 | [rclone](132-rclone.md)                 | hubris  | 192.168.8.214 | priv | 1 | 1 GiB  | 8 GiB  | `/mnt/library` (**ro**) | — (LAN-only UI `:5572`)             | running  |
-|| 134 | [romm](134-romm.md)                     | **strong** | 192.168.8.249 | priv | 1 | 2 GiB  | 16 GiB | `/mnt/media_local` (via mp0) | `roms.hubris.network`          | running  |
-
-## Recently destroyed (kept for archaeology)
-
-| ID  | Name             | Destroyed       | Reason                                        |
-| --- | ---------------- | --------------- | --------------------------------------------- |
-| 127 | mule-photos-new  | 2026-05-22      | PhotoPrism + sidecar + SvelteKit stack promoted to LXC 120 via Mulimage 2.0 merge (`70dc1b6`); M0 test LXC retired. Caddy + dnsmasq + gitea webhook + NC webhook listeners all cleaned up in the same cutover. |
-| 100 | arr (yunohost)   | ~2026-04-28     | Migrated to docker stack on [arriman](122-arriman.md); planned retention window expired |
-| 106 | flaresolverr     | ~2026-04-28     | Folded into the arriman docker compose       |
-| 116 | heaper           | 2026-05-14      | Decommissioned by user; data subtree at `/mnt/library/heaper` (224 MiB) retained |
-| 126 | plato            | 2026-06-28      | Notes/discovery workspace decommissioned; data at `/mnt/library/documents/plato` retained for archaeology |
-| 123 | claudio-bot (destroyed — see [archive](archive/123-claudio-bot.md)) | 2026-06-04      | Replaced by Hermes Agent on mac-mini; monitoring migrated to `homelab-health-watchdog` cron. See [deprecation plan](../../../plans/done/2026-06-04_130000-deprecate-claudio-bot.md) |
-| 109 | syncthing        | 2026-05-14      | Decommissioned by user; `/mnt/library/syncthing` was already empty |
-| 125 | seafile          | 2026-05-13      | Seafile Pro evaluation, user disliked the product; teardown also removed `files.hubris.network` from caddy + dnsmasq |
-| 107 | marimo           | between 2026-04-21 and 2026-04-28 | Decommissioned                |
-| 110 | photoprism       | between 2026-04-21 and 2026-04-28 | Replaced by [mulita](120-mule-images.md) |
-| 111 | karakeep         | between 2026-04-21 and 2026-04-28 | Decommissioned                |
-| 112 | immich           | between 2026-04-21 and 2026-04-28 | Replaced by [mulita](120-mule-images.md) |
-| 115 | reticulum        | between 2026-04-21 and 2026-04-28 | Decommissioned                |
-
-> Several `.conf.bak` files survive under `/etc/pve/lxc/` if you need to recover any of the configs.
-
-## Conventions
-
-- All net0 are `bridge=vmbr0`, `ip=dhcp` except [124 (authentik)](106-auth-outpost.md) which is statically `192.168.8.180/24`. Containers on [strong](../hosts/strong.md) use `bridge=vmbr1` with static IPs in the `192.168.8.240/28` range.
-- `onboot=1` on every container — the host brings them up after `pve-guests.service`.
-- Bind mounts are declared as `mp0: /mnt/library,mp=/mnt/library` on hubris, or `mp0: /mnt/media_local,mp=/mnt/library` on strong.
-- Most containers are privileged. Unprivileged ones require an idmap block in their conf to participate in the [media GID 10000](../infrastructure/media-permissions.md) standard.
-
-## Related
-- [Hubris host](../hosts/hubris.md)
-- [Media permissions](../infrastructure/media-permissions.md)
-- [Caddy](121-caddy.md) — terminates every public hostname
-- [DNS](../infrastructure/dns.md) — split-horizon entries for each subdomain

archive/knowledge/hosts/hubris.md

@@ -1,162 +0,0 @@
-# `hubris` — Proxmox host
-
-Proxmox VE host running 1 VM and 13 LXC containers — the whole homelab's
-workloads still live here. As of 2026-07-01, hubris is node 1 of the 2-node
-`Homelab` cluster (see [Cluster](#cluster)); the second node is
-[strong](strong.md), which hosts nothing yet.
-
-## At a glance
-- **Role:** Proxmox VE 9.1.2 hypervisor (kernel `6.14.11-4-pve`)
-- **Hardware:** GMKtec NucBox M6 Ultra — AMD Ryzen 5 7640HS (Phoenix APU), 12 vCPU / ~28 GiB RAM, 2× Samsung 990 EVO Plus NVMe (one SSD primary, one for `library` LVM). 2× Realtek RTL8125 NICs (`r8169`).
-- **BIOS:** 1.02 (2025-08-06) — vendor not on LVFS, no automated update path. See [investigations](../../sources/investigations/archive/2026-04-21-hubris-crash-loop.md).
-- **Uplink:** `vmbr1` (slave: `eno1`) → SODOLA switch → Fritz!Box 7590. DHCP-reserved `192.168.178.10/24`, gateway `192.168.178.1`.
-- **Homelab bridge:** `vmbr0` — portless internal bridge, `192.168.8.77/24` + `192.168.8.1/24` alias (LXC default gateway). All 16 LXCs and the HAOS VM are on `vmbr0`. Proxmox routes between `vmbr0` and `vmbr1`; Fritz!Box has a static route `192.168.8.0/24 → 192.168.178.10`.
-- **WiFi:** disabled 2026-06-02 — `wlp3s0` removed from `/etc/network/interfaces`, wpa config deleted. Was used as a failover to the now-retired Slate AX AP.
-- **Mesh:** Netbird `wt0` `100.122.38.109/16`. Resolver: `100.122.38.109` (the local netbird daemon, which forwards to LAN/upstream and learns `*.hubris.network` answers via that path). See [mesh](../infrastructure/mesh.md).
-- **UI:** `https://proxmox.hubris.network` (via [caddy](../containers/121-caddy.md)) or `https://192.168.8.77:8006`.
-
-## Storage
-
-| Pool         | Type      | Size  | Use                                    |
-| ------------ | --------- | ----- | -------------------------------------- |
-| `local`      | dir       | ~95G  | ISOs, templates, `/etc`, configs       |
-| `local-lvm`  | lvmthin   | 856G  | LXC/VM rootfs                          |
-| `library`    | lvmthin   | 3.7T  | Backs `/mnt/library` ext4 (mounted as `/dev/mapper/library-library`) |
-
-`/mnt/library` holds the shared media + data pool: `anime`, `audiobooks`, `books`, `comics`, `documents`, `downloads`, `heaper`, `homecloud`, `images`, `marimo`, `movies`, `music`, `notes`, `podcasts`, `repos`, `roms`, `sophia`. Bind-mounted into every container that needs it. Permissions standard: [media GID 10000](../infrastructure/media-permissions.md).
-
-## Cluster
-
-Member of `Homelab`, a 2-node Proxmox cluster with [strong](strong.md)
-(cluster/OS hostname `strong`), formed 2026-07-01.
-
-- **Corosync ring0:** hubris's internal `192.168.8.77` (the `vmbr0` address).
-  strong reaches it via the existing Fritz!Box static route
-  (`192.168.8.0/24 → 192.168.178.10`) — no dedicated corosync link, just the
-  household LAN. Fine for a home cluster; not latency-isolated.
-- **Quorum:** 2 nodes, 1 vote each, no QDevice tiebreaker. Quorum needs both
-  votes — if either node is down (reboot, maintenance, network hiccup), the
-  survivor's running guests keep working but `/etc/pve` goes read-only:
-  no start/stop/create/edit until quorum returns. Decided to skip a QDevice
-  for now; revisit if hubris's periodic reboots (BIOS/thermal work, see
-  Quirks below) make this painful in practice.
-- **Storage:** `local` / `local-lvm` are the standard per-node default IDs
-  (every node has its own, not actually shared). The `library` lvmthin pool
-  is explicitly restricted to `nodes hubris` in `/etc/pve/storage.cfg` since
-  it's a physical thinpool that only exists on this host's hardware.
-- strong currently hosts no LXCs/VMs — it exists solely as a cluster
-  member so far. See [strong.md](strong.md) and the [library-SSD
-  migration plan](../../../.hermes/plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md)
-  for what comes next (physical drive move, service migration — not started).
-
-## Tenants
-
-### VMs
-- [108 — `haos-16.3`](../vms/108-haos.md) — Home Assistant OS, 4 GiB / 32 GiB
-
-### LXC containers
-See [containers/index](../containers/index.md). 10 active on hubris (101, 118, 122, 129, 130 migrated to [strong](strong.md) 2026-07-05).
-
-## Boot-time tuning (load-bearing)
-
-- **TCP BBR + `fq` qdisc** in `/etc/sysctl.d/99-bbr.conf`: `net.ipv4.tcp_congestion_control=bbr`, `net.core.default_qdisc=fq`, socket buffers up to 64 MiB (`rmem_max`/`wmem_max`/`tcp_rmem`/`tcp_wmem`). `tcp_bbr` module pinned to load at boot via `/etc/modules-load.d/bbr.conf`. Improves single-TCP-stream throughput on jittery / lossy links (notably WiFi clients downloading from [114 — nextcloud](../containers/114-nextcloud.md)). Container traffic crosses this kernel, so every guest inherits the change.
-- **`cpu-epp.service`** (enabled) sets `scaling_governor=powersave` + EPP=`balance_power` at boot — drops idle Tctl from ~95 °C → ~60 °C, clocks from 4.4 GHz pinned → 1.1–2 GHz idle. In `amd-pstate=active` mode the governor MUST be `powersave`, not `performance`, for EPP to apply. Unit ordering: `After=sysinit.target` + `Before=pve-guests.service` so it runs before the guest fleet starts (the original `After=multi-user.target` left the hottest boot window on `performance`). Fixed 2026-04-22.
-- **Crash capture:** `/etc/sysctl.d/60-crash-capture.conf` (panic on oops/hardlockup/softlockup/rcu, auto-reboot 10 s), `/etc/modprobe.d/softdog.conf` (`soft_panic=1 soft_margin=60`), `/etc/systemd/system.conf.d/watchdog.conf` (`RuntimeWatchdogSec=15s`). Pstore traces collected to `/var/lib/systemd/pstore/` by `systemd-pstore.service`. **Caveat:** silent CPU lockups leave pstore empty.
-- **`rasdaemon`** (Debian pkg) collects MCE / memory / PCIe AER / thermal events to `/var/lib/rasdaemon/ras-mc_event.db`. Query with `ras-mc-ctl --summary` / `--errors`. (mcelog is retired in Debian 13 — don't go looking for it.)
-
-## Network performance baseline (2026-05-14)
-
-| Path | Throughput | Notes |
-| ---- | ---------- | ----- |
-| WAN (Ookla, from host) | ↓ 113.5 Mbit/s · ↑ 19.9 Mbit/s · 24.6 ms | Asymmetric residential link. 20 Mbit upload is the cap for public ingress (artifacto, blog via VPS traefik). |
-| `eno1` link | 1000 Mbit/s, Full duplex | Negotiated correctly to router. |
-| Host → LXC over `vmbr0` | **34.7 Gbit/s** | Single TCP stream, iperf3 10 s, 0 retransmits. |
-| LXC → LXC over `vmbr0` | **34.8 Gbit/s** | Single TCP stream, iperf3 5 s, 0 retransmits. |
-
-Intra-host throughput is memory-bandwidth bound — not a bottleneck for any current workload.
-
-**eno1 error counters** (uptime 14 d 6 h at measurement time): `tx_packets` 99.99 M / `rx_packets` 96.08 M; `rx_errors` 1,619,203 (~1.7 % of RX); `align_errors` 10,919; `tx_errors` 20. The 1.6 M rx_errors in 14 days is the noteworthy datapoint — likely cable / switch-port. Re-check this counter in ~1 week and confirm it is not still climbing at the same rate; if it is, swap the patch cable first.
-
-## Host services owned by external repos
-
-| What                              | Repo                       | Path on host                  |
-| --------------------------------- | -------------------------- | ----------------------------- |
-| `claudio-monitor` (5-min watchdog) | `dtoro/claudio-monitor`   | `/opt/claudio-monitor`        |
-| `backup-library` (restic)         | `dtoro/backup-library`     | `/opt/backup-library` *(disabled)* |
-| `hubris-public-cert-sync`         | (script + systemd unit)    | `/usr/local/bin/hubris-public-cert-sync.sh`, daily timer |
-
-See [monitoring](../infrastructure/monitoring.md), [backups](../infrastructure/backups.md), [ingress](../infrastructure/ingress.md).
-
-## Quirks
-
-- `/etc/pve` is fuse — the Proxmox cluster filesystem, now genuinely cluster-synced (2-node) rather than the single-node-but-still-fuse case this note used to describe.
-- ZFS is **not** in use; storage is LVM-thin + ext4.
-- Two Realtek 8125 NICs use the in-tree `r8169` driver, not the OOT `r8125`.
-- Hardware is thermally marginal. NVMe sensors live near warn temp under load. Thermal pads installed on the SSDs 2026-04-23; host relocated to a better-ventilated spot 2026-04-29.
-- Non-ECC RAM: silent memory faults are possible; suspect DIMMs if `cpu-epp` is on and crashes still happen.
-- BIOS update path requires a Windows-To-Go USB (no LVFS, no Linux flasher).
-
-## Authorized SSH keys (root)
-
-- `root@hubris` (self, RSA) — local
-- `d.toro.v@pm.me` (ed25519) — user's iMac, added 2026-04-22
-- `root@strong` (RSA) — strong's cluster-join key, added 2026-07-01 so
-  `pvecm add` could authenticate without a password prompt
-
-OpenSSH on `0.0.0.0:22`. Netbird's built-in SSH server is on `100.122.38.109:22022` and bypasses `authorized_keys` (OIDC/browser). See [SSH access](../infrastructure/ssh-access.md) for the dual-server gotcha.
-
-## Related
-- [Containers index](../containers/index.md)
-- [DNS split-horizon](../infrastructure/dns.md)
-- [Caddy reverse proxy](../containers/121-caddy.md)
-- [Mesh / Netbird](../infrastructure/mesh.md)
-- [Media permissions](../infrastructure/media-permissions.md)
-- [Monitoring](../infrastructure/monitoring.md)
-- [Backups (disabled)](../infrastructure/backups.md)
-- [Operations cheatsheet](../../../.agents/operations/commands.md)
-- [Investigation: 2026-04-21 crash loop](../../sources/investigations/archive/2026-04-21-hubris-crash-loop.md)
-- [strong — Proxmox host](strong.md)
-
-## Changelog
-
-### 2026-07-01 — strong joined as a 2nd cluster node ("Homelab")
-User reformatted `strong` (formerly a Linux dev workstation, `192.168.178.181`) to Proxmox VE 9.2.3. Cluster/OS hostname on that box is `strong` (left as-is from install). Bootstrapped root SSH on strong from a one-time console password (installed hubris's existing trusted key set: `root@hubris`, `d.toro.v@pm.me`), then generated a keypair on strong and pre-authorized it here (`root@strong`) so `pvecm add 192.168.8.77 --use_ssh 1` (run from strong) could join without an interactive password prompt. No cabling/routing changes needed — strong reaches hubris's corosync address (`192.168.8.77`) via the existing Fritz!Box static route. Cluster now 2 nodes, quorate, **no QDevice** (explicit choice — see [Cluster](#cluster) above for the quorum tradeoff this implies). strong hosts no guests yet; this is Phase 1 of the [library-SSD migration plan](../../../.hermes/plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md), nothing further from that plan has been executed.
-
-### 2026-06-02 — Slate AX retired; SODOLA switch added; network restructured
-Replaced GL.iNet Slate AX sub-router with SODOLA 5-Port 2.5Gbit managed switch. Fritz!OS 8.x lacks second-IP-network support on LAN ports, so Proxmox now acts as the subnet router: `vmbr1` (eno1 → SODOLA → Fritz!Box) is the uplink at `192.168.178.10/24`; `vmbr0` is a portless internal bridge holding all LXCs/VMs with `192.168.8.1` as an alias (unchanged LXC gateway). Fritz!Box static route `192.168.8.0/24 → 192.168.178.10` enables inbound routing. No LXC configs changed. Eliminated double-NAT. WiFi (`wlp3s0`) also removed — was pointing at the Slate AX SSID, no longer useful. See [network](../infrastructure/network.md) and [migration plan](../../../plans/done/2026-06-01-slate-ax-to-sodola-migration.md).
-
-### 2026-05-14 — LXC 109 (syncthing) decommissioned
-User destroyed the syncthing LXC (had been stopped since 2026-04-21, never re-enabled). `pct destroy 109 --purge` cleaned `vm-109-disk-0` on `local-lvm` and the `/etc/pve/lxc/109.conf` entry. Data subtree `/mnt/library/syncthing` was already empty and retained as an empty dir. No DNS, Caddy, NFS-export, or claudio-monitor references to clean up. Entry moved to the "recently destroyed" table in [containers/index](../containers/index.md#recently-destroyed-kept-for-archaeology); references stripped from [README](../../../README.md), [media-permissions](../infrastructure/media-permissions.md), [vms/100-zimaos](../vms/100-zimaos.md), and [containers/102-nfs-export](../containers/102-nfs-export.md).
-
-### 2026-05-14 — network performance baseline captured
-First explicit speed snapshot: WAN ↓113.5 / ↑19.9 Mbit (24.6 ms), `eno1` 1 Gb full-duplex negotiated, intra-host `vmbr0` ~34.7 Gbit/s host↔LXC and ~34.8 Gbit/s LXC↔LXC (single TCP stream, zero retransmits). `iperf3` + `speedtest-cli` installed on host. Noted `eno1` `rx_errors` at 1.62 M (~1.7 % of 96 M RX packets in 14 d uptime) plus 10.9 k `align_errors` — flagged for follow-up; expect to recheck the trend in ~1 week, suspect patch cable / switch port first if still climbing. See new "Network performance baseline" section above.
-
-### 2026-05-14 — LXC 116 (heaper) decommissioned
-User destroyed the heaper LXC. No `116.conf.bak` left behind in `/etc/pve/lxc/`. Data subtree `/mnt/library/heaper` (224 MiB) retained for archaeology — see [containers/index](../containers/index.md#recently-destroyed-kept-for-archaeology) and [media-permissions](../infrastructure/media-permissions.md).
-
-### 2026-05-13 — TCP BBR + fq qdisc enabled
-`/etc/sysctl.d/99-bbr.conf` switches `net.ipv4.tcp_congestion_control` from `cubic` to `bbr` and `net.core.default_qdisc` from `fq_codel` to `fq`. Also bumps `rmem_max`/`wmem_max` to 64 MiB and widens `tcp_rmem`/`tcp_wmem`. `tcp_bbr` module pinned at boot via `/etc/modules-load.d/bbr.conf`. Triggered by Nextcloud client downloads from a WiFi laptop pulling ~2 MB/s despite a 152 Mbps link — server-side baseline through Caddy with BBR is ~400 MB/s single-stream loopback, so any client-perceived single-stream improvement is pure congestion-control win. Touches every LXC's outbound TCP since they all share this kernel.
-
-### 2026-04-29 — relocated to better-ventilated spot
-User physically moved the host to a new location with improved airflow. Post-move idle baseline (45 min uptime, light load): k10temp Tctl **47.2 °C**, amdgpu edge 42 °C, nvme0 composite 34.9 °C / sensor1 32.9 °C, nvme1 composite 38.9 °C / sensor1 52.9 °C, DRAM 34–35.5 °C, ACPI zone 47–49 °C. Compares well against the 2026-04-23 thermal-pad steady-state (nvme0 sensor1 60–61 °C). Watch the lifetime NVMe warning-time counter over the coming days for confirmation. See [investigation](../../sources/investigations/archive/2026-04-21-hubris-crash-loop.md#2026-04-29-physical-relocation).
-
-### 2026-04-28 — Phase 1 WiFi failover
-Host now dual-homed: LAN `192.168.8.77` (primary) + WiFi `192.168.8.141` (failover, metric 200) on the GL-AXT1800-714-5G AP. Installed `wpasupplicant`+`iw`; added `wlp3s0` stanza to `/etc/network/interfaces` with `wpa-conf`; ARP isolation sysctls in `post-up`. Built `wan-failover.service` to remove the vmbr0 default route on `eno1` carrier loss, since the bridge's carrier doesn't follow `eno1` (the LXC veths keep it `1`). LXC/VM guests are still LAN-only — Phase 2 will migrate them.
-
-### 2026-04-28 — wiki started
-This wiki created. Live state at this date: 14 LXCs running (109 syncthing stopped), 1 VM, kernel `6.14.11-4-pve`, uptime 3 d 0 h post drive-removal A/B test. Compared to memory snapshot from a week ago, **destroyed**: LXC 100 (yunohost arr), 106 (flaresolverr), 107 (marimo), 110 (photoprism), 111 (karakeep), 112 (immich), 115 (reticulum). 100 + 106 destroyed per the planned 2026-04-21 \*arr migration retention; the others removed since.
-
-### 2026-04-23 — SSD cooling + thermal pads installed
-Thermal pads on both NVMe drives. Steady-state nvme0 composite 47 °C / sensor1 60–61 °C, nvme1 38–40 °C. Zero new warning-time minutes after install. Watch the lifetime warning-time counter going forward, not absolute sensor1. See [investigation](../../sources/investigations/archive/2026-04-21-hubris-crash-loop.md#2026-04-23-thermal-pad-verdict).
-
-### 2026-04-22 — drive removal A/B test
-Removed external USB backup drive (Silicon Motion `090c:2320`). Disabled the four `backup-library*.timer` units, commented the fstab entry. Goal: confirm whether the drive + UAS interaction on the AMD USB4 PCIe tunnel is the dominant root cause of the silent hard-locks. Pre-drive uptime was 33 days; with drive, repeated crashes despite UAS blacklist + mount-on-demand. **Result so far:** 3+ days uptime — the drive looks like the primary contributor; `cpu-epp` remains as belt-and-suspenders thermal protection. See [investigation](../../sources/investigations/archive/2026-04-21-hubris-crash-loop.md).
-
-### 2026-04-22 — `cpu-epp.service` ordering bug fixed
-Was `After=multi-user.target` + `WantedBy=multi-user.target` — queued behind `pve-guests.service`, so the hottest boot window (20+ guests starting on `performance`) preceded EPP application. Now `After=sysinit.target` + `Before=pve-guests.service`.
-
-### 2026-04-21 — crash-capture + RAS telemetry enabled
-`60-crash-capture.conf`, softdog `soft_panic=1`, RuntimeWatchdog 15 s. `rasdaemon` installed and enabled. Pure silicon hangs still leave no trace; this catches everything else.
-
-### 2026-04-21 — `cpu-epp.service` deployed
-Pinned governor=`powersave`, EPP=`balance_power` at boot. Stopped the host idling at ~95 °C with everything pinned at 4.4 GHz. First fix in the [crash-loop incident](../../sources/investigations/archive/2026-04-21-hubris-crash-loop.md).

archive/knowledge/hosts/index.md

@@ -1,9 +0,0 @@
-# Hosts
-
-The two Proxmox VE nodes that run the fleet. Narrative pages; the machine-readable host records are
-the generated `hosts/*.yaml` files at the repo root.
-
-| Document | What it covers |
-|----------|----------------|
-| [hubris.md](hubris.md) | Primary PVE node (GMKtec NucBox M6 Ultra, `192.168.8.77`) — runs most LXCs plus the VMs. |
-| [strong.md](strong.md) | Secondary PVE node / cluster member (`192.168.178.181`) — hosts the LXCs migrated from hubris. |

archive/knowledge/hosts/strong.md

@@ -1,159 +0,0 @@
-# `strong` — Proxmox host
-
-Second node in the `Homelab` cluster, alongside [hubris](hubris.md). Formerly
-a Linux dev workstation nicknamed "ludo" (or "ludo-mini") — reformatted to
-Proxmox VE on 2026-07-01. No LXCs/VMs deployed on it yet.
-
-## At a glance
-
-- **Role:** Proxmox VE 9.2.3 cluster member (kernel `7.0.12-1-pve`) — hosts [7 LXCs](../containers/index.md) migrated from hubris (Phase 1+2, 2026-07-05)
-- **Naming:** the OS/cluster hostname is `strong` (leftover from install,
-  kept as-is). This wiki page and `inventory.yaml` also use `strong` as of
-  2026-07-01 — earlier the same day the inventory entry was briefly named
-  `ludo-mini`, but that was renamed so the hostname bootstrap needs
-  (`hosts/$(hostname).yaml`) would just resolve. "Ludo"/"ludo-mini" remains
-  the machine's everyday nickname; some older docs (investigations, the
-  library-SSD migration plan) still refer to it that way — that's fine,
-  those are historical.
-- **Hardware:** AMD Ryzen 7 PRO 6850U, 16 threads, 28 GiB RAM.
-  - `nvme0n1` — MasonSemi MC3100 1TB (boot/OS): `pve-root` 96G, `pve-data`
-    (thinpool) 815G, 8G swap.
-  - `nvme1n1` — WD_BLACK SN7100 2TB, added 2026-07-01. Arrived with an
-    existing APFS partition (previously used in a Mac) — wiped via
-    `pvesh set nodes/strong/disks/wipedisk --disk /dev/nvme1n1`, then turned
-    into its own LVM-thin pool via `pvesh create nodes/strong/disks/lvmthin`
-    (handles pvcreate/vgcreate/lvcreate + storage.cfg registration in one
-    step). Registered as Proxmox storage `ludo-lvm` (VG `ludo-lvm`, thinpool
-    `ludo-lvm`, ~1.8 TiB usable — kept the `ludo-lvm` name since that's what
-    was actually created live; not worth renaming), restricted `nodes strong`
-    in `/etc/pve/storage.cfg` — same pattern as hubris's `library` pool.
-    Empty so far; this is separate from the [library-SSD migration
-    plan](../../../.hermes/plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md)'s
-    planned drive move from hubris (that hasn't happened) — this is
-    general-purpose VM/CT capacity.
-- **Network:** `vmbr0` is bridged straight onto the household LAN —
-  `192.168.178.181/24`, gateway `192.168.178.1`. Unlike hubris, there is no
-  internal/uplink bridge split yet — `vmbr0` here plays the role hubris's
-  `vmbr1` plays there. Reachable from the homelab subnet (`192.168.8.0/24`)
-  via the existing Fritz!Box static route through hubris; no new cabling
-  or routing was needed to join the cluster.
-- **Storage:** `local` + `local-lvm` (cluster-wide default names, shared
-  with hubris by convention, actually separate per-node volumes). Hubris's
-  `library` lvmthin pool is restricted to `nodes hubris` in
-  `/etc/pve/storage.cfg` and does not exist here.
-- **Mesh:** Netbird not installed — fresh OS wiped whatever the old
-  workstation had. Reachable today only via LAN routing (confirmed DNS for
-  `*.hubris.network` already resolves correctly here via `192.168.8.2`).
-  Add to Netbird if off-LAN access to this host itself (distinct from any
-  future guests) is needed.
-- **Homelab-context client enrollment:** done 2026-07-01 via
-  `bootstrap.sh --no-secrets` (reused the operator's existing Gitea PAT for
-  the initial clone). `/opt/homelab-context`, the `homelab` CLI, and the
-  5-min sync timer are live; `homelab whoami` resolves correctly. See
-  [agent-enrollment.md](../../../.agents/operations/agent-enrollment.md).
-- **Age key / secrets:** issued the same day over plain LAN (no Netbird
-  needed — see the `--no-mesh` bootstrap.sh fix below). Key lives at
-  `/etc/age/key.txt`; pubkey `age1rtwvdct6avjkr3cyxv3vue3vqx4d524fjfr3vk7xrnvyrylnry5sm54sn4`
-  recorded in `inventory.yaml`. Not yet a recipient on any actual secret
-  (`hello.yaml`, `gitea-pat.yaml`, etc.) — that's a separate grant, see
-  ["Granting a secret to a new client"](../../../.agents/operations/agent-enrollment.md#granting-a-secret-to-a-new-client).
-
-## Cluster membership
-
-Joined hubris's single-node cluster (`Homelab`) via `pvecm add` on
-2026-07-01. See [hosts/hubris.md#cluster](hubris.md#cluster) for the full
-cluster picture, node IDs, and the quorum tradeoff (2 nodes, no QDevice —
-either node going down freezes management on the survivor).
-
-## SSH
-
-Root login via the same key set trusted on hubris (`root@hubris`,
-`d.toro.v@pm.me`) — installed 2026-07-01 by appending to
-`/root/.ssh/authorized_keys` (now symlinked to `/etc/pve/priv/authorized_keys`
-post cluster-join, so it's cluster-synced same as hubris). No password auth
-needed going forward.
-
-## Related
-
-- [hubris — Proxmox host](hubris.md)
-- [Library SSD migration plan](../../../.hermes/plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md) — the larger project this is Phase 1 of (filename kept as-is, historical)
-- [Network](../infrastructure/network.md)
-- [SSH access](../infrastructure/ssh-access.md)
-- [Agent enrollment](../../../.agents/operations/agent-enrollment.md)
-
-## Changelog
-
-### 2026-07-05 — Phase 2d: grimmory (130) migrated to strong
-Migrated book library from hubris (192.168.8.213) to strong (192.168.8.247).
-Rsync'd /books (2.6G) from hubris library SSD to ludo-lvm/media. Container
-mounts /mnt/media_local → /mnt/library locally. Caddy backend for
-books.hubris.network updated.
-
-### 2026-07-05 — Phase 2: arriman (122) + jellyfin (101) migrated; library on ludo-lvm
-Migrated arriman (→ 192.168.8.245) and jellyfin (→ 192.168.8.246) to strong.
-Created 1.5T thin volume on ludo-lvm for media library (/mnt/media_local).
-Rsync'd 363G of media data (movies, tv, anime, downloads, music) from hubris
-library SSD to ludo-lvm. Both containers now mount /mnt/media_local directly
-as local ext4 — no NFS cross-node dependency. Jellyfin gets Radeon 680M iGPU
-(for VAAPI) + RX 7600 dGPU passthrough via dev0/dev1. Caddy backends updated
-for media, jellyseerr, qbit, sab. Hubris freed 16 GiB RAM (8+8).
-Dhcp scope narrowed to 192.168.8.100-239.
-
-### 2026-07-05 — house (LXC 129) migrated to strong; DHCP scope narrowed
-Migrated Yuvomi family planner from hubris (192.168.8.212) to strong
-(192.168.8.244). Followed same restore pattern as elementsynapse (Phase 1b).
-Discovered IP conflict: teddycloud (LXC 131) had 192.168.8.243 via DHCP
-(scope was 192.168.8.241-254). Narrowed DHCP scope to 192.168.8.100-239,
-gave teddycloud static IP 192.168.8.150. Caddy updated: house.hubris.network
-→ 192.168.8.244:3000, teddy.hubris.network → 192.168.8.150:8443.
-
-### 2026-07-05 — elementsynapse (LXC 118) migrated to strong
-Migrated Matrix/Synapse + Element client from hubris (192.168.8.239) to a new
-LXC on strong (192.168.8.242). Added vmbr1 on strong at 192.168.8.241/28
-(portless internal bridge) for strong-hosted guests. Enabled IP forwarding,
-proxy ARP on hubris vmbr0, and specific /32 routes for strong's guest subnet.
-Caddy updated: element.hubris.network → 192.168.8.242:8080.
-VPS traefik updated: matrix.hubris.network backend → 192.168.8.242:8008.
-This is Phase 1a of the strong migration plan — see .hermes/plans/2026-07-05_strong-migration-assessment.md.
-
-### 2026-07-01 — age key issued over LAN; 3 bugs found/fixed in bootstrap.sh
-Re-ran bootstrap without `--no-secrets` to get a real age key. Hit three real bugs live, fixed all three in `bootstrap.sh` and re-ran clean:
-1. The `mcp`-CLI pipx-install step and the (unused, `--with-hermes`-only) Goose installer both called `sudo -u <user>` unconditionally — fails with "sudo: command not found" on a minimal root-only image with no `sudo` binary at all. Added a `run_as()` helper that only shells out to `sudo` when there's a real distinct invoking user.
-2. `sops` isn't an apt/dnf package (matches what `agent-enrollment.md`'s manual-install recipe already does) — the auto-installer tried `apt-get install sops` and failed outright. Added `install_sops_binary()`, fetching the GitHub release binary directly on both dnf and apt paths.
-3. Bigger one: running without `--no-secrets` unconditionally tries to install + interactively connect Netbird (device-code SSO), even though the very next check already knows how to accept plain LAN reachability instead. Over SSH with nobody watching, this hangs forever — had to manually kill a stuck `netbird up` process. Added `--no-mesh`, which skips the Netbird install/connect step but keeps the LAN-fallback path for secrets issuance. This run used `bootstrap.sh --no-mesh` and completed cleanly: `mesh: lan`, age key installed, `mcp` CLI installed via pipx (proving fix #1 too).
-
-Result: age key at `/etc/age/key.txt`, pubkey recorded in `inventory.yaml`. Not yet granted access to any actual secret file — see the note above.
-
-### 2026-07-01 — enrolled as a homelab-context client
-Ran `bootstrap.sh --no-secrets` (reused the operator's existing personal Gitea PAT for the initial clone rather than minting a fresh read-only one). Installed git, cloned `/opt/homelab-context`, installed the 5-min systemd sync timer, symlinked `homelab` CLI and `AGENTS.md`. Skipped age-key/secrets issuance and Netbird per operator choice — but bootstrap's own connectivity check reported `mesh: lan`, i.e. the secrets-issuance endpoint is already reachable over plain LAN, so re-running without `--no-secrets` later wouldn't require a Netbird join. Known gap: the `mcp` pipx CLI install step silently failed (`sudo: command not found` — bootstrap.sh's pipx step assumes a `sudo` binary even when already root; harmless, only affects the `homelab mcp <tool>` shell subcommand).
-
-### 2026-07-01 — inventory identity renamed ludo-mini → strong
-Discovered while starting client enrollment: `bootstrap.sh` looks up
-`hosts/$(hostname).yaml`, and the OS hostname here is `strong`, not
-`ludo-mini`. Renaming the OS hostname was ruled out (already a cluster
-member — Proxmox doesn't support in-place node rename, only leave+rejoin).
-Renamed the wiki/inventory side instead: `inventory.yaml` key, this page
-(`hosts/ludo-mini.md` → `hosts/strong.md`), README, ssh-access.md all now
-say `strong`. "Ludo"/"ludo-mini" is still fine as a spoken nickname.
-
-### 2026-07-01 — 2nd NVMe added; new LVM-thin pool `ludo-lvm`
-User added a WD_BLACK SN7100 2TB (`nvme1n1`), previously used in a Mac
-(arrived with an EFI + APFS partition table — confirmed disposable, wiped).
-Used Proxmox's own disk-management API rather than raw LVM commands:
-`pvesh set nodes/strong/disks/wipedisk --disk /dev/nvme1n1` to clear the old
-partition table/signatures, then `pvesh create nodes/strong/disks/lvmthin
---name ludo-lvm --device /dev/disk/by-id/nvme-WD_BLACK_SN7100_2TB_251663803202
---add_storage 1` to create the PV/VG/thinpool and register it as Proxmox
-storage in one step. Result: storage ID `ludo-lvm`, ~1.8 TiB, `content
-rootdir,images`, `nodes strong` (mirrors hubris's `library` node-restriction
-pattern — this pool only physically exists here). Empty — no VM/CT disks
-placed on it yet.
-
-### 2026-07-01 — Proxmox install; joined Homelab cluster
-Reformatted from Linux workstation to Proxmox VE 9.2.3. SSH keys seeded from
-hubris's trusted set (root password used once, then discarded). Joined the
-existing `Homelab` cluster via `pvecm add 192.168.8.77 --use_ssh 1` from
-this node's side, using key-based SSH pre-authorized in both directions —
-no interactive password prompt needed for the join itself. Cluster now 2
-nodes (`hubris`, `strong`), quorate, no QDevice. Decided to leave hostname
-as `strong` and skip a QDevice for now — both revisitable later.

archive/knowledge/index.md

@@ -1,14 +0,0 @@
-# Knowledge
-
-The durable, authoritative current-state documentation of the homelab: one page per node and per
-cross-cutting system, synthesized from live state and evidence. Structure and rules are in
-[the knowledge schema](../.agents/domains/knowledge/schema.md).
-
-| Section | What it covers |
-|---------|----------------|
-| [wiki/hosts/](wiki/hosts/index.md) | Proxmox host narratives — `hubris`, `strong`. |
-| [wiki/containers/](wiki/containers/index.md) | LXC fleet — one page per container, plus the master table and archaeology. |
-| [wiki/vms/](wiki/vms/index.md) | Virtual machines — ZimaOS, Home Assistant OS. |
-| [wiki/infrastructure/](wiki/infrastructure/index.md) | Cross-cutting systems — DNS, ingress, mesh, storage, auth, monitoring, generated topology. |
-| [sources/](sources/index.md) | External reference docs and the pointer to incident evidence. |
-| [GLOSSARY.md](GLOSSARY.md) | Term definitions. |

archive/knowledge/infrastructure/index.md

@@ -1,66 +0,0 @@
-# Infrastructure — cross-cutting systems
-
-The homelab's shared infrastructure: systems that span multiple nodes and
-are documented in their own pages. Each system below links to its full doc.
-
-## Network
-
-- **[Network](network.md)** — physical topology, subnets, routing, DHCP.
-  Homelab `192.168.8.0/24` isolated from household `192.168.178.0/24`.
-  Proxmox hubris acts as subnet router.
-- **[DNS — split-horizon](dns.md)** — Technitium DNS on LXC 107,
-  `192.168.8.2:53`. `*.hubris.network` resolves to LAN IPs on the homelab
-  network and to mesh addresses off-LAN.
-
-## Connectivity / mesh
-
-- **[Mesh — Tailscale → Netbird migration](mesh.md)** — overlay networking.
-  Netbird is the preferred path; Tailscale is legacy.
-- **[SSH access](ssh-access.md)** — dual-server SSH (OpenSSH + Netbird SSH)
-  on hubris, key distribution.
-
-## Public ingress
-
-- **[Public ingress — VPS traefik + cert mirror](ingress.md)** — how home
-  services reach the open internet. Two-stage: VPS traefik (IONOS) terminates
-  TLS, proxies over Netbird to home Caddy.
-- **[Caddy reverse proxy](../containers/121-caddy.md)** — LAN endpoint.
-  Terminates TLS for every `*.hubris.network` hostname, forwards to backends.
-
-## Storage
-
-- **[Media permissions — GID 10000 standard](media-permissions.md)** — shared
-  group permission model across all LXCs that read/write the media library.
-- **[Backups — rclone → Proton Drive](backups.md)** — off-host backup strategy.
-  LXC 132 handles rclone to Proton Drive; restic-on-USB deprecated.
-
-## Identity & access
-
-- **[Authentik SSO](../containers/106-auth-outpost.md)** — identity provider.
-  Core server runs on the VPS; LAN forward-auth outpost at LXC 106.
-  OIDC providers configured for Jellyfin, Jellyseerr, Sabnzbd, qBittorrent,
-  Yuvomi, and more.
-
-## Management & automation
-
-- **[Homelab context distribution](homelab-context.md)** — `/opt/homelab-context`
-  clone, MCP server, secrets issuance, cross-client sync.
-- **[Auto-deploy — gitea-webhook pipelines](auto-deploy.md)** — push-to-deploy
-  for Caddy config, mule-image, and other tracked repos.
-- **[Monitoring](monitoring.md)** — health checks, watchdogs, alerting
-  (migrated from claudio-bot to Hermes cron).
-- **[VPS hardening](vps-hardening.md)** — IONOS netbird VPS: fail2ban,
-  nftables, OIDC SSH, security posture.
-
-## Topology
-
-- **[Topology diagram (generated)](topology.md)** — Mermaid graph of compute,
-  ingress routing, and storage mounts. Auto-generated from `inventory.yaml`
-  by `oikos/gen-topology.py` (Python — Go DB-native replacement planned).
-
-## Related
-
-- [README](../../../README.md) — entry point
-- [Containers index](../containers/index.md)
-- [Operations cheatsheet](../../../.agents/operations/commands.md)
-- [OIKOS operating model](../../../.agents/OIKOS.md)

archive/knowledge/infrastructure/topology.md

@@ -1,96 +0,0 @@
-<!-- Generated by oikos/gen-topology.py from inventory.yaml. -->
-<!-- Do NOT edit by hand - your changes will be overwritten. -->
-
-# Topology (generated)
-
-Source: [inventory.yaml](../../../inventory.yaml) — 2 hypervisors, 20 LXCs, 2 VMs, 2 workstations, 18 services.
-Edge semantics: [oikos/ontology.yaml](../../../oikos/ontology.yaml). Operating model: [OIKOS.md](../../../.agents/OIKOS.md).
-
-## Compute & ingress
-
-```mermaid
-flowchart LR
-    subgraph hubris_sub["hubris (Proxmox)"]
-        trmnl["trmnl<br/>LXC 128<br/>trmnl-middleware<br/>192.168.8.211"]
-        nfs_export["nfs-export<br/>LXC 102<br/>storage-export<br/>192.168.8.200"]
-        paperless["paperless<br/>LXC 103<br/>document-archive<br/>192.168.8.130"]
-        gitea["gitea<br/>LXC 104<br/>git-server<br/>192.168.8.121"]
-        apps["apps<br/>LXC 105<br/>docker-apps<br/>192.168.8.205"]
-        auth_outpost["auth-outpost<br/>LXC 106<br/>authentik-gateway<br/>192.168.8.6"]
-        dns["dns<br/>LXC 107<br/>dns-server<br/>192.168.8.2"]
-        nextcloud["nextcloud<br/>LXC 114<br/>file-sync<br/>192.168.8.224"]
-        sophia["sophia<br/>LXC 119<br/>workshop<br/>192.168.8.109"]
-        mule_images["mule-images<br/>LXC 120<br/>photo-management<br/>192.168.8.136"]
-        caddy["caddy<br/>LXC 121<br/>reverse-proxy<br/>192.168.8.175"]
-        teddycloud["teddycloud<br/>LXC 131<br/>teddycloud<br/>192.168.8.150"]
-        zimaos["zimaos<br/>VM 100<br/>nas-frontend-eval<br/>192.168.8.195"]
-        haos["haos<br/>VM 108<br/>home-automation<br/>192.168.8.101"]
-    end
-    subgraph strong_sub["strong (Proxmox)"]
-        house["house<br/>LXC 129<br/>family-planner<br/>192.168.8.244"]
-        jellyfin["jellyfin<br/>LXC 101<br/>media-server<br/>192.168.8.246"]
-        elementsynapse["elementsynapse<br/>LXC 118<br/>matrix-server<br/>192.168.8.242"]
-        arriman["arriman<br/>LXC 122<br/>arr-stack<br/>192.168.8.245"]
-        grimmory["grimmory<br/>LXC 130<br/>book-library<br/>192.168.8.247"]
-        seanime["seanime<br/>LXC 133<br/>anime-media-server<br/>192.168.8.248"]
-        romm["romm<br/>LXC 134<br/>rom-manager<br/>192.168.8.249"]
-    end
-    rclone["rclone<br/>lxc<br/>backup"]
-    republic_laptop([republic-laptop<br/>workstation<br/>primary-dev])
-    mac_mini([mac-mini<br/>workstation<br/>dev<br/>192.168.178.182])
-    netbird_vps[[netbird-vps<br/>external<br/>netbird-mgmt]]
-    url_artifacto(["artifacto.hubris.network"]) -->|routes-to| apps
-    url_authentik(["auth.hubris.network"]) -->|routes-to| netbird_vps
-    url_gitea(["git.hubris.network"]) -->|routes-to| gitea
-    url_homelab_mcp(["mcp.hubris.network"]) -->|routes-to| apps
-    url_jellyfin(["media.hubris.network"]) -->|routes-to| jellyfin
-    url_matrix(["matrix.hubris.network"]) -->|routes-to| elementsynapse
-    url_nextcloud(["cloud.hubris.network"]) -->|routes-to| nextcloud
-    url_paperless(["paperless.hubris.network"]) -->|routes-to| paperless
-    url_photos(["photos.hubris.network"]) -->|routes-to| mule_images
-    url_proxmox_ui(["proxmox.hubris.network"]) -->|routes-to| hubris_sub
-    url_secrets_issuance(["secrets.hubris.network"]) -->|routes-to| apps
-    url_teddycloud(["teddy.hubris.network"]) -->|routes-to| teddycloud
-    url_trmnl(["trmnl.hubris.network"]) -->|routes-to| trmnl
-    url_zimaos(["zimaos.hubris.network"]) -->|routes-to| zimaos
-```
-
-## Storage (mounts)
-
-```mermaid
-flowchart LR
-    mnt_library[("/mnt/library")]
-    mnt_media_local[("/mnt/media_local")]
-    mnt_media_local_anime[("/mnt/media_local/anime")]
-    apps["apps"] -->|mounts| mnt_library
-    arriman["arriman"] -->|mounts| mnt_media_local
-    gitea["gitea"] -->|mounts| mnt_library
-    grimmory["grimmory"] -->|mounts| mnt_media_local
-    hubris["hubris"] -->|mounts| mnt_library
-    jellyfin["jellyfin"] -->|mounts| mnt_media_local
-    mule_images["mule-images"] -->|mounts| mnt_library
-    nextcloud["nextcloud"] -->|mounts| mnt_library
-    paperless["paperless"] -->|mounts| mnt_library
-    romm["romm"] -->|mounts| mnt_media_local
-    seanime["seanime"] -->|mounts| mnt_media_local_anime
-    sophia["sophia"] -->|mounts| mnt_library
-    teddycloud["teddycloud"] -->|mounts| mnt_library
-```
-
-## Archaeology (destroyed nodes)
-
-| Node | ID | Destroyed | Reason |
-|---|---|---|---|
-| plato | 126 | 2026-06-28 | notes workspace decommissioned; data retained at /mnt/library/documents/plato |
-| claudio-bot | 123 | 2026-06-04 | replaced by Hermes Agent on mac-mini; monitoring moved to homelab-health-watchdog cron |
-| mule-photos-new | 127 | 2026-05-22 | PhotoPrism test stack promoted to LXC 120 (Mulimage 2.0 merge) |
-| heaper | 116 | 2026-05-14 | decommissioned; data retained at /mnt/library/heaper |
-| syncthing | 109 | 2026-05-14 | decommissioned; library subtree was empty |
-| seafile | 125 | 2026-05-13 | Seafile Pro evaluation rejected; files.hubris.network removed from caddy + dns |
-| arr-yunohost | 100 | 2026-04-28 | migrated to docker stack on arriman (LXC 122) |
-| flaresolverr | 106 | 2026-04-28 | folded into the arriman docker compose |
-| marimo | 107 | 2026-04-28 | decommissioned |
-| photoprism | 110 | 2026-04-28 | replaced by mule-images (LXC 120) |
-| karakeep | 111 | 2026-04-28 | decommissioned |
-| immich | 112 | 2026-04-28 | replaced by mule-images (LXC 120) |
-| reticulum | 115 | 2026-04-28 | decommissioned |

archive/knowledge/investigations/2026-04-21-hubris-crash-loop.md

@@ -1,89 +0,0 @@
-# 2026-04-21 — Hubris crash loop (thermal + USB drive)
-
-## Summary
-
-[`hubris`](../../../wiki/hosts/hubris.md) hard-locked repeatedly on 2026-04-21 (silent CPU hangs, no panic, no OOM, no MCE). Two contributors identified: idle CPU sitting at ~95 °C on the `performance` governor, and a USB-attached external SSD whose UAS interaction with the AMD USB4/Thunderbolt PCIe tunnel triggered hard locks. CPU thermal addressed via `cpu-epp.service`; drive removed 2026-04-22 as an A/B test. As of 2026-04-28 the host has 3+ days uptime — the drive looks like the primary contributor; `cpu-epp` remains as belt-and-suspenders.
-
-## Timeline
-
-### 2026-04-19 — drive attached
-External `Silicon Motion Portable SSD` (vid:pid `090c:2320`) attached for the new restic [backup pipeline](../../../wiki/infrastructure/backups.md). Pre-attach uptime had been 33 days stable.
-
-### 2026-04-19 → 2026-04-21 — first crashes
-Two hard crashes in 2.5 days (46 h then 12 h uptime). Kernel logs ended abruptly with routine apparmor entries — no panic, OOM, or MCE — the classic hard-lock signature. Preceded by `uas_eh_abort_handler` storms and xHCI resets on port 6-1.
-
-### 2026-04-21 — crash cadence escalates
-23:02 (previous night) → 12:01 the next day. Cadence: 12 h → 43 m → 8 m → 5 m. Stable since the 12:03 boot once `cpu-epp.service` started applying `EPP=balance_power`.
-
-### 2026-04-21 — first set of mitigations applied
-
-- **`cpu-epp.service`** deployed. Sets `scaling_governor=powersave` + EPP=`balance_power` at boot. Drops idle Tctl from ~95 °C → ~60 °C, clocks from 4.4 GHz pinned → 1.1–2 GHz idle.
-- **Crash capture**: `/etc/sysctl.d/60-crash-capture.conf` (panic on oops/hardlockup/softlockup/rcu, auto-reboot 10 s), `/etc/modprobe.d/softdog.conf` (`soft_panic=1 soft_margin=60`), `/etc/systemd/system.conf.d/watchdog.conf` (`RuntimeWatchdogSec=15s`).
-- **`rasdaemon`** installed (Debian pkg; mcelog is retired) — logs MCE / memory / PCIe AER / thermal events to `/var/lib/rasdaemon/ras-mc_event.db`. Query `ras-mc-ctl --summary`.
-- **UAS blacklist** for the drive: `/etc/modprobe.d/usb-storage-quirks.conf` → `options usb-storage quirks=090c:2320:u`. Forces BOT instead of UAS for the SMI bridge.
-- **Mount-on-demand** for the drive: `/usr/local/sbin/backup-usb.sh attach|detach|status` toggles `/sys/bus/usb/devices/*/authorized` so the drive is de-authorized when no backup is running.
-
-### 2026-04-22 — recurrence after 30 h 37 m
-Same silent-cutoff signature at 18:42:08. Much longer than any pre-`cpu-epp` crash (12 h max), so `cpu-epp` helps but is not sufficient on its own. [claudio-monitor](../../../wiki/infrastructure/monitoring.md) showed healthy runtimes up to 43 s before the hang (no pre-crash degradation). No MCE / no RAS / pstore empty.
-
-### 2026-04-22 — `cpu-epp.service` design bug fixed
-Was `After=multi-user.target` + `WantedBy=multi-user.target` — queued behind `pve-guests.service`. The hottest window of every boot (20 LXCs + 1 VM coming up) ran on the `performance` governor. Fixed: now `After=sysinit.target` + `Before=pve-guests.service`.
-
-### 2026-04-22 — drive removed (A/B test)
-User physically removed the external USB drive. [Backup timers disabled](../../../wiki/infrastructure/backups.md#status), fstab entry commented, drive de-authorized. Goal: confirm whether the drive + UAS + AMD USB4 PCIe-tunnel interaction is the dominant root cause.
-
-### 2026-04-23 — SSD cooling + thermal pads installed
-Cold-boot baseline (3 min uptime): nvme0n1 35 °C composite / sensor1 (controller) **53 °C**; nvme1n1 36 °C composite / both sensors ≤36 °C. Lifetime warning-time counters at install: nvme0n1 709 min warn + 5 min crit; nvme1n1 778 min warn + 45 min crit — both drives had spent real time in thermal warning historically.
-
-#### 2026-04-23 thermal-pad verdict
-Resolved (3 h self-paced watch). Steady-state across 17:03 → 19:56 stayed pinned at nvme0 composite 47 °C / sensor1 60–61 °C, nvme1 38–40 °C. Zero new warning-time minutes on either drive. Controller sensor1 at 60-ish is normal idle for M.2 NVMe. **The load-bearing signal is the lifetime warning-time counter, not absolute sensor1** — watch that going forward, not sensor1 threshold.
-
-### 2026-04-28 — A/B test passing so far
-3+ days continuous uptime with the drive removed. If uptime now exceeds ~3 days without crash, the drive/PCIe-tunnel interaction is confirmed as the dominant root cause. Will revisit options (different drive, different USB port, different bridge) once stability is firmly established.
-
-### 2026-04-29 — physical relocation
-User moved the host to a spot with better airflow. Post-move idle baseline (45 min uptime, light load): Tctl **47.2 °C**, GPU 42 °C, nvme0 composite 34.9 °C / sensor1 32.9 °C, nvme1 composite 38.9 °C / sensor1 52.9 °C, DRAM 34–35.5 °C. Notably nvme0 sensor1 is **27 °C cooler** than the 2026-04-23 thermal-pad steady-state of 60–61 °C. Watch lifetime warning-time counters (`nvme smart-log` → "Warning Comp. Temperature Time") over the next week — flat trend confirms the move helped. Doesn't change the drive-removal A/B test, but reduces residual thermal headroom risk independently.
-
-## Root cause
-
-Two-contributor:
-1. **Thermal**: Ryzen 5 7640HS (Phoenix APU) in a passively-cooled GMKtec NucBox sitting at ~95 °C idle under `performance` governor. Mitigated by `cpu-epp.service`. In `amd-pstate=active` mode the governor MUST be `powersave` for EPP values to take effect — `performance` silently ignores them.
-2. **Storage**: external USB SSD's UAS keepalive interacts badly with the AMD USB4/Thunderbolt PCIe tunnel. UAS blacklist + mount-on-demand reduced but did not eliminate it. Removing the drive eliminates it (so far).
-
-Background: BIOS 1.02 (latest publicly visible from GMKtec). Vendor not on LVFS so `fwupdmgr` can't update. Non-ECC RAM means memory faults are silent and undetectable except by memtest86+.
-
-## Diagnostic notes
-
-- **Pure hardware hangs leave no trace.** `pstore` stays empty across reboots despite `panic_on_oops/hardlockup/softlockup/rcu` + softdog `soft_panic=1` being configured. The CPU is gone before the kernel can react. Don't waste time on panic traces — use crash cadence + uptime pattern as the diagnostic.
-- **First check** if hubris crash-loops again with the same silent-cutoff signature: `cpu-epp.service` is active and `/sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference` is `balance_power`.
-- **Non-ECC RAM means memory faults are silent.** If `cpu-epp` is on and crashes still happen, suspect DIMM next (run memtest86+) and/or try the commented-out `pcie_aspm=off pci=nomsi` workarounds in `/etc/default/grub`.
-- **Grub escalation** (`pcie_aspm=off pcie_port_pm=off pci=nomsi`) **deliberately NOT applied** yet to keep the drive-removal test clean. Enable only if crashes continue without the drive.
-- `mcelog` is not in Debian 13 repos; `rasdaemon` is the replacement.
-
-## BIOS update path
-
-Checked 2026-04-21. GMKtec is **not on LVFS**, so `fwupdmgr` can't update the NucBox M6 Ultra. BIOS 1.02 (2025-08-06) is the latest publicly visible — GMKtec's download center only publishes Windows drivers, no BIOS listing or changelog. Update path is a `.exe` flasher that needs Windows (would require Windows-To-Go USB on hubris). Before committing to that, email `service@gmktec.com` with the S/N to confirm a newer BIOS / AGESA level actually exists. `fwupd` is now installed, so if GMKtec ever onboards to LVFS, updates appear automatically.
-
-## Mitigations applied
-
-| Mitigation                                | Status   | Notes                                                |
-| ----------------------------------------- | -------- | ---------------------------------------------------- |
-| `cpu-epp.service` (powersave + balance_power) | Active   | Unit ordering fixed 2026-04-22 to run before guests |
-| Crash capture (sysctl + softdog + watchdog) | Active   | Catches everything but pure silicon hangs           |
-| `rasdaemon`                               | Active   | Persistent telemetry for MCE / memory / PCIe AER    |
-| UAS blacklist for `090c:2320`             | Active (drive currently absent) | `/etc/modprobe.d/usb-storage-quirks.conf` |
-| Mount-on-demand (`backup-usb.sh`)         | Active (drive currently absent) | Backup unit `ExecStartPre`/`ExecStopPost` hooks |
-| Drive physically removed                  | Active   | A/B test in progress                                 |
-| Thermal pads on NVMes                     | Active 2026-04-23 | Steady-state composite 47 °C / sensor1 60 °C |
-| `pcie_aspm=off pci=nomsi`                 | NOT applied | Reserved for if crashes recur without the drive    |
-
-## Affected nodes
-- [Hubris host](../../../wiki/hosts/hubris.md)
-- [Backups (disabled)](../../../wiki/infrastructure/backups.md)
-- [Monitoring](../../../wiki/infrastructure/monitoring.md)
-
-## Open questions
-- Will the host stay up indefinitely without the drive? (Test ongoing — 3+ days as of 2026-04-28.)
-- If yes: which mitigation lets the drive come back? (different drive? different USB port bypassing the hub chain? rear motherboard USB 3 port? alternative bus path?)
-- Newer BIOS / AGESA from GMKtec — answered email pending. Without LVFS we need explicit vendor confirmation.
-- Memtest86+ pass on the DIMMs — not yet run; deferred until the drive case is closed.

archive/knowledge/investigations/2026-05-31-authentik-vps-migration.md

@@ -1,109 +0,0 @@
-# 2026-05-31 — Authentik migrated from LXC 124 to the VPS
-
-## Summary
-
-The NetBird management server (on the [VPS](../../../wiki/infrastructure/ingress.md)) crash-looped 1200+ times because it fetches the Authentik OIDC discovery document on startup, and Authentik was only reachable via the NetBird mesh — which was down *because* mgmt couldn't start. A classic bootstrap deadlock: **mgmt needs OIDC → OIDC needs the mesh → the mesh needs mgmt.**
-
-Resolved by moving Authentik off [LXC 124](../../../wiki/containers/106-auth-outpost.md) onto the VPS itself, so `auth.hubris.network` resolves to a container co-located with netbird-mgmt — no mesh dependency. A `depends_on: condition: service_healthy` on the mgmt service makes the deadlock structurally impossible to recur.
-
-The full Authentik Postgres DB (all users, apps, passwords, groups) was migrated, so every gated app keeps working with no per-app reconfiguration.
-
-## Timeline
-
-### Trigger
-`netbird status` on clients showed `Management: Disconnected`; `netbird.hubris.network` unreachable. VPS `docker logs netbird-mgmt`:
-```
-Error: failed reading provided config file: /etc/netbird/management.json:
-OIDC configuration request returned status 504 with response: Gateway Timeout
-```
-The 504 came from VPS traefik trying to reach the old `auth-authentik` backend (`https://192.168.8.175`, home Caddy) over the down mesh.
-
-### Fix — Phase A (restore the mesh)
-1. Stood up Authentik on the VPS in `/opt/docker-compose.yml`: `authentik-postgres`, `authentik-redis`, `authentik-server`, `authentik-worker` (image `ghcr.io/goauthentik/server:2026.5.2`), on a dedicated `auth` Docker network (`172.30.1.0/24`). Traefik joined both `netbird` and `auth` networks.
-2. Removed the `auth-authentik` → `192.168.8.175` backend from `/opt/traefik-dynamic.yaml`; Authentik now routed via Docker provider labels.
-3. Added `depends_on: authentik-server: condition: service_healthy` to the mgmt service.
-4. Created the NetBird OAuth2 provider/app manually (only manual step), then mgmt auto-recovered within 30 s.
-
-### Fix — Phase B (full data migration)
-Once the mesh was back, the homelab DB was reachable:
-1. `ssh proxmox 'pct exec 124 -- docker exec authentik-postgresql-1 pg_dump -U authentik authentik'` → gzip.
-2. Stopped VPS authentik server/worker, dropped + recreated the VPS DB (connect to the `postgres` DB to drop `authentik`), restored the dump.
-3. **Swapped `AUTHENTIK_SECRET_KEY` in `/opt/authentik.env` to the homelab's key** — Authentik encrypts OAuth2 client secrets in the DB with this key; a mismatch makes every client secret unreadable and silently breaks all SSO.
-4. Restarted Authentik. All users / apps / passwords / groups present.
-
-Scripts left on the VPS: `/opt/migrate-authentik.sh` (re-runnable), `/opt/backup-authentik.sh` (daily cron, 14-day retention).
-
-### Fix — DNS cutover (the long tail)
-The real reason the browser kept hitting the *old* Authentik even after the VPS one was healthy: split-horizon dnsmasq on LXC 124 still had `address=/auth.hubris.network/192.168.8.175`, and the NetBird per-client resolver (`100.122.255.254`) cached it. Symptom: the login page console logged `authentik(early): version 2026.2.2` (the old LXC) instead of `2026.5.2` (the VPS).
-
-- Updated dnsmasq: `address=/auth.hubris.network/82.165.190.79`, `systemctl restart dnsmasq`.
-- `netbird down && netbird up` does **not** reliably flush the NetBird resolver cache. Immediate per-client fixes: `/etc/hosts` override (mac), `sudo resolvectl flush-caches` (Linux), `sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder` (mac).
-
-## Issues hit during the migration (and fixes)
-
-1. **Redirect URI error.** The restored DB had redirect URIs in `REGEX` matching mode; in Authentik 2026.5.x they failed to match. Fixed by switching to `STRICT` exact matching (Django ORM, `RedirectURIMatchingMode.STRICT`). Set all four: `http://localhost:53000/` (CLI), `https://netbird.hubris.network/{peers,nb-auth,nb-silent-auth}`.
-2. **Only the password field showed (no username).** NetBird passes `login_hint=<email>` in the OAuth2 URL → Authentik pre-identifies and skips the identification stage. Expected behavior; not a bug.
-3. **"Request has been denied. Unknown error."** Several overlapping causes: wrong password (reset via Django shell), reputation lockout after repeated failures (`Reputation.objects.all().delete()` — see [124-authentik](../../../wiki/containers/106-auth-outpost.md)), and **broken default expression policies**. The restored DB carried 8 default policies authored in old `return`-style syntax incompatible with 2026.5.x's eval context; `ak apply_blueprints` re-applied the current defaults.
-4. **Browser ran stale frontend JS.** Console showed `version 2026.2.2` while the backend was `2026.5.2` — because DNS still pointed at the old LXC (see DNS cutover above), not a cache issue.
-5. **WebAuthn devices dead post-migration.** Passkeys are device/origin-bound and don't survive a host move. Deleted all WebAuthn devices via Django ORM; users must re-register MFA.
-
-## Architecture delta
-
-| | Before | After |
-|---|---|---|
-| Authentik host | [LXC 124](../../../wiki/containers/106-auth-outpost.md) `192.168.8.180` | VPS `82.165.190.79`, `auth` Docker net `172.30.1.0/24` |
-| Version | `2026.2.2` | `2026.5.2` |
-| `auth.hubris.network` (LAN) | dnsmasq → `192.168.8.175` (Caddy) | dnsmasq → `82.165.190.79` (VPS traefik) |
-| `auth.hubris.network` (public) | IONOS wildcard → VPS → mesh → LXC 124 | IONOS wildcard → VPS → local container |
-| Reachability | mesh-only (split-horizon) | **public** (auth UI now exposed on the open internet) |
-| Redis | none (docs said 2026.x dropped it) | present (this deploy uses Redis) |
-| DB engine | sqlite? (`StoreConfig` in mgmt) / Postgres for Authentik | Postgres, separate from netbird |
-
-> **Security note:** the Authentik admin UI is now publicly reachable. Mitigated with a traefik `admin-allowlist` ipAllowList middleware on `/if/admin/` (currently `5.61.168.0/24`). Login/flow endpoints are public by necessity. The `auth` Docker network isolates Postgres/Redis from the netbird containers.
-
-## Lessons learned
-
-1. **Never put the IdP behind the VPN it authenticates.** The circular dependency is invisible until a restart, then it's total.
-2. **`depends_on: condition: service_healthy` is the structural fix.** Docker refuses to start mgmt until Authentik is healthy, regardless of boot order.
-3. **Migrating an Authentik DB requires carrying its `AUTHENTIK_SECRET_KEY`.** It encrypts client secrets at rest; a mismatch breaks SSO silently with no useful error.
-4. **Default expression policies break across major Authentik versions.** Always run `ak apply_blueprints` after restoring an older DB into a newer Authentik.
-5. **Split-horizon DNS + a VPN resolver cache = an invisible stale answer.** The NetBird resolver (`100.122.255.254`) outlives `netbird down/up`. Removing the dnsmasq override (fall through to public DNS) is the durable fix once a service is genuinely public.
-6. **Redirect URIs: prefer `STRICT` over `REGEX`** in Authentik 2026.x.
-7. **Frontend/backend version skew shows as "Unknown error."** Confirm which Authentik the browser actually loaded (`version` line in the console) before chasing backend logs.
-8. **WebAuthn/passkeys do not survive host migrations** — delete and re-enroll.
-
-## Forward-auth outpost — RESOLVED 2026-06-01
-
-Forward-auth apps (Paperless, qBittorrent, Artifacto) initially still validated against LXC 124's *embedded* outpost (Caddy → `192.168.8.180:9000`) — split-brain against the frozen DB. Pointing Caddy at `https://auth.hubris.network` instead fails: VPS Traefik rewrites `X-Forwarded-Host` → outpost can't match the app → 404 (tested + reverted).
-
-Fixed with a **dedicated LAN outpost** ([106 — auth-outpost](../../../wiki/containers/106-auth-outpost.md), `192.168.8.6`): `goauthentik/proxy` connects outbound to the VPS core and serves forward-auth locally; Caddy → outpost over the LAN, no Traefik, header preserved. Outpost `hubris-lan-outpost` carries the 3 proxy providers. Verified with 124-Authentik **stopped**. This was Phase 1 of the broader architecture migration (plan: VPS edge / hubris LAN core / Mac Mini redundancy).
-
-### 2026-06-05 — identification stage skip: broken "Trust me" reputation policy
-
-The default authentication flow was skipping the identification stage (showing only a password field with `pending_user: ""`), making login impossible. Root cause: a **"Trust me" reputation policy** (`threshold: -3`, `negate: true`) attached to the identification stage binding (#10). The `negate: true` + broken policy evaluation caused the stage binding to fail re-evaluation, and Authentik's `ReevaluateMarker` skipped the stage entirely.
-
-**Fix:** Deleted from Postgres:
-```sql
-DELETE FROM authentik_policies_policybinding WHERE policy_id = '<uuid>';
-DELETE FROM authentik_policies_reputation_reputationpolicy WHERE policy_ptr_id = '<uuid>';
-DELETE FROM authentik_policies_policy WHERE policy_uuid = '<uuid>';
-```
-The policy was orphaned (no matched type data or had incompatible evaluation). Removing it restores normal two-stage login (identification → password).
-
-**Note:** This is different from the 2026-05-31 issue where NetBird's `login_hint` OAuth2 param intentionally pre-identifies users. That was expected behavior; this was a genuine bug.
-
-## Outstanding
-
-- **NetBird client version skew.** Mac client is `0.68.3` vs mgmt `0.71.3`; NetBird-SSH cert exchange fails between them. Upgrade all clients toward `0.71.x`.
-- **republic-laptop** regular SSH publickey auth still rejected (correct `authorized_keys`/perms/SELinux context, yet denied — `sshd_config` `AuthorizedKeysFile` suspect). DNS not yet flushed there either.
-- **muli-laptop** needs `netbird down && netbird up` + `resolvectl flush-caches`.
-- **VPS port 22** opened for this repair; close once remote access is otherwise stable.
-- **Decommission LXC 124 Authentik** after a ~2-week dual-run validation. dnsmasq stays on 124 regardless (separate service).
-- **Reconcile [124-authentik](../../../wiki/containers/106-auth-outpost.md) provider notes** — docs describe a `Public`/PKCE provider; the migrated DB carries the `Confidential` `netbird-dashboard` client. Verify which is live and correct the page.
-- **sops-encrypt** the VPS secrets (`/opt/authentik.env`) into the `secrets/` tree.
-
-## Related
-- [124 — authentik](../../../wiki/containers/106-auth-outpost.md)
-- [DNS split-horizon](../../../wiki/infrastructure/dns.md)
-- [Public ingress (VPS traefik)](../../../wiki/infrastructure/ingress.md)
-- [Mesh migration](../../../wiki/infrastructure/mesh.md)

archive/knowledge/investigations/2026-06-01-mac-mini-onboarding.md

@@ -1,191 +0,0 @@
-# mac-mini onboarding — post-mortem & lessons learned
-
-Onboarded the `mac-mini` workstation (macOS Sequoia, arm64) into the hubris
-homelab context system with the `--with-hermes` profile. What follows is a
-chronological recap of every hitch, the fix, and the systemic improvements
-needed so the next workstation takes 5 min instead of an hour.
-
-## Session log
-
-### Step 1 — clone + symlink
-- Manually cloned `git.hubris.network/dtoro/Homelab-Docs` to `/Users/dtoro/Homelab-Docs`.
-- Created `/opt/homelab-context` → `/Users/dtoro/Homelab-Docs` symlink.
-- **Lesson:** bootstrap.sh was designed to do this from scratch, but we'd
-  already cloned by hand. The bootstrap's `clone exists; pulling` path handled
-  it gracefully.
-
-### Step 2 — hostname mismatch
-- `scutil --get LocalHostName` → `Davids-Mac-mini`
-- `hostname -s` → `Mac`
-- Inventory file: `hosts/mac-mini.yaml`
-- **Fix:** `sudo scutil --set LocalHostName mac-mini && sudo scutil --set HostName mac-mini`
-- **Lesson:** The bootstrap and `homelab whoami` use different hostname
-  resolution. Bootstrap uses `scutil --get LocalHostName` (correct on macOS),
-  but the `homelab` CLI binary uses `hostname -s`. Both need to match the
-  inventory key. On a fresh macOS machine, neither does.
-
-### Step 3 — bootstrap dependencies
-- pyyaml was missing → `pip install pyyaml`
-- age and sops were missing → `brew install age sops`
-- Netbird was already installed and connected ✓
-- **Lesson:** The bootstrap preflight handles these, but only if running
-  `bootstrap.sh` from the start. Since we ran it after manual setup, some
-  steps (netbird install) were correctly skipped as already-present.
-
-### Step 4 — full bootstrap with `--with-mcp --with-hermes`
-- Ran `sudo HOMELAB_GITEA_TOKEN=... bash bootstrap.sh --with-mcp --with-hermes`
-- Age key issued ✓
-- Launchd sync timer installed ✓
-- Goose binary installed ✓
-- Hermes CLI linked ✓
-- MCP config merged ✓
-- `refresh-creds` skipped (not yet a recipient) ⚠️
-- Cosmetics: `chown: dtoro: illegal group name` at the end (benign, macOS
-  group-naming quirk)
-
-### Step 5 — finalize from hubris
-- Ran `homelab client add mac-mini --finalize-pubkey <age...> --with-hermes` on
-  hubris
-- Push failed: `[rejected] main -> main (fetch first)` — hubris clone was
-  stale, bootstrap had already pushed from mac-mini
-- **Fix:** `git pull --rebase && git push` on hubris
-- **Lesson:** bootstrap pushes remote changes before hubris can finalize,
-  creating a race. The `homelab client add --finalize-pubkey` command should
-  pull before committing/pushing.
-
-### Step 6 — sops couldn't find the age key
-- `homelab secret hello` failed because sops looks in
-  `/Users/dtoro/.ssh/id_rsa` etc. by default, not `/etc/age/key.txt`
-- The `homelab` CLI re-execs via `sudo -E env SOPS_AGE_KEY_FILE=... sops ...`,
-  but this requires passwordless sudo and the correct env var passthrough
-- **Fix:**
-  1. Added NOPASSWD sudo rules
-  2. Eventually `SOPS_AGE_KEY` env with the raw key content worked directly
-- **Lesson:** Document the explicit `SOPS_AGE_KEY_FILE` incantation in
-  agent-enrollment troubleshooting. New clients can't assume `homelab secret`
-  works out of the gate — the sudo re-exec chain has permission pitfall.
-
-### Step 7 — OpenRouter key was a placeholder
-- `secrets/openrouter-api-key.yaml` contained
-  `api_key: PLACEHOLDER_REPLACE_WITH_REAL_OPENROUTER_KEY`
-- User ran `sops` on hubris, but got the same error (age key not found on
-  hubris either — `/root/.config/sops/age/keys.txt` didn't exist)
-- **Fix:** `SOPS_AGE_KEY_FILE=/etc/age/key.txt sops ...` on hubris.
-  Later: the user pasted the real key, but the sops file showed
-  `sk-or-...5c55` — the literal content was truncated with ellipsis.
-
-### Step 8 — editor loaded the wrong data
-- Neovim on the system is configured with `clipboard+=unnamedplus`, which
-  points `*` and `+` registers to the macOS clipboard manager rather than
-  X11. When editing SOPS files, this caused the **system clipboard** to be
-  pasted instead of the actual ciphertext.
-- This wasn't diagnosed during the session — the sops file would load empty
-  or show the wrong content because the editor's idea of "paste" was
-  disconnected from what sops expected.
-- **Fix:** Run `sops` with `EDITOR=nano` or another editor that doesn't
-  hijack OS clipboards:
-  ```bash
-  EDITOR=nano SOPS_AGE_KEY_FILE=/etc/age/key.txt sops secrets/openrouter-api-key.yaml
-  ```
-- **Lesson:** Add a strong warning to `hermes-agent.md` / `agent-enrollment.md`:
-  macOS neovim with `clipboard+=unnamedplus` silently breaks sops editing
-  because the paste register reads from the system clipboard instead of the
-  sops-managed buffer. Use `EDITOR=nano` or `EDITOR=vim` when running sops
-  interactively. Alternatively, override the clipboard option with
-  `EDITOR='nvim -c "set clipboard="'`.
-- Also useful for the troubleshooting table in `agent-enrollment.md` under a
-  new row: "sops file loads empty / wrong content on macOS"
-
-### Step 9 — model doesn't support tool use
-- Goose config pinned `nousresearch/hermes-4-405b` via OpenRouter
-- Error: `No endpoints found that support tool use`
-- **Fix:** Switched to `deepseek/deepseek-v4-flash` in
-  `~/.config/goose/config.yaml`
-- Also updated `operations/hermes-agent.md` with the correct model
-- **Lesson:** The default model in `bootstrap.sh` and `hermes-agent.md` was
-  never validated on OpenRouter for tool-use capability. Need to either:
-  (a) Pin a model known to work (`deepseek/deepseek-v4-flash`)
-  (b) Or have the bootstrap probe OpenRouter at install time
-
-### Step 10 — MCP homelab extension returns 404
-- Goose's homelab extension configured as `streamable_http` at
-  `https://mcp.hubris.network/mcp` returns HTTP 404
-- The actual MCP server runs on SSE (`/sse`), not streamable_http
-- **Known follow-up** from `hermes-agent.md` — server needs migration
-- **Workaround:** The agent works fine via the built-in `developer` extension
-  (shell + file) and the `homelab` CLI
-
-### Step 11 — git credential dance
-Several layers of issues with git authentication:
-
-1. **Directory permissions:** `/etc/homelab-context` was `0700 root` — dtoro
-   couldn't access the credential file, and git's `store` helper couldn't
-   create its `.lock` file.
-   - **Fix 1a:** `sudo chmod 755 /etc/homelab-context`
-   - **Fix 1b:** `sudo chown -R dtoro:staff /etc/homelab-context`
-
-2. **macOS built-in osxkeychain:** Apple's git has `osxkeychain` compiled in
-   as a default credential helper. Even after configuring the `store` helper,
-   git calls osxkeychain after every successful `get`, which prompts for
-   macOS keychain access.
-   - `credential.helper = ""` does NOT disable the compiled-in default
-   - The `store` helper's `.lock` file in `/etc/homelab-context/` also failed
-     silently, causing fallback behaviour
-   - **Fix:** Embed the credential in the remote URL directly:
-     `https://dtoro:TOKEN@git.hubris.network/dtoro/Homelab-Docs.git`
-   - This bypasses all credential helpers entirely
-
-3. **refresh-creds:** The credential is now managed by the remote URL.
-   If the PAT is rotated, `homelab refresh-creds` won't update the URL.
-   - **Workaround:** Run `git remote set-url origin` after `refresh-creds`
-
-### Step 12 — `homelab` CLI hostname detection
-- `homelab whoami` failed with `no hosts/Mac.yaml` because the CLI uses
-  `hostname -s` (returning `Mac`) while the bootstrap uses
-  `scutil --get LocalHostName` (which we fixed to `mac-mini`)
-- **Fix:** Set both `LocalHostName` and `HostName` via `scutil`
-- **Lesson:** The homelab CLI on macOS should prefer `scutil --get
-  LocalHostName` like the bootstrap does, or at least try both and pick the
-  one that matches an inventory key. This is a CLI bug.
-
-## Improvement backlog
-
-### High priority
-
-| # | Issue | Fix |
-|---|-------|-----|
-| 1 | Homelab CLI uses `hostname -s` on macOS; should use `scutil --get LocalHostName` to match bootstrap | Patch `bin/homelab` to try `scutil` first, fall back to `hostname -s` |
-| 2 | `homelab client add --finalize-pubkey` on hubris fails to push when remote is ahead (bootstrap pushes first) | `pull --rebase` before committing in `cmd_client_add` |
-| 3 | Default Goose model (`nousresearch/hermes-4-405b`) doesn't support tool use on OpenRouter | Update `bootstrap.sh` default and `hermes-agent.md` to `deepseek/deepseek-v4-flash` |
-| 4 | MCP server needs streamable_http migration | Follow-up #1 from `hermes-agent.md` — FastMCP `transport="sse"` → `transport="streamable_http"` |
-| 5 | `homelab refresh-creds` should also update embedded remote URLs | In `cmd_refresh_creds`, after writing the credential file, update any remote URL that has an embedded credential |
-
-### Medium priority
-
-| # | Issue | Fix |
-|---|-------|-----|
-| 6 | macOS neovim with `clipboard+=unnamedplus` breaks sops editing | Add troubleshooting row to `agent-enrollment.md`; recommend `EDITOR=nano` |
-| 7 | `/etc/homelab-context` directory with 0700 root permissions blocks non-root git | Change to 755 in `bootstrap.sh` on all OSes (or at least macOS) |
-| 8 | Bootstrap `chown` at end gives `illegal group name` on macOS | Fix group detection in bootstrap.sh for macOS |
-| 9 | `homelab secret` re-exec via sudo chain is fragile — needs passwordless sudo or TTY | Consider `SOPS_AGE_KEY` env-var fallback path in the CLI itself |
-
-### Low priority
-
-| # | Issue | Fix |
-|---|-------|-----|
-| 10 | Onboarding this machine revealed no `HERMES.md` file in the repo | Create the persona file for the Goose hints symlink |
-| 11 | Git credential `store` helper lock mechanism is OS-sensitive and fragile | Document embedded-URL pattern as the preferred approach for workstations |
-| 12 | AGENTS.md references `/opt/homelab-context/hosts/<hostname>.yaml` but the canonical path is now a symlink | Verify the path resolution edge cases |
-
-## Changelog
-
-### 2026-06-01 — initial post-mortem
-Captured the full onboarding of mac-mini into the hubris homelab context
-system, including the hostname mismatch, sudo/sops credential chain, model
-selection, git credential gymnastics, and editor clipboard interference.
-
-### 2026-06-02 — MCP server migrated to streamable-http
-Item #4 resolved. FastMCP server now uses `transport="streamable-http"` (hyphen,
-not underscore), serving at `https://mcp.hubris.network/mcp`. All doc references
-and client configs (Goose, bootstrap.sh, agent-enrollment.md) updated. Service
-re-deployed on apps LXC (105).

archive/knowledge/investigations/2026-06-03-moonlight-sunshine-wifi-jitter.md

@@ -1,84 +0,0 @@
-# 2026-06-03 — Moonlight/Sunshine game streaming unstable over WiFi
-
-## Summary
-
-[`ludo-mini`](../../../hosts/strong.yaml) runs Sunshine as the game-streaming server; [`mac-mini`](../../../hosts/mac-mini.yaml) runs Moonlight as the client. Despite both machines being on the same physical subnet (192.168.178.0/24), streaming was unstable — stuttering, dropouts, and high latency. Root cause: **mac-mini is connected only via WiFi**, while ludo-mini is wired Ethernet (2.5 Gbps). WiFi throughput shows 1-second UDP dropouts and high jitter (28 ms stddev), which breaks real-time video streaming.
-
-## Timeline
-
-### Pre-existing state
-- ludo-mini: wired Ethernet (eno1, 2.5 Gbps), 192.168.178.181/24
-- mac-mini: WiFi (en1, 802.11ac, 234 Mbps Tx rate, 1 stream, -60 dBm RSSI), 192.168.178.99/24
-- Both on the same subnet via a consumer router at 192.168.178.1
-- Sunshine configured: bitrate=80 Mbps, encoder=amf (AMD GPU), fec_percentage=5, hevc_mode=2
-- Moonlight configured: bitrate=57 Mbps, fps=60, localaddr=192.168.178.181 (correct)
-
-### 2026-06-03 — investigation
-**Network tests (iperf3 between mac-mini ↔ ludo-mini):**
-- TCP throughput: 49–86 Mbps, average ~65 Mbps — highly variable
-- UDP throughput: 1-second complete dropout during a 5-second test; 0% loss otherwise
-- Ping: 4.7 ms avg, but **28 ms stddev**, max **138 ms** — WiFi-level jitter
-- Netbird P2P connection also showed 7 ms latency over the tunnel (unnecessary given same-subnet direct connection)
-
-**Additional findings:**
-- mac-mini has a built-in Ethernet port (en0) but it is inactive — no cable connected
-- mac-mini also has Thunderbolt Ethernet adapters (en5, en6, en7) all inactive
-- ludo-mini's en0 shows `speed 2500` (2.5 GbE)
-- Netbird routes `192.168.8.0/24` via `utun100`, but 192.168.178.0/24 traffic stays on `en1`
-
-## Root cause
-
-mac-mini is on WiFi. WiFi introduces:
-1. **Throughput variance** — 49–86 Mbps TCP fluctuation
-2. **Dropouts** — 1-second UDP blackouts from radio retransmissions
-3. **Jitter** — 28 ms stddev with spikes to 138 ms
-
-Moonlight/Sunshine streams real-time video over UDP. Any jitter spike or dropout causes visual stutter or frame drops. The 57 Mbps Moonlight bitrate was too aggressive for the WiFi link's consistency, even though the average throughput is ~65 Mbps.
-
-## Mitigations applied
-
-### mac-mini — Moonlight (via `defaults write`)
-
-| Setting | Before | After | Rationale |
-||---------|--------|-------|-----------|
-|| bitrate | 57 Mbps | 25 Mbps | Reduce to a level WiFi can sustain consistently |
-|| framepacing | off (0) | on (1) | Smooths frame timing over variable latency |
-|| fps | 30 | 60 | Restored to game-appropriate value |
-
-### mac-mini — Moonlight (current, wired — 2026-06-04)
-
-| Setting | WiFi value | Wired value | Rationale |
-||---------|-----------|-------------|-----------|
-|| bitrate | 60 Mbps | 80 Mbps | Wired 1 GbE can sustain comfortably |
-|| framepacing | on (1) | off (0) | Wired latency is consistent, no smoothing needed |
-|| fps | 60 | 60 | Unchanged |
-
-### ludo-mini — Sunshine (via SSH)
-
-| Setting | WiFi value | Wired value | Rationale |
-||---------|-----------|-------------|-----------|
-|| bitrate | 40 Mbps | 80 Mbps | Wired can handle full bandwidth |
-|| fec_percentage | 2 | 5 | Restored to default — wired has no dropout concern |
-|| packetsize | 1024 | 1316 | Restored to default (Ethernet MTU) |
-
-Sunshine restarted after changes; confirmed active.
-
-## Resolution
-
-### 2026-06-04 — mac-mini wired to LAN
-
-mac-mini plugged into Ethernet (en0, 192.168.178.182). This definitively resolves the WiFi jitter that caused streaming instability. All WiFi-era conservative settings reverted to appropriate wired values on both ends.
-
-## Open questions
-
-~~1. **Ethernet wiring** — mac-mini has an active en0 port. Plugging it into the same switch/router as ludo-mini would eliminate WiFi jitter entirely. This is the definitive fix.~~ **RESOLVED** — mac-mini now wired via en0.
-2. **WiFi alternatives** — If wiring is impractical, a WiFi 6 (802.11ax) USB adapter or Thunderbolt-to-Ethernet adapter would help, but wired Ethernet is the only reliable solution for game streaming.
-3. **Netbird route** — `192.168.8.0/24` is routed over Netbird `utun100`. If Moonlight ever falls back to that subnet (ludo-mini's 192.168.8.133 LAN IP), traffic tunnels unnecessarily. Moonlight correctly uses 192.168.178.181, so this is not currently an issue.
-
-## Changelog
-
-### 2026-06-04 — mac-mini wired to LAN, configs reverted from WiFi mitigations
-- mac-mini connected via en0 (wired Ethernet, 192.168.178.182), WiFi mitigations no longer needed
-- Moonlight: bitrate 60→80 Mbps, framepacing disabled
-- Sunshine: bitrate 40→80 Mbps, fec_percentage 2→5, packetsize restored to default (1316)
-- First root cause in investigation (Open questions #1) resolved

archive/knowledge/investigations/2026-06-06-authentik-session-lifetime.md

@@ -1,101 +0,0 @@
-# 2026-06-06 — Frequent Authentik login prompts fixed (session duration)
-
-## Summary
-
-User needed to re-authenticate to Authentik several times per day. Root cause was the Django session being configured as a **session cookie** (cleared on browser close) with a short 24-hour lifetime. Fixed by extending both the session cookie lifetime and the user_login stage session duration to 30 days.
-
-## Timeline
-
-- **2026-06-06 ~23:00** — User reports "having to login to authentik several times per day"
-- **~23:10** — Investigation begins: check Authentik OAuth2 provider settings, proxy session table, Django session config
-- **~23:20** — Found `SESSION_EXPIRE_AT_BROWSER_CLOSE=True` — the `authentik_session` cookie has no Max-Age, cleared on browser close
-- **~23:25** — Found the `user_login` stage has `session_duration=seconds=0`, which calls `session.set_expiry(0)` → `_session_expire_at_browser_close=True`
-- **~23:30** — Applied DB fix: updated `authentik_stages_user_login_userloginstage` → `session_duration='days=30'`
-- **~23:35** — Added `AUTHENTIK_SESSIONS__UNAUTHENTICATED_AGE=days=30` to `/opt/authentik.env` (maps to `sessions.unauthenticated_age` in Authentik config, setting `SESSION_COOKIE_AGE` to 30 days)
-- **~23:40** — Recreated container with `docker compose up -d` (restart doesn't re-read env file)
-- **~23:45** — Verified both changes took effect
-
-## Root cause
-
-Two independent but compounding issues:
-
-1. **`SESSION_EXPIRE_AT_BROWSER_CLOSE=True`** — hardcoded in `/authentik/root/settings.py`. Makes the `authentik_session` cookie a session cookie (no `Max-Age`), cleared when the browser closes. Cannot be changed via env vars or config files (hardcoded in Python source).
-
-2. **`user_login` stage `session_duration=seconds=0`** — the default-authentication-login stage called `session.set_expiry(0)`, which in Django sets `_session_expire_at_browser_close=True` on the session object, overriding any session cookie lifetime set via `SESSION_COOKIE_AGE`.
-
-3. **`sessions.unauthenticated_age=days=1`** (default) — `SESSION_COOKIE_AGE` was 86,400 seconds (24 hours), so even with the browser left open, the server-side session data expired after 24 hours with no way to extend it (`SESSION_SAVE_EVERY_REQUEST=False`).
-
-### Why forward-auth worked but OAuth2 didn't
-
-- **Forward-auth (Caddy-gated services)** — The `authentik_proxy_*` cookie is a *persistent* cookie with 24-hour validity, set by the Authentik proxy outpost. It survives browser restart. Caddy's forward-auth validates this cookie directly with the outpost API — no Django session needed.
-- **OAuth2 (Gitea, Jellyfin, etc.)** — These services redirect to `auth.hubris.network/application/o/authorize/`, which checks the Django session (`authentik_session` cookie). If the browser was closed, this cookie is gone → user is redirected to the login form.
-
-## Changes applied
-
-### 1. Database — `authentik_stages_user_login_userloginstage`
-
-```sql
-UPDATE authentik_stages_user_login_userloginstage
-SET session_duration = 'days=30'
-WHERE stage_ptr_id = (
-    SELECT stage_uuid FROM authentik_flows_stage 
-    WHERE name = 'default-authentication-login'
-);
-```
-
-This causes the login stage to call `session.set_expiry(timedelta(days=30))`, which:
-- Sets `_session_expire_at_browser_close=False` for that session
-- Sets the session cookie `Max-Age` to 30 days (persistent cookie)
-- Sets the server-side session expiry to 30 days
-
-### 2. Environment — `AUTHENTIK_SESSIONS__UNAUTHENTICATED_AGE`
-
-Added to `/opt/authentik.env`:
-
-```
-AUTHENTIK_SESSIONS__UNAUTHENTICATED_AGE=days=30
-```
-
-This maps to config key `sessions.unauthenticated_age`, which Authentik's `settings.py` reads via:
-
-```python
-SESSION_COOKIE_AGE = timedelta_from_string(
-    CONFIG.get("sessions.unauthenticated_age", "days=1")
-).total_seconds()
-```
-
-Result: `SESSION_COOKIE_AGE` = 2,592,000 seconds (30 days). This is a fallback for sessions that don't go through the `user_login` stage or when the stage's explicit `set_expiry` doesn't apply.
-
-## Verification
-
-```python
-# Inside authentik-server container:
-import os
-os.environ.setdefault("DJANGO_SETTINGS_MODULE", "authentik.root.settings")
-import django
-django.setup()
-from django.conf import settings
-print("SESSION_COOKIE_AGE:", settings.SESSION_COOKIE_AGE)  # → 2592000.0
-print("SESSION_EXPIRE_AT_BROWSER_CLOSE:", settings.SESSION_EXPIRE_AT_BROWSER_CLOSE)  # → True
-
-from authentik.stages.user_login.models import UserLoginStage
-stage = UserLoginStage.objects.filter(name="default-authentication-login").first()
-print("session_duration:", stage.session_duration)  # → "days=30"
-```
-
-## Open questions
-
-- `SESSION_COOKIE_SECURE=False` — Should be `True` since Authentik is HTTPS-only, but the custom `SessionMiddleware.is_secure()` method dynamically sets the cookie's `secure` flag based on the request, so it's fine.
-- 30 days is generous. Could be reduced to 7-14 days if desired. Change the DB value and env var accordingly.
-
-## Related
-
-- [Container 106 — auth-outpost](../../wiki/containers/106-auth-outpost.md)
-- [Authentik VPS migration](archive/2026-05-31-authentik-vps-migration.md)
-- [Ingress (VPS Traefik)](../../wiki/infrastructure/ingress.md)
-- `.hermes/plans/2026-06-06_232200-authentik-frequent-login-fix.md` — original plan
-
-## Changelog
-
-### 2026-06-06 — created
-Documented the session lifetime investigation, root cause, and applied fixes.

archive/knowledge/investigations/2026-06-06-caddyfile-truncation.md

@@ -1,61 +0,0 @@
-# Investigation: Caddyfile truncation — all LAN services down (2026-06-06)
-
-**Date:** 2026-06-06
-**Status:** resolved
-**Duration:** ~10 hours (from last known good state ~12:39 UTC to restoration ~22:40 UTC)
-
-## Symptom
-
-All `*.hubris.network` URLs except `photos.hubris.network` and `auth.hubris.network` returned `tlsv1 alert internal error` or TCP timeouts from LAN/mesh clients. `dig @192.168.8.2` and `dig @100.122.255.254` both resolved to `192.168.8.175` correctly — DNS was fine. The issue was at the Caddy level.
-
-## Root cause
-
-The Caddyfile on LXC 121 was manually edited directly on the filesystem (not via the `dtoro/caddy-conf` git repo), reducing it from 260 lines/30+ site blocks to 43 lines with only 3 photo-related site blocks: `photos.hubris.network`, `prism.hubris.network`, and `photos2.hubris.network`.
-
-### Timeline
-
-| Time (UTC+2) | Event |
-|---|---|
-| Jun 04 23:43 | Last successful git-push deploy — full Caddyfile (260 lines) |
-| Jun 06 ~12:00 | Caddyfile manually edited locally, truncating to 3 sites |
-| Jun 06 12:39 | Deploy webhook triggered → `git pull --ff-only` failed: "Your local changes would be overwritten" |
-| Jun 06 14:13 | Deploy webhook triggered again → `deploy ok` (the truncated file was committed or merged somehow) |
-| Jun 06 22:34 | Investigation began |
-| Jun 06 22:43 | Caddyfile restored from `origin/master`, `systemctl reload caddy` |
-
-### Evidence
-
-- `git diff HEAD -- Caddyfile` on LXC 121: `+3 / -159` lines
-- Git reflog: HEAD at `32575ce` (fix: sab port 8081→8082), working tree diverged
-- Backup file `Caddyfile.bak.1780263919`: 225 lines, full original config
-- `git stash list` shows one auto-stash entry
-- `origin/master` at `1b977aa`: 260 lines, all site blocks present
-
-### Secondary root cause found during investigation
-
-**elementsynapse (LXC 118)** had `iface eth0 inet dhcp` internally despite `pct set 118 --net0 ... ip=192.168.8.239/24`. On DHCP lease renewal, dhclient grabbed `.244` from Technitium's pool. Caddy's `reverse_proxy 192.168.8.239:8008` was hitting a dead IP.
-
-This is the same class of drift as the June 5th incidents (paperless, HAOS, apps, mule-images). Elementsynapse was missed during the 2026-06-02 static-IP migration.
-
-## Fix applied
-
-1. **Caddyfile** → `git checkout --force origin/master -- Caddyfile` + `systemctl reload caddy`
-2. **elementsynapse** → replaced `iface eth0 inet dhcp` with static, killed dhclient, verified connectivity
-
-## Permanent safeguards (all deployed)
-
-| Safeguard | Location | What it does |
-|---|---|---|
-| Site-count guard | `/etc/caddy/scripts/deploy.sh` | Refuses reload if <20 `hubris.network` site blocks |
-| Dirty-tree auto-stash | `/etc/caddy/scripts/deploy.sh` | Stashes local edits before git pull |
-| Auto-backup | `/etc/caddy/scripts/deploy.sh` | Saves Caddyfile.bak.<timestamp> before any change, keeps 5 |
-| Caddy backend health | `/etc/cron.d/caddy-backend-health` on hubris | Runs `check-caddy-backends.sh` every 10 min |
-| DNS sync | `/etc/cron.d/dns-sync` on LXC 107 | Runs `dns-sync.py` every 10 min (was missing since 2026-06-04) |
-
-## Related
-
-- DHCP drift investigation (previous incident) — not filed as its own investigation; see the [DNS sync fix](../../../.hermes/plans/2026-06-05_170000-prevent-dhcp-ip-drift.md)
-- [Caddy (121)](../../wiki/containers/121-caddy.md)
-- [elementsynapse (118)](../../wiki/containers/118-elementsynapse.md)
-- [dns-sync script](../../../scripts/dns-sync.py)
-- [check-caddy-backends script](../../../scripts/check-caddy-backends.sh)

archive/knowledge/investigations/index.md

@@ -1,29 +0,0 @@
-# Investigations
-
-Time-stamped incident reports and experiments. One entry per incident; the entry is the canonical source. Per-node changelog entries link back here.
-
-## Active / recent
-
-| Date         | Title                                                              | Status        |
-| ------------ | ------------------------------------------------------------------ | ------------- |
-| 2026-06-06   | [Caddyfile truncation incident](2026-06-06-caddyfile-truncation.md) | Resolved — permanent safeguards deployed (site-count guard, auto-stash, auto-backup) |
-| 2026-06-06   | [Frequent Authentik login prompts — session lifetime fix](2026-06-06-authentik-session-lifetime.md) | Resolved — `session_duration=days=30`, `SESSION_COOKIE_AGE=30d` |
-| 2026-06-03   | [Moonlight/Sunshine streaming — WiFi jitter](2026-06-03-moonlight-sunshine-wifi-jitter.md) | Mitigations applied; definitive fix requires wiring mac-mini via Ethernet |
-| 2026-06-01   | [Mac-mini onboarding](2026-06-01-mac-mini-onboarding.md) | Onboarded |
-
-## Resolved (archived)
-
-See [`archive/`](archive/):
-
-| Date         | Title                                                              |
-| ------------ | ------------------------------------------------------------------ |
-| 2026-04-21   | [Hubris crash loop — thermal + USB drive](archive/2026-04-21-hubris-crash-loop.md) |
-| 2026-05-31   | [Authentik migrated from LXC 124 to the VPS](archive/2026-05-31-authentik-vps-migration.md) |
-
-## Conventions
-
-- File name: `YYYY-MM-DD-<slug>.md`. Use the *first* date if the incident spans multiple days.
-- Mandatory sections: Summary, Timeline, Root cause, Mitigations applied, Open questions.
-- Update the entry as the situation evolves; never rewrite history. Add new dated sections at the bottom.
-- Link back from every node's changelog that's affected.
-- Move to `archive/` when the incident is fully resolved and no longer actively referenced.

archive/knowledge/log.md

@@ -1,10 +0,0 @@
-# Knowledge — operations log
-
-Append-only record of documentation-maintenance operations on the knowledge wiki (restructures,
-source ingests, lint sweeps). One line per operation, newest last. Infrastructure changes belong in
-each page's `## Changelog` and the Oikos change ledger, not here.
-
-## [2026-07-06] restructure | moved node/infrastructure narratives under knowledge/wiki/; references under knowledge/sources/; repointed inventory doc_page fields and gen-topology.py output.
-## [2026-07-06] lint | banned-vocabulary scan of knowledge/ clean; added .agents/skills/docs-lint and knowledge/wiki/hosts/index.md.
-## [2026-07-06] lint | fixed 126 pre-existing broken links (124-authentik.md rename, investigations/plans moved to archive/done, archive/ sibling depth, destroyed-node delinks); 2 remaining are an intentional cross-repo reference.
-## [2026-07-06] restructure | Phase 6 consolidation: investigations/ -> knowledge/sources/investigations/; operations/ -> .agents/operations/; HERMES.md -> .agents/; deleted root OIKOS/CAVEMAN/CONTRIBUTING stubs.

archive/knowledge/references/cert-sync-and-traefik-config.md

@@ -1,351 +0,0 @@
-# Current cert sync script + traefik dynamic config
-
-Snapshot of the two artifacts that control public service exposure as of
-2026-07-05. Updated 2026-07-05: fixed Jellyfin backend from dead hubris IP
-(192.168.8.206) to new strong IP (192.168.8.246).
-
-## hubris-public-cert-sync.sh (PVE host, `/usr/local/bin/`)
-
-```bash
-#!/bin/bash
-# Mirrors home caddy's LE certs for publicly-exposed hubris.network hostnames
-# into the VPS traefik's /letsencrypt volume. Traefik file-watches the volume
-# and hot-reloads.
-#
-# Why: netbird-proxy's HostSNI(*) TCP passthrough intercepts ACME TLS-ALPN-01
-# challenges before traefik's allowACMEByPass can respond, so traefik can't
-# obtain its own cert. Home caddy uses IONOS DNS-01 (no such conflict);
-# we just mirror what it already has.
-#
-# Runs daily via hubris-public-cert-sync.timer.
-
-set -euo pipefail
-
-CADDY_LXC=121
-CADDY_BASE=/var/lib/caddy/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory
-VPS_HOST=root@100.122.165.149
-VPS_DEST=/var/lib/docker/volumes/opt_netbird_traefik_letsencrypt/_data
-
-# Map: source hostname -> "crt_filename key_filename" on the VPS.
-# Stable names so traefik dynamic.yaml doesn't need edits on renewal.
-declare -A HOSTS=(
-  [artifacto.hubris.network]="fullchain.crt privkey.key"
-  [blog.hubris.network]="blog.fullchain.crt blog.privkey.key"
-  [trmnl.hubris.network]="trmnl.fullchain.crt trmnl.privkey.key"
-  [sso.hubris.network]="sso.fullchain.crt sso.privkey.key"
-  [media.hubris.network]="media.fullchain.crt media.privkey.key"
-  [paperless.hubris.network]="paperless.fullchain.crt paperless.privkey.key"
-)
-
-TMP=$(mktemp -d)
-trap 'rm -rf "$TMP"' EXIT
-
-for host in "${!HOSTS[@]}"; do
-  read -r crt_name key_name <<< "${HOSTS[$host]}"
-  pct pull "$CADDY_LXC" "$CADDY_BASE/$host/$host.crt" "$TMP/$crt_name"
-  pct pull "$CADDY_LXC" "$CADDY_BASE/$host/$host.key" "$TMP/$key_name"
-
-  if ssh -o BatchMode=yes "$VPS_HOST" "test -f $VPS_DEST/$crt_name && diff -q - $VPS_DEST/$crt_name" < "$TMP/$crt_name" >/dev/null 2>&1; then
-    echo "hubris-public-cert-sync: $host unchanged"
-    continue
-  fi
-
-  scp -q -o BatchMode=yes "$TMP/$crt_name" "$TMP/$key_name" "$VPS_HOST:$VPS_DEST/"
-  echo "hubris-public-cert-sync: shipped $host ($(openssl x509 -in "$TMP/$crt_name" -noout -enddate))"
-done
-```
-
-### Adding a new host
-
-1. Caddy must already have the cert (verify `pct exec 121 -- ls "$CADDY_BASE/$host/"`)
-2. Add a line to the HOSTS array: `[new-host.hubris.network]="nickname.fullchain.crt nickname.privkey.key"`
-3. `systemctl start hubris-public-cert-sync.service` to sync immediately
-4. Verify certs landed: `ssh "$VPS_HOST" "ls -la $VPS_DEST/nickname.*"`
-5. Add matching `tls.certificates` entry in traefik dynamic config
-
----
-
-## traefik-dynamic.yaml (VPS, `/opt/`)
-
-```yaml
-tcp:
-  serversTransports:
-    pp-v2:
-      proxyProtocol:
-        version: 2
-
-tls:
-  certificates:
-    - certFile: /letsencrypt/fullchain.crt
-      keyFile: /letsencrypt/privkey.key
-    - certFile: /letsencrypt/blog.fullchain.crt
-      keyFile: /letsencrypt/blog.privkey.key
-    - certFile: /letsencrypt/trmnl.fullchain.crt
-      keyFile: /letsencrypt/trmnl.privkey.key
-    - certFile: /letsencrypt/sso.fullchain.crt
-      keyFile: /letsencrypt/sso.privkey.key
-    - certFile: /letsencrypt/media.fullchain.crt
-      keyFile: /letsencrypt/media.privkey.key
-    - certFile: /letsencrypt/paperless.fullchain.crt
-      keyFile: /letsencrypt/paperless.privkey.key
-
-http:
-  routers:
-    artifacto-public:
-      rule: 'Host(`artifacto.hubris.network`) && (PathPrefix(`/p/`) || PathPrefix(`/static/`) || Path(`/healthz`))'
-      entryPoints:
-        - websecure
-      priority: 10
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - artifacto-strip-sso
-        - artifacto-ratelimit
-      service: artifacto-public
-
-    blog-public:
-      rule: 'Host(`blog.hubris.network`)'
-      entryPoints:
-        - websecure
-      priority: 10
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - blog-ratelimit
-      service: blog-public
-
-    trmnl-public:
-      rule: 'Host(`trmnl.hubris.network`)'
-      entryPoints:
-        - websecure
-      priority: 10
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - trmnl-ratelimit
-      service: trmnl-public
-
-    matrix-public:
-      rule: 'Host(`matrix.hubris.network`) && !PathPrefix(`/.well-known/matrix/`)'
-      entryPoints:
-        - websecure
-      priority: 10
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - matrix-ratelimit
-      service: matrix-public
-
-    matrix-wellknown:
-      rule: 'Host(`matrix.hubris.network`) && (PathPrefix(`/.well-known/matrix/`) || PathPrefix(`/.well-known/acme-challenge/`))'
-      entryPoints:
-        - websecure
-      priority: 20
-      tls:
-        certResolver: letsencrypt
-      service: matrix-wellknown-svc
-
-    house-public:
-      rule: Host(`house.hubris.network`)
-      entryPoints:
-        - websecure
-      priority: 10
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - house-ratelimit
-      service: house-public
-
-    sso-public:
-      rule: 'Host(`sso.hubris.network`)'
-      entryPoints:
-        - websecure
-      priority: 10
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - sso-ratelimit
-      service: sso-public
-
-    media-public:
-      rule: 'Host(`media.hubris.network`)'
-      entryPoints:
-        - websecure
-      priority: 10
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - media-ratelimit
-      service: media-public
-
-    paperless-api-public:
-      rule: 'Host(`paperless.hubris.network`) && PathPrefix(`/api/`)'
-      entryPoints:
-        - websecure
-      priority: 20
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - paperless-ratelimit
-      service: paperless-public
-
-    paperless-public:
-      rule: 'Host(`paperless.hubris.network`)'
-      entryPoints:
-        - websecure
-      priority: 10
-      tls:
-        certResolver: letsencrypt
-      middlewares:
-        - authentik-forwardauth
-        - paperless-ratelimit
-      service: paperless-public
-
-  middlewares:
-    artifacto-strip-sso:
-      headers:
-        customRequestHeaders:
-          X-Artifacto-Gateway: ""
-          X-Authentik-Username: ""
-          X-Authentik-Groups: ""
-          X-Authentik-Email: ""
-          X-Authentik-Name: ""
-          X-Authentik-Uid: ""
-          X-Authentik-Jwt: ""
-          X-Authentik-Meta-Jwks: ""
-          X-Authentik-Meta-Outpost: ""
-          X-Authentik-Meta-Provider: ""
-          X-Authentik-Meta-App: ""
-          X-Authentik-Meta-Version: ""
-
-    admin-allowlist:
-      ipAllowList:
-        sourceRange:
-          - "5.61.168.0/24"
-
-    artifacto-ratelimit:
-      rateLimit:
-        average: 50
-        period: 1s
-        burst: 100
-    blog-ratelimit:
-      rateLimit:
-        average: 100
-        period: 1s
-        burst: 200
-    trmnl-ratelimit:
-      rateLimit:
-        average: 20
-        period: 1s
-        burst: 40
-    matrix-ratelimit:
-      rateLimit:
-        average: 30
-        period: 1s
-        burst: 60
-    house-ratelimit:
-      rateLimit:
-        average: 30
-        period: 1s
-        burst: 60
-    sso-ratelimit:
-      rateLimit:
-        average: 30
-        period: 1s
-        burst: 60
-    media-ratelimit:
-      rateLimit:
-        average: 30
-        period: 1s
-        burst: 60
-    paperless-ratelimit:
-      rateLimit:
-        average: 20
-        period: 1s
-        burst: 40
-    authentik-forwardauth:
-      forwardAuth:
-        address: "http://192.168.8.6:9000/outpost.goauthentik.io/auth/traefik"
-        trustForwardHeader: true
-        authResponseHeaders:
-          - X-authentik-username
-          - X-authentik-groups
-          - X-authentik-email
-          - X-authentik-name
-          - X-authentik-uid
-          - X-authentik-jwt
-          - X-authentik-meta-jwks
-          - X-authentik-meta-outpost
-          - X-authentik-meta-provider
-          - X-authentik-meta-app
-          - X-authentik-meta-version
-
-  services:
-    artifacto-public:
-      loadBalancer:
-        servers:
-          - url: 'http://192.168.8.205:3100'
-    blog-public:
-      loadBalancer:
-        servers:
-          - url: 'http://192.168.8.205:8080'
-    trmnl-public:
-      loadBalancer:
-        servers:
-          - url: 'http://192.168.8.211:9851'
-    matrix-public:
-      loadBalancer:
-        servers:
-          - url: 'http://192.168.8.242:8008'
-    matrix-wellknown-svc:
-      loadBalancer:
-        servers:
-          - url: 'http://matrix-wellknown:80'
-    house-public:
-      loadBalancer:
-        servers:
-          - url: 'http://192.168.8.244:3000'
-    sso-public:
-      loadBalancer:
-        servers:
-          - url: 'http://192.168.8.6:9000'
-    media-public:
-      loadBalancer:
-        servers:
-          - url: 'http://192.168.8.246:8096'
-    paperless-public:
-      loadBalancer:
-        servers:
-          - url: 'http://192.168.8.130:8000'
-```
-
-### Adding a new service — four blocks needed
-
-1. **Router** — `http.routers.<name>-public` with `tls: {}` (not
-   `certResolver`)
-2. **Middleware** — rate limit, one per service
-3. **Service** — `http.services.<name>-public` with the backend URL
-4. **tls.certificates** — add a new `- certFile/keryFile` pair matching the
-   cert sync HOSTS entry
-
-### Key file naming convention
-
-| Cert name | Host | Convention |
-|-----------|------|------------|
-| `fullchain.crt` + `privkey.key` | `artifacto.hubris.network` | First service — no prefix |
-| `blog.fullchain.crt` + `blog.privkey.key` | `blog.hubris.network` | `{nickname}.fullchain.crt` |
-| `trmnl.fullchain.crt` + `trmnl.privkey.key` | `trmnl.hubris.network` | `{nickname}.fullchain.crt` |
-| `sso.fullchain.crt` + `sso.privkey.key` | `sso.hubris.network` | `{nickname}.fullchain.crt` |
-| `media.fullchain.crt` + `media.privkey.key` | `media.hubris.network` | `{nickname}.fullchain.crt` |
-| `paperless.fullchain.crt` + `paperless.privkey.key` | `paperless.hubris.network` | `{nickname}.fullchain.crt` |
-
-### ⚠️ Critical — keep backends in sync after LXC migrations
-
-When moving an LXC between Proxmox nodes, update **both**:
-1. **Caddy** (`/etc/caddy/Caddyfile` on LXC 121)
-2. **VPS traefik** (`/opt/traefik-dynamic.yaml` — via hubris bridge SSH)
-
-Jellyfin migration from hubris to strong (2026-07-05) was fixed in Caddy
-but **missed** in VPS traefik — old IP `192.168.8.206` remained. This caused
-Bad Gateway for off-LAN users. Use Python-based editing (see
-`references/traefik-config-editing.md`) for accurate surgical fixes.

archive/knowledge/sources/index.md

@@ -1,9 +0,0 @@
-# Sources
-
-Immutable evidence the wiki synthesizes from. External reference docs live under `references/`;
-incident evidence lives in [`investigations/`](investigations/index.md) (written once at
-incident time, then linked from the changelogs of the nodes they implicate).
-
-| Slug | Reference | Summary |
-|------|-----------|---------|
-| cert-sync-and-traefik-config | [references/cert-sync-and-traefik-config.md](references/cert-sync-and-traefik-config.md) | VPS traefik config and the LAN↔VPS certificate mirror. |

archive/knowledge/vms/100-zimaos.md

@@ -1,90 +0,0 @@
-# 100 — `zimaos`
-
-ZimaOS (IceWhale / CasaOS-family NAS distro), installed as a Proxmox VM to evaluate it as a potential primary NAS frontend in front of `/mnt/library` — alongside the existing fleet ([nextcloud (114)](../containers/114-nextcloud.md), [jellyfin (101)](../containers/101-jellyfin.md), [mule-images (120)](../containers/120-mule-images.md)).
-
-## At a glance
-- **Type:** QEMU VM
-- **ZimaOS version:** `v1.6.1` (build 2026-04-21, kernel 6.12.25)
-- **IP:** `192.168.8.195` (DHCP lease from the LAN router — see "Open items" below)
-- **Hostname (LAN DNS):** [`zimaos.hubris.network`](../infrastructure/dns.md) → [caddy (121)](../containers/121-caddy.md) `192.168.8.175` → VM `192.168.8.195:80`. TLS terminates at Caddy (Let's Encrypt via IONOS DNS-01).
-- **Resources:** 4 vCPU, 8 GiB RAM (balloon min 2 GiB), 64 GiB OS disk on `local-lvm`
-- **BIOS / machine:** OVMF (UEFI), `q35`, `virtio-scsi-pci`
-- **EFI disk:** none — ZimaOS installer writes a removable-media fallback (`/EFI/BOOT/BOOTX64.EFI`), so a persistent EFI vars disk isn't required. PVE warns "no efidisk configured! Using temporary efivars disk" on start; harmless.
-- **ISO:** `/var/lib/vz/template/iso/zimaos-x86_64-1.6.1_installer.iso` (1.48 GB, from `IceWhaleTech/ZimaOS` GitHub releases; upstream publishes SHA256 only for the `.img`/`.raucb` variants, not the `.iso`)
-
-## Web UI
-
-- **LAN:** <https://zimaos.hubris.network> (via [caddy (121)](../containers/121-caddy.md))
-- **Netbird mesh (off-LAN):** same URL — works because hubris advertises `192.168.8.0/24` into the mesh, and once a peer resolves `zimaos.hubris.network → 192.168.8.175`, the request tunnels home. DNS resolution from a mesh peer needs **either** a netbird Management nameserver group (`hubris.network` match domain → `192.168.8.180`), or an `/etc/hosts` override on the peer (`192.168.8.175 zimaos.hubris.network`). See [mesh](../infrastructure/mesh.md).
-- **Direct fallback:** <http://192.168.8.195> — backend ZimaOS bundles its own Caddy (`Server: Caddy`, `Via: ZimaOS-Gateway`), which the front-end Caddy on LXC 121 reverse-proxies to. Two Caddys in series.
-
-## SSH
-
-Disabled by default. To enable:
-1. Toggle SSH on in the ZimaOS web UI ("Settings → SSH"), OR
-2. From the VM console, switch to TTY2 with **Alt+F2** and run `passwd` to set a root password first.
-
-## Storage strategy
-
-**Initial assumption (didn't work).** PVE 9's native virtiofs share with the host's existing `library` dir mapping (used by [108-haos](108-haos.md)) was the obvious path. Attaching it took one line — but ZimaOS's kernel ships *without* the virtiofs module (`modinfo virtiofs` → `Module virtiofs not found`). The kvm-side device was attached fine; the guest just can't mount it. Detached on 2026-05-14.
-
-**What we ended up with.** A dedicated NFS re-export LXC [102-nfs-export](../containers/102-nfs-export.md) bind-mounts `/mnt/library` from the host and serves it over NFSv4 to ZimaOS. Performance is within ~2% of host-served NFS (LXC adds namespace isolation only, not an IO hop), with the upside that no NFS/RPC daemons run on the bare-metal host. Read-only during evaluation; promote to rw once the UI test confirms behavior.
-
-**Filesystem layout inside ZimaOS.** `/etc/fstab` lives on a writable overlay so persistent mounts via fstab DO survive reboots, but the *standard* path to add a network share is the ZimaOS Files UI (Connect Network Storage → NFS). UID/GID mapping is squashed at the server to `www-data:media` (33:10000) — the same identity Nextcloud and mule-images use — so any rw activity from ZimaOS records as a normal `media`-group write.
-
-**Caveats discovered during install.**
-- Root filesystem is **squashfs / read-only**; only `/DATA` is writable.
-- `dtoro` identity is `uid 999, gid 1000(samba), groups samba+wheel`. Primary group is **`samba`** (not `dtoro` — that group doesn't exist). SSH key needs `chown dtoro:samba` to satisfy sshd StrictModes.
-- `dtoro`'s home directory is literally `/DATA` (not `/home/dtoro`). Authorized keys go at `/DATA/.ssh/authorized_keys`.
-- `/etc` is a writable overlay rooted at `/mnt/overlay/upper_etc`. Mounts added to `/etc/fstab` persist across reboots.
-- `mount.nfs4` is a stripped busybox variant — rejects `_netdev`, `nofail`, `actimeo=N`. The working minimal fstab line: `192.168.8.200:/mnt/library /media/library nfs rw,vers=4 0 0`. **Mount path matters** — see the 2026-05-15 Changelog entry on why the NFS export is mounted at `/media/library` and not `/DATA/library`.
-- No `qemu-guest-agent` is bundled — `qm guest cmd` calls fail. IP discovery via `qm monitor` + `screendump` instead.
-- No package manager at runtime — no `apt`, no `opkg`. Apps come via ZimaOS's CasaOS-style appstore only.
-
-The alternative (dedicated virtual data disk on the `library` lvmthin pool, e.g. `qm set 100 --scsi1 library:1024`) was rejected because it would start empty and force content migration; the NFS path keeps `/mnt/library` as the single source of truth shared with the existing 8 LXCs.
-
-## Open items
-
-- **DHCP → static IP fixed (2026-06-03).** ZimaOS IP drifted from `.195` (Slate AX) → `.103` (Technitium) after the DHCP migration, causing Caddy 502s. Fixed by injecting a static systemd-networkd config and restarting the VM. IP now pinned at `192.168.8.195`. See [changelog](#2026-06-03--static-ip-set-to-195-dhcp-drift-fixed).
-- **No Authentik wiring.** [authentik (124)](../containers/106-auth-outpost.md) isn't enforcing auth in front of ZimaOS yet — ZimaOS handles its own first-run wizard. The Caddyfile block uses bare `reverse_proxy` rather than the `import authentik` pattern used by e.g. artifacto; layer it in once the wizard is complete and a static admin user exists.
-- **No PBS backup.** No Proxmox Backup Server configured on hubris today; this VM is not backed up.
-- **qemu-guest-agent not installed.** ZimaOS's installer doesn't bundle it, so `qm guest cmd 100 ...` returns "QEMU guest agent is not running". IP discovery during this install was done via console screendump → `qm monitor` → `screendump`.
-
-## Related
-- [108 — `haos-16.3`](108-haos.md) — the existing VM, same q35/OVMF pattern; also a virtiofs `library` consumer
-- [DNS](../infrastructure/dns.md) — split-horizon entry lives here
-- [Caddy (121)](../containers/121-caddy.md) — would front this if/when promoted
-- [Media permissions](../infrastructure/media-permissions.md) — relevant when wiring `/mnt/library`
-
-## Changelog
-
-### 2026-06-03 — Static IP set to `.195`; DHCP drift fixed
-ZimaOS had drifted from `.195` (Slate AX DHCP) → `.103` (Technitium DHCP), causing Caddy 502s. Injected `/etc/systemd/network/10-static.network` into overlay (match `en*/eth*`, address `192.168.8.195/24`, gateway `.1`, DNS `.2`). VM restarted; verified reachable at `.195`. Caddy (`zimaos.hubris.network`) now returns 200. See [plan](../../../.hermes/plans/2026-06-03_223218-dhcp-pool-exclude-static-ips.md).
-
-### 2026-05-15 — NFS mount relocated to `/media/library` (UI delete fix)
-
-Symptom: deleting any file or folder inside the NFS-served `library` tree from the ZimaOS Files UI failed with `rename ... invalid cross-device link`. Root cause: ZimaOS's "Move to Trash" is implemented as `rename(2)` into a `.trash/` directory derived from the *drive root*, and icewhale-files identifies the drive root with the regex `^/media/([^/]+)`. With the NFS mounted at `/DATA/library`, the visible UI path was `/media/ZimaOS-HD/library/foo` → drive `ZimaOS-HD` → trash at `/media/ZimaOS-HD/.trash` (which lives on the local ext4 `/dev/sda8`). NFS → ext4 rename = `EXDEV`.
-
-Fix: remount the NFS export at `/media/library` so it sits as its own `/media/<name>` segment. Now icewhale-files extracts drive=`library`, computes trash at `/media/library/.trash`, and the rename stays within the NFS — no cross-device. The local-storage daemon (LSBLK-based) doesn't surface the NFS in the Files-app *sidebar* (drives sidebar only lists block devices), but the icewhale-files daemon picks the mount up as its own "storage" tile in the Files view, and crucially exposes a direct **Delete** action there (no trash flow, since ZimaOS treats non-LSBLK mounts as foreign and skips trash for them). For a 4 TB NFS share, immediate delete is arguably the right behavior anyway.
-
-Concrete change:
-- `/etc/fstab` line changed from `… /DATA/library nfs rw,vers=4 0 0` to `… /media/library nfs rw,vers=4 0 0`.
-- New mountpoint dir `/var/lib/casaos_data/.media/library` (= `/media/library` via the existing `/media` bind).
-- Old `/DATA/library` mountpoint dir removed.
-
-Side effect: navigating via `ZimaOS-HD → library` in the UI now shows an empty/missing folder. Users access the library via the separate `library` tile in the Files app instead.
-
-### 2026-05-14 — Mesh-reachable from netbird peers
-Verified `https://zimaos.hubris.network` reachable from `republic-laptop` (100.122.78.140) through the existing hubris→netbird subnet advertisement (`192.168.8.0/24`). No new infrastructure required — the path was already wired by [mesh](../infrastructure/mesh.md). Open: configure a netbird Management nameserver group for `hubris.network` so peers don't need per-device `/etc/hosts` overrides.
-
-### 2026-05-14 — Phase 2 promoted to rw
-NFS export on [nfs-export (102)](../containers/102-nfs-export.md) flipped from `ro` to `rw` after Files UI evaluation passed. Verified the squash: a write from ZimaOS appears on hubris's `/mnt/library` as `www-data:media` (uid 33, gid 10000), matching the existing tree convention.
-
-### 2026-05-14 — Phase 2: NFS mount via new LXC 102 (read-only)
-Virtiofs path abandoned — ZimaOS kernel 6.12.25 ships without the virtiofs module (verified by `modinfo virtiofs` returning "Module not found"). Pivoted to NFSv4: built [nfs-export (102)](../containers/102-nfs-export.md) as a dedicated 512-MiB privileged Debian LXC bind-mounting `/mnt/library` and serving it on `192.168.8.200:2049` with `ro,all_squash,anonuid=33,anongid=10000` to the LAN subnet. Detached the now-useless `virtiofs0` from VM 100. ZimaOS-side mount via Files UI (NFS protocol, server `192.168.8.200`, path `/mnt/library`). Promote export to `rw` after Files UI evaluation passes.
-
-### 2026-05-14 — Wired through Caddy (HTTPS)
-Added `zimaos.hubris.network` site block to `/etc/caddy/Caddyfile` on [caddy (121)](../containers/121-caddy.md): bare `reverse_proxy 192.168.8.195` + IONOS DNS-01 TLS, same pattern as plato/jellyfin. dnsmasq entry repointed from `192.168.8.195` to `192.168.8.175`. Let's Encrypt cert issued on first request. Caddy commit `a219176` pending push to `dtoro/caddy-conf`.
-
-### 2026-05-14 — VM created, ZimaOS 1.6.1 installed (Phase 1)
-`qm create 100` with q35/OVMF, no EFI disk, 4 vCPU / 8 GiB / 64 GiB on `local-lvm`. Installed via the official ISO (manual console install). Web UI verified at `http://192.168.8.195`. `onboot=1`, `startup order=20`. dnsmasq entry `zimaos.hubris.network → 192.168.8.195` initially added direct-to-VM on [authentik (124)](../containers/106-auth-outpost.md) (later repointed — see above). `/mnt/library` is **not** yet shared into the VM; Phase 2 (virtiofs) is gated on UI evaluation.

archive/knowledge/vms/108-haos.md

@@ -1,44 +0,0 @@
-# 108 — `haos-16.3`
-
-Home Assistant OS — the only VM on hubris (HAOS doesn't run cleanly in an LXC, hence the qm tenant).
-
-## At a glance
-- **Type:** QEMU VM
-- **HAOS version:** 16.3 (last verified)
-- **IP:** `192.168.8.101`
-- **Resources:** 4 GiB RAM, 32 GiB boot disk
-- **Public hostname:** [`home.hubris.network`](../infrastructure/dns.md) → [caddy (121)](../containers/121-caddy.md) → `192.168.8.101:8123`
-
-## Auth
-
-Native OIDC via the HACS integration `christiaangoossens/hass-oidc-auth` (repo `https://github.com/christiaangoossens/hass-oidc-auth`).
-
-Key gotchas:
-- HAOS containers don't honor the Network-panel DNS. Set Supervisor DNS via:
-  ```
-  ha dns options --servers "dns://192.168.8.180" --servers "dns://1.1.1.1"
-  ```
-  so OIDC discovery resolves internally to [authentik (124)](../containers/106-auth-outpost.md).
-- Authentik app slug in the discovery URL is whatever was set in Authentik — confirm via the DB rather than guessing. User set `home-assistant` (with hyphen).
-- YAML config:
-  - `features.automatic_user_linking: true` — link to existing HA users by `preferred_username` match (otherwise a duplicate is created).
-  - `features.default_redirect: true` — skip the welcome-splash so users land on the normal HA login page.
-- Run `ha core restart` after each config change — HA caches DNS and OIDC discovery across frontend reloads.
-
-## Telemetry
-
-HA pulls Proxmox metrics via the official Proxmox VE integration. As of 2026-04-21 [claudio-monitor](../infrastructure/monitoring.md) stopped publishing to MQTT/REST (commit `82f0596`) — HA gets metrics from PVE directly; claudio-monitor focuses on alerting.
-
-## Related
-- [Authentik (124)](../containers/106-auth-outpost.md)
-- [Caddy (121)](../containers/121-caddy.md)
-- [DNS](../infrastructure/dns.md)
-- [Monitoring](../infrastructure/monitoring.md)
-
-## Changelog
-
-### 2026-04-28 — wiki entry created
-Initial documentation.
-
-### 2026-04-21 — wired into Authentik via HACS hass-oidc-auth
-Supervisor DNS pointed at LXC 124 dnsmasq; YAML features for auto-linking + default redirect.

archive/knowledge/vms/index.md

@@ -1,14 +0,0 @@
-# VMs — index
-
-Two QEMU VMs running on [hubris](../hosts/hubris.md):
-
-| ID | Name | Role | IP | Public hostname |
-|----|------|------|----|-----------------|
-| 100 | [zimaos](100-zimaos.md) | NAS frontend eval (ZimaOS) | `192.168.8.195` | [`zimaos.hubris.network`](../infrastructure/dns.md) |
-| 108 | [haos-16.3](108-haos.md) | Home automation (HAOS) | `192.168.8.101` | [`home.hubris.network`](../infrastructure/dns.md) |
-
-## Related
-
-- [Hubris host](../hosts/hubris.md) — both VMs run here
-- [Containers index](../containers/index.md) — LXCs on both nodes
-- [README](../../../README.md)

archive/ledger/2026-07.jsonl

@@ -1,5 +0,0 @@
-{"ts": "2026-07-06T11:05:35+00:00", "agent": "mac-mini", "entity": "host:teddycloud", "action": "activate", "risk": "config_mutation", "verification": "homelab node teddycloud relations", "result": "ok"}
-{"ts": "2026-07-06T11:15:04+00:00", "agent": "mac-mini", "entity": "repo:Homelab-Docs", "action": "register-webhook", "risk": "config_mutation", "result": "ok", "notes": "webhook id 14 for oikos-console deploy"}
-{"ts": "2026-07-06T11:29:56+00:00", "agent": "mac-mini", "entity": "service:caddy", "action": "add-site-block", "risk": "config_mutation", "verification": "curl -s https://git.hubris.network (unrelated route still healthy after reload)", "result": "ok", "notes": "oikos.hubris.network -> 192.168.8.205:8091, Authentik-gated, in dtoro/caddy-conf@c195142"}
-{"ts": "2026-07-06T11:40:28+00:00", "agent": "mac-mini", "entity": "host:dns", "action": "add-record", "risk": "config_mutation", "verification": "dig @192.168.8.2 +short oikos.hubris.network", "result": "ok", "notes": "oikos.hubris.network A -> 192.168.8.175 (Caddy LAN IP), via Technitium API, no token persisted"}
-{"ts": "2026-07-06T11:57:21+00:00", "agent": "mac-mini", "entity": "host:apps", "action": "deploy-oikos-console", "risk": "config_mutation", "verification": "curl http://127.0.0.1:8091/ on apps -> 200; https://oikos.hubris.network/ -> 302 (Authentik gate)", "result": "ok"}

archive/oikos-cards/cards/host-apps.md

@@ -1,21 +0,0 @@
-# apps (host:apps)
-
-- kind: lxc (LXC 105)
-- state: active
-- runs-on: host:hubris
-- role: docker-apps
-- address: 192.168.8.205 (mesh: tailscale:apps)
-- mounts: /mnt/library
-- doc: knowledge/wiki/containers/105-apps.md
-- secrets: enrolled (age key present)
-
-## Blast radius
-- impacts: service:artifacto, service:homelab_mcp, service:secrets_issuance
-- affected by: host:hubris, mount:/mnt/library, repo:dtoro/Artifacto, repo:dtoro/Homelab-Docs
-- full blast radius: service:artifacto, service:homelab_mcp, service:secrets_issuance
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- 2026-07-06T11:57:21+00:00 deploy-oikos-console (config_mutation) — ok

archive/oikos-cards/cards/host-arriman.md

@@ -1,20 +0,0 @@
-# arriman (host:arriman)
-
-- kind: lxc (LXC 122)
-- state: active
-- runs-on: host:strong
-- role: arr-stack
-- address: 192.168.8.245 (mesh: tailscale:arr)
-- mounts: /mnt/media_local
-- doc: knowledge/wiki/containers/122-arriman.md
-
-## Blast radius
-- impacts: service:arr_stack
-- affected by: host:strong, mount:/mnt/media_local
-- full blast radius: service:arr_stack
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-auth-outpost.md

@@ -1,18 +0,0 @@
-# auth-outpost (host:auth-outpost)
-
-- kind: lxc (LXC 106)
-- state: active
-- runs-on: host:hubris
-- role: authentik-gateway
-- address: 192.168.8.6
-- doc: knowledge/wiki/containers/106-auth-outpost.md
-
-## Blast radius
-- impacts: (none)
-- affected by: host:hubris
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-caddy.md

@@ -1,19 +0,0 @@
-# caddy (host:caddy)
-
-- kind: lxc (LXC 121)
-- state: active
-- runs-on: host:hubris
-- role: reverse-proxy
-- address: 192.168.8.175
-- doc: knowledge/wiki/containers/121-caddy.md
-
-## Blast radius
-- impacts: service:caddy
-- affected by: host:hubris, repo:dtoro/caddy-conf
-- full blast radius: service:caddy
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-dns.md

@@ -1,19 +0,0 @@
-# dns (host:dns)
-
-- kind: lxc (LXC 107)
-- state: active
-- runs-on: host:hubris
-- role: dns-server
-- address: 192.168.8.2
-- doc: knowledge/wiki/containers/107-dns.md
-
-## Blast radius
-- impacts: service:dns
-- affected by: host:hubris
-- full blast radius: service:dns
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- 2026-07-06T11:40:28+00:00 add-record (config_mutation) — ok

archive/oikos-cards/cards/host-elementsynapse.md

@@ -1,19 +0,0 @@
-# elementsynapse (host:elementsynapse)
-
-- kind: lxc (LXC 118)
-- state: active
-- runs-on: host:strong
-- role: matrix-server
-- address: 192.168.8.242
-- doc: knowledge/wiki/containers/118-elementsynapse.md
-
-## Blast radius
-- impacts: service:matrix
-- affected by: host:strong
-- full blast radius: service:matrix
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-gitea.md

@@ -1,20 +0,0 @@
-# gitea (host:gitea)
-
-- kind: lxc (LXC 104)
-- state: active
-- runs-on: host:hubris
-- role: git-server
-- address: 192.168.8.121 (mesh: tailscale:gitea)
-- mounts: /mnt/library
-- doc: knowledge/wiki/containers/104-gitea.md
-
-## Blast radius
-- impacts: service:gitea
-- affected by: host:hubris, mount:/mnt/library, repo:dtoro/gitea-customizations
-- full blast radius: service:gitea
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-grimmory.md

@@ -1,20 +0,0 @@
-# grimmory (host:grimmory)
-
-- kind: lxc (LXC 130)
-- state: active
-- runs-on: host:strong
-- role: book-library
-- address: 192.168.8.247
-- mounts: /mnt/media_local
-- doc: knowledge/wiki/containers/130-grimmory.md
-- secrets: enrolled (age key present)
-
-## Blast radius
-- impacts: (none)
-- affected by: host:strong, mount:/mnt/media_local
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-haos.md

@@ -1,19 +0,0 @@
-# haos (host:haos)
-
-- kind: vm (VM 108)
-- state: active
-- runs-on: host:hubris
-- role: home-automation
-- address: 192.168.8.101 (mesh: tailscale:homeassistant)
-- doc: knowledge/wiki/vms/108-haos.md
-
-## Blast radius
-- impacts: service:haos
-- affected by: host:hubris
-- full blast radius: service:haos
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-house.md

@@ -1,19 +0,0 @@
-# house (host:house)
-
-- kind: lxc (LXC 129)
-- state: active
-- runs-on: host:strong
-- role: family-planner
-- address: 192.168.8.244
-- doc: knowledge/wiki/containers/129-house.md
-- secrets: enrolled (age key present)
-
-## Blast radius
-- impacts: (none)
-- affected by: host:strong
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-hubris.md

@@ -1,20 +0,0 @@
-# hubris (host:hubris)
-
-- kind: proxmox-host
-- state: active
-- role: hypervisor
-- address: 192.168.8.77 (mesh: netbird:proxmox-server.netbird.selfhosted)
-- mounts: /mnt/library
-- doc: knowledge/wiki/hosts/hubris.md
-- secrets: enrolled (age key present)
-
-## Blast radius
-- impacts: host:apps, host:auth-outpost, host:caddy, host:dns, host:gitea, host:haos, host:mule-images, host:nextcloud, host:nfs-export, host:paperless, host:sophia, host:teddycloud, host:trmnl, host:zimaos, service:proxmox_ui
-- affected by: mount:/mnt/library
-- full blast radius: host:apps, host:auth-outpost, host:caddy, host:dns, host:gitea, host:haos, host:mule-images, host:nextcloud, host:nfs-export, host:paperless, host:sophia, host:teddycloud, host:trmnl, host:zimaos, service:artifacto, service:caddy, service:dns, service:gitea, service:haos, service:homelab_mcp, service:nextcloud, service:paperless, service:photos, service:proxmox_ui, service:secrets_issuance, service:teddycloud, service:trmnl, service:zimaos
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-jellyfin.md

@@ -1,20 +0,0 @@
-# jellyfin (host:jellyfin)
-
-- kind: lxc (LXC 101)
-- state: active
-- runs-on: host:strong
-- role: media-server
-- address: 192.168.8.246 (mesh: tailscale:jellyfin)
-- mounts: /mnt/media_local
-- doc: knowledge/wiki/containers/101-jellyfin.md
-
-## Blast radius
-- impacts: service:jellyfin
-- affected by: host:strong, mount:/mnt/media_local
-- full blast radius: service:jellyfin
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-mac-mini.md

@@ -1,17 +0,0 @@
-# mac-mini (host:mac-mini)
-
-- kind: workstation
-- state: active
-- role: dev
-- address: 192.168.178.182 (mesh: netbird:mac-mini-234-17.netbird.selfhosted)
-- secrets: enrolled (age key present)
-
-## Blast radius
-- impacts: (none)
-- affected by: (none)
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-mule-images.md

@@ -1,20 +0,0 @@
-# mule-images (host:mule-images)
-
-- kind: lxc (LXC 120)
-- state: active
-- runs-on: host:hubris
-- role: photo-management
-- address: 192.168.8.136 (mesh: tailscale:muleimage)
-- mounts: /mnt/library
-- doc: knowledge/wiki/containers/120-mule-images.md
-
-## Blast radius
-- impacts: service:photos
-- affected by: host:hubris, mount:/mnt/library, repo:dtoro/mule-image
-- full blast radius: service:photos
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-netbird-vps.md

@@ -1,17 +0,0 @@
-# netbird-vps (host:netbird-vps)
-
-- kind: external
-- state: active
-- role: netbird-mgmt
-- address:  (mesh: netbird:netbird-ionos.netbird.selfhosted)
-
-## Blast radius
-- impacts: service:authentik
-- affected by: (none)
-- full blast radius: service:authentik
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-nextcloud.md

@@ -1,20 +0,0 @@
-# nextcloud (host:nextcloud)
-
-- kind: lxc (LXC 114)
-- state: active
-- runs-on: host:hubris
-- role: file-sync
-- address: 192.168.8.224 (mesh: tailscale:nextcloud)
-- mounts: /mnt/library
-- doc: knowledge/wiki/containers/114-nextcloud.md
-
-## Blast radius
-- impacts: service:nextcloud
-- affected by: host:hubris, mount:/mnt/library
-- full blast radius: service:nextcloud
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-nfs-export.md

@@ -1,18 +0,0 @@
-# nfs-export (host:nfs-export)
-
-- kind: lxc (LXC 102)
-- state: active
-- runs-on: host:hubris
-- role: storage-export
-- address: 192.168.8.200
-- doc: knowledge/wiki/containers/102-nfs-export.md
-
-## Blast radius
-- impacts: (none)
-- affected by: host:hubris
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-paperless.md

@@ -1,20 +0,0 @@
-# paperless (host:paperless)
-
-- kind: lxc (LXC 103)
-- state: active
-- runs-on: host:hubris
-- role: document-archive
-- address: 192.168.8.130 (mesh: tailscale:paperless)
-- mounts: /mnt/library
-- doc: knowledge/wiki/containers/103-paperless.md
-
-## Blast radius
-- impacts: service:paperless
-- affected by: host:hubris, mount:/mnt/library
-- full blast radius: service:paperless
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-rclone.md

@@ -1,17 +0,0 @@
-# rclone (host:rclone)
-
-- kind: lxc
-- state: active
-- role: backup
-- address:  (mesh: netbird:rclone.netbird.selfhosted)
-- secrets: enrolled (age key present)
-
-## Blast radius
-- impacts: (none)
-- affected by: (none)
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-republic-laptop.md

@@ -1,16 +0,0 @@
-# republic-laptop (host:republic-laptop)
-
-- kind: workstation
-- state: active
-- role: primary-dev
-- address:  (mesh: netbird:republic-laptop.netbird.selfhosted)
-
-## Blast radius
-- impacts: (none)
-- affected by: (none)
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-romm.md

@@ -1,19 +0,0 @@
-# romm (host:romm)
-
-- kind: lxc (LXC 134)
-- state: active
-- runs-on: host:strong
-- role: rom-manager
-- address: 192.168.8.249
-- mounts: /mnt/media_local
-- doc: knowledge/wiki/containers/134-romm.md
-
-## Blast radius
-- impacts: (none)
-- affected by: host:strong, mount:/mnt/media_local
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-seanime.md

@@ -1,19 +0,0 @@
-# seanime (host:seanime)
-
-- kind: lxc (LXC 133)
-- state: active
-- runs-on: host:strong
-- role: anime-media-server
-- address: 192.168.8.248
-- mounts: /mnt/media_local/anime
-- doc: knowledge/wiki/containers/133-seanime.md
-
-## Blast radius
-- impacts: (none)
-- affected by: host:strong, mount:/mnt/media_local/anime
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-sophia.md

@@ -1,19 +0,0 @@
-# sophia (host:sophia)
-
-- kind: lxc (LXC 119)
-- state: active
-- runs-on: host:hubris
-- role: workshop
-- address: 192.168.8.109 (mesh: tailscale:sophia)
-- mounts: /mnt/library
-- doc: knowledge/wiki/containers/119-sophia.md
-
-## Blast radius
-- impacts: (none)
-- affected by: host:hubris, mount:/mnt/library
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)

archive/oikos-cards/cards/host-strong.md

@@ -1,19 +0,0 @@
-# strong (host:strong)
-
-- kind: proxmox-host
-- state: active
-- role: hypervisor
-- address: 192.168.178.181
-- doc: knowledge/wiki/hosts/strong.md
-- secrets: enrolled (age key present)
-
-## Blast radius
-- impacts: host:arriman, host:elementsynapse, host:grimmory, host:house, host:jellyfin, host:romm, host:seanime
-- affected by: (none)
-- full blast radius: host:arriman, host:elementsynapse, host:grimmory, host:house, host:jellyfin, host:romm, host:seanime, service:arr_stack, service:jellyfin, service:matrix
-
-## Safe actions
-- see the services this host runs for action-level risk classes
-
-## Recent changes
-- (none yet)