Some more (perhaps relevant?) backgroup info.

These four servers have recently (last week) been struck by corruption of the underlying .dbd files. In order to get things working again, we did on all four servers: - stop slapd - slapcat > temp.ldif - remove /var/lib/ldap/* (except DB_CONFIG) - slapadd -n 2 -l temp.ldif - chown ldap:ldap /var/lib/ldap/* - chown root:root /var/lib/ldap/DB_CONFIG - start slapd

Perhaps this background info is relevant..?

Thanks again for your efforts, they are much appreciated!

On Mon, 12 Jun 2023 at 17:02, 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.

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

# numResponses: 1

EXAMPLE MASTER: 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 #

# infra, com dn: o=infra,c=com contextCSN: 20180917142109.765066Z#000000#000#000000 contextCSN: 20230612144901.796553Z#000000#001#000000 contextCSN: 20230612144904.899482Z#000000#002#000000

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1

On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount quanah@fast-mail.org wrote:

...

--On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb cyusedfzfb@gmail.com wrote:

...

Hi Quanah,

Thanks for the swift reponse! I think I do, yes, see, from consumer one:

olcSyncrepl: {0}rid=202 provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcSyncrepl: {1}rid=201 provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" starttls=critical tls_reqcert=demand olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389 olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389

That's syncrepl, not syncprov.

However, the issue could be ACLs. If you use the rootdn for your database to run the query, can you see the contextCSN value stored in your database root?

--Quanah

--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.

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