Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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

Summary:	Sorting with attributes in ldapsearch gives incorrect result
Product:	Red Hat Enterprise Linux 6	Reporter:	Noriko Hosoi <nhosoi>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Sankar Ramalingam <sramling>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.4	CC:	amsharma, jgalipea, nhosoi, nkinder
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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.	Story Points:	---
Clone Of:	918712	Environment:
Last Closed:	2013-11-21 21:11:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	918712
Bug Blocks:

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