Red Hat Bugzilla – Bug 989692
Sorting with attributes in ldapsearch gives incorrect result
Last modified: 2013-11-21 16:11:24 EST
+++ This bug was initially created as a clone of Bug #918712 +++ This bug is created as a clone of upstream ticket: https://fedorahosted.org/389/ticket/543 I have performed sorting in ldapsearch operation with all the combination of two attributes (sn, telephonenumber). I have made the 'sn' values of all the entries same and the 'telephonenumber' values different so that the sorting order for all the search results will be same. But the sorting order for the search results are not same as expected. When I sort with "sn", "sn telephonenumber" and "telephonenumber sn" the ordering of the search results are same. The search results of "telephonenumber" sort is different from other results. At least the search results for sorting with "telephonenumber" and "telephonenumber sn" should give similar results as all the entries have same 'sn' value. Note: It is reproduced in 389 DS-1.2.15 Reproducer details: ---------------------------------------------------------------------- The data I have uploaded to the database is given below dirsrv12@dirsrv12-VirtualBox:~$ cat data.ldif dn: uid=scarter, ou=People, dc=asiapacific,dc=hpqcorp,dc=net cn: Sam Carter sn: Test sn givenname: Sam objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: scarter telephonenumber: 12 dn: uid=tmorris, ou=People, dc=asiapacific,dc=hpqcorp,dc=net cn: Ted Morris sn: Test sn givenname: Ted objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: tmorris telephonenumber: 1 3 dn: uid=kvaughan, ou=People, dc=asiapacific,dc=hpqcorp,dc=net cn: Ken kvaughan sn: Test sn givenname: Kirsten objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: kvaughan telephonenumber: 1 23 The sorting search results for all the combinations are given below Sorting with sn dirsrv12@dirsrv12-VirtualBox:~$ ldapsearch -h dirsrv12-VirtualBox -p 389 -b "ou=people,dc=asiapacific,dc=hpqcorp,dc=net" -s one -S "sn" -x "(objectclass=inetorgperson)" sn telephonenumber # extended LDIF # # LDAPv3 # base <ou=people,dc=asiapacific,dc=hpqcorp,dc=net> with scope oneLevel # filter: (objectclass=inetorgperson) # requesting: sn telephonenumber # # scarter, People, asiapacific.hpqcorp.net dn: uid=scarter,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 12 # tmorris, People, asiapacific.hpqcorp.net dn: uid=tmorris,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 1 3 # kvaughan, People, asiapacific.hpqcorp.net dn: uid=kvaughan,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 1 23 # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Sorting with telephonenumber dirsrv12@dirsrv12-VirtualBox:~$ ldapsearch -h dirsrv12-VirtualBox -p 389 -b "ou=people,dc=asiapacific,dc=hpqcorp,dc=net" -s one -S "telephonenumber" -x "(objectclass=inetorgperson)" sn telephonenumber # extended LDIF # # LDAPv3 # base <ou=people,dc=asiapacific,dc=hpqcorp,dc=net> with scope oneLevel # filter: (objectclass=inetorgperson) # requesting: sn telephonenumber # # kvaughan, People, asiapacific.hpqcorp.net dn: uid=kvaughan,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 1 23 # tmorris, People, asiapacific.hpqcorp.net dn: uid=tmorris,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 1 3 # scarter, People, asiapacific.hpqcorp.net dn: uid=scarter,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 12 # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Sorting with telephonenumber sn dirsrv12@dirsrv12-VirtualBox:~$ ldapsearch -h dirsrv12-VirtualBox -p 389 -b "ou=people,dc=asiapacific,dc=hpqcorp,dc=net" -s one -S "telephonenumber sn" -x "(objectclass=inetorgperson)" sn telephonenumber # extended LDIF # # LDAPv3 # base <ou=people,dc=asiapacific,dc=hpqcorp,dc=net> with scope oneLevel # filter: (objectclass=inetorgperson) # requesting: sn telephonenumber # # scarter, People, asiapacific.hpqcorp.net dn: uid=scarter,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 12 # tmorris, People, asiapacific.hpqcorp.net dn: uid=tmorris,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 1 3 # kvaughan, People, asiapacific.hpqcorp.net dn: uid=kvaughan,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 1 23 # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3 Sorting with sn telephonenumber dirsrv12@dirsrv12-VirtualBox:~$ ldapsearch -h dirsrv12-VirtualBox -p 389 -b "ou=people,dc=asiapacific,dc=hpqcorp,dc=net" -s one -S "sn telephonenumber" -x "(objectclass=inetorgperson)" sn telephonenumber # extended LDIF # # LDAPv3 # base <ou=people,dc=asiapacific,dc=hpqcorp,dc=net> with scope oneLevel # filter: (objectclass=inetorgperson) # requesting: sn telephonenumber # # scarter, People, asiapacific.hpqcorp.net dn: uid=scarter,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 12 # tmorris, People, asiapacific.hpqcorp.net dn: uid=tmorris,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 1 3 # kvaughan, People, asiapacific.hpqcorp.net dn: uid=kvaughan,ou=People,dc=asiapacific,dc=hpqcorp,dc=net sn: Test sn telephonenumber: 1 23 # search result search: 2 result: 0 Success # numResponses: 4 # numEntries: 3
Test case: clu/cluSearch:trac543
In acceptance test report of RHEL65 :: Bug trac 543 is fixed. Search result /tet/testcases/DS/6.0/tet_tmp_dir//cluSearch_trac543.txt is identical to good result /tet/tet/../data/DS/6.0/clu/en//trac543.g_e.out.good backend for dc=trac543,dc=com is trac543 modifying entry cn=USN,cn=plugins,cn=config Hence Marking as VERIFIED.
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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1653.html