dovecot - Apr 2007 - Comment from OpenLDAP developer regarding "deferring operations"

I received this response from a member of the OpenLDAP core team when
asking about meaning of the deferred operations I was seeing.

Is it possible that this is what I'm seeing, Timo?

-Ben

---------------------------------------------

I'd note that if your client is performing search + bind on the same
connection in an asynchronous manner, then the server behavior as per
RFC4511 is undefined, since a server is not supposed to be willing to
handle operations intermixed with binds until a bind is concluded.  That
is, any operation can be multiplexed on a single LDAP connection
__except__ binds, which must be serialized.  A more appropriate client
for that type of operations would need to use at least 2 connections,
one for searches and one for binds, and the one for binds should take
care of either performing synchronous binds, or in any case to wait for
response to a bind before performing another.  In case of failure (e.g.
timeout) while waiting for bind response, the connection should be
trashed (see ldap_unbind_ext(3)) and recreated.  This is what is done,
for example, by slapd-ldap(5).

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati at sys-net.it
---------------------------------------

On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
> I'd note that if your client is performing search + bind on the same
> connection in an asynchronous manner, then the server behavior as per
> RFC4511 is undefined, since a server is not supposed to be willing to
> handle operations intermixed with binds until a bind is concluded.  That
> is, any operation can be multiplexed on a single LDAP connection
> __except__ binds, which must be serialized.
That's how I thought it was working. But I think I found a bug in there.
See if the attached patch fixes it?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldap-bind-fix.diff
Type: text/x-patch
Size: 538 bytes
Desc: not available
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070412/18a38113/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070412/18a38113/attachment-0003.bin>

I'll apply the patch later this morning and and let you know what I see.

For what it's worth, last night I started dumping traffic between
dovecot and openldap.  The pattern I see most consistently was this:

-> bind request (anonymous)
-> search request
<- bind response
<- search result

As I understand it, the search request being sent before the result of
the bind request is received could trigger the deferrals.

Thanks!

-Ben

On 4/12/07, Timo Sirainen <tss at iki.fi> wrote:
> On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
> > I'd note that if your client is performing search + bind on the
same
> > connection in an asynchronous manner, then the server behavior as per
> > RFC4511 is undefined, since a server is not supposed to be willing to
> > handle operations intermixed with binds until a bind is concluded. 
That
> > is, any operation can be multiplexed on a single LDAP connection
> > __except__ binds, which must be serialized.
>
> That's how I thought it was working. But I think I found a bug in
there.
> See if the attached patch fixes it?
>
>
>

On 4/12/07, Timo Sirainen <tss at iki.fi> wrote:
> On Wed, 2007-04-11 at 19:50 -0500, Ben Beuchler wrote:
> > I'd note that if your client is performing search + bind on the
same
> > connection in an asynchronous manner, then the server behavior as per
> > RFC4511 is undefined, since a server is not supposed to be willing to
> > handle operations intermixed with binds until a bind is concluded. 
That
> > is, any operation can be multiplexed on a single LDAP connection
> > __except__ binds, which must be serialized.
>
> That's how I thought it was working. But I think I found a bug in
there.
> See if the attached patch fixes it?
It does!  Not a single "deferring operation" entry in nearly an hour!

Now to wait and see if this change, Roy's patch, and linking against
the new libldap_r can combine to eliminate my intermittent (and
frustratingly non-reproducible) auth freezes.

-Ben