463 lines with 64 mentions of specific hosts, in a public repo: the primary and tunnel hosts by name, the registrar/DNS step, the tunnel resource wiring, shared token custody, per-machine flip dates, and a palace lineage naming three work machines. Now in the private fleet repo (fleet-ops 093fb65); this file becomes a moved-note in the shape docs/synlig-primary-runbook.md already established. Git history keeps the old text, so this limits future exposure rather than undoing it. Unlike the primary-host runbook, this file was MIXED — and the stub says so instead of quietly implying the toolkit still documents HTTP exposure. §1.1-§1.3 (why one shared fleet token rather than per-device proxy users, and the one place per-device identity does exist), §2 (the bind trap and the Host/Origin pin) and §3.7 (a client is flipped by three env vars that travel as a set) are reusable mechanism now published nowhere else. Named in the stub so the extraction is tracked debt rather than a silent loss, and named in the private copy too so whoever extracts it can delete the duplicate. Inbound references fixed rather than left pointing at content that moved: two §3.8 pointers in extensions/pi/README.md are replaced by the instruction they were pointing at (the palace path reported by mempalace_status must be the remote host's — a half-flipped client looks healthy while reporting a local path), and the bind-trap reference is replaced by the Host/Origin sentence itself, so the extension README no longer depends on the moved file. contrib also loses a hostname and a seeding date it did not need to make its point.
2.8 KiB
(moved) Phase 1 exposure runbook
This file used to contain the Phase 1 exposure record for one specific deployment — the primary host and tunnel host by name, the DNS registrar step, the Pangolin/newt resource wiring, the shared-token handling, per-machine flip dates, and a palace lineage naming three work machines.
That content now lives in a private repository, for the same reason
synlig-primary-runbook.md does: a host inventory
is operator data for one deployment, not part of the toolkit. This repository is
public and keeps only host-agnostic mechanism.
What lives where:
| Content | Home |
|---|---|
| Why a palace needs a special backup, and how to restore one | backup-and-recovery.md (here) |
| The coordination log: semantics, delivery, trust model, landmines | rfc-003-coordination-log.md (here) |
| What the stores are for, and how a fleet shares one palace | fleet-memory.md (here) |
| Unit/timer/plist templates | contrib/ (here) |
| Which host is primary and which fronts the tunnel, at which addresses, as which user | private fleet repository |
| Registrar/DNS records, tunnel resource config, token custody | private fleet repository |
| Per-machine flip dates, seeding history, palace lineage | private fleet repository |
The mechanism this file also carried — not yet extracted
Unlike the primary-host runbook, this file was mixed: several sections were reusable mechanism that would be true of anyone's palace, and those are not published anywhere else yet. Named here so the debt is visible rather than lost:
- The bind trap, in full. Why binding a palace to a public interface is not
the same as exposing it, and the
Host/Originpin that makes an MCP endpoint refuse requests that arrive with the wrong hostname — the single most surprising failure in the whole exposure path. - Why not per-device users at the proxy. The reasoning behind one shared
fleet token instead of per-device proxy credentials, and the consequence
documented in
rfc-003-coordination-log.md§6: the deployment authenticates the fleet, not the agent. - The one place per-device identity does exist, and why that is the feeder path rather than the HTTP path.
- Flipping a client: three variables, or none. The all-or-nothing shape of pointing a machine at a remote palace, and how a half-flipped client fails.
Until that extraction happens, the mechanism is readable only in the private
record. If you are standing up your own palace over HTTP, the two pieces you
must not skip are the Host/Origin pin and the fact that a client is flipped
by environment variables that travel as a set.