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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
