Re: no contextCSN attribute on consumers
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
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 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
Re: no contextCSN attribute on consumers
Op 12-06-2023 om 17:29 schreef Quanah Gibson-Mount: > It appears you are using the historic back-hdb or back-bdb backend to > OpenLDAP. These backends are particularly susceptible to corruption. > You should migrate to using the supported backend (back-mdb). You > should also upgrade to a supported release series (2.5 or 2.6) as 2.4 > hasn't been supported for a few years. Yes we are in the middle of migrating. :-) The old structure still uses bdb, yes. While working on new (RHEL9) servers with symas-repo 2.5 openldap, things started happening with the 'old' (but still production) ldap. Thank you very much for your insights! Kind regards!
Re: no contextCSN attribute on consumers
--On Monday, June 12, 2023 6:14 PM +0200 cYuSeDfZfb cYuSeDfZfb wrote: 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 I would generally suggest using -q with slapadd as well here. - chown ldap:ldap /var/lib/ldap/* - chown root:root /var/lib/ldap/DB_CONFIG - start slapd Perhaps this background info is relevant..? It appears you are using the historic back-hdb or back-bdb backend to OpenLDAP. These backends are particularly susceptible to corruption. You should migrate to using the supported backend (back-mdb). You should also upgrade to a supported release series (2.5 or 2.6) as 2.4 hasn't been supported for a few years. Regards, Quanah
Re: no contextCSN attribute on consumers
--On Monday, June 12, 2023 6:02 PM +0200 cYuSeDfZfb cYuSeDfZfb 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 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
Re: no contextCSN attribute on consumers
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
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 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 with scope baseObject
> # filter: (objectclass=*)
> # requesting: contextCSN
> #
>
> # infra, com
> dn: o=infra,c=com
> contextCSN: 20180917142109.765066Z#00#000#00
> contextCSN: 20230612144901.796553Z#00#001#00
> contextCSN: 20230612144904.899482Z#00#002#00
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
> On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount
> wrote:
>
>>
>>
>> --On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
>> 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
>>
>>
>>
>>
Re: no contextCSN attribute on consumers
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 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 with scope baseObject
# filter: (objectclass=*)
# requesting: contextCSN
#
# infra, com
dn: o=infra,c=com
contextCSN: 20180917142109.765066Z#00#000#00
contextCSN: 20230612144901.796553Z#00#001#00
contextCSN: 20230612144904.899482Z#00#002#00
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount
wrote:
>
>
> --On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
> 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
>
>
>
>
Re: no contextCSN attribute on consumers
--On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
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
Re: no contextCSN attribute on consumers
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
And the second consumer looks similar.
Thanks again!
On Mon, 12 Jun 2023 at 15:56, Quanah Gibson-Mount wrote:
>
>
>
> --On Monday, June 12, 2023 3:23 PM +0200 cYuSeDfZfb cYuSeDfZfb
> wrote:
>
> > Is there any explanation, why I would be unable to obtain these
> > contextCSN attributes through an ldapsearch?
>
> Do you have the syncprov overlay instantiated on the database on the
> consumers?
>
> --Quanah
>
>
>
>
Re: no contextCSN attribute on consumers
--On Monday, June 12, 2023 3:23 PM +0200 cYuSeDfZfb cYuSeDfZfb wrote: Is there any explanation, why I would be unable to obtain these contextCSN attributes through an ldapsearch? Do you have the syncprov overlay instantiated on the database on the consumers? --Quanah
no contextCSN attribute on consumers
Hi, We have a 4-machine setup with two providers (replicating between each other) and two consumers (for client access) that both replicate from both providers, type=refreshAndPersist I'm trying to write a script to monitor replication, using the contextCSN attribute. ldapsearch on the providers gives the expected the contextCSN attributes: contextCSN: 20230612115901.693614Z#00#001#00 contextCSN: 20230612115904.937471Z#00#002#00 However, the same ldapsearch on the consumers gives *no* contextCSN attributes *at all*. But when using slapcat to check directly on the consumers databases, we *can* see the attributes, and they are also up-to-date: contextCSN: 20230612115801.572594Z#00#001#00 contextCSN: 20230612115804.594419Z#00#002#00 Is there any explanation, why I would be unable to obtain these contextCSN attributes through an ldapsearch? This is RHEL7.9, with openldap 2.4.44 Thanks!
