Description of problem: Customer is migrating from and HP directory server where the case of the entries is preserved and returned when queried. RHDS does not do this and this breaks a large amount of applications/code used internally Version-Release number of selected component (if applicable): RHDS 11 How reproducible: everytime. Steps to Reproduce: 1. import HPDS ldif file 2. query data 3. observe that the results are all uppercase when the ldif file has lower case data Actual results: data returned from LDAP is all upper case Expected results: data returned to be the same case that was in the ldif file. Additional info:
I can not reproduce the server making DN's upper case (or lower case), and I have never heard of this happening until now. In my testing, using ldapmodify to add an entry, and also exporting and importing the LDIF, the case is preserved: # ldapmodify -D cn=dm -W dn: cn=Mark's Group,dc=example,dc=com changetype: add objectClass: top objectClass: groupOfNames cn: Mark's Group # ldapsearch -xLLL -D cn=dm -W -b dc=example,dc=com cn=mark* dn dn: cn=Mark's Group,dc=example,dc=com Then I exported and imported the database, and the case remained intact: # ldapsearch -xLLL -D cn=dm -W -b dc=example,dc=com cn=mark* dn dn: cn=Mark's Group,dc=example,dc=com So this is NOT an RFE as the server is already preserving the DN case. I tested RHDS 11 and RHDS 12 and both work as expected. There could be a bug, but we would need a reproducible testcase to verify the behavior described in the bug description. Please provide all the necessary information to reproduce the problem in this bugzilla.
If acceptable, would you test that easy fix Save a copy of /usr/lib/python3.9/site-packages/lib389/backend.py Then apply that change diff --git a/src/lib389/lib389/backend.py b/src/lib389/lib389/backend.py index 5520834c6..d5550c355 100644 --- a/src/lib389/lib389/backend.py +++ b/src/lib389/lib389/backend.py @@ -608,7 +608,7 @@ class Backend(DSLdapObject): dn = ",".join(dn_comps) if properties is not None: - suffix_dn = properties['nsslapd-suffix'].lower() + suffix_dn = properties['nsslapd-suffix'] dn_comps = ldap.dn.explode_dn(suffix_dn) ndn = ",".join(dn_comps) properties['nsslapd-suffix'] = ndn
After further discussion with the team, this kind of fix is possibly not valid and may not work to address initial concern. Indeed, 'after creating the suffix '"O=TEST2_XXX,C=WW", if I add the entry 'uid=FOO,ou=people,o=test2_xxx,c=ww' and then search it, it will be returned with uppercase ldapsearch -LLL ... -b "O=TEST2_XXX,C=WW" uid=FOO uid dn: uid=FOO,ou=people,O=TEST2_XXX,c=WW uid: FOO
(In reply to thierry bordaz from comment #14) > After further discussion with the team, this kind of fix is possibly not > valid and may not work to address initial concern. > > Indeed, 'after creating the suffix '"O=TEST2_XXX,C=WW", if I add the entry > 'uid=FOO,ou=people,o=test2_xxx,c=ww' and then search it, it will be returned > with uppercase > > ldapsearch -LLL ... -b "O=TEST2_XXX,C=WW" uid=FOO uid > dn: uid=FOO,ou=people,O=TEST2_XXX,c=WW > uid: FOO It is important to note that all DN's will follow what is in the backend configuration under cn=config. So if you define the suffix in uppercase, then ALL entries will be returned in UPPER case, even if they are adding in LOWER case. So it's all or nothing with the current design - you can not mix and match DN's with different cases for the root suffix component of the DN.
The RFE is not yet fully clear to help us to status on it. Reviewing it we ended with that set of options. Could you confirm which one is required: 1 - Return the entry DN as it is added DB contains o=SWIFT,cn=WW o=foo, o=SWIFT,cn=WW ADD: uid=bar,o=FOO,o=SWIFT,cn=WW ldapsearch -b "o=SWIFT,cn=WW" uid=bar ==> uid=bar,o=FOO,o=SWIFT,cn=WW 2- Return the entry DN as it is requested DB contains o=SWIFT,cn=WW o=foo, o=SWIFT,cn=WW uid=bar,o=foo,o=SWIFT,cn=WW ldapsearch -b "o=FOO,o=SWIFT,cn=WW" uid=bar ==> uid=bar,o=FOO,o=SWIFT,cn=WW ldapsearch -b "o=foO,o=SWIFT,cn=WW" uid=bar ==> uid=bar,o=foO,o=SWIFT,cn=WW ldapsearch -b "o=foo,o=SWIFT,cn=WW" uid=bar ==> uid=bar,o=foo,o=SWIFT,cn=WW ldapsearch -b "o=SWIFT,cn=WW" uid=bar ==> uid=bar,o=foo,o=SWIFT,cn=WW 3 - Return the entry DN in upper/lower case DB contains o=SWIFT,cn=WW o=foo, o=SWIFT,cn=WW uid=bar,o=foo,o=SWIFT,cn=WW ldapsearch -b "o=SWIFT,cn=WW" uid=bar ==> uid=bar,o=foo,o=swift,cn=ww (lowercase) ldapsearch -b "o=SWIFT,cn=WW" uid=bar ==> uid=BAR,o=FOO,o=SWIFT,cn=WW (uppercase) If none of those options address completely the RFE, would you please give some examples (current state, actions, expected results) of the requirements.
Closing this bug as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2075017 In RHDS 12 we will look into this above mentioned bug as it provides a noticeable performance boost. As a side effect of this feature it will also preserve the case of the DN (providing exactly what the customer wants - hence it's now a duplicate). *** This bug has been marked as a duplicate of bug 2075017 ***