`rotate-dashboard-onion` crashes with `HOST_IP: unbound variable`; onion address not captured when enabled via `upgrade`

[VijitSingh97]

Two related rough edges in the dashboard-onion (#343) provisioning outside of setup.

Bug A — rotate-dashboard-onion crashes

./pithead rotate-dashboard-onion -y

→ aborts:

./pithead: line ~2469: HOST_IP: unbound variable
[ERROR] pithead aborted unexpectedly (exit 1).

Root cause: the rotate function (~pithead:2210-2250) calls provision_tor then render_env, but never calls resolve_dashboard_host — which is what sets the HOST_IP global that render_env reads. Under set -u, render_env dies on the unbound HOST_IP. setup (pithead:2907) and apply (pithead:3138) both call resolve_dashboard_host first; rotate is the only path that skips it.

Consequence: it wipes/regenerates the hidden service, then crashes before render_env persists the new address + client keypair — leaving the onion in a half-provisioned state (new authorized_clients pubkey written, but the private key not saved anywhere).

Fix: call resolve_dashboard_host (non-interactive) inside rotate_dashboard_onion before render_env, mirroring apply.

Bug B — onion address not captured when enabled via upgrade

Enabling dashboard.onion.enabled: true and running ./pithead upgrade generates the tor hidden-service hostname, but the .onion address is never written to .env, so pithead status / onion-client-key can't show it.

Root cause: only apply captures it (pithead:3231 provision_dashboard_onion && render_env), and that block is gated behind change-detection — if a prior upgrade already enabled the onion, the next apply hits pithead:3195 "No configuration changes detected. Nothing to apply." and returns before reaching the capture block. upgrade itself never runs provision_tor/capture.

Fix: capture the dashboard onion address whenever it's enabled-but-uncaptured (address empty/placeholder), independent of change detection — in both apply and upgrade.

Workarounds used (v1.2.1 live deploy)

• Bug A: HOST_IP=<dashboard host> ./pithead rotate-dashboard-onion -y
• Bug B: the rotate above is what finally provisioned + captured the address.

Suggested tests

tests/stack assertions (stubbing docker/tor as the existing onion tests do): rotate provisions + persists a new address without crashing; enabling the onion + apply captures the address into .env.

Impact: medium — the primary key-rotation/recovery command is unusable as shipped, and the address is invisible after a plain upgrade-based enable.

[VijitSingh97]

Additional impact of Bug A: rotate-dashboard-onion also clobbers DEPLOYMENT_COMPLETED

Even with the HOST_IP workaround, the rotate's render_env rewrites DEPLOYMENT_COMPLETED from the ${DEPLOYMENT_COMPLETED:-false} default — and the rotate flow never sets that variable to true (it doesn't go through the require_deployed/DEPLOYMENT_COMPLETED=true path that apply/upgrade do). So after a rotate, .env ends up with DEPLOYMENT_COMPLETED=false.

The running stack is unaffected (containers stay up), but the next apply/up/upgrade then fails with:

[ERROR] Stack is not fully provisioned. Run './pithead setup' first.

even though the stack is fully deployed. Recovery is to manually set DEPLOYMENT_COMPLETED=true back in .env.

So the fix for rotate should also preserve DEPLOYMENT_COMPLETED (load it from the existing .env / set it true, same as apply) before calling render_env — folding this in with the resolve_dashboard_host/HOST_IP fix. Observed on the same v1.2.1 live deploy.