Hi,
We have a 3 node multi master replication configuration setup with many consumers replicating from all 3 provider nodes.
The consumers and providers replicate the from the MDB tree dc=example,dc=com. They do not replicate their config databases.
The root password we are rotating is for cn=admin,dc=example,dc=com.
Upon updating the olcRootPW we see the provider where the password was updated commit a new CSN and then syncrepl seems to fail for connected consumers with
slapd[9227]: conn=1439 op=1 syncprov_op_search: consumer 2102 state 20230712210938.878334Z#000000#836#000000 is newer than provider 2102 state 20230712210402.018624Z#000000#836#000000
It seems as if the consumers reconnect with a state newer than the provider that just committed a new CSN for the new root password?
It did not seem like the root password was replicated across the cluster however which I imagine is a deliberate choice to not replicate root db DNs.
Is there a recommended workflow to rotate the root credential for a replicated database to avoid syncrepl disruption?
OpenLDAP 2.4.56 (we are working to upgrade to OpenLDAP 2.5 LTS)
--On Thursday, July 13, 2023 2:33 AM +0000 thomaswilliampritchard@gmail.com wrote:
Hi,
We have a 3 node multi master replication configuration setup with many consumers replicating from all 3 provider nodes.
The consumers and providers replicate the from the MDB tree dc=example,dc=com. They do not replicate their config databases.
The root password we are rotating is for cn=admin,dc=example,dc=com.
If you're modifying olcRootPw in the cn=config DB, and you don't replicate it, then there should be no change logged for syncrepl since it would not "see" the change to cn=config, only the database(s) being replicated. Since you are seeing a change generated, then it sounds like your syncrepl config is different than your expectations.
--Quanah
-----Original Message----- From: thomaswilliampritchard@gmail.com thomaswilliampritchard@gmail.com Sent: Wednesday, July 12, 2023 6:34 PM To: openldap-technical@openldap.org Subject: Rotating olcRootPW
I don't see the usefulness for a root password. Root = anonymous super user. Do you really want all your creatorsNames/modifiersNames to be rootdn? IMO: Better to use access control and give the right people the right access. Yes, in a real world, sometimes you need total circumvention. For that there is EXTERNAL IPC mode, to map the system root to rootdn per admin guide 15.2.4.2. I like to have that restricted to the host. Seems to me to be just right that way.
Update:
After more experimenting we realized the the ldif we ran was doing a few things.
1. updating cn=config rootdn and password (was not changing anything just re-running modify to the same values) 2. updating dc=example,dc=com rootdn and password (only changing password) 3. updating the db suffix for dc=example,dc=com (was not changing the value just running a modify to the same value)
We've narrowed it down to updating the suffix seemed to be giving the providers issues. The scope of our changes really only needs to modify olcRootPW on the dc=example,dc=com database which seems to be working just fine and not giving any databases a hard time when we only run that change.
After investigation the logs closer we noticed that on provider instances when we updated all 3 in the same LDIF the providers seemed to crash and restart. When they restarted the syncrepl aspect of the providers determined the most recent CSN correctly, however the sncprov aspect of the providers was reset to a CSN hours old, therefore thinking the consumers upon reconnect were 'ahead'. After issuing a write to the crashed provider syncprov determined it's CSN was now 'newer' than the consumer and would oblige the delta sync repl requests.
Anyway we have changed our approach here to rotate the password and think it will be okay.
As Chris mentions we should be in a model where we can simply operate without a root password.
openldap-technical@openldap.org
-
Christopher Paul -
Quanah Gibson-Mount -
thomaswilliampritchard＠gmail.com