[Date Prev][Date Next]
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
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
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