Re: RFC: Debian Package Configuration Proposal
On Thu, 23 Jan 1997, Vociferous Mole wrote:
> I. The Goals
[snip]
> 6. Users don't have to use the tool -- editing the "normal" config
> file should have priority.
Difficult - we would need to re-merge this info back into the CDB later.
> II. The Files
[snip]
> 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.
I think we should be more specific than preferably non-interactive. Maybe
add another which is interactive. That way, we can ensure truly
non-interactive configuration. So pkg.postcfg _MUST_ be non-interactive,
but if you want to do interactive things here, call it
pkg.postcfg.interactive instead.
>
> 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
Can we do this for perl/emacs/etc., as well (example: innshellvars.*).
> 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).
One point. What do we count as "configuration data"? I would define it to
only include data used by the package the configuration script uses. So
inetd, etc., still belongs in postinst.
> 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
Hold on a minute. It already takes long enough to download 800K's worth of
package data over my 14.4K modem - unless these are going to be small
enough (which I doubt they are), this would seriously make me not consider
using dconfig/dselect.
> /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).
This is definitely an advantage.
> 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.
Maybe we could do a `dconfig --update' which does exactly this from the
CDB.
> 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).
This is a good reason to have a pkg.postcfg.interactive as well.
> 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.
Not necessarily. If you just put these values in the CDB, then if they are
already there, you can use the existing ones.
> III. The dconfig program.
If we standardize all this pretty quickly, I can get to work on this. Or
should we assign a team of developers?
> 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
Or a newer Configure file being installed. Which is a problem. We should
probably make sure that for installed packages, this is never updated. (Or
maybe installing a package places an 'override' file in /var/lib/...).
> 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.
Maybe we should have a list of these files instead (pkg.dconfig-files),
the same way conffiles already does it. This will avoid the extra
slowness of running, e.g. 14 copies of this.
> 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.
The easiest way to do this that springs to mind is have a whole tree of
whatever of the CDB that you exclude - say "local/*". Since this is only
going to be a list of absolutely critical things (hostname, IP addresses,
hardware info), it should be kept to an absolute minimum.
> 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.
Could you clarify this - can this be an xterm? Can we use ncurses (like
dselect)?
> 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.
I think scripts should have the values inserted by sed, i.e.
HOSTNAME=blah ## __DCONFIG__HOSTNAME__
Then do a sed -e 's/^[^# ]\+\([ ]\+##
__DCONFIG__HOSTNAME__.*\)$/HOSTNAME="`cfgtool -get basecfg_HOSTNAME`"\1/g'
to the script (maybe perl is more suited to this).
Then the user can EASILY see how to edit the scripts values, and the
automatic tool/user combination can be managed fairly easily - just run a
dconfig --update-all to set back to the CFGDB/update from the CFGDB
(warnings would appear if the md5sum didn't match).
> Pre-install configuration can be done without the package files.
This is very nice. I haven't seen or heard of _ANY_ OS that can do this
yet.
> Configurations may be moved from machine to machine; or at least
> this gets us headed that direction.
This is probably more dependant on individual packages doing it "the right
way".
> 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.
See above comments about sed.
> 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.
I would describe it as "a much needed addition to dpkg".
--
Tom Lees <tom@lpsg.demon.co.uk> http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)
--
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: