[stack] feat(infra): Latitude host provisioning + isolation by michaelshimeles · Pull Request #22 · boringcomputers/nehemiah

michaelshimeles · 2026-08-11T00:15:42Z

Part of landing the Nehemiah managed cloud as reviewed slices (rename, docs, guest-agent, nehemiahd, gateway, control plane, clients, web already on main).

This PR: bare-metal host provisioning (infra/). The Latitude provisioning chain (render-user-data → provision → cloud-init → bootstrap → net-setup), a from-scratch minisign verifier, signed offline package closure, the egress firewall matching the non-overridable hard-deny floor, bridge L2 hardening, WireGuard config validation, and verify-isolation.sh (real netns/ARP/source-spoof adversarial checks). Local vs managed systemd units, and a managed-provisioning shell test.

Note: nehemiahd.service already landed with the daemon slice (its scope tests assert against it) and is excluded here.

Self-consistent: shellcheck -S error clean across infra/, Python scripts compile.

Base: main.

🤖 Generated with Claude Code

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

Provisioning chain (render-user-data → provision → cloud-init → bootstrap → net-setup), from-scratch minisign verifier, signed offline package closure, the egress hard-deny firewall floor, bridge L2 hardening, WireGuard config validation, and verify-isolation.sh adversarial checks. Local and managed systemd units.

vercel · 2026-08-11T00:15:46Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
boringcomputers	Ready	Preview	Aug 11, 2026 1:36pm

greptile-apps · 2026-08-11T00:23:56Z

Greptile Summary

The teardown flow now reads provisioning records from the configured Latitude state directory, including LATITUDE_STATE_DIR and XDG configuration locations, so operators can stop a managed host without manually recovering its server ID. Offline fake-provider checks confirmed the expected hostname verification and delete behavior for both locations.

Confidence Score: 5/5

No blocking failure remains.

Offline checks exercised custom state-directory discovery, API-key-file lookup, hostname-only recovery, conflicting-record refusal, and the managed provisioning regression without finding an actionable failure.

T-Rex Logs

What T-Rex did

Conducted focused before-and-after teardown validation, comparing the parent teardown against the current teardown behavior; the parent teardown issued no API calls for alternate state locations, while the current teardown performed GET /servers and DELETE /servers/sv_current1234 for both LATITUDE_STATE_DIR and XDG_CONFIG_HOME.
Verified hostname-only recovery and stale-ID conflict paths: hostname recovery deleted the resolved server, while conflicting recovery records stopped before deletion.
Ran the offline managed-provisioning regression against the fake Latitude API; the regression completed successfully.
Captured focused teardown and regression artifacts for review, including scripts and outputs that demonstrate before/after state behavior and results.

_{Ran code and verified through T-Rex}

_{Reviews (14): Last reviewed commit: "fix(infra): teardown reads the provision..." | Re-trigger Greptile}

Latitude accepts the billable POST /servers before provision.sh parses the id, so an accepted-but-malformed response previously aborted with no local record (WORK_DIR is removed on exit). The raw response is now saved to STATE_DIR/last-created-server.json at mode 0600 immediately after the 201, so a potentially-billed host can always be identified and torn down.

…aged-only bootstrap.sh installs Firecracker/jailer/kernel only from signed managed-release artifacts, so the self-serve setup.sh / setup-local.sh flows that invoked it would exit cryptically on the first missing signed-release var. They now fail fast with a clear message pointing at the managed provisioning path, gated behind an explicit NEHEMIAH_ALLOW_UNMANAGED_BOOTSTRAP=1 opt-in for operators who have primed the target.

michaelshimeles · 2026-08-11T00:36:02Z

@greptile review

