Webmin on data appliances: primary only through the VIP, replica with a warning #57

New issue

Open

opened 2026-10-03 11:39:31 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-10-03 11:39:31 -03:00

(Migrated from github.com)

Maintainer decisions of 2026-10-03 on Webmin for the data appliances (MariaDB, PostgreSQL), to implement and to record in a decision note.

Decided

Standalone (one machine, no mesh): Webmin stays as today, public, with the full database module (the phpMyAdmin-like experience TurnKey users rely on). confconsole gets an option to restrict it.
Cloud modes, primary: Webmin is reachable only through the database VIP inside the WireGuard mesh, never on the public address. The VIP always points at the primary, so an operator who opens https://<vip>:12321 lands on the primary and cannot change the replica by mistake. Before etcd exists the VIP moves on a manual promote; with etcd it moves on failover (decisions 0020, 0025). It is a routed address moved by keel, not VRRP, since WireGuard carries no multicast or ARP.
Cloud modes, replica: Webmin stays reachable for system work (logs, files, services) on the replica's own mesh address and on a private LAN address, but every page shows a clear warning, and the first visit in a session must be acknowledged:

This node is a REPLICA, not the primary. Changes to the database here are not replicated and can break replication or lose data on failover. Use it only if you know what you are doing, for example to compare a file that is missing here but present on the primary. The primary is at .

The database module on the replica is read-only, or disabled with a link to the primary. On promotion it comes back and the warning goes away, driven by keel's role, not by hand. On demotion the reverse.
Webmin is never exposed publicly in cloud modes.

Why (MariaDB detail)

read_only does not stop root (Webmin connects as root): a write on a MariaDB replica is accepted, the replica diverges, replication breaks silently, and a failover can lose data. PostgreSQL refuses writes on a standby, but the warning still applies to files and services.

Pieces, probably across repos

keel: expose the node's role and the VIP to whatever renders the warning; bind Webmin per mode (miniserv bind/allow), applied by keel spec apply and switched on promote/demote.
common or the engine appliances: the Webmin theme banner, the acknowledgement page, the read-only module config (Webmin ACL for the mysql and postgresql modules).
confconsole: the restrict option in standalone; show where Webmin is reachable.
A decision note in the handbook recording this.

Done when: a two-node test (primary and replica over WireGuard) shows Webmin on the VIP reaching the primary, the replica's Webmin showing the warning and a read-only database module, the public address refusing Webmin in cloud modes, and promote/demote switching all of it.

Maintainer decisions of 2026-10-03 on Webmin for the data appliances (MariaDB, PostgreSQL), to implement and to record in a decision note. ## Decided 1. **Standalone** (one machine, no mesh): Webmin stays as today, public, with the full database module (the phpMyAdmin-like experience TurnKey users rely on). confconsole gets an option to restrict it. 2. **Cloud modes, primary:** Webmin is reachable only through the database VIP inside the WireGuard mesh, never on the public address. The VIP always points at the primary, so an operator who opens `https://<vip>:12321` lands on the primary and cannot change the replica by mistake. Before etcd exists the VIP moves on a manual promote; with etcd it moves on failover (decisions 0020, 0025). It is a routed address moved by keel, not VRRP, since WireGuard carries no multicast or ARP. 3. **Cloud modes, replica:** Webmin stays reachable for system work (logs, files, services) on the replica's own mesh address and on a private LAN address, but every page shows a clear warning, and the first visit in a session must be acknowledged: > This node is a REPLICA, not the primary. Changes to the database here are not replicated and can break replication or lose data on failover. Use it only if you know what you are doing, for example to compare a file that is missing here but present on the primary. The primary is at <vip>. The database module on the replica is read-only, or disabled with a link to the primary. On promotion it comes back and the warning goes away, driven by keel's role, not by hand. On demotion the reverse. 4. Webmin is never exposed publicly in cloud modes. ## Why (MariaDB detail) `read_only` does not stop root (Webmin connects as root): a write on a MariaDB replica is accepted, the replica diverges, replication breaks silently, and a failover can lose data. PostgreSQL refuses writes on a standby, but the warning still applies to files and services. ## Pieces, probably across repos - keel: expose the node's role and the VIP to whatever renders the warning; bind Webmin per mode (miniserv `bind`/`allow`), applied by `keel spec apply` and switched on promote/demote. - common or the engine appliances: the Webmin theme banner, the acknowledgement page, the read-only module config (Webmin ACL for the mysql and postgresql modules). - confconsole: the restrict option in standalone; show where Webmin is reachable. - A decision note in the handbook recording this. Done when: a two-node test (primary and replica over WireGuard) shows Webmin on the VIP reaching the primary, the replica's Webmin showing the warning and a read-only database module, the public address refusing Webmin in cloud modes, and promote/demote switching all of it.