RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 989692 - Sorting with attributes in ldapsearch gives incorrect result
Summary: Sorting with attributes in ldapsearch gives incorrect result
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On: 918712
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-29 18:07 UTC by Noriko Hosoi
Modified: 2020-09-13 20:21 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.2.11.15-22.el6
Doc Type: Bug Fix
Doc Text:
Cause: When a server side sorting request is evaluated, the sort type (e.g., string, integer) was picked up only from the first attribute in the request and not reset even if the following attributes have the different sort type. Consequence: If the server receives a server side sorting request containing multiple sort attributes with the different sort types, it returns the incorrect result once it hits the different sort type from the first one. Fix: The server side sorting resets the sort type for each sort attribute in the request. Result: The server side sorting returns the correct sorted result when the server receives a request containing multiple sort attributes with the different sort types.
Clone Of: 918712
Environment:
Last Closed: 2013-11-21 21:11:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 543 0 None None None 2020-09-13 20:21:42 UTC
Red Hat Product Errata RHBA-2013:1653 0 normal SHIPPED_LIVE 389-ds-base bug fix update 2013-11-20 21:53:19 UTC

Description Noriko Hosoi 2013-07-29 18:07:14 UTC 
+++ 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
Comment 1 Noriko Hosoi 2013-07-31 20:03:39 UTC 
Test case: clu/cluSearch:trac543
Comment 3 Amita Sharma 2013-09-20 10:04:34 UTC 
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.
Comment 4 errata-xmlrpc 2013-11-21 21:11:24 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.