[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LDAP db; openldap libraries



On Tue, Oct 12, 2004 at 04:59:47AM -0300, Jeff Warnica wrote:
> Greets all.
> 
> As you may be aware, I've been doing some work on the LDAP database
> module. Over the last week or so I've gotten back to working on it, or
> more accurately, working on the router scripts to take advantage of it.
> Ive put together a quick proto module implementing the long expired
> "LDAP Schema for Intranet Mail Routing". In beginning to write up some
> documentation for the db module, I was reminded of some deficiencies,
> and that led me to slogging around C, and my current problem.
> 
> Many of the things I want to accomplish in modernizing the LDAP module,
> while supported by the LDAPv3 spec are _not_ mentioned in the draft LDAP
> C API RFC - they may only be supported by the OpenLDAP libraries. Or are
> handled in a significantly different way with, say, the Mozilla LDAP
> libraries. Some examples:
> 
> Mozilla has a bunch of ldapssl_* functions, and it is unclear if they
> also work with TLS. OpenLDAP and Mozilla definitely treat certificate
> databases differently. The former uses OpenSSL, which uses flat/text +
> PEM encoded files, the later Mozilla/Netscapes Network Security Services
> library, which uses Berkeley DB 1.85 hashes + god knows what.
> 
> ldap_init() is part of the draft spec. ldap_initialize(), which can take
> a list of URIs is not supported by Moz, but "preferred" by OpenLDAP. The
> later allows at least two interesting things to happen at the library
> level,  server fall-over, ldapi:/// (ldap over a socket).

I would, myself, wastly prefer a library that does (for a read-only
client) automagic server fail-over.  Is it parametrizable somehow ?
E.g. if query takes too long (5+ seconds) abort and switch to other
server  ?

So far we have used simple synchronous interfaces that won't let one
to watch over details like "it takes too long" -- it has been simple
to code such, but also there has not been all that much of interest at
improving the subsystem.

With the SleepyCat DB, there is a libary of support routines for
a whole family of those databased that are used within the router.
Something similar could be cooked up to support advanced LDAP APIs.
Maybe even to support (alternatively) OpenLDAP and Netscape-LDAP.


> etc, etc, etc.
> 
> So I have a couple of questions for the list:
> 
> - Is anyone actually interested in seeing a modernized LDAP db
>    module? .cf updates to utilize it?
> - Would requiring the OpenLDAP libraries (but not necessarily an
>   OpenLDAP server) be an unreasonable requirement?

I would, for one.  I might even get to use it.

-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi