Thursday, April 15, 2021

[389-users] Re: dsctl healthcheck bug - or bad at least a bad resolution

On 4/15/21 1:24 PM, Gary Waters wrote:
> Hi Mark ,
>
> Thank you so much for your time.
>
> On 4/15/21 7:54 AM, Mark Reynolds wrote:
>>
>> I don't see your backend entry in your output, just the mapping tree
>> entry.  It takes two entgries to define a backend and suffix
>> (annoying I know but that's how it works).  So how did you create
>> your suffix?  Did you use ldapmodify or did you use dsconf?
>>
>> Do you have these two entries in your config?  If so, please show
>> both of them.
>
> I used ldapmodify to create my backend and suffix. Here are both from
> the dse.ldif:
>
> dn: cn=somesuffixRoot,cn=ldbm database,cn=plugins,cn=config
> objectClass: extensibleObject
> objectClass: nsBackendInstance
> objectClass: top
> cn: somesuffixRoot
> creatorsName: cn=directory manager
> modifiersName: cn=directory manager
> createTimestamp: 20210415004818Z
> modifyTimestamp: 20210415004818Z
> numSubordinates: 4
> nsslapd-suffix: ou=somesuffix,o=caltech,c=us
> nsslapd-cachesize: -1
> nsslapd-cachememsize: 134217728
> nsslapd-readonly: off
> nsslapd-require-index: off
> nsslapd-require-internalop-index: off
> nsslapd-dncachememsize: 67108864
> nsslapd-directory: /var/lib/dirsrv/slapd-ldaphub/db/somesuffixRoot
>
> dn: cn=ou\3Dsomesuffix\2Co\3Dcaltech\2Cc\3Dus,cn=mapping tree,cn=config
> objectClass: top
> objectClass: extensibleObject
> objectClass: nsMappingTree
> nsslapd-state: referral on update
> nsslapd-backend: somesuffixRoot
> cn: ou=somesuffix,o=caltech,c=us
> creatorsName: cn=directory manager
> modifiersName: cn=server,cn=plugins,cn=config
> createTimestamp: 20210415004818Z
> modifyTimestamp: 20210415005939Z
> numSubordinates: 1
> nsslapd-referral:
> ldap://supplier2:389/ou%3Dsomesuffix%2Co%3Dcaltech%2Cc%3Dus
> nsslapd-referral:
> ldap://supplier1:389/ou%3Dsomesuffix%2Co%3Dcaltech%2Cc%3Dus
> nsslapd-referral:
> ldap://supplier0:389/ou%3Dsomesuffix%2Co%3Dcaltech%2Cc%3Dus
> nsslapd-referral:
> ldap://supplier4.caltech.edu:389/ou%3Dsomesuffix%2Co%3Dcaltech%2
>  Cc%3Dus
> nsslapd-referral:
> ldap://supplier5.caltech.edu:389/ou%3Dsomesuffix%2Co%3Dcaltech%2
>  Cc%3Dus
> nsslapd-referral:
> ldap://supplier3.caltech.edu:389/ou%3Dsomesuffix%2Co%3Dcaltech%2
>
> Cc%3Dus

These entries look fine.  I'm assuming you are running this on a hub or
consumer, is that correct?  Does it work correctly on the supplier
replica?  I think the "nsslapd-state=referral on update" might be
tripping up the healthcheck.

Mark

>
>
>> You can not set a replica ID for a hub. Only supplier replicas get
>> unique replica ID's.  So when you try and set a replica id on a hub
>> or consumer it will get replaced by 65535.
>>
> I was thinking that was the case because it was a number larger than
> possible for the field.
>
> -Gary
>
--

389 Directory Server Development Team
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

No comments:

Post a Comment