--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