malice
acef894b21central-migrate invocations were run via bare `cen "$VENV/bin/central-migrate"`, which does not set the working directory or source the EnvironmentFile that the systemd unit provides. This caused the pre-flight --check to fail during the v0.14.6 deploy with `PermissionError: [Errno 13] Permission error: '.env'` because central-migrate tried to read .env from the caller's cwd instead of /opt/central, and the DB DSN was missing. The daemons themselves are unaffected — they always get WorkingDirectory= /opt/central and EnvironmentFile=/etc/central/central.env from systemd. The deploy script is the only place that invoked central-migrate outside that context. Fix: add ENV_FILE=/etc/central/central.env to the config block and a cen_migrate() helper that wraps every central-migrate call with: sudo -u central bash -c "cd /opt/central && set -a && . /etc/central/central.env && set +a && /opt/central/.venv/bin/central-migrate <args>" Replace all four bare invocations (--check preflight, --dry-run, apply, --check post-deploy) with cen_migrate. Exit-code propagation is unchanged — bash -c forwards the inner exit status, so set -e / the ERR trap still fires on non-zero exits. Co-authored-by: Ubuntu <zvx@cortex.echo6.co> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| .gitkeep | ||
| deploy.sh | ||
| README.md | ||
scripts/
deploy.sh — tag-based deploy for central on CT 104
Codifies the manual deploy procedure for the central service running on
Proxmox CT 104 (utility, Tailscale 100.64.0.12).
What it does
- Preflight — checks that
/opt/centralis a git repo, captures the currently-deployed ref for rollback messaging, reports unit status (warns but does not abort on inactive units), runscentral-migrate --checkto gate on migration drift, and takes a pre-deploypg_dumpbackup. - Deploy — fetches from
origin, verifies the requested ref exists, checks it out as a detached HEAD, and runsuv syncto update the venv against the checked-outuv.lock. - Confirm — shows a
--dry-runmigration preview and prompts for confirmation before applying any changes to the running system (skip with-y). - Apply — runs
central-migrateto apply pending SQL migrations, then restarts all three systemd units (central-supervisor,central-archive,central-gui). - Verify — confirms all units are active, re-runs
central-migrate --checkfor a clean post-deploy state, and pollshttp://localhost:8000/health(up to 5 retries, 2 s apart) for an HTTP 200. - ERR trap — on any unexpected failure, prints a ROLLBACK block with the exact commands to re-checkout the previous ref, re-sync the venv, restart services, and (if needed) restore from the pre-deploy dump.
Usage
Run on CT 104 as a user with passwordless sudo (e.g. zvx):
/opt/central/scripts/deploy.sh <tag-or-ref> [-y|--yes]
<tag-or-ref>— any Git tag, branch, or commit SHA (tags are the standard deploy unit; e.g.v0.14.5).-y/--yes— skip the interactive confirmation prompt (safe for automation once you have reviewed the dry-run output manually).
Pre-flight backup
Before applying any changes, the script takes a pg_dump -Fc of the
central database and writes it to /var/backups/central/. The 10 newest
dumps are retained; older ones are pruned automatically.
Migrations are forward-only. There are no down-scripts. The pg_dump is
the only automated mechanism for rolling back the database. If you need to
revert after migrations have run, restore from the dump printed in the SUCCESS
(or ERR-trap) output.
One-time cutover steps
Some releases require manual cutover steps that cannot be automated (e.g.
removing a deprecated EONET region key from config.adapters). These are
intentionally out of scope for this script. See the vault runbook
central-deploy-cutover.md for guidance on release-specific procedures.
Bootstrap caveat
This script is version-controlled inside the central repository. The very
first deploy that introduces it must still be performed manually (the script
ships in the repo it deploys and cannot deploy itself from scratch).