Bug 696160

Summary:	Openldap server fails to handle paged queries
Product:	Red Hat Enterprise Linux 5	Reporter:	Ian Kent <ikent>
Component:	autofs	Assignee:	Ian Kent <ikent>
Status:	CLOSED DUPLICATE	QA Contact:	yanfu,wang <yanwang>
Severity:	medium	Docs Contact:
Priority:	high
Version:	5.7	CC:	ikent, jplans, jvcelak, yanwang
Target Milestone:	rc
Target Release:	---
Hardware:	ppc64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-16 03:27:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Ian Kent 2011-04-13 13:06:46 UTC

Description of problem:

When result set size is restricted on the server and a client tries
to use the paged LDAP request API to obtain a query result set that
is larger than the restricted result set size the server responds
incorrectly following the fist set of results. The problem occurs
on the architectures ppc64 (and probably s390x which I will be
testing soon) only. Other architectures function properly.

The sequence of calls for a paged LDAP query is:

Use ldap_create_page_control() to create a page control object.
Call ldap_search_ext_s() for the query using the page control.
Parse the result using ldap_parse_result() to retrieve the
control(s).
Use ldap_parse_page_control() to parse the retrieved control.

It is at this point that an incorrect result is received in
the cookie used to indicate that more results are available
after the first page of results is received.

Specifically, if more results are available the contents of
the field cookie->bv_val should be not be empty, which is the
server telling use we can get another page of results if needed.

On ppc64 the cookie bv_val is empty after receiving the first
set of results which is the server saying there are no more
results, when in fact there are.


Version-Release number of selected component (if applicable):
Sorry, I didn't check the version. If really needed I can
check out a lab machine and re-run my test.

How reproducible:
always.

Steps to Reproduce:

The Beaker workflow-autofs subtest bz563956 demonstrates the
failure provided autofs-5.0.1-0.rc2.155.el5 or later is used.
The test sets up an automount map with 1100 entries and 
configures LDAP to allow an unlimited result set size, then
checks LDAP is functioning. It then changes the LDAP configuration
to a hard sizelimit of 2000 and a soft sizelimit of 1000 to test
the paged query needed to read the automount map.

The problem was identified by checking out a lab system with a
current RHEL-5.7 install then adding debug prints to the
automount program and carrying out the test steps manually.

Comment 1 Ian Kent 2011-04-13 13:13:22 UTC

Yanfu Wang and myself can help with any testing needed.

I've set the priority to high because we have a z-stream bug
held up in QA due to this difficulty. Any help or suggestions
as to how this should be done differently, if that is the case,
would be much appreciated.

Comment 2 Jan Vcelak 2011-04-13 23:36:51 UTC

Hi Ian,

openldap in EL5 doesn't export ldap_create_page_control(). I quickly scanned autofs sources and they use their own implementation of this function.

The problem appeared when the server was running on ppc64? Or client? Or both? I would like to write a minimal reproducer.

Jan

Comment 3 Ian Kent 2011-04-14 02:38:40 UTC

(In reply to comment #2)
> Hi Ian,
> 
> openldap in EL5 doesn't export ldap_create_page_control(). I quickly scanned
> autofs sources and they use their own implementation of this function.

Ahh, thanks for your catching that obvious problem that I missed.

That's done because in earlier versions of openldap a couple of
the paged query functions were not declared in the header files
but existed and in the libraries and functioned ok. So configure
checks for them and if they aren't present autofs uses its own.

I guess that means that the autofs internal functions need to
be updated to also detect when paged result sets aren't supported
by the server. Once again any suggestions would be appreciated. 

> 
> The problem appeared when the server was running on ppc64? Or client? Or both?
> I would like to write a minimal reproducer.

In this case the test sets up LDAP on the same machine as the
autofs client so the ppc machine is both client and server.

Comment 4 Jan Vcelak 2011-04-14 08:29:01 UTC

(In reply to comment #3)
> I guess that means that the autofs internal functions need to
> be updated to also detect when paged result sets aren't supported
> by the server. Once again any suggestions would be appreciated. 

I don't know yet. 'ldapsearch -E !pr=10/noprompt' obviously works on RHEL-5. Please, can you try reproducing it with ldapsearch?

Comment 5 Ian Kent 2011-04-14 15:26:31 UTC

(In reply to comment #4)
> (In reply to comment #3)
> > I guess that means that the autofs internal functions need to
> > be updated to also detect when paged result sets aren't supported
> > by the server. Once again any suggestions would be appreciated. 
> 
> I don't know yet. 'ldapsearch -E !pr=10/noprompt' obviously works on RHEL-5.
> Please, can you try reproducing it with ldapsearch?

OK, so loading up the LDAP server with 1100 entries, setting
sizelimit.hard=2000 and sizelimit.soft=1000, and using 
"ldapsearch -E '!pr=1000/noprompt'" looks like it does do
a paged query successfully against the ppc64 server. So I
wonder what I'm doing wrong ....

Comment 7 Ian Kent 2011-05-16 03:27:18 UTC

Another bug has been opened to work on this issue.

*** This bug has been marked as a duplicate of bug 700896 ***