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>
Approved in the Tailscale admin console, so xtrm-unraid now shows as
"offers exit node" and appears in tailscale exit-node list. The tailnet has
two exit nodes: mikrotik-tailscale (primary) and xtrm-unraid (fallback).
Neither has been exercised from the Mac. Noted that without
--exit-node-allow-lan-access an exit node cuts the client's own LAN access,
which would break an SSH session routed over Tailscale.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Unraid's Tailscale plugin node had been logged out since roughly May 2026.
Re-enrolled as xtrm-unraid (100.100.208.69); the stale 100.100.208.70 node
was deleted first, so the tailnet issued a new address.
Dropped the old 192.168.31.0/24 advertisement — that subnet is only the
macvlan shim and nothing reachable lives there. No LAN subnet routes are
advertised from Unraid; the MikroTik container stays primary. accept-routes
and accept-dns stay off, the former because Unraid sits on 192.168.10.0/24
and would otherwise loop.
Tailscale SSH enabled, since sshd binds only 192.168.10.20 and
192.168.31.250 and so never listens on the Tailscale IP. Port forwarding
over it verified.
Exit node advertised, pending approval in the admin console.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Xiaomi miIO/MIoT devices silently ignore UDP packets from source IPs
outside their subnet. Added SRCNAT masquerade rule documentation for
VLAN 10 → VLAN 30 on UDP 54321, enabling HA local control of air
purifiers and other Xiaomi WiFi devices.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The country=United States override existed to reach UNII-3 (5745 MHz),
which is not permitted in the EU. It cost more than it gained: clients in
the BG regulatory domain were power-restricted on those channels.
Setting country=Bulgaria raised the test client from 241 to 295 Mbps
immediately and ~451 Mbps once rate adaptation settled, with client signal
improving from -72 to -67 dBm. Total gain this session: 38 -> 451 Mbps.
Also:
- cfg-xtrm security.encryption tkip -> ccmp (provisioning rule 0 would
have handed TKIP to any new 5GHz CAP interface, forcing legacy rates)
- cap-wifi1 moved to 5220 MHz (ch 44, non-DFS, legal in BG); still disabled
- Corrected: HAP wifi2 is disabled with encryption="", not tkip
- Noted that country does NOT hard-block an illegal frequency
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Channel 149 (UNII-3) is not permitted in Bulgaria/EU. The radio reached it
via country=United States, but BG-domain clients were power-restricted
there, giving a badly asymmetric link and ~38 Mbps at the desk.
Moving to 5180 MHz (ch 36), legal in BG and non-DFS, raised the same
client to ~241 Mbps.
Also corrected:
- CAP capdp datapath is vlan-id=30, not 40
- RouterOS versions: hAP, cAP XL and cAP AC are all on 7.23.3
- Added WAN baseline: ~880 Mbps down / ~720 Mbps up on a 1 Gbps ONT link
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Audit 2026-08-07 found dns-failover-down NAT script pointed DNS traffic
at 192.168.10.10:3000 (AdGuard web UI) instead of :53 (DNS resolver).
On real failover this would have broken DNS network-wide. Fixed live on
MikroTik and verified with controlled failover test.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
5-view Mushroom dashboard deployed to HAOS via init_commands technique
(file-based YAML cannot be saved via lovelace/config/save WebSocket).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Compose stack at appdata/immich, exposed via Traefik at photos.xtrm-lab.org
- Library on cache NVMe (raidz1), Postgres on cache
- Nightly backup (DB dump + originals rsync) to parity-protected array disk1
- Google Takeout import ready via immich-go v0.32.0
The flash-attention + q8_0 KV cache settings were removed after they (and the
gfx1103 ROCm path generally) crash on large prompts. Document that the 780M iGPU
is direct/interactive-chat only, not an agent backend (Hermes ~15.5k-token prompt
crashed every call; reverted to cloud model).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Document ollama migrated to Dockge stack on ollama/ollama:rocm with
gfx1103 enablement (HSA_OVERRIDE_GFX_VERSION=11.0.0, OLLAMA_IGPU_ENABLE=1)
- Verified Ornith 1.0 9B runs 100% on the 780M iGPU (~11 tok/s)
- CHANGELOG entry for 2026-06-29
- (also includes previously-uncommitted Development services section
already present in the working tree)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Replace v1 AUTOKUMA_DOCKER=1 with v2 env vars (ENABLED, HOSTS, SOURCE)
- Rewrite traefik-manager labels in v2 4-part syntax: kuma.<id>.<type>.<setting>
- Delete manually-created monitor #38; AutoKuma recreates it (now #39) cleanly
- Document v2 label requirements and the remaining v1-label migration
Default AUTOKUMA__DOCKER__SOURCE is Swarm Services — must be set to
Containers for standalone Docker. v2 also doesn't accept the v1 shorthand
(kuma=URL + kuma.name=... + kuma.type=...), only the explicit 4-part form.
- Pinned traefik-manager to 172.18.0.4 (was floating in the dynamic pool)
- Added Uptime Kuma monitor id=38 "Traefik Container (direct)" — TCP probe
at 172.18.0.3:80, decoupled from the routing-layer HTTP probe so a
Traefik container failure is distinguishable from a routing breakage
- Documented that AutoKuma v2 is silently broken; monitor was created via
direct SQL insert as a workaround
Recreated dockerproxy network with --ip-range 172.18.0.128/25 so Docker
auto-allocations are isolated from the .2-.127 static reservation block.
Eliminates IP-collision class that caused the 2026-05-17 Traefik outage.
Adds 13-DOCKERPROXY-NETWORK.md as the canonical reference for the
network spec, recreate command, and current IP assignments.
Fixed Transport endpoint not connected error — Plex volume mount
needed :rslave propagation to see rclone FUSE mount from zurg.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
