Send the reader between the two halves, in the order that works #9

2026-08-11T19:13:03-07:00

dejima-agent commented

2026-08-11 19:13:03 -07:00

Summary generated by LLM agent

The node runbook never told anyone to install an operating system.

It creates a VM in §2, configures a firewall in §3, and finishes §3 by testing that firewall from inside the VM — a VM with no OS on it, because installing one is the guest runbook's §1 and this page never pointed there.

Both pages then described an order that cannot happen. The node page said to do it "up to the end of §3, then go there". The guest page said to do the node-side steps first and "come back here once the installer has booted" — the same contradiction from the other side, since the installer boots in its own §1.

What it says now

An order section near the top, an explicit handoff to install the OS at the end of §2, and a handoff back to the guest at the end of §3. The guest runbook defers to that order rather than stating its own, keeping its note about the two snapshot moments, which was always right.

The sequence is: §1 and §2 here, install the OS, §3 here including both halves of its verification, then the guest runbook from its §2 onward — which sends you back to §4 twice for the snapshots.

The trap that makes the order load-bearing

Worth flagging because it decides the sequence rather than being a matter of taste.

The Debian installer takes its address by DHCP whatever you intend to pin it to afterwards, and a lease needs a reply back in. Apply the security group before installing, without the DHCP pair from §3, and the installer has no network at all — which presents as a broken mirror or a dead link, not as a firewall you switched on ten minutes earlier.

Ticking the Firewall checkbox in §2 is safe on its own. The group and the policies in §3 are what start dropping things, which is why they go on after the OS is there.

Verified

bats test/ passes, 77 ok and 0 failed. Every new cross-document anchor resolves — the link guard from the link guard checked them, and it caught a wrong one on the sister project while I was writing the same change there.

The same fix is in dejima-devbox-hardener.

**Summary generated by LLM agent** The node runbook never told anyone to install an operating system. It creates a VM in §2, configures a firewall in §3, and finishes §3 by testing that firewall **from inside the VM** — a VM with no OS on it, because installing one is the guest runbook's §1 and this page never pointed there. Both pages then described an order that cannot happen. The node page said to do it "up to the end of §3, then go there". The guest page said to do the node-side steps first and "come back here once the installer has booted" — the same contradiction from the other side, since the installer boots in its own §1. ## What it says now An **order section** near the top, an explicit handoff to install the OS at the end of §2, and a handoff back to the guest at the end of §3. The guest runbook defers to that order rather than stating its own, keeping its note about the two snapshot moments, which was always right. The sequence is: §1 and §2 here, install the OS, §3 here including both halves of its verification, then the guest runbook from its §2 onward — which sends you back to §4 twice for the snapshots. ## The trap that makes the order load-bearing Worth flagging because it decides the sequence rather than being a matter of taste. **The Debian installer takes its address by DHCP whatever you intend to pin it to afterwards**, and a lease needs a reply back in. Apply the security group before installing, without the DHCP pair from §3, and the installer has no network at all — which presents as a broken mirror or a dead link, not as a firewall you switched on ten minutes earlier. Ticking the Firewall checkbox in §2 is safe on its own. The group and the policies in §3 are what start dropping things, which is why they go on after the OS is there. ## Verified `bats test/` passes, 77 ok and 0 failed. Every new cross-document anchor resolves — the link guard from the link guard checked them, and it caught a wrong one on the sister project while I was writing the same change there. The same fix is in `dejima-devbox-hardener`.

dejima-agent added 1 commit 2026-08-11 19:13:04 -07:00

Send the reader between the two halves, in the order that works

tests / runner-env (pull_request_target) Successful in 31s

Details

tests / tests (pull_request_target) Successful in 46s

Details

1f22689eda

The node runbook never told anyone to install an operating system. It created a VM in section 2, configured a firewall in section 3, and ended section 3 by testing that firewall from inside the VM - a VM with no OS on it, because installing one is the guest runbook's section 1 and this page never pointed there.

The two documents interleave and neither said so. The guest runbook claimed the node page should be done through the end of its section 3 first, which cannot happen for the same reason.

There is now an order section near the top, an explicit handoff to install the OS at the end of section 2, and a handoff back to the guest runbook at the end of section 3. The guest runbook defers to that order rather than stating its own.

It also names the trap in the ordering, which is why the sequence is what it is rather than a preference. The Debian installer takes its address by DHCP whatever you intend to pin it to afterwards, and the lease reply needs the inbound rule from section 3. Apply the group before installing, without the DHCP pair, and the installer has no network - which presents as a broken mirror or a dead link, not as a firewall switched on ten minutes earlier. Ticking the Firewall checkbox in section 2 is safe on its own; the group and the policies are what start dropping things.

The link guard caught a wrong anchor while I was writing it, which is the second time it has paid for itself.

branderson approved these changes 2026-08-11 20:37:44 -07:00

branderson merged commit b382a92724 into main

2026-08-11 20:37:59 -07:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima-devbox-hardener#9