docs: Unraid as a Herdr machine, and why it needed a --via wrapper

herdr-core machine add kept failing with "core did not start within 5 s".
Cause: hc puts its core socket under XDG_RUNTIME_DIR, which on Unraid is
/run/user/0 — created and destroyed per login session by elogind. The socket
vanished with the session that started the core, so later clients found an
empty directory. The core itself kept running on an unlinked socket, and
core.log stayed empty because the failure is client side.

Fixed entirely on the Mac with a --via transport that pins
XDG_RUNTIME_DIR=/var/run/herdr-rt. Nothing on the server was changed. The
transport uses key auth on 192.168.10.20:422, not Tailscale SSH, since --via
needs something that asks nothing and the default tailnet ACL demands
periodic browser re-auth.

Also records the reboot caveat (/ is RAM, so the remote hc binary is lost)
with a go-script fix written up but not applied, and corrects the
192.168.31.0/24 note: that shim was created for a Pi-hole that AdGuard
replaced.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Kaloyan DanchevandClaude Opus 5 committed 2026-11-03 22:29:40 +02:00
1 parent da981a7b40
commit 32a60f0c6e
3 files changed
+106 -1

No files matched your search

+1 -1
View File
@@ -228,7 +228,7 @@ logged out since roughly May 2026 and was re-enrolled on 2026-11-03.
| Pref | Value | Reason |
|------|-------|--------|
| `--advertise-routes` | none | The old `192.168.31.0/24` advertisement was dropped. That subnet is only the macvlan shim (`br0-shim` holds `192.168.31.250/32` with one host route to `192.168.31.4`) — nothing reachable lives there. |
| `--advertise-routes` | none | The old `192.168.31.0/24` advertisement was dropped. That subnet is only the macvlan shim created in `/boot/config/go` for a Pi-hole at `192.168.31.4`. Pi-hole was replaced by AdGuard: there is no such container any more and the address is silent, so nothing reachable lives there. |
| LAN subnet routing | not advertised | The MikroTik container is primary for `192.168.10.0/24`, `.20`, `.25`, `.30`. A second advertiser for a subnet Unraid itself sits on would create a routing conflict. |
| `--advertise-exit-node` | on | Redundant with the hAP today, kept as a fallback on the 24/7 box. **Approved in the admin console 2026-11-03** — shows as `offers exit node` and appears in `tailscale exit-node list`. |
| `--accept-routes` | **false** | Critical. Unraid is *on* `192.168.10.0/24`; accepting the hAP's route for its own subnet would loop. This is why `tailscale status` reports the health warning "Some peers are advertising routes but --accept-routes is false" — expected here, not a fault. |