Motivation
This library was written for Linux. Linux is, in my opinion, an
extraordinary operating system. It is robust, flexible, fast and free.
It is however not particularly easy to configure. It can be said that
that is a significant feature since it prevents large numbers
non-enthusiasts from using the operating system. This keeps the user
population to a relatively small, dedicated and knowledgeable elite.
While keeping Linux to an expert user group has many advantages, it
seems necessary to expand the user base in order for Linux to acquire
the large set of applications which it deserves. And that means that
Linux can benefit from becoming easier to set up and configure.
The Current State of Affairs
Currently most Linux applications and system utilities maintain their
separate configuration files. While these configuration files do provide
the information needed by the program, they do have the following
disadvantages:
- Configuration files are difficult to locate: While informal
standards have evolved which define the location and name of each
configuration file, there is no definitive location nor name for a
configuration file. The configuration file of foo could
exist as /etc/foo.conf, /etc/foo.cf,
/usr/share/foo/bar.config, /usr/local/etc/config.foo or
/usr/lib/foo/bar.cf depending on the type of configuration data,
local setup policies or author.
- The location of the configuration files is difficult to change:
Typically the location of the configuration file is fixed at compile time.
Some programs allow the user to specify the location of the configuration file
from the command line or via an environment variable, but this may make
usage more complex and may not be desirable for security reasons.
- The syntax between configuration files varies: Some configuration
files require tabs at special locations, others do not tolerate blank lines,
some use C style comments, others use shell style comments. This lack
of consistency seems pointless.
Please note that these disadvantages do not make a Linux system
difficult to use as such - it only makes it more difficult to
learn. That is not the same thing, but many novices seem unaware
of this fact and are discouraged by the steep learning curve. However, there are
numerous users who do posses sufficient experience to recall the location and
syntax of almost every configuration file on their system without the
slightest bit of hesitation or discomfort... and they will be able
to tell you about the often overlooked advantages of the current
state of affairs:
- The configuration files are ASCII text: This means that is
is possible to view or modify these files even under adverse circumstances, such
as from a rescue boot disk or a 300 baud dial-up line using an editor
like ex or even cat.
- There exists a reasonable degree of flexibility in allowing
access to a particular file: Each configuration file can
potentially have a different owner or access permissions, allowing
different groups of users to read or modify the configuration.
It seems important that any extensions to the configuration process retain
these existing strengths.
Other attempts at automating the setup
Several attempts have been made to automate the viewing and editing of
Linux configuration files. Typically these require the construction of
a separate parser for each configuration file - a task which requires
a constant effort to keep up with the configuration files of new programs.
This approach does not seem to be an elegant or economical solution, but
it does have the advantage that it works with existing programs.
A Different Approach
The approach used by the kunf library is somewhat different. It tries
to pre-empt the difficulties caused by heterogenous configuration files
(instead of building fixes on top of them).
The kunf library provides a set of functions to C programmers and a
utility for shell programmers to acquire configuration information. It is
thus conceptually similar to the PAM library (Pluggable Authentication
Module which hides the details of the authentication mechanism) or the
syslog facility (where logging information is written using a set of
library functions instead of directly to file), since it also imposes a
layer between the program and its support files.
A program requiring configuration information calls an initialization function,
then makes calls to a function to acquire the its entries and finally shuts
down the configuration library. As in the case of the syslog facility,
the client program does not need to know the location of the file containing
that information, since the information is accessed by name. This approach
should have the following advantages:
- It makes it easier for a programmer to use configuration files:
Where previously a programmer would have had to create a complete parser
for the configuration file, the programmer can, by using the kunf library,
access configuration information with only a few function calls.
- The location of the configuration files is known: The kunf
library keeps track of its configuration files, reducing the need to manually
search for configuration files.
- The location of the configuration files can be altered after
the program has been compiled: Very little information is fixed at
compile time allowing the system administrator to change the location of
various configuration entries without having to change the programs (if
more radical changes have to be made, only the library has to be altered).
- There exists a consistent configuration file syntax across
programs: The kunf library uses the same syntax for all its
entries. This makes it easier for novices to edit configuration files
by hand if the need arises.
- There exist support utilities: An editor and syntax checker
are provided as part of this package. It should be easy to add other
support tools to this library.
Using the kunf library should make life easier for programmers, system
administrators and end-users alike.
Next: Example Usage (Shell and C)