Description of problem: The healthcheck tool is reporting an error message while the suffix is indeed correctly defined. Adding and searching entries work just fine. $ dsctl <INSTANCE> healthcheck ... [1] DS Lint Error: DSBLE0001 -------------------------------------------------------------------------------- Severity: MEDIUM Check: backends:uppercase:mappingtree Affects: -- uppercase Details: ----------- This backend may be missing the correct mapping tree references. Mapping Trees allow the directory server to determine which backend an operation is routed to in the abscence of other information. This is extremely important for correct functioning of LDAP ADD for example. ... $ Version-Release number of selected component (if applicable): $ cat /etc/redhat-release Red Hat Enterprise Linux release 8.7 (Ootpa) $ $ rpm -qa | grep 389-ds 389-ds-base-1.4.3.31-11.module+el8dsrv+17815+4f95348d.x86_64 cockpit-389-ds-1.4.3.31-11.module+el8dsrv+17815+4f95348d.noarch 389-ds-base-legacy-tools-1.4.3.31-11.module+el8dsrv+17815+4f95348d.x86_64 389-ds-base-libs-1.4.3.31-11.module+el8dsrv+17815+4f95348d.x86_64 $ How reproducible: Always. Steps to Reproduce: 1. Define a suffix using mixed cases or upper case for the "nsslapd-backend" and "nsslapd-directory". For instance: ============================================== dn: cn=O\3DUPPERCASE,cn=mapping tree,cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree cn: O=UPPERCASE cn: O\=UPPERCASE nsslapd-state: referral on update nsslapd-backend: UPPERCASE creatorsName: cn=Directory Manager modifiersName: cn=server,cn=plugins,cn=config createTimestamp: 20230603080224Z modifyTimestamp: 20230603081059Z nsslapd-referral: ldap://<SUPPLIER_HOST>:<SUPPLIER_PORT>/o%3Duppercase numSubordinates: 1 ============================================== ============================================== dn: cn=UPPERCASE,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance cn: UPPERCASE creatorsName: cn=Directory Manager modifiersName: cn=Directory Manager createTimestamp: 20230603080224Z modifyTimestamp: 20230603080224Z nsslapd-suffix: O=UPPERCASE nsslapd-cachesize: -1 nsslapd-cachememsize: 603979776 nsslapd-readonly: off nsslapd-require-index: off nsslapd-require-internalop-index: off nsslapd-dncachememsize: 67108864 nsslapd-directory: /var/lib/dirsrv/slapd-<INSTANCE>/db/UPPERCASE numSubordinates: 4 ============================================== The trigger seems to be the presence of the "nsslapd-referral" parameter. The server is configured as a consumer for this suffix: ============================================== dn: cn=replica,cn=O\3DUPPERCASE,cn=mapping tree,cn=config objectClass: top objectClass: nsds5Replica cn: replica nsDS5ReplicaRoot: o=uppercase nsDS5Flags: 0 nsDS5ReplicaType: 2 nsDS5ReplicaBindDN: cn=replication manager,cn=config creatorsName: cn=Directory Manager modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config createTimestamp: 20230603080558Z modifyTimestamp: 20230615120958Z nsDS5ReplicaId: 65535 nsState:: //8AAAAAAABN/4pkAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA== nsDS5ReplicaName: 68a75783-01e511ee-9ffab29b-2dbcec18 ============================================== I cannot reproduce the issue when the suffix is not replicated. 2. Run the healthcheck command: $ dsctl <INSTANCE> healthcheck 3. Check the results. Actual results: Misleading messages. Expected results: The suffix is correctly configured so there should be no error message. Additional info: The same error message is repeated several times for the same backend: $ dsctl GSS_EMEA healthcheck | egrep "DS Lint Error: DSBLE0001|Check:" [1] DS Lint Error: DSBLE0001 Check: backends:uppercase:mappingtree [2] DS Lint Error: DSBLE0001 Check: backends:uppercase:mappingtree [3] DS Lint Error: DSBLE0001 Check: backends:uppercase:mappingtree [4] DS Lint Error: DSBLE0001 Check: backends:uppercase:mappingtree $
Upstream ticket: https://github.com/389ds/389-ds-base/issues/2374
Build tested: 389-ds-base-1.4.3.37-1.module+el8dsrv+19621+efe8bde6.x86_64 With the test case from the description healthcheck no longer returns DSBLE0001. Marking as VERIFIED. There is no test case dirsrvtests/tests/suites/healthcheck/health_config_test.py associated with this specific issue, so changing qe_test_coverage to ?. Automation will follow.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (redhat-ds:11 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:7519