Install the upgrade tool on the privileged tier, which never got it #21

2026-08-27T19:58:38-07:00

dejima-agent commented

2026-08-27 19:58:38 -07:00

Summary generated by LLM agent

The sharpest of the bugs reported alongside #20, and the one that did not make it in before that merged.

The privileged tier never got the tool at all

install.sh puts dejima-ci-upgrade on a confined host and does not run on a privileged one — that is the grant the tier exists for. Nothing else installed it.

So the single tier whose only boundary is the node firewall was the single tier unable to ask which node-side versions it was missing. Exactly backwards from where the need is greatest.

The fix, and the precedent it follows

dejima-ci-bootstrap --role privileged now installs it, alongside dejima-ci-runners. The justification was already written above that line and applies word for word:

The runner itself still has to be built, and on this role install.sh is not there to do it. Install the generator and its templates directly, so that this host ends up with the same "re-run it to change something" story as a confined one.

It also records tier=privileged. The tool refuses to guess the tier, which is right — an absent config identifies a privileged host and equally a confined one whose install.sh has not run — but this branch is the privileged path, so there is nothing to guess and no reason to make an operator type it.

A comment that had quietly become false

status said "this tier installs nothing in the guest by design". That was true when it was written and stopped being true when bootstrap started placing dejima-ci-runners there.

The distinction that actually holds: guest_version tracks the guest-side controls — the allowlist, the resolver, the job firewall — and this tier runs none of them. The programs bootstrap places are tools, deliberately uncounted, and a stale installed copy is something dejima-ci-upgrade already reports about itself. Both the comment and docs/upgrading.md now say that instead.

What this does not fix

A privileged host already built at v1. Bootstrap is not part of the v2 upgrade, so those hosts still have no copy and will not get one from anything on that page.

upgrades/0002 now says so under its own heading, where a privileged operator will be looking rather than buried in confined-tier instructions. The answer for v2 is the checkout — which is not a workaround, since the node rules are in force regardless and a checkout is the recommended way to run this tool on any tier. Re-running bootstrap is the alternative, and the note says plainly that it is a guest-side change with a rollback cycle behind it.

Tested

bats test/ — 135 passing, 2 new: that the privileged branch of bootstrap installs the tool, and that it records the tier. Both read the branch out of the script rather than running it, following units.bats's precedent for testing bootstrap's behaviour without a machine to run it on.

The pattern behind all four

Every bug in this round sat in the same seam: the upgrade tooling assumed it was already installed. Verify commands assumed $PATH, the note assumed install.sh had run, and bootstrap assumed the confined tier.

None was caught by tests, because the tests run in a checkout where everything is present. The thing that would have caught all four is running the documented upgrade end-to-end on a v1 box of each tier — which is not something this repository can do to itself, and is worth knowing about the limits of its own suite.

