Configuration
Sorry for the bogus return address, but I noticed some spam posted to
the mailing list, and I prefer not to be spammed myself. If you need to
send me personal email, follow the directions at the bottom.
Anyways, I am a veteran linux user and have used it since the 1.0.x
days. I originally started by using slackware, then moved on to
RedHat. I also have used some unixes, most prominently Solaris and
IRIX. However, out of all these systems, I absolutely hate the way you
must configure each piece of software differently. Before you delete
this email hear me out. The one configuration system that has the right
idea is Microsoft's registry. Now, I used to HATE the registry, it has
all kinds of cryptic info, no editable text files, and no comments as to
how the entries affect the program. However, as I began to learn how
the registry was laid out, more and more, I found myself browsing to the
correct location in the registry to configure something in a program
that I knew nothing about. Then it hit me -- Window's layout of the
registry is a defacto standard as far as windows applications are
concerned, and that is why using the registry became so easy. Most
global program info goes under
HKEY_LOCAL_MACHINE\Software\<VENDOR>\<PROGRAM> and most user specific
info goes under HKEY_LOCAL_MACHINE\Software\<VENDOR>\<PROGRAM>.
I also used a tool on RedHat called linuxconf. Using linuxconf got me
thinking too. It is a great tool, but it no doubt is unnecessarily
bloated because it needs to know how to parse and edit multiple types of
configuration files. Not only that, but it is DOG SLOW. When you think
about how every program's configuration file is put in a different place
with a different format, you can begin to understand why linuxconf is
such a slug.
My idea is simple. Take the organization and simplicity of the windows
registry, and linuxize it. Use a file format that is human-readable and
editable, use the linux filesystem to organize the "Keys" and the file
permissions to implement security. Then, make the internal file format
easily parsible by a program. Here are the advantages that I see we can
have:
1. Organization -- it is easy to find the configuration for a program,
you just look under /etc/config/<Category>/<Program> (for example). No
more do you have to search on the internet to find out how to configure
each individual program, you need only figure out how the configuration
is laid out, then proceed to the correct file.
2. Elimination of redundancy -- if you have multiple types of config
files, you have more than one instance of file-parsing code. There
could be one shared library that exposes the correct methods to
programmers to easily parse the files.
3. Streamlined and Global linuxconf -- the tool that edits/reads the
current configuration does not have to contain all the redundant code
from part 2. This allows a newbie user or normal everyday user to
configure the system without having to edit configuration files. Since
the directory structure is similar in all cases, the configuration
program doesn't need to have special knowledge about which programs are
on the system, it can just say "Hey, here's a directory inside the
/etc/config, I will present the interface to configure it to the user".
This allows the functionality of the tool to be worked on instead of
having to add new parts to the tool when some new essential program
comes out that the tool needs to configure for a newbie.
4. Improved security -- if most programs use this configuration system,
security problems are contained within one library. Fixing security
bugs in that library fixes the security problems for all programs.
Right now, if some developer decides to introduce his tool with HIS
implementation of a config file format, it is more prone to security
problems, and every program must be tested instead of the global
library.
Here is one disadvantage to this system:
1. Time & Effort -- it will take time and effort to not only develop
this system, but to migrate targeted programs to this system (something
that I am more than happy to donate my time to). However, this does not
prevent newer programs from being developed that use the system.
I am not an expert on file parsing and security, so which file format is
used is something I will leave up to whoever is the expert. However,
from what I've been hearing about XML, it sounds like something in that
direction would be good. It needs to be extendable, and very parsible
by software, yet editable by a human. Something that a perl or shell
script can manipulate will also be preferable for automation and
installation. It might also be good to put a similar directory
structure in the user's home directory for settings that are
user-specific.
OK, so there's my idea, I have typed all I can think of, I would
appreciate some feedback, good or bad. Thanks for your time.
-Steve
--
To send email to me, send it to:
nihil aht gis dot net.
Reply to: