Automate manual post-install steps + install hardening (HAM-120)

[pbitzer]

Summary

Automates the recurring manual post-install steps that keep getting missed on sensor bring-up (Epic HAM-120), plus a set of install-hardening fixes surfaced by a Jira + sensor-log audit. Every new install step is best-effort / non-fatal — a failure logs a warning and never aborts the install.

Base: 0.4.x. 7 commits, +671 lines. 106 unit/dry-run tests passing.

What's in it

Post-install automation (new Phase 7, --skip-postinstall to opt out):

• HAM-118 — fetch the .googlechat webhook key so state_monitor notifications work (now chmod 600)
• HAM-80 — provision the local datasync account (user/group/.ssh//media perms; the pull-side key is still installed separately)
• cleanup_legacy_services — remove retired pre--default units (autossh-hamma.service, brokkr-hamma.service) that compete with the current units (sensor-log Add daily compression plugin for HAMMA trigger data #43/Mount udisks filename #9)
• normalize_pi_ownership — best-effort chown pi:pi on /home/pi/{dev,.ssh,.config} + /etc/systemd/system mode, fixing the recurring root-owned-from-sudo breakage (sensor-log fix(state_monitor): level-triggered, numeric-robust, observable auto-scrub #78/Python interpreter in sunsaver.py #11/PR Jira Tickets #33)

brokkr install:

• HAM-84 — pin gpiozero<2.0 on Python ≤3.7 (2.0 breaks relay.py on Buster); auto-heals on newer Python
• HAM-158 — install notifiers editable-as-pi so on-sensor git pull deploys and brokkr survives reboot (same safe pattern as the sindri HAM-163 plan)

hardware phase:

• Package + enable a boot-time stale-mountpoint cleanup oneshot (files/hamma-cleanup-stale-mountpoints.service) that rmdirs empty /media/pi/DATA?? orphans before the drive is mounted, so a dirty unmount can't push it to a suffixed path brokkr's DATA?? glob misses (sensor-log feat: on-demand sensor noise check script #52; previously hand-installed per unit). rmdir is empty-only → safe no-op once mounted.

verify_deployment.sh:

• New check_post_install_config (timezone/HAM-71, gpiozero import, .googlechat, datasync, pi-ownership) and a --full check_hamma_repo_access deploy-key check (bounded with BatchMode+ConnectTimeout).

install.sh:

• REPO_BRANCH 0.3.x → 0.4.x so the mjolnir-hamma self-update actually runs on 0.4.x units (it only pulls when already on that branch, so the stale value silently skipped updates).

Jira sub-tickets

Closeable on merge: HAM-71, HAM-84, HAM-118, HAM-158.
Partially addressed (install hook only; per-sensor backfill remains): HAM-80.
Untracked audit items implemented here (will file under HAM-120): legacy-unit cleanup, ownership normalization, deploy-key verify, udisks oneshot.

Testing

• pytest tests/unified → 106 passing (new tests/unified/test_postinstall.py: dry-run manifest assertions + a sandboxed set -e non-fatal harness that is mutation-verified to fail if a guard is dropped).
• Full no-skip install.sh --dry-run → exit 0; no new shellcheck findings in any changed line.
• Read-only E2E on mj02: all new verify_deployment checks pass live; the oneshot unit passes systemd-analyze verify (rc=0) and is a correct no-op on that healthy unit; rmdir-only safety proven (removes empty, keeps non-empty/mounted).
• Two independent review rounds (incl. a Raspberry-Pi/systemd expert) — all confirmed findings addressed; the Pi expert's key catch (making the oneshot's real Before=multi-user.target / brokkr ordering explicit rather than relying on the non-load-bearing Before=udisks2.service) is in.

Known follow-ups (not blocking)

• Docker/systemd integration suite (tests/integration/test-with-systemd.sh) not run here (no Docker on the dev host) — worth one real-Buster run before fleet rollout.
• Boot-time E2E of the oneshot (verifying it prevents the suffixed mountpoint on a unit with the hard-reset pattern, e.g. mj51) needs a reboot — deferred to avoid disrupting a live sensor.

🤖 Generated with Claude Code