--On Tuesday, August 02, 2011 11:03:24 AM -0700 Quanah Gibson-Mount <[email protected]> wrote:
> --On Tuesday, August 02, 2011 5:54 PM +0000 [email protected] wrote: > >> >> >> --On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister >> <[email protected]> wrote: >> >>> >>> >>> --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu >>> <[email protected]> wrote: >>> >>>> [email protected] 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= >>>>> world)))" >>>>> >>>>> 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. >>> >>> Not sure which log you are looking at. When I look at the log: >>> >>> http://www.stanford.edu/~whm/files/ldap-debugging/slapd-trace-paged-resu >>> lts.log.gz >>> >>> The only connection I see in the log is conn=1000 and it ends with: >>> >>> conn=1000 op=5 SEARCH RESULT tag=101 err=2 nentries=0 text=paged results >>> cookie is invalid ldap_read: want=8, got=7 >>> 0000: 30 05 02 01 07 42 00 0....B. >>> ldap_read: want=8, got=0 >>> >>> conn=1000 op=6 UNBIND >>> conn=1000 fd=11 closed >>> >>> These tests where made with a single ldapsearch request. The ldapsearch >>> tests fail when using the proxy and succeed when connecting directly to >>> the LDAP server with the database on it. >>> >>> A side node: the test case I submitted used ldapsearch, but the >>> problem was uncovered using a python application that is used for >>> syncing Gmail account data. >>> >>> Bill >> >> I have copied the backend server configuration to >> http://www.stanford.edu/~whm/files/ldap-debugging/. I dumped an >> copy of cn=config and there is a files based version the in ldap >> subdirectory as well. > > Where's the configuration for the slapd-ldap server? That's of the > most importance... > > --Quanah Of course, sorry about that. I have copied the files to the web site. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University
