PROPOSAL: Lire Configuration Framework based on XML

[Wessel Dankers]

On 2002-04-30 13:24:51-0400, Francis J. Lacoste wrote:
[snip configuration proposal]

> Requirements
> ------------
> 
> A. Must be "easily" accessible from several languages (perl, php, shell).
> B. Metadata for automatic documentation and for use by configuration
>     tools.
>     - Documentation
>     - Type
>     - Defaults
>     - Complexity (Advanced, Normal, Novice)
>     - Grouping of related configuration data together.
>     - Dependencies? (So that some variables can affect others)
>     - Levels (Global,Superservice,Service)
> 
> C. Multiple configuration frontends (Web, GUI, Console, vi).
> D. Levels of configurability
>     - System : defaults settings for all users/jobs.
>     - Group/Client : settings for a group of users. This is
>       interesting for ASP setup.
>     - User : user may want to override some settings.
> 
>     - At each of these levels. There may be sublevels of
>       configuration:
>       1. Global		-> default settings
>       2. Superservice	-> Settings overriden based on the superservice
>       3. Service.	-> Settings overriden based on the service.
>       4. Job.		-> Settings overriden based on the job
> 		           identifier.
> 
> E. Security
>     - Some settings may be locked at a higher level. Settings locked
>       at the system level may not be overidden at the group or client.
>     - Group may lock settings for users.
> F. Portability
>     - Should be installable on all Lire's supported platform.
> G. Additional requirements
>     - Should require minimum additional libraries/tools.

[snip]

> I propose that we implement the configuration metadata using a XML DTD
> we would define and that would resemble the param-spec element in our
> report and filter specifications. We would need some others elements
> for grouping, user level, security, sections, etc. With the XML
> configuration metadata, we can than write data driven configuration
> frontends.

I propose another solution, which (if done right) would satisfy all seven
requirements: a small number of XML files which contain _all_ information,
and is private to the Lire system.

There would be a "defaults" file, a "site" file, a "group" file and a
"user" file. Command line options would form the last layer. It would not
be hard to add a command line option to specify additional configuration
files. Command line options are added as the last layer to the
configuration information.

Each file would have a structure like this:

<config>
  <global>
    <prefix locked="error">/usr</prefix>
    <exec_prefix lock="error"><reference name="prefix"/></exec_prefix>
  </global>
  <defaults>
    <tmpdir>~/tmp</tmpdir>
    <keep locked="yes">no</keep>
    <week_starts_on>monday</week_starts_on>
    <jade_path locked="warn">/usr/bin/jade</jade_path>
    <!-- many more -->
  </defaults>
  <superservice name="proxy">
    <defaults>
      <targetuser>sysadmin</targetuser>
      <output_format>txt</output_format>
    </defaults>
    <service name="squid">
      <log_file>/var/log/squid/access.log</log_file>
      <output_format>pdf</output_format>
      <image_format>pdf</image_format>
    </service>
    <service name="welf">
      <!-- ... -->
    </service>
  </superservice>
  <superservice name="www">
    <!-- common, mod_gzip, combined, ... -->
  </superservice>
  <!-- email, firewall, ... -->
</config>

(Since we're moving away from the superservices concept, a different
approach might be to move the <service> tags to the top, rename the
<superservice> elements to <template> and allow the <service> tags to
reference one or more templates.)

A. Perl and PHP can parse XML themselves. For shell scripts, a solution
   like
      eval `lr_shellconfig "$@"`
   would be reasonable. As an additional bonus, this would make parsing
   command line arguments of shell scripts easy and reliable.

B. Metadata is easy to add once you use the XML format. In fact, item E
   can be implemented using metadata.
    - Documentation can be added using DocBook elements
    - Types can be checked using an XML Schema
    - Defaults are explicitly present in the scheme
    - Complexity can be regulated by hiding configuration elements with
      a "level" attribute that is too high.
    - Information is inherently grouped.
    - Variables can depend on eachother through defaults and through
      substitution (like <exec_prefix>)
    - The different levels are overtly present.

C. Multiple configuration frontends can be implemented. I would imagine
   that the "vi" configuration method prepares a temp file and reads it
   back when the user is finished. Sort of like vipw and crontab -e.
   The tempfile would contain (for instance) .ini style syntax.

   Any language that can handle XML can be used to write frontends.

D. Multiple levels of configurability are possible by having some
   configuration files override previous ones.
    - Defaults: Lire-supplied settings so that at least everything
      has _some_ value. Contains "sensible" defaults.
    - System: default settings for all users/jobs.
    - Group/Client: settings for a group of users.
    - User: user may want to override some settings.
    - Command line specified file may override settings for a session;
    - Command line options may override settings for a session;

    - At each of these levels. There may be sublevels of
      configuration:
      1. Global		-> Settings relevant for Lire's functioning
      2. Superservice	-> Settings overriden based on the superservice
      3. Service.	-> Settings overriden based on the service
      4. Job.		(this is handled by command line options)

E. Security
    - Some settings may be locked at a higher level. Settings locked
      at the system level may not be overidden at the group or client.
    - Group may lock settings for users.
    - Generally speaking, each layer may lock items for subsequent
      sessions. Items may be locked as "error", "warn" and "silent",
      to improve resiliency to configuration changes (one doesn't want
      all cron jobs to fail because a new variable has been locked).

F. Portability
    - Since all Lire platforms must already support perl and XML, this
      scheme can be directly implemented on all supported platforms.

G. Additional requirements
    - Does not require software components that aren't already required.

RFC!

--
Wessel Dankers <wsl at logreport.org>

Dew on the telephone lines.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20020915/d6185a87/attachment.bin