PROPOSAL: Dconfig standard
After reading the RFC posted to debian-devel yesterday by Vociferous Mole
<stevegr@neosoft.com>, I have started work on a dconfig. I have also
drafted some standards which are specific enough for dconfig to be coded
to. Here is the document I have written so far. I would appreciate any
comments on this.
I would also like to have more than just me coding this (otherwise, it
will take forever, as I don't have all that much free time due to
school, etc.).
[start of file]
Note that I have now started work on dconfig. If anyone wants a copy of my
(rather small) source base, please ask. Note that you will need automake 1.1l
minimum, autoconf 2.12 minimum, and GNU gettext 0.10.26 minimum if you want
to edit the relative files.
The dconfig standards:-
CONTENTS
1. pkg.dbcfg
2. pkg.cfg
3. pkg.postcfg
4. Dconfig conffiles
5. The CDB
6. Miscellaneous
============
1. pkg.dbcfg
============
>From the original RFC:
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.
I have decided to base this on the existing dpkg control format. Here is an
example of the format I have decided to use:-
Item: admin/mailname
Section: General
Type: string
Description: System's mail name
This is the name that external mail from your system will be shown to have.
Item: admin/mail/sendmail/masquerade_envelope
Section: Sendmail
Type: bool
Default: yes
Description: Masquerade envelope option
Enable this option to make all headers appear "masqueraded" to come from
the system mail-name rather than the qualified hostname.
Item: admin/mail/sendmail/
Following are descriptions of the various fields currently defined:
* Item - is the name of the CDB item.
* Section - The following sections are currently defined:-
- General - General system config values - hostname, mailname, etc.
<More ideas for this needed>
In addition, package-specific values can be placed under a section with the
name of the source package. Virtual package names can also be used (e.g.
"HTTPd" for values common to all [or at least most] http servers).
Note that capitalization _DOES_ matter for all fields, so virtual package
maintainers should standardize on the capitalization that should be used
for each virtual package.
The section is entirely for the user interface. The location within the CDB
is controlled entirely by the "Item" line (see section 5 for more details
about the partitioning of the CDB space).
* Type - The following types are defined:-
- bool - `yes'/`no'
- string - A string
- int - An integer
* Range - supports the following formats for numeric types:-
x-y - Between x and y
<n - Less than n
>n - Greater than n
[x,y,z] - Only x, y, and z
[^x,y,z] - Anything but x, y, or z
You can also specify multiple limiting factors, e.g.:-
Range: <50, [^32]
(Although when this would be useful I don't know).
* Default - obviously, a default (sane) value for this. Don't specify if
it's something like hostname, IP, etc. Dconfig will choke on having no
default if it is told to not ask the user, and the package will be left
unconfigured.
* Description
As for the dpkg description, the first line is ashort description, suitable
for use next to a check-box, etc. Then follows a long description, suitable
for help dialogues, etc.
NOTE: Multiple packages supplying the same value
If more than one package provides the same value, they should try to
standardize the description and types of values they demand. The last instance
of the section will be used. If they must use, e.g. different ranges, then
they should be probably use variables in their own sections.
==========
2. pkg.cfg
==========
>From the original RFC:-
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.
Here are some additional clarifications:-
* It should definitely _NOT_ require that it is running on any particular
terminal - certainly _NOT_ that it is on a utmp-identified one (major
dpkg bug with this). This should ensure that ptys can be used by an X11
configuration program which uses its own builtin terminal (would look nicer
than an xterm, and be less prone to failure).
* Maintainers really should try not to supply a pkg.cfg unless it really is
necessary (often postinst or preinst will do instead).
======================================
3. pkg.postcfg/pkg.postcfg.interactive
======================================
>From the original RFC:-
3. pkg.postcfg -- A preferably non-interactive script, run after package
installation completes, but before the postinst.
These files should be installed by the package into /var/lib/dconfig/info.
pkg.postcfg _MUST_ be non-interactive - if you need to use an interactive
script for this, call it pkg.postcfg.interactive.
pkg.postcfg will be called with the arguments a list of the conffiles it
should update (see section 4).
====================
4. Dconfig Conffiles
====================
NOTE: Is there a better name for this? (i.e. does it get confusing between
dpkg's conffiles and dconfig's conffiles).
Conffiles can be registered in one of two ways for a package.
1. By the postcfg running dconfig --register <pkg> <files> after
having inserted configuration values into them.
2. By supplying a file /var/lib/dconfig/info/pkg.conffiles, which
will automatically be reregistered every time after the postcfg
is run.
For both methods, the registered md5sums are checked before the postcfg is run
again, and if they are different (i.e. if the user has edited the file, not
the CDB), the user will be prompted whether to update from the CDB, or not
modify that file. This is why the list of files to update is supplied on the
commandline of the pkg.postcfg script.
Note that probably the best way to generate pkg.postcfg files is with m4 (as
GNU autoconf does to generate configure scripts). I have hacked together a
couple of m4 macro-files which enable a postcfg to be genrated fairly easily.
However, they still generate very inefficient code :(.
==========
5. The CDB
==========
One of the first standardizations that needs to be made is the configuration
database format. Currently, I have only seen one tool to do this - cfgtool,
which is in experimental or unstable (I can't remember which). Therefore, I
suggest that we use this for the CDB, although it probably needs optimizing
at the moment.
Since the plan I have outlined above does not require putting `blah` all over
the shell scripts, does not add dozens of tiny little scripts, and does not
look too difficult for newbie (to Debian), or, more likely, experienced
sysadmins to modify _WITHOUT_ using the supplied UI. This addresses all the
concerns that have been expressed by others. It also unifies the interface
for storing values shared among packages, which is a Good Thing.
The best way to partition the CDB is hierarchical, so that it is (fairly)
easy to browse. I suggest that we follow the lead of menu, and adopt the
idea of using slashes to delimit the hierarchical classifications, e.g.
/admin/mail/mailname.
Here is my list for the basic level of the hierarchy possible:-
/local - Values that should not be transported between systems:
use as sparingly as possible!
/admin/mail - MTA stuff
/admin/news - NTS stuff
/admin/<pkg> - Non-transient info specific to <pkg> (use discouraged)
/admin/<vpkg> - Non-transient info specific to most or all providers of
<vpkg> (use discouraged)
/<pkg> - Config info specific to <pkg>
/<virtual-pkg> - Config info specific to all (or at least most) packages
providing <virtual-pkg>
Note that packages should avoid putting things in /<pkg> or /<virtual-pkg>
if there is an obviously better place for them in /admin (I will add any
extra sub-classifications to /admin if they are suggested). Having said
that, remember that /admin/xxx is never removed - transient package data
_SHOULD_ be kept in /<pkg>.
================
6. Miscellaneous
================
- dpkg --purge vs. dpkg --remove, and their respective effects on the CDB
dpkg --purge should remove the tree /<pkg> from the CDB, which dpkg
--remove should not do.
dpkg --purge should remove the tree /<virtual-pkg> from the CDB if
this is the last instance of <virtual-pkg> being removed, and all
of the packages providing it are purged, not just removed.
NOTE: This should not be done by a special postrm, but by dpkg itself,
when the upgrade to dconfig integration is done.
Variables outside this tree should never be purged unless specifically
requested by the user. This means that, even if someone removes all
MTAs (say, when upgrading MTA), the MTA parameters (like mailname)
are not lost.
[end of file]
--
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: