joakimp
d2764bf78e
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.
48 lines
2.8 KiB
Markdown
48 lines
2.8 KiB
Markdown
# (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`](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`](backup-and-recovery.md) (here) |
|
|
| The coordination log: semantics, delivery, trust model, landmines | [`rfc-003-coordination-log.md`](rfc-003-coordination-log.md) (here) |
|
|
| What the stores are for, and how a fleet shares one palace | [`fleet-memory.md`](fleet-memory.md) (here) |
|
|
| Unit/timer/plist templates | [`contrib/`](../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`/`Origin` pin 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`](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.
|