Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'

[quanah@zimbra.com]

--On Monday, August 01, 2011 9:47 PM +0000 hyc@symas.com wrote:

> whm@stanford.edu wrote:
>> Full_Name: Bill MacAllister
>> Version: 2.4.26
>> OS: Debian 6
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (171.64.19.165)
>>
>>
>> We typically setup local proxy servers to support applications that
>> cannot support a GSSAPI bind to the directory server.  The proxy server
>> allows anonymous access to the directory for connections from the
>> localhost and connects to the master using GSSAPI.  We are experiencing
>> a failures when we attempt to use the paged results control on the
>> proxy.  For example:
>>
>> ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h
>> localhost "(&(objectClass=suPerson)(suVisibIdentity=world))" ou
>>   telephonenumber title
>>
>> ends with the error:
>>
>> # search result
>> search: 5
>> result: 0 Success
>> control: 1.2.840.113556.1.4.319 false MA0CAQAECCiDAAAAAAAA
>> pagedresults: cookie=KIMAAAAAAAA=
>> # extended LDIF
>> #
>> # LDAPv3
>> # base<cn=people,dc=stanford,dc=edu>  with scope subtree
>> # filter: (&(objectClass=suPerson)(suVisibIdentity=world))
>> # requesting: ou telephonenumber title
>> # with pagedResults control: size=1000
>> #
>>
>> # search result
>> search: 6
>> result: 2 Protocol error
>> text: paged results cookie is invalid
>>
>> # numResponses: 4005
>> # numEntries: 4000
>>
>> This result is not consistent.  We have seen examples where 2000 and 3000
>> entries being returned and then the error.  Another test that we
>> performed with a slightly more complex filter, i.e.
>>
>>    "(&(objectClass=suPerson)(|(suVisibIdentity=world)(suVisibIdentity=wo
>>    rld)))"
>>
>> returned usually returned 1000 entries before erroring.
>>
>> Issuing a similar search directly against the backend ldap server
>> completes without
>> error.
>>
>> We have seen the same behavior on OpenLDAP 2.4.23 as well.
>>
>> Logs generated running slapd standalone with '-d stats,packets' are
>> available at http://www.stanford.edu/~whm/files/ldap-debugging/.
>
> Your log shows that the subsequent search request initiates a new Bind to
> the  remote server, which implies that it's not re-using the same
> connection as the  first request. Since a paged results cookie is only
> valid within the context  of a single connection, you get this error
> result.

Given that the client making the request is ldapsearch, which is not going 
to rebind mid search, and you can see it is done with noprompt, so there's 
no human interaction here, it seems like back-ldap is buggy here.  Why is 
*back-ldap* closing its connection to the upstream server and initiating a 
new bind?

--Quanah



--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration