linux registry (no, not that again!)

[Avi Alkalay]

On Thu, 04 Nov 2004 10:11:14 +0100, Iago Rubio <iago.rubio at hispalinux.es> wrote:
> ITOH as you ask me to explain my thoughts, hiveconf scares me less
> because it uses application's configuration files and will not drive
> anybody to use a fixed configuration scheme, and a fixed configuration
> files' layout on disk.
> 
> It also scares me, because it's a central failure point for the whole
> system.

I don't know much about Hiveconf. I only know it is made in Python or Ruby....
Anyway, being a library and not a service, again, Elektra is not a
SPoF. By design.
The namespace is unified, but not the underlying storage. On purpose.



> About Elektra, I don't know how will it fit in chrooted environments.

You'll have a separate tree of keys under $(chroot)/etc/kdb/ or
$(chroot)/~user/.kdb/ for your in-jail program. You can also use
SELinux with Elektra for improved security.



> But technical matters apart, Elektra could be a good idea but I don't
> spect rapid doption by upstream developers, and maintenance of all
> config packages elektrified will require a huge patching effort.

Being realistic, me neither. I agree.



> Sysadmins will not be happy to change their sendmail configuration files
> that have been around for years.

/etc/sendmail.cf is not a configuration file. It is a full program
:-). A very special case.
But I got your point. A switch will not happen from one day to
another. It is a paradigm shift, and it takes time. But IMHO, I can't
handle such a big mess of different configuration files and locations
anymore. And I can't handle to explain that to customers and business
software developers. They see Linux as a very confusing system.
Obviously, switching from plain text to a key namespace is not enough.
It must be adopted by higher level software, OS base configurations,
distros, an ecosystem. Then we'll stop having different flavors of
Linux, and something way more usable.


> So to get a chance for adoption, you should also code the conversion of
> old config files to elektra - a "hiveconf" layer between old configs and
> elektra.
> 
> Once you get this done and you get elektra adopted by upstream
> developers of important packages, it's time to advocate for the
> inclusion in a distro.

This is the chicken-and-egg problem. Samba, Apache, etc may adopt it
if major distros adopt it. Major distros will adopt it if Samba,
Apache etc adopt it.

Out there in the business world, developers (specially those who came
from a Windows environment) are thirsty for some registry-like
configuration store. Its easy to handle configurations (nobody wants
to write configuration file compilers). Its better to design software
that provides a plugin architecture (extensions integrate themselves
changing a few keys, instead of having to understand and regenerate
the whole configuration file). Current Linux (distro-specific) ad-hoc
for this is the configuration dir, where you drop your configuration
piece.
I believe it is the distribution role to feel this market need and
include developer tools like Elektra. I'm not saying to patch
everything to a key database right now, but to just include it and let
the ecosystem (specially of commercial apps) grow. It doesn't have to
be Elektra, but for obvious reasons I believe it is the most
system-wide, simple, and close to what they already know (WRegistry).
BTW, Elektra API is also being ported to Windows, so a cross-platform
app will have the same source code to access configurations (namespace
is cross-plat too), and on Windows the API will fetch keys in the
Windows Registry. More about this architecture in this presentation (I
just uploaded an update):

http://elektra.sourceforge.net/elektra.sxi     or
http://elektra.sourceforge.net/presentation/elektra.html



> Right now, I don't think redhat folks have time to expend in the
> enourmous task of elektrify - and maintain elektrified - the whole
> fedora, even if they'd think it's the best idea in years.

Nobody has time :-( This is why it takes time. And this is natural in
the Open Source model.
We at the Elektra list are writing patches (and help is welcome):
- Patch for /sbin/init ready to be used (try the FC2 RPM from SF)
- A name system switch (to get users from Elektra instead of passwd
and group) ready to be used
- Some patches to libc
- And the X.org patch, so no /etc/X11/xorg.conf, but keys under
system/sw/xorg/* . It is almost ready (by now I can convert any
xorg.conf file to Elektra and vice-versa, and make X read its
configurations from the key database) and very nice.
- A graphical key database editor, similar to gconf-tool



> It should be adopted by upstream developers.

Including it in major distros may help here. Fedora/Red Hat is key.

Regards,
Avi