RE: back-ldap, libldap_r

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

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
>
>