Frank
54bb0202c2
Three pages described the fleet; two of them still described the pre-September arrangement. Re-read live on 2026-10-21 (`/v1/models`, `systemctl`, `lspci`, `nproc`, `resolvectl`): - `system/network.md` called Dankclaw the "large inference model" box and Dankserver the "small" one — that is the topology from before the RTX 3090 moved in September. The served ids today are `frank-archon` on Dankserver:7770 (the main model) and `frank-dragoon` (:7770) + `frank-zealot` (:7771) on Dankclaw. The gateway and the DNS pin were re-read too. - `system/dankserver.md` claimed `frank-medium` is *masked*: the unit file does not exist (`is-enabled` answers `not-found`), which is a different fact with a different remedy. And it claimed 8C/16T: this 7700X exposes **8 threads** (`nproc` = 8), so anything sized for 16 is sized for a machine that is not this one. - `system/dankclaw.md` transcribed the engine's slot/KV/context math — `2×262,144 slots over one 524,288 pool, unquantized f16 K+V, MTP off` — while the live unit says `3x200704 slots over one 602112 pool, f16 K + q8_0 V, MTP armed`, and dragoon's ctx had moved too. That math belongs to the serverAppConfigs runbook the page already names: the unit's `ExecStart` is a wrapper script, so any copy here rots on the next engine change. The page now keeps the contract — id, unit, port, engine family, which GPU, and how to prove it — and disowns the numbers, with the reason stated so the next agent does not re-transcribe them. Also recorded, because it is how this audit nearly missed a stopped service: `curl :7770/v1/models` answered normally while `frank-dragoon.service` sat `inactive` with `Result=exit-code` — the container is running outside systemd. A serving port is not a healthy unit. (Flagged for Frank separately; no production unit was touched.) Refs #64
3.4 KiB
type, title, description, tags, verified
| type | title | description | tags | verified | |||||
|---|---|---|---|---|---|---|---|---|---|
| reference | Network | LAN topology for the fleet and the client-side DNS pinning rule for multi-homed Linux workstations. |
|
2026-10-21 |
Network
How the LAN is addressed, which host answers what, and the one DNS rule that bites every Linux workstation with both Wi-Fi and Ethernet plugged in.
Topology
| Host | IP | Role |
|---|---|---|
| Router | 192.168.0.1 | DHCP; hands out the DNS server to clients |
| Dankclaw | 192.168.0.143 | Pi-hole DNS, Caddy edge, Gitea, service stack, secondary inference (frank-dragoon :7770, frank-zealot :7771) |
| Dankserver | 192.168.0.235 | Main inference — frank-archon on 2× R9700 (TP=2), :7770 |
| Clients | DHCP from 192.168.0.0/24 | workstations, phones |
The router (default gateway 192.168.0.1, both re-read 2026-10-21) hands clients
192.168.0.143 as their DNS server; Pi-hole answers
every *.franksdank.cloud name with the LAN address of the box that serves
it. Names that resolve to the public WAN address time out on the LAN because
the G36 has no NAT loopback — a symptom that looks like "the network is
down" and is not. Full DNS mechanics live in the serverAppConfigs knowledge
base (Infrastructure/LAN-DNS.md); this page is the client-side view.
The multi-link resolver rule
A Linux client with two +DefaultRoute links will flap its DNS.
NetworkManager marks both a wired and a Wi-Fi connection as default routes.
Both get the same DHCP DNS list from the router, and systemd-resolved
resolves queries against one "current" resolver per link. When the links
disagree — one landed on the Pi-hole address, the other on a DHCP-provided
upstream that answers with the public WAN IP — every lookup can return a
different address, and half of them time out on the LAN.
Enumerate the links and their resolvers before changing anything:
nmcli -t -f NAME,DEVICE connection show --active # one entry per default link
resolvectl status # per-link "Current DNS Server"
ip -br addr
The fix is to pin the LAN resolver on each connection, because
/etc/systemd/resolved.conf's DNS= is only a per-link fallback and does
not override what the link itself was handed:
for c in "<wired connection>" "<wifi connection>"; do
nmcli connection modify "$c" ipv4.method auto \
ipv4.dns 192.168.0.143 \
ipv4.ignore-auto-dns yes \
ipv4.ignore-auto-routes no
done
nmcli connection up "<wired connection>"
nmcli connection up "<wifi connection>"
systemctl restart systemd-resolved
method auto keeps DHCP for address, gateway, and routes; ignore-auto-dns yes makes the static resolver the only one used; ignore-auto-routes no
keeps the DHCP routes, so the dual-default traffic path survives.
Verify with a cache-clear loop — the name must return the LAN address on every run, not on average:
for i in $(seq 1 10); do resolvectl flush-caches; dig romm.franksdank.cloud +short; done
A single successful dig proves nothing on a flapping resolver.
Servers
- Dankserver — main model,
frank-archon - Dankclaw — secondary models, DNS, edge, forge
See Also
- System Documentation — bundle navigation
- CachyOS — NetworkManager, systemd-resolved, BlueZ