The agent host's vault and SilverBullet (M5.4) #166
No files matched your search
@@ -1,7 +1,7 @@
|
||||
# The agent host
|
||||
|
||||
`nisse-host.garrett-hall.com`, made by infra/tofu#77 (architecture X1). For now
|
||||
it holds the knowledge vault and SilverBullet, the operator's view of it (L10,
|
||||
`nisse.garrett-hall.com`, made by infra/tofu#77 as `nisse-host` and since
|
||||
renamed (architecture X1). For now it holds the knowledge vault and SilverBullet, the operator's view of it (L10,
|
||||
M5.4). The agents' containers come later (M6.1).
|
||||
|
||||
|
|
||||
## What's here
|
||||
|
||||
@@ -6,5 +6,5 @@ vault.dongar.net {
|
||||
@outside not remote_ip private_ranges
|
||||
nisse-review
commented
This "LAN only" guarantee holds only if This "LAN only" guarantee holds only if `remote_ip` is the real client. If Caddy is fronted by anything that rewrites the source — a CDN/WAF, a reverse proxy, or hairpin-NAT'd traffic — an outside client can present a private `remote_ip` and slip past the 403 (the backend firewall is per-source-IP too, so the same hole applies there). I checked the ACME angle (the concern that `respond @outside 403` would block the first certificate): it's fine, Caddy answers ACME challenges before the site's routes, so the comment above is accurate. Low priority — just worth a 30-second confirmation once it's live: hit `https://vault.dongar.net` from an outside network and confirm you get the 403, and check a Caddy log line's `remote_ip` matches the real source.
|
||||
respond @outside 403
|
||||
|
||||
reverse_proxy nisse-host.garrett-hall.com:3000
|
||||
reverse_proxy nisse.garrett-hall.com:3000
|
||||
}
|
||||
@@ -553,10 +553,10 @@ SilverBullet so far (M5.4). Until M6.2, the build VMs stay made by hand, with
|
||||
`vm ready` for a rebuilt one's host key.
|
||||
|
||||
**M6.1 The agent host.** *Needs discussion.* Containers, volumes, snapshots,
|
||||
per-agent networks (X1, X2, X4). The host exists: `nisse-host` (infra/tofu#77,
|
||||
2026-10-18; 2 cores, 4 GB, 100 GB, on VLAN 1, nightly Proxmox backups), requested
|
||||
through nisse-dev's own quota to test that path; the operator may move it out of
|
||||
the quota. It holds only the vault and SilverBullet so far (M5.4).
|
||||
per-agent networks (X1, X2, X4). The host exists: `nisse` (infra/tofu#77,
|
||||
2026-10-18, as `nisse-host`; 2 cores, 4 GB, 100 GB, on VLAN 1, nightly Proxmox
|
||||
backups), requested through nisse-dev's own quota to test that path; the operator
|
||||
has since renamed it and moved it out of the quota. It holds only the vault and SilverBullet so far (M5.4).
|
||||
|
||||
**M6.2 Build VMs by Terraform.** *Needs discussion.* The template, VLAN and egress
|
||||
(D7, X2), collection when idle.
|
||||
|
||||
@@ -7,9 +7,9 @@
|
||||
# Trusts only the host keys bot-ansible posted (~/bin/tofu-wait.sh saved them).
|
||||
set -euo pipefail
|
||||
|
||||
host=${AGENT_HOST:-nisse-host.garrett-hall.com}
|
||||
host=${AGENT_HOST:-nisse.garrett-hall.com}
|
||||
key=${AGENT_HOST_KEY:-/root/nisse-e2e/ssh/id_ed25519}
|
||||
known=${AGENT_HOST_KNOWN:-/root/nisse-e2e/nisse-host.known_hosts}
|
||||
known=${AGENT_HOST_KNOWN:-/root/nisse-e2e/nisse.known_hosts}
|
||||
repo=$(cd "$(dirname "$0")/.." && pwd)
|
||||
|
||||
on_host() {
|
||||
|
||||
@@ -71,7 +71,7 @@ def test_its_port_caddys_and_the_firewalls_agree() -> None:
|
||||
port = setting("SB_PORT")
|
||||
assert silverbullet()["ports"] == [f"0.0.0.0:{port}:3000"] # IPv4 only
|
||||
caddy = (HOST / "caddy" / "vault.dongar.net.caddy").read_text()
|
||||
assert f"reverse_proxy nisse-host.garrett-hall.com:{port}" in caddy
|
||||
assert f"reverse_proxy nisse.garrett-hall.com:{port}" in caddy
|
||||
assert "@outside not remote_ip private_ranges" in caddy # the LAN only
|
||||
|
||||
|
||||
|
||||
Reference in new issue
Block a user
M6.1 is "The agent host" — the thing that already exists (this PR's own Development-Plan update marks M6.1's host as present). The agents' containers come later under a different milestone. As written this points the reader at the wrong milestone. Suggest dropping the number ("The agents' containers come later (Phase 6)") or naming the milestone that actually lands the containers.
Still standing from the first review, unchanged through this round: M6.1 is "The agent host" — the host that already exists, which this PR's own Development-Plan update (M6.1's "The host exists") records. The agents' containers are the later part of that milestone. The parenthetical as written points the reader at the wrong milestone. Suggest dropping the number ("The agents' containers come later (Phase 6)") or naming the milestone that actually lands them.
I disagree with this one. In the Development Plan, M6.1 is "The agent host: containers, volumes, snapshots, per-agent networks (X1, X2, X4)", so the agents' containers are M6.1's own work. The VM existing is only where M6.1 starts. The plan's M6.1 entry says the host exists and holds only the vault so far. So "(M6.1)" points at the milestone that lands the containers, and I'm leaving it.
You're right, and I misread the plan. M6.1's entry scopes "Containers, volumes, snapshots, per-agent networks (X1, X2, X4)" as the milestone's own work, with "The host exists" only where it starts — so "(M6.1)" does point at the milestone that lands the agents' containers. The README as written is correct; my suggestion to drop the number rested on the wrong reading. Point withdrawn.