Say which way the console orders rules, and fix the numbering #5

2026-08-10T16:56:50-07:00

dejima-agent commented

2026-08-10 16:56:50 -07:00

Summary generated by LLM agent

The runbook said the Proxmox console appends new rules at the bottom, and that entering them in the documented order was all it took. It inserts them at the top.

Why this is worse than a wrong sentence

Entering the table in order produces the reverse of it: the four DROPs above every pinhole, and a devbox that cannot reach its forge or resolve anything.

So the instructions produced the exact failure the same paragraph was warning about — and it is the failure with no symptom. The VM boots. The console shows all the rules present. Nothing looks wrong until something tries to reach the forge, which on a fresh build is after you have moved on to the guest half and are looking somewhere else entirely.

What it says now

The console's behaviour is named outright, with the consequence spelled out rather than left as an ordering rule to follow carefully.

Two ways through it: drag each rule to the bottom as you add it, which keeps the list matching the table at every step and is the easier one to check; or enter them in reverse and let the insertions stack into the right order, which is quicker but has you reading the table backwards while you work.

Either way, read the finished list top to bottom against the table before trusting it. That step is not optional politeness — it is the only thing that catches this.

The template and dejima-devbox-audit's FAIL message said the same wrong thing and are corrected. So is test/firewall.bats's explanation of why it exists, which gets stronger for it: getting the order wrong is the default outcome of following the table, not an unusual slip.

A second bug found while reading it

The rule numbers in that section were inherited from the sister project's eight-row table and never updated for this one's ten rows. It cited rules 5–8 as the DROPs, rules 2–4 as the LAN exposure, and rule 8 as the last. Here those are 7–10, 3–6 and 10.

The "Values that must agree" table further down was already correct, which is probably what let the mismatch survive a read: the numbers are right in one place and wrong in another, on the same page.

Verified

bats test/ passes, 64 ok and 0 failed.

Not verified by me: the console behaviour itself, which I have no Proxmox access to check. This is on the operator's report of what the editor actually does, which is better evidence than what the previous sentence was based on.

The same correction is in dejima-ci-hardener PR #15, whose rule numbering was already right.

**Summary generated by LLM agent** The runbook said the Proxmox console appends new rules at the bottom, and that entering them in the documented order was all it took. It inserts them at the **top**. ## Why this is worse than a wrong sentence Entering the table in order produces the reverse of it: the four DROPs above every pinhole, and a devbox that cannot reach its forge or resolve anything. So the instructions produced the exact failure the same paragraph was warning about — and it is the failure with no symptom. The VM boots. The console shows all the rules present. Nothing looks wrong until something tries to reach the forge, which on a fresh build is after you have moved on to the guest half and are looking somewhere else entirely. ## What it says now The console's behaviour is named outright, with the consequence spelled out rather than left as an ordering rule to follow carefully. Two ways through it: drag each rule to the bottom as you add it, which keeps the list matching the table at every step and is the easier one to check; or enter them in reverse and let the insertions stack into the right order, which is quicker but has you reading the table backwards while you work. Either way, read the finished list top to bottom against the table before trusting it. That step is not optional politeness — it is the only thing that catches this. The template and `dejima-devbox-audit`'s FAIL message said the same wrong thing and are corrected. So is `test/firewall.bats`'s explanation of why it exists, which gets stronger for it: getting the order wrong is the *default* outcome of following the table, not an unusual slip. ## A second bug found while reading it The rule numbers in that section were inherited from the sister project's eight-row table and never updated for this one's ten rows. It cited rules 5–8 as the DROPs, rules 2–4 as the LAN exposure, and rule 8 as the last. Here those are 7–10, 3–6 and 10. The "Values that must agree" table further down was already correct, which is probably what let the mismatch survive a read: the numbers are right in one place and wrong in another, on the same page. ## Verified `bats test/` passes, 64 ok and 0 failed. Not verified by me: the console behaviour itself, which I have no Proxmox access to check. This is on the operator's report of what the editor actually does, which is better evidence than what the previous sentence was based on. The same correction is in `dejima-ci-hardener` PR #15, whose rule numbering was already right.

dejima-agent added 1 commit 2026-08-10 16:56:51 -07:00

Say which way the console orders rules, and fix the numbering

tests / tests (pull_request_target) Successful in 1m50s

Details

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

Details

037fb800aa

The runbook said the console appends new rules at the bottom and that entering them in the documented order was all it took. It inserts them at the top. Entering the table in order therefore produces the reverse of it: the four DROPs above every pinhole, and a devbox that cannot reach its forge.

That made the instructions produce the exact failure the same section warns about, and it is the failure with no symptom - the VM boots, the console shows the rules present, and nothing looks wrong until something tries to reach the forge. The runbook now names the behaviour, gives both ways through it, and says to read the finished list against the table before trusting it, because nothing else catches this.

The template and the audit's FAIL message said the same wrong thing and are corrected. So is test/firewall.bats's explanation of why it exists, which is now stronger: getting the order wrong is the default outcome of following the table rather than an unusual mistake.

Separately, the rule numbers in that section were inherited from the sister project's eight-row table and never updated for this one's ten rows. It cited rules 5-8 as the DROPs, rules 2-4 as the LAN exposure and rule 8 as the last. Those are 7-10, 3-6 and 10 here. The Values that must agree table further down was already correct, which is what made the mismatch survive a read.

dejima-agent referenced this pull request

2026-08-10 20:27:57 -07:00

Carry dejima's canonical statements: the disclaimer, and the push rule #8

branderson approved these changes 2026-08-11 18:30:10 -07:00

branderson merged commit 2f499914ef into main

2026-08-11 18:32:23 -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#5