Hi Quanah,
Just to follow-up & close this conversation from last monday, and also for the archives.
Turns out you were completely right: the root DSE ('slapcat | grep "o: infra"') was missing on both slaves. We have no idea how long already, and what caused this.
I have scripts that compare the actual served full DIT, and those all matched, and also replication was still working.
So, we ended up dropping the database on the slaves, let replication do it's thing, and 2 1/2 minute later: voila: contextCSN records *were* returned on the slaves. (and "o: infra" now also exists, DITs are in sync)
Thanks again for your assistance. And yes: we are in the middle of moving away from 2.4/bdb to 2.5/mdb
Have a good day, everybody!
Op 12-06-2023 om 17:28 schreef Quanah Gibson-Mount:
--On Monday, June 12, 2023 6:02 PM +0200 cYuSeDfZfb cYuSeDfZfb cyusedfzfb@gmail.com wrote:
Hi!
I am using the cn=admin,o=infra,c=com with correct password to connect. I will further check ACLs! Thank you for that suggestion. crrectcompare Just to make things more concrete, below are two samples. One on the MASTER with contextCSN, and one from the SLAVE without contextCSN.
EXAMPLE SLAVE: ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b "o=infra,c=com" -s base contextCSN # extended LDIF # # LDAPv3 # base <o=infra,c=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN #
# search result search: 2 result: 0 Success
I've no idea if 'cn=admin,o=infra,c=com' is a rootdn or not. Since it couldn't even find the root of your DIT, I would suspect it is not the rootdn and that ACLs are the issue. If it is the rootdn, then that database is corrupt.
--Quanah