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:
1 parent
da981a7b40
commit
32a60f0c6e
3 files changed
+106
-1
No files matched your search
@@ -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. |
|
||||
|
||||
Reference in new issue
Block a user