dank/command-center
1
0 Fork 0
Code Issues 11 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(system): the fleet re-read from the boxes, and the math that no longer belongs here

Browse Source 
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
This commit is contained in:
Frank committed 2026-10-21 02:22:37 -07:00
1 parent fb36a1b0fd
commit 54bb0202c2
3 files changed
+32 -17
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

omp-docs/system/network.md
+7 -6
View File
@@ -8,7 +8,7 @@ tags:
- systemd-resolved
- workstation
- unverified
verified: 2026-08-28
verified: 2026-10-21
---
# Network
@@ -23,11 +23,12 @@ bites every Linux workstation with both Wi-Fi and Ethernet plugged in.
| 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, large inference model |
| Dankserver | 192.168.0.235 | small inference model |
| 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 hands clients `192.168.0.143` as their DNS server; Pi-hole answers
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
@@ -88,8 +89,8 @@ A single successful `dig` proves nothing on a flapping resolver.
## Servers
- [Dankserver](/system/dankserver.md) — small inference model
- [Dankclaw](/system/dankclaw.md) — large inference model, DNS, proxy
- [Dankserver](/system/dankserver.md) — main model, `frank-archon`
- [Dankclaw](/system/dankclaw.md) — secondary models, DNS, edge, forge
## See Also