PostgreSQL pair, minor: database status is MariaDB only, wrong primary address on the holder, changelog trailer, image notes #155

New issue

Open

opened 2026-10-14 18:04:52 -03:00 by marcos-mendez · 2 comments

marcos-mendez commented

2026-10-14 18:04:52 -03:00

(Migrated from github.com)

Minor items found on real nodes on 2026-10-14 (keel 0.23.18, PostgreSQL VIP pair). The evidence is in the handbook, docs/evidence/2026-10-14-postgresql-pair-real.md.

keel database status is MariaDB only. On a PostgreSQL pair it prints "server: no MariaDB server installed here" and nothing about the standby, the slot or the synchronous commit. docs/replication-postgresql.md says "Both timelines are numbers ...; keel diff and keel database status show them". Neither shows a timeline (keel diff shows only engine, role, listen and the primary's host and port).
The primary's address is the other member on the primary. On the VIP holder, keel database status says "the primary's address: ", and keel spec apply says "the role is the VIP's: primary here (epoch known, held at )". keel vip status on the same node says the holder is this node.
debian/changelog: the 0.23.18 entry has no trailer line. dpkg-parsechangelog on the build host: "found start of entry where expected more change data or trailer" at line 72. The package built and published.
Follow names the wrong missing field. On a node with appliance.vip and no database.server, follow says "this node declares no appliance.vip: there is no VIP for the database to follow".

Not keel, recorded for the image owners (keel-postgresql image, step 12):

The image has a physical replication slot pg_receivewal_service, inactive, restart_lsn 0/1000000, wal_status reserved. It keeps all WAL from the start of the cluster.
On a restart of CT 9062, the first-boot inithooks ran again ("inithooks.conf: Permission denied" lines; regen-sshkeys, 29sudoadmin "password for 'root' changed"). The SSH host keys and the root password changed on a plain reboot.

Minor items found on real nodes on 2026-10-14 (keel 0.23.18, PostgreSQL VIP pair). The evidence is in the handbook, `docs/evidence/2026-10-14-postgresql-pair-real.md`. 1. **`keel database status` is MariaDB only.** On a PostgreSQL pair it prints "server: no MariaDB server installed here" and nothing about the standby, the slot or the synchronous commit. `docs/replication-postgresql.md` says "Both timelines are numbers ...; `keel diff` and `keel database status` show them". Neither shows a timeline (`keel diff` shows only engine, role, listen and the primary's host and port). 2. **The primary's address is the other member on the primary.** On the VIP holder, `keel database status` says "the primary's address: <the other member>", and `keel spec apply` says "the role is the VIP's: primary here (epoch known, held at <the other member>)". `keel vip status` on the same node says the holder is this node. 3. **`debian/changelog`: the 0.23.18 entry has no trailer line.** `dpkg-parsechangelog` on the build host: "found start of entry where expected more change data or trailer" at line 72. The package built and published. 4. **Follow names the wrong missing field.** On a node with `appliance.vip` and no `database.server`, follow says "this node declares no appliance.vip: there is no VIP for the database to follow". Not keel, recorded for the image owners (keel-postgresql image, step 12): 5. The image has a physical replication slot `pg_receivewal_service`, inactive, `restart_lsn 0/1000000`, `wal_status reserved`. It keeps all WAL from the start of the cluster. 6. On a restart of CT 9062, the first-boot inithooks ran again ("inithooks.conf: Permission denied" lines; regen-sshkeys, 29sudoadmin "password for 'root' changed"). The SSH host keys and the root password changed on a plain reboot.

marcos-mendez commented

2026-10-14 18:27:19 -03:00

(Migrated from github.com)

After the inithooks run at boot, passwd -S root gives L (locked) on CT 9062 and P on CT 9054.

After the inithooks run at boot, `passwd -S root` gives L (locked) on CT 9062 and P on CT 9054.

navigator commented

2026-10-15 19:54:52 -03:00

Owner

Items 1, 2 and 3: keel#181 (0.23.30, not released). Item 6: common#55 and inithooks#47. The cause was 35pgsqlpass, which waited on a console that nobody reads, so 98finalize never ran. The hostname change of CT 9054 comes from Proxmox, which writes /etc/hostname from the CT configuration at each start. Evidence: handbook docs/evidence/2026-10-15-inithooks-first-boot-again.md. Items 4 and 5 stay open.

Items 1, 2 and 3: keel#181 (0.23.30, not released). Item 6: common#55 and inithooks#47. The cause was `35pgsqlpass`, which waited on a console that nobody reads, so `98finalize` never ran. The hostname change of CT 9054 comes from Proxmox, which writes `/etc/hostname` from the CT configuration at each start. Evidence: handbook `docs/evidence/2026-10-15-inithooks-first-boot-again.md`. Items 4 and 5 stay open.