Found while auditing the new LDAP MMR auto-config for gaps: neither
POST /site-promote nor POST /demote ever touched SiteSpoke. Two real
problems:
1. The demoted old master got a fresh masterJoinKey but was never
registered as a spoke of the new master -- no SiteSpoke row, no
ldapServerId, invisible to GET /ldap-peers's peer list. It also
structurally could not self-heal: POST /join refuses re-join for a
node that's already a spoke, and separately requires a fresh
install (siteIsFresh()) -- neither true for a former master with
real users/agents. Fixed: /demote now registers itself with the new
master immediately (POST /spokes), the same way a real join does,
deriving its own endpoint from stack.selfUrl (override) or
https://stack.ssoHost (the normal case).
2. The promoted node's live OpenLDAP ServerID doesn't change --
GET /ldap-replication-config starts advertising 1 for it
immediately (derived purely from cfg.isMaster), but nothing
restarts slapd with that value (OpenLDAP's static slapd.conf only
reloads at process start, and this app has no safe way to restart
its own container). Can't be fixed in-process; surfaced instead --
/site-promote's response now includes ldapReplicationNote telling
the operator to re-run setup.sh promptly.
Verified against real running containers (docker-compose.multisite-e2e.yml):
after promotion, the demoted old master correctly appears in the new
master's LDAP peer list with a real assigned ldapServerId.
wmantly
dae0361e82