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 <cyusedf...@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 <qua...@fast-mail.org>
> wrote:
>
>>
>>
>> --On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
>> <cyusedf...@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
>>
>>
>>
>>
