[rfc] New package idea with policy problems
Hi
I'm trying to write for myself a bew configuration management system,
and since I'm a debian user, I thought once it was finished
I'd pack it up (under the GPL) and make it available to Debian
if anyones interested.
But before I got round to asking if anyone is interested I
noticed it got a _few_ problems with policy, like it
modifies other packages config files, - after all it is trying
to manage those packages.
Someone [Oliver Elphick, IIRC] suggested I should post a formal
proposal here for you guy's to rip apart ;-).
Seriously though, say what you think can be done to the Mechanim to
make it more policy compliant. The `Aim' of the package is rather
fixed though - I have an actual problem to solve.
Proposal for Configuration Scheme Management System/Package
==========================================================
This a proposal for a package called `sites', although schemes might
be a better name this is avoided due to limit confusion with a certain
programming language.
Aim & Rationale
---------------
The aim of this package is to allow a more dynamic configuration
of a machine , one use (and the one I'm primarily coding
it for as this is why I need it myself ;-) is for notebooks which
are regularly used if different capacities on different networks.
Although package called `divine' already exists this is quite
limited it in use if you want to take the differences in configuration
beyond changes to interfaces configuration and DNS setup.
The aim of site will be to build a system where by a administrator or
other authorised user (ie. with sudo) can issue a command to switch
between pre-defined configurations.
Mechanism
---------
The definitions of these configurations will consist of a directory
of alternate config files for various packages in the system.
An interesting package is defined one whose configuration we may changed
in the course of a scheme change and may have zero or more configuration
files associated with it to be `swapped' at re-config time.
These configuration files are known as the packages list files, a conffile
for `sites' is maintained which contains this information.
All schemes must contain all the listed configuration files for all the
interesting packages, although this does not preclude such files being
symlinks to the another configuration schemes equivalent.[1]
At switch time the following occurs,[2]
For each interesting package. (Order as listed in /etc/sites/sites.conf)
It is shut down by running "/etc/init.d/<packagename> stop"
It's listed configuration files are checked to be symlinks,
if there are not a warning is issued, and the
we continue on directly to the next package. This package
is _not_ restarted.
Each listed configuration file is replaced with a symlink to
the pre-defined config file for that package in that scheme.
The package is restarted by running "/etc/init.d/<packagename> start"
Additionally each scheme may provide a arrive, and/or depart script to be run.
Finally this mechanism may be replaced by a sites aware package, by
provided a perl subroutine to handle it's own reconfiguration (only)
this routine is passed the name of the new scheme and a list of key-value
pairs in the form of a hash read form the package specific portion of
/etc/sites/sites.conf, to define the administrators choices of
re-configuration of that package.
File System Layout
------------------
/usr/sbin/sites <-- Program which actually does the above
evil
/usr/man/man8/sites <-- Man page for above.
/usr/man/man5/sites.conf<-- sites.conf file format (prolly .ini
section per interesting package).
/etc/sites/ <--- Directory for global configuration
which applies to all schemes.
/etc/sites/sites.conf <--- Our basic configuration file,
/etc/sites/<packagename><--- Custom config routine for <packagename>
/etc/sites/<schemename> <--- Directory contain the config files
required for scheme name.
Installation
------------
This is tricky I can't see what it can do safely, sensibly and within
policy. If the rest of it hasn't blown policy right out of the water.
Removal
-------
Umm The same applies here really. Purging the package could be
messy, unless it resets it cofniguration on removal. If so
how should it determine which scheme to use.
Aware Packages
--------------
Ok so currently there obviously aren't any, and I don't plan
on writing any other package which woud be specicallty `sites-aware'
myself atm, but the mechanism in dpkg etc, are not really set
up for this sort of `dependency'.
[1] I envisage a scheme called default which many scheme may link to,
although this is really site policy as far as my package is concerned.
[2] With the exception of the special case scenario list at the end.
-->
So what do you think?
TTFN
--
Roger
Fear is finding cthulhu.tiff in your home directory.
Reply to: