Why Elektra is the wrong approach (Was Re: The Strengths and Weakness of Fedora/RHEL OS management)

Avi Alkalay avi at unix.sh
Tue Apr 4 15:48:07 UTC 2006


On 4/4/06, Joe Orton <jorton at redhat.com> wrote:
>
> On Mon, Apr 03, 2006 at 01:27:00AM -0400, David Zeuthen wrote:
> > I wish that people working on the server bits (e.g. Apache, Postfix)
> > would take a similar stance and only make their software read
> > settings from LDAP (or whatever) for the site-wide case.
>
> This always seems like a nice simple idea in theory.  The reality is
> that you'd have to put so much complexity in to deal with stuff like
> working out what to do during a restart if the LDAP server suddenly
> stops responding (at the point where you have already thrown away the
> old config).  You also have to come up with (and hard-code!) some LDAP
> schema; and have it extensible to third-party modules (i.e. generic
> enough that it's just untyped key-value pairs again).  And how do you
> configure the LDAP connection: TLS, auth, etc?  Just relying on the
> system-wide defaults doesn't cut it for 99% of apps so why would it
> here?  And why only support an LDAP backend?  Why not also an SQL
> database, or a WebDAV repository?
>

I also think LDAP adds a considerable ammount of complexity with its need
for a schema, was not designed for this purpose, adds risk of network
unavailability, makes no sense in single computer environments, and is
wrongly inspired in AD, because AD is not LDAP: it is more than LDAP, and
some parts of it can be represented as an LDAP server.

On the other hand, if these softwares are elektrified, you can point their
configurations to be read from the network, just switching the key database
backend. This is transparent to the application.

Regards,
Avi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20060404/1223acdf/attachment-0002.html 


More information about the devel mailing list