Hi all,
Thanks to Joel and Chris for your feedback and ideas. I have yet to
study all available solutions mentioned, but I would like to make
further comments.
Instead of the superficial middle layer interfaces, I'm more focused on
the core system facilitating the systematic storage and access of
configuration parameters. I believe that such a centralized system is
not so well received right now due to several factors, namely inertia
(towards the old system), uncertainty towards a new, undefined system,
and also the bad example of the Windows registry.
First, I speak not of user interfaces to generate configurations, i.e.
Webmin, linuxconf, etc. These generate old style configuration files in
the end. I am talking about implementing this at the operating system
level, yes, just like Windows - having a central registry where all
applications store and access their configuration. Applications till
Win3.11 still used INI files, very much like conf files. But nowadays,
pretty much every Windows application is using the registry. I believe
this can be done for Linux applications too, provided the interface to
the configuration system is clearly defined.
The registry is a beast, yes, but I think it is the particular
implementation and the organization of the Windows registry that puts
most people off; of course regedt32 is horrible too. But apart from
that, I think they have pretty much figured out what a registry needs to
be. I don't think the /etc is very friendly either. Well, at least
/proc/sys is well organized; in fact it is exactly how we should be
modeling the management of userspace application configurations!
The config manager will be backed by a structured data-store. Most
systems I've seen use either the .reg format or XML format. I personally
feel that it should be backed by a REAL database, e.g. SQLite instead of
being an XML file.
This system need not restrict what and how applications can store their
configurations. It only provides the facilities for easy access. Such a
system allows for a convenient, standardized way to count, list, query,
add, and delete configuration entries. Both command line and
programmatic interfaces can be provided for accessing the configuration
store. The command line tool is a generic application that does not know
about ANY specific application or system module - its job is just to
help the user discover/read/change the configuration store.
Each application will have it's own branch in the config 'tree' for
example, and it can organize it's parameters as the designer sees fit.
This does not take away flexibility of the software author to change
configuration structures. Individual application configurations can also
be exported/imported easily since each module/application is stored
independently from one another. In fact, this makes a sysadmin's life
much easier especially if he/she has to manage several similarly
configured machines and make regular backups of the system configurations.
For example, a /etc/resolv.conf can be organized like so:
system/dns:
nameserver
165.21.83.88
165.21.100.88
search
com
org
sortlist
...
The convenience afforded by being able to generate configurations with
shell scripts/sed/awk/grep can be more easily provided by specific
tools/library functions to access the database.
Now say for example, if I want to get a list of the currently configured
DNS servers on the system. Traditionally, I would have to do
grep nameserver /etc/resolv.conf | awk '{print $2}'
Similarly, I can use my command line tool, let's call it 'cfg':
cfg list system/dns:nameserver
to achieve the same result => a shorter, more logical command.
Applications such as dhclient/pppd, upon getting new DNS entries, can do:
cfg add system/dns:nameserver x.x.x.x
cfg add system/dns:nameserver y.y.y.y
without needing to insert special comment markers into configuration
files, and needing much less to parse any file at all. => More
straightforward.
Alright, I think I have said enough for one day. More comments and
discussions are welcome.
Regards,
Kokhong
_______________________________________________
Slugnet mailing list
[email protected]
http://www.lugs.org.sg/mailman/listinfo/slugnet