…verable - Remove the broken NEHEMIAH_ALLOW_UNMANAGED_BOOTSTRAP override: setup.sh and setup-local.sh invoked the remote bootstrap without staging/forwarding the signed-release inputs (SSH/Lima don't inherit the operator env), so the override produced an unusable host. Both flows now hard-fail with a pointer to the managed provision path. - provision.sh persists the requested hostname (a durable correlation value) and the validated server id BEFORE polling, and on a malformed 201 body it aborts with actionable recovery guidance instead of a bare parse error. - teardown.sh gains a hostname-based recovery path: when no id is known it queries Latitude and deletes the single validated match, never inferring an id from a malformed body.

michaelshimeles · 2026-08-11T00:51:28Z

@greptile review

A malformed create left the prior provision's server_id in the state dir while recording the new host's hostname, so teardown used the stale id and deleted the old server — leaving the newly billed host running. provision.sh now clears the stale server_id the moment a new (billable) host is accepted, so an incomplete create falls through to hostname recovery for the current host (which fails closed on an ambiguous multi-match rather than deleting the wrong server).

michaelshimeles · 2026-08-11T00:59:03Z

@greptile review

The README and local-setup docs still advertised infra/setup.sh and infra/local/setup-local.sh, which now exit unconditionally since host bootstrap installs only signed managed-release artifacts. Point both at the managed Latitude runbook and mark the script headers descoped. Co-authored-by: Cursor <cursoragent@cursor.com>

Fixes the web + sdk CI lint failure. Co-authored-by: Cursor <cursoragent@cursor.com>

… stale id A kill between removing the prior server_id and landing the new last-created-hostname left the state directory with no record of the just-billed host, so teardown could not discover it. Persist the hostname record first (staged in STATE_DIR so the rename is atomic across filesystems), then drop the stale id; the parse-failure path still falls through to hostname recovery for the new host. Co-authored-by: Cursor <cursoragent@cursor.com>

An interrupted provisioning run can leave a stale server_id file alongside a newer last-created-hostname; teardown silently preferred the id and could delete the previous server while the newly billed host kept running. When the id comes from the state file and a hostname record exists, verify via the provider that both identify the same server and abort on a conflict (or on a failed lookup) with explicit recovery guidance. An explicit LATITUDE_SERVER_ID still bypasses the check. Co-authored-by: Cursor <cursoragent@cursor.com>

The requested hostname is the durable recovery correlation value when a create response is unparseable, but the default (nehemiah-metal-01) is reusable: a second live server with the same hostname makes hostname recovery ambiguous and can strand a billed host. Query the provider before creating and refuse to proceed while any live server already carries the hostname. The test harness covers the collision refusal and the new provider read. Co-authored-by: Cursor <cursoragent@cursor.com>

The preflight hostname listing is check-then-create, so two concurrent runs with the same LATITUDE_HOSTNAME could both pass it and create two billed servers behind one recovery correlation value, which hostname recovery then refuses to disambiguate. Latitude enforces neither hostname uniqueness nor create idempotency, so uniqueness is generated locally: every run appends a random 8-hex suffix to the (now max 23 char) base hostname, keeping the correlation value unique across concurrent runs. The preflight check stays as defense-in-depth against pre-existing duplicates. Co-authored-by: Cursor <cursoragent@cursor.com>

…in it The managed-provisioning harness hard-asserted on scripts/release/ files (packages policy, build.mjs, release shellcheck targets) that ship in a separate stack slice, so the harness could never pass on this branch and everything after the first missing-file grep never ran. Gate those assertions on the pipeline's presence with a loud skip notice; the full harness now runs end to end here and still asserts the release invariants on checkouts that include the pipeline. Co-authored-by: Cursor <cursoragent@cursor.com>

michaelshimeles · 2026-08-11T13:19:32Z

@greptile review

provision.sh persists its recovery records under LATITUDE_STATE_DIR, else $XDG_CONFIG_HOME/latitude, else ~/.config/latitude, but teardown hardcoded the home path. A server provisioned with an alternate state location was invisible to a no-argument teardown, which exited before its delete and left the hourly-billed host running. Resolve the state directory (and the LATITUDE_API_KEY_FILE override) exactly like provision.sh, and exercise both alternate locations end-to-end against a stubbed provider. Co-authored-by: Cursor <cursoragent@cursor.com>

michaelshimeles · 2026-08-11T21:11:37Z

@greptile review

vercel Bot deployed to Preview August 11, 2026 00:15 View deployment