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

[David Zeuthen]

Hi Joe,

On Tue, 2006-04-04 at 14:32 +0100, Joe Orton 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).  

You could be more ambitious and just have a local LDAP proxy that caches
values. Yes, this introduces additional complexity.

> And how do you 
> configure the LDAP connection: TLS, auth, etc?  

Use mDNS and Avahi. Or UPnP. Or whaterver. But don't aim to support
everything under the sun... it's just not worth it.. Pick one and go for
that.

> 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?

Because it's crazy to support everything; if you have that goal you end
up with a lot of mediocre software. 

We have the Fedora Directory Server now, just use that. 

And I still want to echo: it's not enough to do this with patches to our
own packages. You want to engage upstream of each project and make them
buy in to the idea. You potentially want to change how upstream software
works in order to support the concept of clusters. You need to make a
case for each and every piece of upstream software why this is a good
idea.

> So the reality is that rather than add all that complexity to 50 
> different daemons,

50!? Again, the golden rule here is simplicity. Don't task yourself with
supporting everything under the sun; pick a few projects that are viable
and go with that; for example

 - Apache
 - Postfix
 - Bind
 - Some SQL server

and do a good job on them. Do you disagree?

>  it's better to go and write one single tool which can 
> create flat file configurations from LDAP databases, 

No, you really really want to change the way upstream software works.
You need to look at the user stories to begin with; if I'm an
administrator with at a big site what do I want to do?

 - Provisioning of machines; Want to be able to plug in a physical box
   and automatically make it join my cluster
 - 99% of users only need Apache, Postfix, Bind, some SQL server or
   whatever
 - (add more user stories here)

Start with the user stories, create the architecture, make a plan,
implement it. It's _a lot_ of work. Or maybe you think this either is
the wrong approach or Utopia?

FWIW, I think what we've been doing / are doing on the desktop with
D-BUS/HAL/NetworkManager/g-v-m/g-p-m etc is very similar to this; this
too was / is a lot of work. But if you see how people receive then most
people like it. Sure, we have some work left (running NM, g-p-m, g-v-m
when no one is logged in). Sure, some oldskool hackers like Pete
Zaitchev [1] complain about it in a sorta condescending way, but if you
read the reviews of FC3, FC4, FC5 you will see that we're going in the
right direction. 

Yes, so maybe right now the desktop bits are not always suitable for
l33t kernel hackers like Pete with very, suffice to say, unusual
requirements but down the road we will fill those gaps too. It's just
about prioritizing. I expect the same to be true if someone tries to
revamp all the server bits.

There is no such thing as a free lunch. But you got to aim high and be
ambitious.

    David

[1] : http://zaitcev.livejournal.com/55435.html