Songbird Technologies :: Wiki: Uniconf

Configuration Management On Linux

Managing the configuration on Linux is an arduous task unless you are a very knowledgeable system administration. Tasks such as the installation and configuration of hardware, configuration of software, or even changing the default screen resolution are tasks which requires the user to have read through reams of documentation.

The problem is even more acute when it comes to remote configuration of Linux PCs.

The problem of configuring Linux is not because that Linux applications are inherently difficult to configure, but that each application stores and retrieves its configuration differently. The configuration files do not follow any standard formats and are strewn across multiple directories on the Linux file system. This problem is further compounded by the fact that different Linux distributions save the configuration files in different directories.

Multiple attempts have been made to solve this problem. Some of the examples which spring to mind are:

Uniconf

URL - http://open.nit.ca/wiki/index.php?page=UniConf∞

A very comprehensive library which merges the configuration management efforts of KDE, GNOME etc... and a few others. The Uniconf developers refer to it as a the "One True Configuration System." :) Quite cool. Haven't really used it but the documentation is pretty good.

Advantages

1. Supports a network daemon mode. So multiple machines can read the configuration of a single server. Neat!
2.

DConf

Eletkra

GConf

URL - http://www.gnome.org/projects/gconf/∞

Another nice introduction http://polishlinux.org/gnome/gconf-gnome-under-the-hood/∞
I initially came upon Gconf a few years ago when I was writing my own implementation of a configuration management library for Linux. At that time, Gconf had the support for using properties files which are similar to INI files but, if I remember correctly, Gconf required that the application specify the exact path to the configuration file. This was not ideal as it implied that the application should be aware of exactly where the configuration repository resides on the PC.

This is no longer the case now. Gconf now stores the configuration information securely in a /etc/gconf directory. The following key improvements have also been made:

Daemon Mode - Gconf now supports a per-user daemon mode which allows the configuration information to be cached
Different settings types - Gconf now supports a cascading order for retrieving settings.
Mandatory Settings - There is an option for mandatory system-wide setting which is stored in /etc/gconf/gconf.xml.mandatory.
User Settings - If a mandatory setting does not exist, then the application specific setting can be read from $(HOME)/.gconf.
Default Settings - If the setting is not found in the user's home directory, then the default value for that setting can be read from /etc/gconf/gconf.xml.defaults file.

Change Notifiers and Listeners - Gconf includes support for notifying all running applications when a configuration setting they depend on is modified. I think this is a wonderful feature.
Network Management Support - Gconf does support the ability for clients to read the settings over the network using CORBA. I feel this could have been done better using a web services layer as it finds greater support these days.

Problems

1. I did not notice any support for network-wide settings. There is an ability to manage settings over a network, but if there was a way for storing the configuration setting itself across a network, it would have been even better.
2. This is related to point 1 - it may be good to include support for storing the configuration information in other data stores other than the file system. Perhaps support for storing the settings in a database or a LDAP repository could be included.
3. Gconf being a product with a "G" prefix (and therefore a flag-waving member of the gnome club) may find few takers in the KDE camp. This is unfortunate.
4. No support for configuration versions, rollbacks etc. (need to verify this)
5. A larger problem is that though Gconf has existed for such a long time, it still doesn't find wide acceptance. This is perhaps because Gconf introduces an unacceptable dependency on gnome libraries which perhaps many developers want to avoid.

Kconfig

URL- http://developer.kde.org/documentation/library/3.4-api/kdecore/html/classKConfig.html∞
I am still in the process of reading up on Kconfig. It seems pretty flexible. But I think it may be again file based requiring the application to specify the path to the configuration file. I did notice there is something called a global setting, so I am still not sure about this.

Problems

1. No noticeable support for network-wide configuration storage
2. No daemon mode. So network accessible configuration may not be possible. DCOP (used for inter-application communication) is available though.
3. Dependency on the KDE libraries and the fact that it starts with "K" will scare away gnome developers. By this time, I am guessing that you are also sick of the fact that developers can't even agree on the usage of a configuration management library.