Re: Configuration management, revision 3
Isn't the obvious generalization to divide configuration questions
into blocks, then specify a state machine to navigate between blocks ?
Within a block a series of questions are specified which are passed to
some front end which interogates the user. Within block questions
aren't ordered; I imagine each block as a series of fields on a web
form, or a series of serially asked questions on a tty.
Once these have been answered, some kind of verification is performed
and a status produced; this status then drives the state machine which
wanders off and handles the next block. I think it would be good to
have a very general verification mechanism: were we to implement this
in perl, then we could just provide a chunk of code and eval() it. I
assume similar features exist in all the other sensible scripting
languages.
If somebody is installing many machines and wants to answer all the
questions (though I'm not sure this ever makes sense), then they can
go through all the blocks and answer all the questions. Otherwise they
just navigate the configuration system under the state machine's
control.
This means that every package would have to contain a file describing
its config data. This file would be divided into blocks, each block
would contain a list of questions and so forth, and also a scriptlet
which can verify that the answers to the questions are valid. The
scriplet returns an status. The file also defines a state machine
which maps from block return code to new block. A special status code
indicates that config is over.
The system provides tools which take such files, query the user and
spit out a list of config data. I see no reason to make this anything
beyond a list of name:value text pairs which can, in extremis, be
edited directly. There's probably scope for a package to manage many
sets of this information locally.
There also needs to be some means to tag the information gleaned from
the inquisition, and store it somewhere permanent. Then one could say
`Configure this system just like that one', or `Configure this system,
taking all the defaults from that one', or `...taking the defaults
from option 4 in this list', &c.
When each package is install dpkg needs to fetch pertinent config data
(from wherever the local admin has deemed suitable), then run a script
in the package which should configure itself based on the name:value
pairs provided by dpkg. This script should return different codes
on invalid and missing data, and dpkg's behaviour in these cases
should be configurable. In the case of a single machine, it should
probably just invoke the default config manager, then call the package
config script again when things are done; in the case of the a network
of machines it should probably halt the installation and mail someone.
Two outstanding issues are:
1. How do you encode per machine data e.g. IP address (presumably you
let the knowledge store refer to data stored in files, or have a
set of per machine variables in which the machine specific things
are encoded).
2. Particularly if you have a large network of machines, it would be
nice to be able to trigger a re-read of the central repository at
any stage. If sysadmins want to, they could run this regularly
so that large compute farms can be reconfigured quite easily.
Cheers,
--
Martin Oldfield.
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: