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/. Bill
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=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. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--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
Quanah Gibson-Mount wrote: > --On Monday, August 01, 2011 9:47 PM +0000 hyc@symas.com 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. > > 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? You haven't provided any slapd configuration info. Without seeing that it's way premature to claim there's any bug here. Look at the log yourself. back-ldap *doesn't* close the connection. Don't spew garbage about what it does when it didn't actually do such a thing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu <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=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-results.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 -- Bill MacAllister Infrastructure Delivery Group, Stanford University
--On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister <whm@stanford.edu> wrote: > > > --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu <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=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-results.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. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University
--On Tuesday, August 02, 2011 5:54 PM +0000 whm@stanford.edu wrote: > > > --On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister > <whm@stanford.edu> wrote: > >> >> >> --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu >> <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= >>>> 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 -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
--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: > >> >> >> --On Tuesday, August 02, 2011 10:08:32 AM -0700 Bill MacAllister >> <whm@stanford.edu> wrote: >> >>> >>> >>> --On Monday, August 01, 2011 02:46:50 PM -0700 Howard Chu >>> <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= >>>>> 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
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/
--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc@symas.com> wrote: > 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. I modified the configuration to include: idassert-bind bindmethod=SASL saslmech=GSSAPI mode=none binddn=cn=auth I am stilling getting the invalid-cookie error. % ldapsearch -E pr=1000/noprompt -x -b "cn=people,dc=stanford,dc=edu" -h localhost "(&(objectclass=suPerson)(suVisibIdentity=world))" ou telephonenumber title ...lots of entries... # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MA0CAQAECGIdAAAAAAAA pagedresults: cookie=Yh0AAAAAAAA= # 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: 3 result: 2 Protocol error text: paged results cookie is invalid # numResponses: 1002 # numEntries: 1000 Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University
--On Tuesday, August 02, 2011 02:16:27 PM -0700 Howard Chu <hyc@symas.com> wrote: > Sounds like this may be related to ITS#6817. Please try adding a > dummy binddn to your idassert-bind directive and re-test. And, at Quanah's prompting I tried it with an empty empty binddn and got similar results. Still a failure, sometimes after returning 1000 entries, sometimes after returning 2000 entries. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University
> Sounds like this may be related to ITS#6817. Please try adding a dummy > binddn > to your idassert-bind directive and re-test. First of all, I believe the real problem is that pr should not be used by the client in the first place. However, the cause of the issue might be something slightly different: back-ldap uses a pool of connections for special identities, including anonymous and rootdn; the latter is the case when identity assertion is used. So it seems plausible that although the client uses the same connection for repeated paged results requests, the proxy is using different ones. We already discussed the possibility to specially handle pr in proxies, in order to decouple its use by the client and the remote server. If slapd handles pr in the frontend, a proxy does not need to propagate pr requests to the remote server. Similarly, if a remote server *needs* pr, the client must not necessarily know about it. Something like this has already been implemented in back-meta(5), which can be instructed to silently continue unsolicited pr responses without informing the client about them (I should have ported this to back-ldap(5) as well). If this is the case (need to investigate in detail, yet), a quick fix could be to detect the presence of pr on a request, and bind the cookie to a specific connection until that cookie is gone. One thing that could be tried is to use slapo-sssvlv(5) on top of back-ldap and let it deal with the pr request. p.
I confirm that the issue is related to performing the operation with a privileged identity, which results in pooled connections taken nearly randomly regardless of the client's connection requesting paged results. p.
changed notes changed state Open to Suspended
This one just bit us again. I know that the client should probably not be using pr at all, but the client is an Google supplied intergration application that we have little control over. Is this a problem that is going to be addressed as some point or will it be treated as a known limitation? Bill -- "We have meet the enemy and he is us." Pogo
back-ldap connection pooling is broken with paged results see discussion
changed notes changed state Suspended to Open moved from Incoming to Software Bugs
See alternative solutions in comment #11