On Thu, 04 Nov 2004 10:11:14 +0100, Iago Rubio <iago.rubio@xxxxxxxxxxxxx> 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
