RFC: Debian Package Configuration Proposal
On Jan 22, in a thread far away from this one, bruce@pixar.com (Bruce
Perens) wrote:
> I would suggest an arbitrary shell script which would be extracted
> from the package at selection time and run. It could query the user
> and store the data any way it liked rather than requiring a fixed
> interface.
(Actually, that title is probably a more formal than this note. Oh well.)
The problem I have with this is that many packages that need some soft
of configuration really only need to set the values of one or more
variables. Requiring the each maintainer to write an interactive script
for each of these seems kind of wasteful. On the other hand, some
packages need to be able to have fairly complex configuration dialogs,
and the freedom of a script is great.
(In the following, names of files, fields, tools, etc. are just for
example; I care about the concepts at this point, not about whether
the file extension is spelled with three q's or four. 'pkg' represents
an arbitrary package name, while a 'package' is the Debian software
delivery entity. I'm assuming cfgtool as the tool to manage the
configuration database (CDB). For the politically correct, please assume
that all gender specific pronouns may be arbitrarily replaced with he,
she, and/or it.)
=================================================
I. The Goals
These are the goals I would like to accomplish, and which I
believe implementation of this proposal would accomplish.
1. A Debian standard tool for package/system configuration. Any
package can be (re-)configured via 'dconfig pkg'.
2. Packages with simple configuration needs (set a few variables)
don't have to spend a lot of effort.
3. Packages with complex configuration needs are accommodated.
4. Pre-install configuration can be done without the package files.
5. Configurations may be moved from machine to machine.
6. Users don't have to use the tool -- editing the "normal" config
file should have priority.
II. The Files
Each package may supply up to three separate configuration files:
1. pkg.dbcfg -- A data file, not a script. An overall description
of what is being configured, followed by a list of variables that
the package needs to have stored in the CDB. Each member of the list
consists of the variable name, datatype (bool, real, int, string,
etc.), brief description, default value, optional long description (aka
item help), optional range of values (1-5, <10, [red, blue, green],
etc.). The new dconfig program would present this to the user in a
standard manner. Dconfig is described in section III below. This file is
read-only, BTW, changes go into the CDB, not pkg.dbcfg.
2. pkg.cfg -- An interactive script. This script would be run
after after pkg.dbcfg, if pkg.dbcfg exists. Pkg.cfg may use any tools on
the base system -- {ba}sh scripts, grep, awk, sed, and perl-base, etc.
-- basically, whatever a preinst or postrm script might use. It may not
assume that any part of pkg is available. However, the only thing
that this script may change is the CDB; no file editing/generation,
etc.
3. pkg.postcfg -- A preferably non-interactive script, run after package
installation completes, but before the postinst.
Why three files? I want the pkg.dbcfg file to deal with the most common
case: the user sets the values of a bunch of variables that are later
accessed from a shell script. I want pkg.cfg to deal with the more
complicated case -- the values interrelate, or you must be able to check
other packages values to be able to figure out what is needed for this
one. The pkg.postcfg is for configuration that requires generation of
a new file, either from scratch or based on a template file included
in the package, or if it requires an tool from the package itself,
or a template file, or some such. Pkg.postcfg should also restart
or otherwise force the associated daemons (if any) to re-read the
configuration file(s).
If they are separated this way, then the first two (.dbdfg and .cfg)
could be kept separate from the package itself. Instead they would
be kept in a file on the server, just as the control information is
kept in the Packages file (let's call it the Configs file for the sake
of argument). When you run the Update step in dselect, it grabs the
Configs file, runs 'dconfig --update-available' to extract them all into
/var/lib/dconfig/available for future use. This avoids multiple passes
through the package files, and makes the configuration step independent
of the Access method (i.e. cdrom, ftp, floppy, tape).
The third (pkg.postcfg) is run before the postinst during a package
installation (or dpkg --configure). It needs to be separate from the
postinst because it will be called every time 'dconfig pkg' is run
(again, section III will explain further). The pkg.postcfg file is part
of the package, just like {pre,post}{inst,rm}.
If this is done correctly, moving the CDB to a new system, and running
all the .postcfg should result in an identical configuration.
Each package would be free to supply any or all of these, as determined
by the maintainer. Note that most existing packages with configuration
scripts run in the postinstall could be updated to this technique simply
by moving the configuration part to pkg.postcfg (although this violates
the "preferably non-interactive" clause, it does get the packages configuration
under the dconfig).
Also, any package whose configuration mainly consists of setting shell
variables need only do two things: modify the script(s) that use those
variables to initialize those variables from the CDB, and create
pkg.dbcfg.
I think the easiest way to deal with variables that are shared between
multiple packages (i.e. some of the MTA information) would probably
be to create a 'configuration-only' upon which the other packages
would depend. Most of the truly core values (hostname and domainname,
timezone, etc) would be part of a base config.
III. The dconfig program.
This would become the standard Debian interface to package/system
configuration. Some basic functions are:
'dconfig pkg' - perform the following steps, in order:
1. If the pkg.dbcfg exists, read it, and present the values to the user
to be examined/changed. If the variables are already in the CDB, use
the CDB value for the default, otherwise, use the defaults in pkg.cfgdb
(which is never changed, except by a new release of pkg). This tool
would enforce the ranges (optionally) specified in pkg.dbcfg. In
addition to changing the value, the user should be able to get specific
help on the variable (it supplied in pkg.dbcfg), reset it to the
maintainer default (from pkg.dbcfg). When finished, the user may choose
to exit (save values to CDB and proceed to next step) or cancel (don't
change CDB, and quit to parent).
2. If the pkg.cfg exists, execute it. If it returns success, move on to
next step, otherwise quit to parent.
3. If the package is already installed (unpacked?), look for the
pkg.postcfg, and run it. If the package is not installed, assume that
dpkg will call us with 'dconfig --postconfig pkg' later (or that dpkg
will call pkg.postcfg directly, or that the postinst is will call to
dconfig req--postconfig pkg, or something--whatever we decide the
standard is).
dconfig --no-ask pkg
Like 'dconfig pkg', except that if *all* the values mentioned in
pkg.dbcfg are in the CDB, don't ask about them.
dconfig --update-available Configure.gz
Extract all the .dbcfg and .cfg files from the download Configures.gz
and put them in the right place.
dconfig --register pkg <file>
Register <file> as a dconfig configuration file, and generate and
store and md5sum for the file. This is for the case where pkg.postcfg
generates/edits a file based on data in the CDB. If the user then
modifies that file, you want to protect against a later dconfig run
inadvertently overwriting those changes. It would be the responsibility
of the postcfg to register any generated files. This is in *parallel* to
dpkg's conffiles, and may or may not eventually replace it.
dconfig --build-transfer file <transfer-file-name>
Gather up the (some of) the CDB and all registered dconfig
configuration file, and put them in one file that can be transferred
to another machine.
dconfig --install-transfer-file <tranferfilename>
Unpack the transfer file onto the new machine, and run all the
postcfgs.
Obviously, the last two are aimed at facility duplicate configurations
and batch installs. However, there are issues, such as some variables
should *not* be transferred (hostname leaps to mind :-)), and this
is one area that definitely needs more thought. It's also not
required in the initial implementation.
One can certainly imagine other functions, refinements and options --
this is just a starting point. Reporting and backups come to mind.
Important note: dconfig is *text* tool. If someone wants to write
xdconfig or tkconfig or svgaconfig, more power to you, but you *have* be
able to run the standard configuration tool on a text console.
IV. Justifications, Thoughts, and Other Stuff.
Many (most?) packages need only provide a list of variables to be
configured, and straight forward modifications to the script (i.e. where
it now says "HOSTNAME=myhost", it would say "HOSTNAME=`cfgtool -get
basecfg_HOSTNAME"). Also, we only need to the write the interactive
script once.
Packages with complex configuration needs are accommodated -- an
arbitrary shell script can be run.
Pre-install configuration can be done without the package files.
Configurations may be moved from machine to machine; or at least
this gets us headed that direction.
User's may opt out of dconfig by editing the actual configuration
file by hand, so long as it is registered with dconfig. There should
also be a dconfig option to get it back under dconfig.
If it seems overly complex, think about what happens during smail
configuration, or (probably any) httpd configuration.
This is NOT the general Debian Sysadmin tool. It is a piece of it, aimed
at package/base system configuration. It doesn't deal with users, or
init.d links, or inetd.conf. (Even though it would be straight forward to
make it deal with the last two, the interface would suck.) Go back
and read Section I again.
=================================================
Ok, that's all I can stand right now. I'm going to try to get enough
of this put together to configure cern-httpd, but it will probably
be at least next week before anything issues.
Steve Greenland
(If I write this much, I get to have two quotes:)
--
The Mole - I think, therefore I scream
"Well, if you can't believe what you read in a comic book,
what *can* you believe?!"
-Bullwinkle J. Moose
--
"I want to buy a husband who, every week when I sit down to watch "St.
Elsewhere", won't scream, "FORGET IT, BLANCHE... IT'S TIME FOR 'HEE
HAW'!!" "
[Bloom County]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: