[Date Prev][Date Next]
RE: back-ldap, libldap_r
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.
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
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