Ideas about metaconfiguration tool (prozą)

[Michal Moskal]

Hello,

Background.

About a month ago there was an discussion about metaconfiguaration
tool on pld-installer@ list. As this problem is only paritally
connected to installer, I think this list is better place to
discuss it.

What is it?

The idea is, to some extent, generalization of rc-inted and
rc-root projects. The goal is to provide unified way of system
configuaration. I.e. it doesn't matter what inetd, finger or
bootloader program you use, you configure them all the same way.
Rc-{boot,inetd} was designed for this purpouse too, but I guess
the main reason was to provide way of spliting configuration into
several files, so they can be easly updated using rpm packages. Of
course metaconfigurator will support all this, but eventaully also
much more.

A quick look into /etc can reveal two facts. 1) each program
uses it's own config file syntax.2) config files are in 95+%
made from default values.  The second fact is in general true for
all systems. However, when you're running mail system for 10000+
users, your configs for [insert-your-favorite-MTA-here] will be,
let's say, in 50% default.  However, you'll still use 99% defaults
in your sshd or fingerd configuration.

Whay several configuation formats are evil? 1) becouse it takes
time to learn the particular syntax. 2) becouse one config files
cannot use values from the other -- it's really a pitty. 3) it's
a bit hard to validate it, before actuall program that use it is run.

Unify config files into [something]? Why [something] is XML? 

Using XML has several advantages, and also disadvatanges. As
everybody knows and loves shell :), scripts for translating
metaconfigs will be possibly written in sh. So why not use format
similar to rc-{boot,inetd} uses?

1) it's kinds incompatybile with languages other then sh. You maight
say it's easy to parse NAME="value" pairs in any languge, but one may
want to use . for includes, variables expansion and so on in config
file. While this ain't a problem in sh, it will be hard to interpret
it in C or perl. 

2) more important: it doesn't allow easy section nesting, and
keeping namespace clean. 

3) it's hard to validate.

Of course, XML is a bit harder to use from inside shell then using
shell from shell :^) However it's not all that bad. The idea is to
provide command, that can be used from shell, to interpret XML. It
would be something about:

xml-parse /etc/rc-inetd.xml/rc-inetd/defaults

for /etc/rc-inetd.xml file containing:

<rc-inetd>
 <defaults>
  <max-connections>10</max-connections>
  <timeout>10s</timeout>
  <foo></foo>
  <date>
   <day>10</day>
   <month>jan</month>
  </date>
 </defaults>
 <services>
  <!-- ... -->
 </services>
</rc-inetd>

would output:

max_connections="10"
timeout="10s"
foo=""
date="<day>10</day>
   <month>jan</month>"
date_day="10"
date_month="jan"

Now you do 

eval `xml-parse /etc/rc-inetd.xml/rc-inetd/defaults`

and have shell variables set. Of course xml-parse utility needs to be
written, but it's not hard.

For easy spliting of config files we can intermix pathes in filesystem
with pathes in XML. However this needs rethink.

Using XML has several advantages:

1) we can write DTD or XML-Schema (maybe better XML-Schema) for /etc,
   and validate it.
2) there are several tools available for validating/editing XML
   (including the most powerful: vi :^)
3) writing frontend will be rather simple.
4) middle-advanced user can think out values for most variables, just
   by reading empty XML file (names are very descriptive), or in case
   of failure, by reading XML-Schema.
5) it seems to be quite modern solution


Wow, great, but what's the cost?

1) it's not all that simple. XML provides several complications
   on its own. I.e. special tool is needed for parsing from shell,
   libraries from C and so on. OTOH simple configuration file parser
   can be written ad hoc in half an hour -- that's why programs doesn't
   like XML for configuration much.
2) it will take a lot of time to create config translation scripts.
3) some ppl doesn't like XML, but like da'old good config files...


Finally end:

Few notes: while it's easy provable, that any config file can be
expressed in XML, but it could be somewhat hard, especially in the
beggining, to transfer entire sendmail config file, and to make xml
layout compatibile with e.g. postfix. So, first we should concentrate
our efforts in providing basic config files functionality (e.g. to set
the hostname, aliases, rely), leaving special and/or rarly used features 
of particular program for later. Note that one can make <mta><postfix>
section for features, which cannot be found in any other MTA, xml
guratnees that there will be no namespace clash. When one is running
mail system for 10k+ users, he will write config files for MTA
himself anyway, but he can still use xml configs for fingerd. 

In the begging there could be need to do some reverse engeenering, to
generate xml configs from /etc/sysconfig (e.g. for conversion, and
until programs using it are changed).

There was an idea to use some templates (from Pawelk) or simple
macro processing (from Klakier) to generate config files. While I agree
this can be part of system, it's not enough. Some programs are configured
by running shell commands, other have they configuration files split
across several files, up to qmail's one-variable <-> one-file approach.
It would be hard to use simple templates here.

Ok, waiting for flames :)


-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:                                  |                : {b,e>+}++ !tv h
: Current project:  http://aleph-0.dhs.org/ywindow/ : PLD Team member