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

David Zeuthen david at fubar.dk
Mon Apr 3 05:27:00 UTC 2006


On Mar 29, 2006, at 7:29 PM, Avi Alkalay wrote:

> In addition to the words bellow, the "D" on D-Conf comes from the  
> "Desktop" word, which means D-Conf is a desktop-oriented wannabe- 
> project. You won´t be able to standarize configuration for say  
> named, dhcpd, resolver, sysctl, modprobe, /sbin/init, network  
> configurations, etc etc etc with it.

Speaking of wanna-be. I think one fundamental problem with the  
LinuxRegistry/Elektra approach is that you try to fix the symptoms of  
the problem instead of the root problems.  I've written about this  
before and I will do it again and again as apparently people are  
still trying to fix the symptoms of our problem:

  Configuration of software in a mainstream distribution is a mess.

Most of this mail is about the desktop, but really, if you look at  
it, desktop is _a lot harder_ than server (there is just so much more  
code and so much more functionality) so my view is that if we solve  
it for desktop then the server bits will pan out mostly by itself.

It seems that Elektra simply wants to remap the configuration file  
for a piece "software" into a hierarchical key/value database and I  
think that's missing the point entirely. First of all you got to ask  
yourself whether there should be a configuration of said piece of  
software in the first place. If you think really hard about it you  
will find that for most pieces of software this is false - you really  
don't want any configuration files... Hence you really don't want nor  
need Elektra.

Let us look at what "configuration" really means; I've seen it being  
used in the following ways

  - The programmer is lazy and makes the user look up configuration  
values he could have determined programmatically - for example this  
includes the laptop_mode scripts where you can configure what IDE  
drives to put to sleep. The poor user will have to put in arcane  
values such as "/dev/hda", "/dev/hdd" and so forth. You know, maybe  
the laptop_mode developer wasn't that lazy, maybe the kernel people  
was just sleeping and gave him no easy way to find out what drives to  
put to sleep when he wants.. or maybe what the kernel said was  
unreliable and the kernel never got fixed.... Does this justify  
bothering the poor end user with crap like this? I think not.

  - Configuration can be system-wide, for example mail and web  
servers... Sure, my web server needs to know where to serve files  
from, my mail server needs to know what domain it serves and so forth

  - When developers write a daemon and decide to make it system-wide,  
then most of the time they either really want it to be site-wide or  
session-wide instead. Most of the time they don't even know this... I  
will argue that system-wide is just plain wrong for most things;  
continue reading...

  - Site-wide software: This includes for example a cluster of web  
servers. The user experience if I'm an administrator is that I can  
just plug in another physical server box, PXE-boot it and it reads  
all "web server configuration" from LDAP. If it blows up I can  
replace it. Hence, no need at all for having some httpd.conf file.  
For the (terribly uninteresting) case of only having one machine as a  
web server it reads settings from the local LDAP server. Ditto with  
mail servers, name servers etc.

  - Session-wide software: Just so we're all on the same page,  
"session-wide" means something that runs in a user desktop session.  
Historically, the desktop wasn't very advanced and didn't integrate  
well with the system. Back then things that really was session-wide  
would run as a system-wide daemon mostly also because it required  
root to enforce policy. Things like acpid for power management event  
handling, updfstab for removable media, ifplugd for handling network  
cable removable, networking scripts etc. comes to mind. As you can  
see with Fedora Core 5 this is radically starting to change; acpid is  
obsoleted by gnome-power-manager, updfstab (and fstab-sync for that  
matter) is obsoleted by gnome-volume-manager / gnome-mount, the  
networking scripts is starting to be completely obsoleted by  
NetworkManager. We have more things on out "hit list"...

  - You really really want session-wide daemons to run in the session  
and not as the system because it's much easier for the user to  
configure it.. in fact, you get per-user settings for removable media  
handling and power management in FC5. And since all this is backed by  
gconf it's easy for the OS vendor _and_ the administrator to set sane  
defaults, lock things down and so forth. It's just a lot better

  - Look at the terrible and insecure hacks for writing out  
configuration files for system-wide daemons that ought to be session- 
wide. See also my rant on fedora-maintainers last week why  
consolehelper (that these tools rely on) is fundamentally flawed.

  - Things like smb.conf is really not interesting for the desktop  
case as it's the wrong solution to the problem of sharing files and  
using files other systems wants to share. The right answer here is  
obviously things like Nautilus and gnome-user-share and other things  
that run in your session and is easy to configure.

  - X.org having a configuration is completely broken too; obviously  
the X.org server should be able to configure itself (and it can but  
X.org itself has bugs so it doesn't always work) and it should offer  
a D-BUS interface for reconfiguration so some per-session piece of  
software can program it with the users setting when your session  
starts. Yes, display configuration is also per-user although the  
brain dead design of X.org doesn't reflect this.

I don't have a good answer to KDE and GNOME sharing configuration; I  
personally think that as this point it's impossible to get developers  
of both camp to agree on a scheme for even simple things like desktop  
backgrounds and HTTP proxies. And should the day come when gconf  
depends on KConfig, vice versa, or when there is D-Conf I'm sure this  
will get solved by itself. It sure as hell doesn't need Elektra for  
this.

So my message is that I think it's a waste of time trying to shoehorn  
a configuration file format onto all kinds of software because said  
software is likely to be already broken for at least desktop use. My  
stance is simply that it's unacceptable in a desktop system to ever  
ever have to touch a configuration file and I think some people  
(*cough* Apple *cough* Microsoft *cough*) take the same stance even  
for the server. So we shouldn't ship software that rely on them.  
Hence, there is zero need for Elektra. It's really that simple if you  
think about it.

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. I think it  
would be great if you could change Elektra into something that would  
fix this. But please back off trying to pretend you solve problems  
for the desktop because you're not. The design of gconf is pretty  
nice (implementation might be another matter but, you know, that's  
totally fixable) and it's more than sufficient for desktop use, thank  
you very much.

Hope this clarifies why Elektra is simply the wrong answer. I'm sorry  
for sounding harsh and saying most of our software in the  
distribution is broken, but it's kinda this conclusion I've arrived  
at. We could do so much better if we all tried to solve the root  
problems and look at what the user experience should be.

Have a nice day.

     David

Disclaimer : this mail doesn't necessarily reflect the views of Red  
Hat, Inc.





More information about the fedora-devel-list mailing list