Re: Configuration management
On Tue, 18 Aug 1998, Ian Jackson wrote:
> I. How is amalgamation of data from various sources done ?
We can probably regulate this to a more implementation issue. So long as
when the package requests something it is retrieved from -someplace-
exactly how is quite flexable.
> II. Where are the questions `defined' ?
>
> Many of the proposals that I've seen so far have a fixed list of
> questions in a file. I don't think this is at all sufficient.
>
> For example, a sophisticated mail system configuration might have
> configs for different virtual domains. The configuration items for
> each virtual domain should have names which include the domain.
Hm, the simple solution is something more like a template, I've already
argued why script-only configuration is not so usefull ...
An example
Variable: mail/virtualdomains/*/domain
Description: The full domain name for the virtual host.
The * would be a match anything sort of arrangement, so that
mail/virtualdomains/debian.org/domain
mail/virtualdomains/bugs.debian.org/domain
Have the same meta-data. This allows the creation of 'arrays of
structures' inside the database.
> mail-transfer-agent.virtualdomain.aliasfile.%domain
This is also quite possible, in the notation we have been using,
Variable: mail/virtualdomains/domain/*
I think the other system is more usefull to the user beacuse a subtree
query command will show the entire configuration
ie:
$ config-query show mail/virtualdomains/debian.org
Domain debian.org
AliasFile /etc/aliases
Foo Bar
...
Similary for a browsing GUI the experience to the user is much more
sensible.
> In any case, in order to get backward compatibility with old versions
> of dpkg, the postinst script will have to be able to invoke the config
> manager programs to do actual queries in case dpkg didn't know how to
> set up the data wherever it is.
Personally I don't see any need to modify dpkg. We need to have a script
that can generate the default configuration file. It is amazingly similar
to our current postinst's except instead of using a shell construct to
query the user it uses a shell construct to invoke the query program.
How would you propose that dpkg get involved?
> III. What form does the specification of which questions to ask take ?
> It is my belief that at least _which_ questions are asked can only be
> determined programatically, even if there is in some sense a set of
> possible questions which could be listed.
Yes of course, but you have to envision what sort of GUI's we wish to
present. I outlined my ideas for a dual mode gui that is capable of both
directly editing the database and running 'wizard-like' scripts to
guide the novice.
The original ideas were basically a series of 'wizard-like' scripts strung
together. I've said before that I don't think this solution gives the
appropriate fineness or sufficient user-friendlyness.
For simple packages I (the user) probably do NOT CARE what they configure
themselves to be. I have no interest in mime-type configuration, no desire
to do things with my mailer or apache. I just want them to work and I
don't want to be bothered because I have nothing to tell them.
99% of all packages should require very, VERY minimal configuration but
on the flip side packages should be highly configurable and have lots of
questions! The goals conflict :>
> IV. What `types' of the configuration data are there ? Is its type
> stored in the database of answers ?
>
> It's entirely unclear to me that anything except the user prompting
> part of the configuration management system (which has to be invoked
> with the names of the data entries et al available) needs to know the
> types of these entries.
My view is that the type is used by the GUI to guide the user and
optionally [depending on the script] by the query program to protect the
script from invalid input. The database is, like you say, not type
enforced.
> Instead, I think that data should be transported as opaque strings and
> validated at the point of use. The facility that retrieves a data
> item should be told the expected `type' and check that the string
> matches it (by regexp, or whatever).
It would make sense to retrive this from the variables definition so we
don't duplicate information.
> Current suggestions seem to be to put the information in additional
> members of the enclosing ar archive. I disagree with this; I think we
> should put it in the control.tar.gz subarchive. Unpacking this part
> is necessary even to find out the name of the package, for crying out
> loud. There's no harm in requiring its unpacking for
> pre-configuration.
Agreed. I'd like to see some of the information avilable sperate on the
FTP howerver.
Jason
Reply to: