[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

whm@stanford.edu wrote:
> --On Tuesday, August 02, 2011 11:03:24 AM -0700 Quanah Gibson-Mount<quanah@zimbra.com>  wrote:
>
>> --On Tuesday, August 02, 2011 5:54 PM +0000 whm@stanford.edu wrote:
>>>>> 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.

Sounds like this may be related to ITS#6817. Please try adding a dummy binddn 
to your idassert-bind directive and re-test.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/