RE: back-ldap, libldap_r

["Howard Chu" <hyc@highlandsun.com>]

The changes described below have been committed to HEAD. back-ldap passes
test008 so I think it's reasonably usable, barring the timeout/retry issues I
mentioned. There are likely to be other shared resources in the LDAP* handle
that need protection that I haven't dealt with. If back-ldap didn't touch
them, I haven't looked.

Todo:
   rebind/retry if an operation on a shared connection fails. This should
only be needed if the remote server has timed out an idle connection.
   SASL bind - this would allow back-ldap to use SASL/EXTERNAL with SSL/TLS
to talk to the remote server. Would also be practical for SASL/GSSAPI if some
other daemon takes care of ticket refresh. Might also be useful for the
interal/privileged binds using passwords.
   timeout idle sessions - close a shared session if it hasn't been used in a
while. I don't think this is a big deal, will probably ignore it.
   limit number of active sessions - will probably ignore it.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Howard Chu
> Sent: Wednesday, February 12, 2003 9:10 PM
> To: openldap-devel@OpenLDAP.org
> Subject: RE: back-ldap, libldap_r
>
>
> Heads up - I've made the changes I alluded to below. Testing
> now; if nothing
> blows up I will commit to HEAD soon. I have also reworked
> back-ldap to allow
> connection pooling:
>   connections that are explicitly bound through back-ldap
> cannot be shared.
>      i.e., a client that binds using a DN that lies under
> back-ldap's suffix
>      gets a private connection.
>   other connections are shared:
>      "privileged" connections are shared:
>          connections authorized as back-ldap's rootdn are shared, and
> 		authenticate to the remote server using the
> binddn/bindpw that
> 		was configured. (Currently this binddn is
> documented as used by
> 		ldap_back_group only. If we need a different
> set of config
> 		keywords for this, that's OK.)
>          operations with op->o_do_not_cache set are
> privileged and share the
> 		root connection as above. This handles SASL
> internal searches.
>          ldap_back_attribute and ldap_back_group are
> privileged and share the
> 		root connection as above.
>      implicitly bound connections are shared:
>          sessions are shared by DN. any operations that all
> have a common
> 		op->o_ndn will share a single session.
>
> Private connections are unbound when the client unbinds.
> Shared connections
> are unbound when the backend is shut down. Will need to
> refine this with some
> timeouts, retries, and max connections later. But for the
> main uses that I
> envision, only the shared privileged session is of interest,
> so I don't
> anticipate this keeping a large number of connections hanging around.
>
> With this setup, I can configure the ldapsasl auxprop module
> to bind thru
> ldapi to a local proxy with SASL/EXTERNAL for Unix-based
> credentials. I can
> use sasl-regexp to map the Unix root uid to the back-ldap
> rootdn (or simply
> set back-ldap's rootdn to the Unix root SASL DN), thus
> allowing privileged
> access to the remote server.
>
>   -- Howard Chu
>   Chief Architect, Symas Corp.       Director, Highland Sun
>   http://www.symas.com               http://highlandsun.com/hyc
>   Symas: Premier OpenSource Development and Support
>
> > -----Original Message-----
> > From: owner-openldap-devel@OpenLDAP.org
> > [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Howard Chu
> > Sent: Saturday, December 21, 2002 1:02 PM
> > To: openldap-devel@OpenLDAP.org
> > Subject: back-ldap, libldap_r
> >
> >
> > Something I'd be interested in trying out would be adding
> some mutexes
> > libldap to allow multiple threads to submit requests on the
> > same handle. I
> > could do pretty much the same thing in back-ldap but I think
> > it could be
> > better done in the library.
> >
> > Need a mutex for each request and response queue. For results
> > we need to
> > tweak try_read1msg() and wait4msg() such that it unlocks
> > (optionally yields)
> > and relocks the response mutex before looping back when it
> > hasn't found the
> > requested msgid. This way multiple threads can wait on
> their responses
> > without too much hassle.
> >
> >   -- Howard Chu
> >   Chief Architect, Symas Corp.       Director, Highland Sun
> >   http://www.symas.com               http://highlandsun.com/hyc
> >   Symas: Premier OpenSource Development and Support
> >
> >
>
>