directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <>
Subject Re: Toward 2.0...
Date Wed, 18 Mar 2009 01:20:36 GMT
David Boreham wrote:
> Graham Leggett wrote:
>> That said, both Fedora and OpenLDAP use the DIT for config, so that
>> may be an XML free option :)
> FDS doesn't exactly use the DIT. We had the same argument that you're
> having, in 1997 or so, and
> decided to write an 'ldif back end' for the server, specifically for
> config (there had been an earlier
> flat-file back end that provided some inspiration and possibly some
> code).

Heh. Sounds like the same discussion we had in 2000, it took us a while to get 
out of the weeds of LDAPv3 before we could see it. ;)

> This replaced the original
> UMich text config file (which I believe OpenLDAP still used until
> recently). So while the config
> manifests as LDAP entries, and can be read/written over-the-wire, it is
> stored in a text file as LDIF.
> If it were in the primary database, you'd have a chicken/egg problem.

Right. We wound up with an LDIF backend as well; it can still be configured as 
a primary database (but that would be stupid) but its main point is that it is 
so simple to configure (just needs a directory path to store its files) that 
its bootstrap can be hardcoded, thus giving us the initial egg.

I also experimented with using back-ldap as the cn=config backing store; i.e., 
running a server with a configuration proxied from (and thus identical to) a 
separate server. But it's more reliable to just replicate the master's config 
to a local LDIF copy. There's no reason we couldn't provide hardcoded 
parameters for any other backend type as well, but back-ldif has the virtue of 
being human-readable/editable in case Something Went Wrong...

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

View raw message