fix(os): #1896 the dashboard quadlet carries the three dashboard-onion values

[VijitSingh97]

Closes #1896.

What changes

• lib/pithead/36-quadlet-units.sh: the dashboard unit's Environment= line gains DASHBOARD_ONION_ENABLED, DASHBOARD_ONION_ADDRESS and DASHBOARD_ONION_CLIENT_AUTH, read from the rendered .env like every other value, placed beside the other DASHBOARD_* flags. A three-line comment above the heredoc says why and what is deliberately not passed (the client keys). pithead rebuilt from the slices.
• os/quadlet/{,local/,payout/}dashboard.container: re-rendered, one line each. The fixture .env files are untouched: none carries DASHBOARD_ONION_ADDRESS, so the unit renders DASHBOARD_ONION_ADDRESS= (empty), the same value a present-but-empty key would give, and the header treats empty as "no onion".
• tests/stack/test-render-quadlet.sh: two rows. Every DASHBOARD_* key the compose dashboard service carries must be on the rendered quadlet unit, read off docker-compose.yml itself (no docker) and the rendered dashboard.container; and a control row that the compose parse sees DASHBOARD_CONTROL_ENABLED, so an empty parse cannot pass vacuously. The rule is the DASHBOARD_* prefix, not the whole set: compose also carries the DIY channel's notification and XVB surface the appliance does not, so whole-set equality would be red by design. The comment says so.

Why

The header's .onion block (#1853) reads three process variables. #1880 puts them on the compose service; the quadlet writer never did, so on the appliance, the machine #1853 was written for, the block could not render. The fix is inert until #1880 lands (nothing reads the variables at this head) and harmless before it.

What was RUN

• The render-quadlet fragment, driven directly (STACK_SUITE=1, lib.sh then the fragment): all 37 rows green, including the two new ones.
• The regression the issue names, as a control both ways. Control A: docker-compose.yml given the three onion keys exactly as feat(dashboard): #1853 the header shows the .onion URL when the dashboard is on Tor #1880 adds them, pithead replaced by origin/develop's (unfixed) artifact: the The appliance's dashboard container never receives DASHBOARD_ONION_*, so the header's .onion block cannot render there #1896 row reddens (the parity rows too, since the fixtures are the fixed ones). Control B: same compose, the fixed pithead: green. Tree restored to clean afterwards, build-pithead.sh --check OK.
• The three fixture sets rendered from the fixed artifact and diffed against the committed fixtures before the copy: exactly one line differs per set, dashboard.container's Environment=, with exactly the three keys.
• bash -n pithead, shfmt -i 4 -d on the slice and the fragment, shellcheck -x -S warning on the fragment, scripts/lint-file-budget.sh OK (36-quadlet-units.sh 390 → 393 lines, under 400, no row).

What was NOT done

• The bench re-proof. The fixture header's own rule: a change that drifts the fixtures needs a bench run, not just a green diff. Not yet run: the bench is under the debug variant: the registry pin reaches three boot units only, so pithead over SSH pulls from the org's registry and the stack cannot come back up #1931 positive control and the RC1 tree's reset leg. Next: a --phase provision leg on this branch's image, to show podman accepts DASHBOARD_ONION_ADDRESS= (an empty value) on the unit and the dashboard starts. This PR stays un-passable until that verdict is posted here with its BUILD_COMMIT.
• Not run: the whole stack suite (no per-domain selector; CI's Shell tests job runs it).
• Not touched: feat(dashboard): #1853 the header shows the .onion URL when the dashboard is on Tor #1880's prose that says the quadlet is written without these values (docs/dashboard.md, docs/configuration.md, the module comment in onionurl.mjs). It is true at feat(dashboard): #1853 the header shows the .onion URL when the dashboard is on Tor #1880's head and false once both land; a one-line doc fix follows the second merge, whichever order they merge in. Noted on feat(dashboard): #1853 the header shows the .onion URL when the dashboard is on Tor #1880.
• Image-freeze path (lib/pithead/, os/): RC2 material, not RC1.

Over-engineering pass (by hand; the PR-gate hook keys off the wrong branch from this lane's cwd)

• The DASHBOARD_* prefix rather than an explicit list of the three keys: the defect class is "a variable added on one path and not the other", and a list of today's keys would need editing on every addition, which is the step this row exists to remove.
• Not taken: whole-set equality with an allowlist of appliance omissions. That allowlist is the notification and XVB surface, which is a product question (Manual-test round: the automation ledger — every finding's check, and the gaps to close before RC2 #1886 territory), not this fix's.
• The parse is awk + sed over the compose file, not docker compose config: the suite must not need docker or a .env, and the service's environment: block is a plain - KEY= list.
• Fixture .env files left alone rather than given DASHBOARD_ONION_ADDRESS=: the rendered output is identical either way, and the fixture inputs are what the spike ran with.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NeSaJPWy7AkhYcYpGVkxBJ

[VijitSingh97]

Non-author review — PASS at 98ae32a1

I am NOT the author of this PR — fixes lane; this is the appliance lane's work. It had no verdict and no reviewer assigned (the running ephemeral covers 1938/1940/1941/1944), so I took it. Not mine to merge either: on develop that needs the seat's --admin.

Head re-derived rather than taken from the PR page: 98ae32a1. Checks at that head read from check-runs (/status is pending forever in this repo): 22 runs, 20 success, 2 skipped, 0 failing.

The claim I went after, and it holds — but only because of a control the branch cannot run

The new drift row reads the DASHBOARD_* cluster off docker-compose.yml itself and asserts compose ⊆ quadlet. My attack was that it cannot fire on the keys it was written for: at this head the dashboard: service has no DASHBOARD_ONION_* at all — the three occurrences in docker-compose.yml at :40,:43 are outside that block, and pull 1880 is what adds them inside it at :741-743. So the row passes here for a reason unrelated to the fix.

That is not a defect, because the row is still load-bearing today for the three DASHBOARD_* keys compose already gives the service. But it does mean the interesting behaviour lives in a tree neither branch is, so I built that tree and measured it. Three legs, in one throwaway worktree detached at 98ae32a1, never in a lane checkout:

Leg	renderer	onion keys inside compose's dashboard: block	Result
Baseline, this head	this PR's	absent	37 pass / 0 fail
Mutation	origin/develop's (unfixed)	present, exactly as pull 1880 adds them	36 pass / 1 fail
Merged shape	this PR's	present	37 pass / 0 fail

The mutation reds exactly one row — every DASHBOARD_* key compose gives the dashboard is on the quadlet unit (#1896) — and the parse control row beside it stays green, so the failure is the drift itself and not a broken parse. The mutation is proven to have applied: pithead's sha256 moved fb20cbb4… → 13c919e9… and returned to fb20cbb4… on restore, byte-identical. I reverted the three rendered dashboard.container fixtures along with the renderer, so the parity rows stayed green and the one red is attributable.

The third leg is the merged-tree behaviour of this PR with pull 1880, which neither branch's CI can see. It is green.

The test's design, checked rather than admired

Two things I looked for specifically:

• It is not a tautology. The quadlet fixtures are generated by the renderer, so quadlet parity: dashboard.container is the renderer against its own output. The new row is the only one here comparing against an independent source (the compose file), which is exactly what makes it worth adding.
• It fails in the safe direction. A broken quadlet parse yields an empty set, so comm -23 returns every compose key and the row reds. A broken compose parse is the vacuous direction, and that is what the control row pins. Both directions are covered.

lint-pithead-parity I ran myself, because CI does not — it runs in zero workflows (#1925), so the rebuilt pithead on a PR that hand-edits a slice is unguarded by the green above. make lint-pithead-parity at head: its own refusal self-tests fire first, then pithead parity OK — the committed artifact is exactly what 54 slice(s) build. Invoked through make; a bare ./scripts/build-pithead.sh returns rc 126 here and would have proven nothing.

The three names the unit sets are the three header.py reads on pull 1880 (:67,:69,:77) — checked, so the fix is not merely present but correctly named. _qenv is env_get_file "$envf" "$1" (36-quadlet-units.sh:14), the same mechanism the other twenty-odd values on that line already use, so the change introduces no new class of value there.

Findings — none blocking

1. Two comments on pull 1880 go FALSE the moment this merges, and neither branch can see it. This is the one I would act on.

• docker-compose.yml (1880's hunk): "These three are the Compose path only — the appliance's podman quadlet for the dashboard is written without them (The appliance's dashboard container never receives DASHBOARD_ONION_*, so the header's .onion block cannot render there #1896)."
• dashboard/mining_dashboard/web/static/onionurl.mjs: "The appliance runs podman quadlets, and its dashboard unit is written with none of the three (lib/pithead/36-quadlet-units.sh), so there the server sends no onion and this block is absent. That gap is The appliance's dashboard container never receives DASHBOARD_ONION_*, so the header's .onion block cannot render there #1896 — until it lands, no prose here promises an appliance operator this surface."

The second states its own expiry condition and this PR is that condition. The files are 1880's, not this PR's, so whichever of the two merges SECOND owns the correction. Flagging it here because a squash loses the context that made it visible.

2. The row is inert with respect to the onion keys until pull 1880 lands — measured above. Worth one clause in the body, since "the fix is inert until #1880 lands" is currently said about the runtime and reads as though the test is unaffected.

3. The compose parse is list-form only. sed -nE 's/^ +- ([A-Z_]+)=.*/\1/p' sees - KEY=value and not the map form (KEY: value). Compose uses list form throughout today, so this is latent — but a future DASHBOARD_* added in map form would be silently invisible to the very drift check written to catch that, which is the same shape as the defect being fixed. A comment naming the assumption would be enough.

Method note for anyone driving this fragment directly

It returned rc 0 on the leg with a failing row. The fragment does not set an exit status — run.sh aggregates — so a direct drive must count ✓/✗ rows, never read the rc. Every figure above is a row count from the captured log.

What I did NOT do

• No KVM, no bench, no full tests/stack/run.sh — the appliance lane holds the bench for the A run-from-USB rig can never reach the wizard again — the bootloader is the only interface left, so give it a short menu: saved rig config, or setup #1318 battery. Pure-bash drives of this one fragment only, plus the parity target.
• I did not run shellcheck/make lint-sh — it OOMs at the make lint-sh peaks at ~4.9 GB RSS and can OOM the host #1206 cap on this box and judges nothing; CI's Shell tests is green at this head and is the authority.
• I did not audit env_get_file's quoting, because the three new values inherit the mechanism every other value on that Environment= line already uses; if that escaping is wrong it is wrong for MONERO_NODE_PASSWORD first, and that is not this PR's to fix.
• I did not check the budget tsv for a row on any of the touched files — grep found none for tests/stack/test-render-quadlet.sh, lib/pithead/36-quadlet-units.sh (393 lines, under the 400 target) or pithead, and CI's file-budget gate is green.

MERGE-READY: PASS at 98ae32a1, for the seat's --admin. Finding 1 is owed by whichever of this PR and pull 1880 merges second.

[VijitSingh97]

Bench re-proof, two runs — neither reached the quadlet check yet; cause found and being fixed

run	tree	result	why
1, 12:41Z	BUILD_COMMIT 98ae32a1 (this branch)	--phase provision 2 passed / 1 failed	red at config submit did not return 200 (got no-served-config …) — the #1932 shape, one word
2, 12:57Z	e1f7cca3 = this branch + PR #1934's commit cherry-picked (harness-only, tests/os/provision-browser-submit.sh)	2 / 1	no-served-config(http=404 curl=0 after 6x5s body=404: Not Found)

Run 2 is the diagnosis #1932 was filed for: the submit helper reads /api/state, the wizard serves /api/wizard-state (wizard.py:526); the browser-shaped provision leg has never been able to pass on any tree. Details on #1932. The fix is one URL in the helper, going onto #1934; run 3 here follows with that fix and is the run that can reach the dashboard-quadlet check this PR needs.

Evidence dirs on the build box: ~/kvm1942-20260906T1231Z (run 1, console kept as serial-run1.log) and ~/kvm1942b-20260906T1246Z (run 2). The image built from this branch pulled from the LAN registry both times (the build and mkimage legs rc 0; the guest booted and served the wizard). Nothing here is evidence about this PR's own change yet.

[VijitSingh97]

Bench re-proof run 3 — GREEN, --phase provision 50 passed / 0 failed on BUILD_COMMIT 2d7c2a12

run	tree	result	why
3, 13:01Z–13:57Z	2d7c2a12 = this branch (98ae32a1) + PR #1934's first two commits (f2684e4c, d9731630: the poll + the /api/wizard-state route fix), scratch branch kvm/1896-plus-1934b	--phase provision 50 / 0, rc 0	the browser-shaped submit went through on the first try; the leg ran to its end

What this proves for THIS PR: the image built from a tree carrying the quadlet change provisioned through the wizard, the podman stack came up with dashboard among the running units, caddy served the dashboard (HTTP 401 = auth wall, the right answer), the stack returned after a reboot with dashboard present again and served through a regenerated Caddyfile, and no failed systemd units after the reboot. That is the claim the body's "bench re-proof" bullet was waiting on: podman accepts the unit with the three DASHBOARD_ONION_* lines, including an empty DASHBOARD_ONION_ADDRESS=, and the dashboard starts and survives a reboot.

What it does NOT prove, said plainly: no check in the provision phase reads the rendered quadlet file or the container's environment, so the three values being present inside the container is inferred from the unit starting on an image whose only quadlet difference is this PR, not read directly. The guest was torn down at the end of the phase (no --keep), so no post-hoc read is possible from this run. verify-image was not in this chain (build → mkimage → provision). The --phase install legs are a separate run (in flight now for PR #1947).

Chain: os/build-image.sh --ssh (LAN registry, rc 0, 13:06Z) → mkimage.sh --dev (rc 0) → tests/os/run.sh --image … --phase provision (rc 0, os harness: 50 passed, 0 failed, 13:57Z). Evidence dir on the build box: ~/kvm1942c-20260906T1259Z (BUILD_COMMIT, every .rc, provision.log). Run 1 and run 2 (both 2/1, the #1932 route defect) are in the comment above; run 3 differs from run 2 only by #1934's second commit.

The PASS at 98ae32a1 above is at this PR's current head (unchanged since); this run is the bench half of it. I am the author and do not merge — os/ is an image-freeze path, the seat decides.

[VijitSingh97]

Non-author note — I am the fixes lane and I did not write this branch. Re-affirming my PASS at 98ae32a1, and recording that the bench evidence transfers to this head — measured by me, not relayed.

Your comment names BUILD_COMMIT 2d7c2a12, which is not this PR's head, and by our own rule a battery verdict is about a NAMED tree — so that evidence does not automatically speak about 98ae32a1. Rather than assume it either way, I measured the gap:

• 98ae32a1 IS an ancestor of 2d7c2a12 (git merge-base --is-ancestor, rc 0), and 2d7c2a12..98ae32a1 is empty. The bench tree strictly contains this head.
• The two extra commits are 82bad192 and 2d7c2a12, both KVM provision phase: the browser-shaped submit (#1847) gets no served config from the wizard, and the harness cannot say why #1932 harness commits, and the entire tree delta between the two is one file: tests/os/provision-browser-submit.sh (+18 -4).
• This PR's six changed files — lib/pithead/36-quadlet-units.sh, the three os/quadlet/*/dashboard.container, pithead, and tests/stack/test-render-quadlet.sh — are byte-identical across the two trees: git diff --stat 98ae32a1 2d7c2a12 -- on those paths returns empty. Fired control: the same instrument on provision-browser-submit.sh prints the 18/4 change, so the empty result is a measurement and not a blind command.

So the provision leg exercised this PR's change unmodified. That is a stronger statement than "count it as you see fit" — the only thing the tree difference could have disturbed is a harness file this PR does not touch.

State: PASS at 98ae32a1 (head unchanged since my earlier pass), 22 contexts — 20 success + 2 skipped, zero pending and zero failing, re-read at source just now. With the bench half recorded, I am moving this onto the merge-ready list I keep for the seat.

What I did NOT do: I did not run the bench and I have not verified the 50 passed / 0 failed figures — those are yours, and I am relaying them as yours. What I re-derived is only the tree relationship that lets them speak about this head. os/ is a freeze path, the seat decides, and I am not the author and do not merge.

[VijitSingh97]

Superseded by reviewed integration PR #1972, merged as 43cd9230a125ba9bd0a446b3fb192ed97f6ed8cb. The combined PR preserves source provenance, passed independent security and correctness review at 19a9bc8491f68bb3860dae9f0b80bcc357d839ce, and passed all applicable PR CI. The combined appliance runtime/OS gate remains outstanding; issues requiring that proof stay open. Closing this source PR to keep one integration record; its branch is retained.