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

Merged

branderson merged 2 commits from upgrade-path-privileged into main 2026-08-27 21:00:17 -07:00

Conversation 1 Commits 2 Files Changed 7

+116 -9

2 Commits

Author	SHA1	Message	Date
branderson	5d61050f87	Do not assume /usr/local/sbin is on the PATH sudo hands you ... Reported from a real box: after the install commands in v2's privileged block, `sudo dejima-ci-upgrade set-tier privileged` was not found. Everything installs to /usr/local/sbin and every instruction in this repository reads `sudo dejima-ci-...`. That works only where sudoers sets a secure_path including sbin. Without one, sudo inherits the caller's PATH - and Debian leaves every sbin directory off a non-root PATH, which is exactly what the reporting operator's PATH showed. The result is a correct install whose documented commands all report "command not found", read as a broken install rather than as a PATH. Nothing checked it, in either project. install.sh reported what it wrote; whether anything could find it afterwards was never asked. install.sh and the privileged branch of bootstrap now check and say so. The check is honest rather than a proxy: both run under sudo, so their own PATH is the one the operator's later sudo commands will get, which makes `command -v` there the real question. v2's install blocks use the full path for the commands immediately after an install, on both tiers, because that is where the problem bites and where naming the path costs nothing. The note also says how to tell which case you are in, since `sudo printenv PATH` answers it and `sudo echo $PATH` does not - the shell expands that one before sudo runs, so it prints the caller's PATH and looks like an answer. `bats test/` 136 passing.	2026-08-27 20:47:52 -07:00
branderson	f6316e6c0e	Give the privileged tier a working v1 -> v2 path, and link the upgrade docs ... Two findings, both from reading the path rather than the code. THE "RECORD IT PROPERLY" BLOCK WAS CONFINED-SHAPED. It ran install.sh - which does not run on a privileged host, deliberately - and then invoked dejima-ci-upgrade bare, which only works because install.sh had just put it there. A privileged operator following it got exactly the error that started this: the tool reporting it could not find itself. There is now a block per tier. Confined keeps install.sh. Privileged gets the three install commands bootstrap uses, because bootstrap is the only thing that installs the tool on that tier and re-running it on a built machine also redoes runner setup - a real cost for a machine that is already serving. Those three duplicate bootstrap's lines and can drift from them, so a test pins both ends to the same destinations. A tool installed to the wrong path is a tool that is not there, reported three sections later as "not installed here", which is how this whole thread started. THE UPGRADE DOCS WERE NOT LINKED FROM THE README AT ALL. Only docs/README.md mentioned them, so an operator with an existing runner had no path from the front page to the flow. There is now an "Updating an existing runner" section with the command to check a version, the instruction to walk the notes in order, and the two things a runner operator needs before starting: run from a checkout, and recording is itself a guest-side change. The runbook and the docs index point at it, and so does the intro, where someone skimming will be. `bats test/` 136 passing, 1 new.	2026-08-27 20:27:30 -07:00