vh
fed29be04e
The coordinator arrived on esh-userland (VLAN 10) at a DHCP-assigned 10.0.10.58. It now sits on esh-iot (VLAN 90) at 10.0.90.10, reserved on the UDM and named slzb-mr1u.esh.internal. Address on the network side, not the device — the pfi-gx10 ruling: a reservation moves with the hardware, a device-side static goes stale. 10.0.90.10 is below the 10.0.90.40-250 pool so it cannot be handed out. The MAC is locally administered (ea:f6:0a:ca:f5:b4, no OUI), which is exactly the case where a reservation can silently stop matching. The PoE power-cycle that makes the device re-DHCP is also the stability test, so it cost nothing: it rebooted and came back on exactly 10.0.90.10, which only happens if the MAC held. ESH-Media carried 8 port_overrides and that PUT is a whole-array replace, so the array was diffed to prove exactly one field on one port changed before sending, and read back after. Inter-VLAN reachability needed no firewall work and was proven from inside the HA container before the move, against existing IoT devices. Testing from the Docker host would have proven the wrong thing — HA runs on a macvlan address, 10.0.50.46, not the host's 10.0.50.45. Documented but NOT fixed: the HA container cannot resolve any .internal name (its resolver is Docker's 127.0.0.11, upstream excludes the fleet AdGuard). Pre-existing, verified against names that predate this change. HA should be configured with the IP; changing the DNS of a live home-automation stack is ha-dev's call.
docs/
Navigation map for the documentation tree. New session? Read
orientation.md first — it's the narrative overview
of the fleet, backup architecture, governing principles, and gotchas,
and it points at everything else.
Tree
docs/
├── orientation.md # start here — fleet overview + where-to-look guide
├── runbooks/ # ops runbooks (recovery, deployment phases)
│ ├── disaster-recovery.md
│ ├── nh3-prune-ritual.md
│ └── pbs-deployment.md
└── pfi/ # PFI-specific reference (services, models, VMs)
├── docker-stack.md
├── model-list.md
├── proxmox-vms.md
├── recommended-model-settings.md
├── vm-102-matrix-appservice.md
└── vm-102-matrix-synapse.md
What goes where
runbooks/— step-by-step ops procedures. Anything you'd reach for during an incident or while standing up new infrastructure. Examples: disaster recovery (blast-radius tiers + restoration steps), PBS deployment (9-phase rollout). New runbook → new file here.pfi/— PFI-specific reference material that's too narrow for the top-level CLAUDE.md but doesn't change incident response. AI model inventory, recommended inference settings, Matrix bridge config, Proxmox VM map. New stable reference → new file here.- Top-level (
docs/orientation.md,docs/README.md) — narrative guides about the workspace itself, not about specific infra.
Cross-references
- Fleet topology + servers table: top-level
CLAUDE.md. - Open work + recent milestones: top-level
STATUS.md. - Durable cross-session facts:
~/.claude/projects/-home-lkraven-development-eshpfi-management/memory/.
Conventions
- Markdown, GitHub-flavored. CommonMark renders fine in most viewers.
- File names are lowercase-kebab-case, descriptive. No dates in filenames — git history covers that.
- One topic per file. If a file grows past ~500 lines, look for a natural split before adding more.
- No checked-in binaries or checksums. Build/release artifacts belong
in a build pipeline or
tools/, notdocs/.