Re: Configuration management, revision 3
>>>>> "Raul" == Raul Miller <rdm@test.legislate.com> writes:
--> Joey's comments snipped <--
Raul> Note that most packages do not require such a state machine.
True, although I note the obvious fact that this is a special case of
a state machine with a simple transition matrix: if the verification
script returns 0 on OK, and -1 on error:
0 => end,
-1 => redo
Raul> I'm not convinced that installation scripts are the right
Raul> place for packages which do require such complicated
Please do you have an example of where this breaks ? It would be nice
to know if it's just difficult, or there's a major conceptual cock-up.
Raul> configuration. As a general rule, when configuration gets
Raul> that complex you're going to want to use the same tool for
Raul> reconfiguration.
Yes indeed. However splitting the task of configuration into two makes
this feasible.
1. Query user, verify results, then and write the results as
name:value pairs. This can be done at any stage, and doesn't need
anything from the package to be installed.
2. Take the name:value pairs and write the usual config files.
There is scope for some discussion about when (2) happens; in
principle it provides a means to automatically propagate changes to
lots of machines: simply edit the central name:value database, then
tell all the relevant packages to configure themselves.
An aside: it seems pretty clear that the installer should store a
checksum of the machine generated file, and not blindly overwrite it
if it's been changed directly. It seems very clear to me that it's
hopeless to expect the package writers to provide configuration
scripts for every nuance of the package's behaviour: if people want to
hack /etc/exim.conf we mustn't make it hard for them to do so.
Raul> For the case of bulk installation (many machines being
Raul> configured) you only need to provide for the simple case.
Raul> It's probably sufficient to provide for one or two simple
Raul> cases, then also give the *option* of running some smarter
Raul> program at postinstallation time.
Isn't it better to have a single tool which scales well ? I appreciate
that this is much more difficult, but I don't see that it's
impossible.
Raul> Then again, for networked installs of these cases you
Raul> probably want to be able to use some pre-built configuration
Raul> file as the surrogate for actually running the program
Raul> interactively.
Yes I agree. Some of the earlier discussions talked about having
several sources of information which you can point the installer
at. The might include a default list in the package; a system wide
list on a server, e.g. the organization; a machine wide list e.g. the
hostname; and an option to `invoke the user querying program'. The
last-named option means that in simple installations the two processes
merge seamlessly. If all the information sources have been tried and
config data are still not forthcoming, then the installer has to throw
a fatal error for that package.
Somebody before talked about this, and I agree that it's good to have
two, orthogonal, components to the config space.
1. A bit specified by the package, describing the `kind' of
information. If I'm exim then I want a private configuration space,
but also to know about general mail things e.g. rewriting rules,
and also general machine things e.g. hostname. It's not clear to me
how feasible it is to have these inter-package bits of config
space; perhaps it would be better to restrict the tags to packages,
but allow a package to look at another package's config space. If
we subsequently abstract some of the config data into config data
only packages, so much the better.
2. A bit specified by the system, describing the repositories of
config data available locally.
--> Raul's comments snipped <--
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: