eblume/blumeops
1
1
Fork 0
Code Issues Pull requests Projects Releases 83 Packages Wiki Activity Actions

Remove superuser from teslamate PG role, transfer extension ownership

Browse source 
teslamate had superuser on the shared blumeops-pg cluster (which also
hosts miniflux and authentik). Downgraded to plain database owner with
extension ownership (cube, earthdistance) transferred manually so it
can still ALTER EXTENSION UPDATE. earthdistance is untrusted in PG so
DROP+CREATE would need temporary superuser escalation.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erich Blume 2026-04-07 15:36:39 -07:00
commit efae404d1e
3 changed files with 19 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/reference/services/teslamate.md
View file

@ -1,6 +1,6 @@
---
title: TeslaMate
modified: 2026-03-23
modified: 2026-04-07
last-reviewed: 2026-03-23
tags:
- service
@ -39,7 +39,19 @@ Self-hosted Tesla data logger collecting vehicle telemetry from the Tesla API.
- Drive Stats, Charging Stats, Projected Range
- Timeline, Updates, Visited
Dashboards use PostgreSQL datasource (not Prometheus).
Dashboards use PostgreSQL datasource (not Prometheus). The Grafana datasource connects as the `teslamate` database user.
## Database Permissions
The `teslamate` role was initially provisioned as superuser to allow extension creation (`cube`, `earthdistance`) during initial setup. Superuser has been removed — `teslamate` is now a plain database owner with extension ownership transferred so it can `ALTER EXTENSION ... UPDATE` without superuser.
Note: `earthdistance` is not a trusted extension in PostgreSQL, so `CREATE EXTENSION earthdistance` still requires superuser. If a future TeslaMate migration does `DROP EXTENSION ... CASCADE` + re-create (as happened in the 2024 migration), it will fail. In that case, temporarily grant superuser for the migration and remove it afterward.
Extension ownership persists across pod restarts and CNPG failovers, but a full cluster rebuild (major PG upgrade, fresh `initdb`) would re-create extensions as `postgres`. After any rebuild, transfer ownership back:
```sql
UPDATE pg_extension SET extowner = (SELECT oid FROM pg_roles WHERE rolname = 'teslamate') WHERE extname IN ('cube', 'earthdistance');
```
## Authentication