1aeea6bdc5
All checks were successful
PR build (required check) / changes (pull_request) Successful in 6s
secrets-guard / encrypted (pull_request) Successful in 5s
PR build (required check) / build-backend (pull_request) Has been skipped
PR build (required check) / build-frontend (pull_request) Has been skipped
shell-lint / shellcheck (pull_request) Successful in 6s
PR build (required check) / validate-observability (pull_request) Has been skipped
PR build (required check) / gate (pull_request) Successful in 1s
Revoking PUBLIC's CONNECT on the guest's own database is the half that does not matter. A fresh Postgres database carries '=Tc' for PUBLIC — TEMP and CONNECT — so as soon as a second role exists on the instance it can open a session against every database still holding the default. Provisioning beta and stopping there left thermograph_beta able to connect to prod's database. The runbook's isolation check caught it on the live cutover; this makes the script produce the state that check expects instead of a false sense of it. Grants the owner's read-only role an explicit CONNECT before the revoke, so the ad-hoc query path (ops/dbq.sh, which connects as thermograph_ro) cannot lose access to prod. The owner's app role owns the database and is a superuser, so it is unaffected either way. |
||
|---|---|---|
| .. | ||
| backup | ||
| db | ||
| forgejo | ||
| migrations | ||
| openmeteo | ||
| secrets | ||
| stack | ||
| swarm | ||
| twa | ||
| Caddyfile.vps1 | ||
| Caddyfile.vps2 | ||
| deploy-dev.sh | ||
| deploy.sh | ||
| env-topology.sh | ||
| migrate-db.py | ||
| POSTGRES-MIGRATION.md | ||
| provision-agent-access.sh | ||
| provision-dev.sh | ||
| provision-mail-supervision.sh | ||
| provision-mail.sh | ||
| provision-secrets.sh | ||
| render-secrets.sh | ||
| RUNBOOK-vps1-vps2-cutover.md | ||
| thermograph-dev.service | ||
| thermograph.env.example | ||
| thermograph.service | ||