**Summary generated by LLM agent** The sharpest of the bugs reported alongside [#20](https://gitbox.branderson.io/dejima/dejima-ci-hardener/pulls/20), and the one that did not make it in before that merged. ## The privileged tier never got the tool at all `install.sh` puts `dejima-ci-upgrade` on a confined host and **does not run on a privileged one** — that is the grant the tier exists for. Nothing else installed it. So the single tier whose *only* boundary is the node firewall was the single tier unable to ask which node-side versions it was missing. Exactly backwards from where the need is greatest. ## The fix, and the precedent it follows `dejima-ci-bootstrap --role privileged` now installs it, alongside `dejima-ci-runners`. The justification was already written above that line and applies word for word: > The runner itself still has to be built, and on this role `install.sh` is not there to do it. Install the generator and its templates directly, so that this host ends up with the same "re-run it to change something" story as a confined one. It also records `tier=privileged`. The tool refuses to *guess* the tier, which is right — an absent config identifies a privileged host and equally a confined one whose `install.sh` has not run — but this branch **is** the privileged path, so there is nothing to guess and no reason to make an operator type it. ## A comment that had quietly become false `status` said *"this tier installs nothing in the guest by design"*. That was true when it was written and stopped being true when bootstrap started placing `dejima-ci-runners` there. The distinction that actually holds: `guest_version` tracks the guest-side **controls** — the allowlist, the resolver, the job firewall — and this tier runs none of them. The programs bootstrap places are **tools**, deliberately uncounted, and a stale installed copy is something `dejima-ci-upgrade` already reports about itself. Both the comment and `docs/upgrading.md` now say that instead. ## What this does not fix **A privileged host already built at v1.** Bootstrap is not part of the v2 upgrade, so those hosts still have no copy and will not get one from anything on that page. `upgrades/0002` now says so under its own heading, where a privileged operator will be looking rather than buried in confined-tier instructions. The answer for v2 is the checkout — which is not a workaround, since the node rules are in force regardless and a checkout is the recommended way to run this tool on any tier. Re-running bootstrap is the alternative, and the note says plainly that it is a guest-side change with a rollback cycle behind it. ## Tested `bats test/` — 135 passing, 2 new: that the privileged branch of bootstrap installs the tool, and that it records the tier. Both read the branch out of the script rather than running it, following `units.bats`'s precedent for testing bootstrap's behaviour without a machine to run it on. ## The pattern behind all four Every bug in this round sat in the same seam: **the upgrade tooling assumed it was already installed.** Verify commands assumed `$PATH`, the note assumed `install.sh` had run, and bootstrap assumed the confined tier. None was caught by tests, because the tests run in a checkout where everything is present. The thing that would have caught all four is running the documented upgrade end-to-end on a v1 box of each tier — which is not something this repository can do to itself, and is worth knowing about the limits of its own suite.

dejima-agent added 1 commit 2026-08-27 19:58:39 -07:00

Install the upgrade tool on the privileged tier, which never got it

tests / runner-env (confined) (pull_request_target) Successful in 41s

Details

tests / tests (pull_request_target) Successful in 1m23s

Details

tests / compose-schema (pull_request_target) Successful in 47s

Details

tests / runner-env (privileged) (pull_request_target) Successful in 40s

Details

e5e5a307b3

Reported: dejima-ci-upgrade never reaches a privileged box. install.sh puts
it on a confined host and does not run on a privileged one - that is the
grant the tier exists for - and nothing else installed it. So the one tier
whose ONLY boundary is the node firewall was the one tier unable to ask which
node-side versions it was missing.

bootstrap now installs it there, alongside dejima-ci-runners and for the same
reason that already justifies that line: on this role install.sh is not there
to do it, and the host should end up with the same "re-run it to change
something" story as a confined one.

It also records tier=privileged. The tool refuses to guess the tier, which is
right - an absent config identifies a privileged host and equally a confined
one whose install.sh has not run - but this branch IS the privileged path, so
there is nothing to guess and no reason to make an operator type it.

guest_version is deliberately still not written there. It tracks the
guest-side controls, and this tier runs none; the two programs bootstrap
places are tools, and a stale installed copy is something the tool already
reports about itself. The comment claiming the tier "installs nothing in the
guest" was true when written and is not any more, so it says what it means
now.

WHAT THIS DOES NOT FIX is a privileged host already built at v1. Bootstrap is
not part of the v2 upgrade, so those hosts still have no copy and will not
get one from anything on that page. The note now says so where a privileged
operator will be looking, points at the checkout as the answer for v2, and
notes that re-running bootstrap is the alternative and is a guest-side change
with a rollback cycle behind it.

`bats test/` 135 passing, 2 new.

branderson approved these changes 2026-08-27 20:13:37 -07:00

branderson merged commit a76f38bcc4 into main

2026-08-27 20:13:42 -07:00

dejima-agent referenced this pull request

2026-08-27 20:29:06 -07:00

Give the privileged tier a working v1 to v2 path, and link the upgrade docs #22

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dejima/dejima-ci-hardener#21