Re: RFC: Debian Package Configuration Proposal
[So far, Tom's is the only response I've gotten. I therefore assume
one of the following:
1. The proposal is blindingly perfect, and everybody agrees.
2. The proposal is mind-numbingly stupid, and not worth replying to.
3. Everybody is too busy to read and respond 300 line e-mails.
4. Nobody cares.
(1) seems unlikely, (2) only slight more likely (Ok, IMHO), and
(4) is scary. I hope it's (3)....
]
On Jan 26, tom@lpsg.demon.co.uk (Tom Lees) wrote:
> 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.
Yep, but there are always going to be situations that a "standard"
configuration won't solve, and people who would just rather
do it by hand. My initial idea is that dconfig would (by default)
refuse to change files that had been edited by hand, and that
'HOSTNAME=`cfgtool -r BASE_HOSTNAME`' is pretty easy to
change to 'HOSTNAME=blah'. Converting back is either
a matter of re-editing (or more likely, reinstalling), and/or the
use of '--force' on dconfig.
>
> > II. The Files
> [snip]
> > 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.
I originally specified non-interactive, but added the 'preferably'
to make it easy for packages with complicated postinstalls (eg
smail) to 'blend in'. I'll try to rephrase to make clear that any
new pkg.postcfg are to be non-interactive.
>
> >
> > 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.*).
Anything that can activate cfgtool and assign the output to a
variable should be able to do this, and that includes perl and
emacs. I was trying to distinguish between package configurations
that could deal with cfgtool directly, and those that need some
sort of post processing to merge items from the CDB into the actual
configuration file -- cern-httpd is an example of such a package.
> 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.
I agree. My definition of "configuration data" is not very good, mostly
along the lines of "I know it when I see it." A very basic rule would
be "If you ask the user about it, or expect them to change variable
definitions in a file, then it's configuration data." Or at least,
it's configuration data I want to be able to handle with dconfig.
> > 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.
I understand. But I actually don't think it would be all that big --
most packages *don't* have any configuration data, and many of the
rest would just have a few variables. I just tarred up my whole
/etc (including a bunch of X stuff), and the total came to
about 200K, compressed. It may not be a very good indicator, but
I would astonished if the actual 'config' information came to
more than 30K, compressed.
An alternative would be to have a 'package configuration file' (say
'.dcf') alongside the .deb files in the archive. Then you would
only retrieve the ones you needed (via ftp, if necessary), after
making your selections. My only real objection to this is
the clutter on the archive site. Maybe they could all be grouped
under stable/config and unstable/config rather than with the
binaries, after all, they should be architecture neutral.
> > 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.
Exactly.
> > 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.
As I mentioned earlier, this is the *only* reason I would allow
.postcfg to be interactive.
> > 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.
Yeah, but when you purge a package that uses them, who gets to
delete them? Tracking multiple references is a real PITA.
> > 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?
I'd like to spec out the .dbcfg format, and the basic dconfig architecture
first (all open to discussion, I'm not trying to dictate, but I don't
want to spend a bunch of time coding and then discover we've forgotten
something critical).
> > '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/...).
Oops, glad you caught this. I think there are two trees -- one for
installed packages, one for the stuff from the distribution. If you're
modifying an existing configuration, then you want the version of the config
files that correspond to that version. If you're upgrading, then you want
the new ones. After a successful upgrade, you copy the new ones
into the installed tree. Looks like more options for dconfig.
Or, this may be another argument for individual package configuration
files (.dcf, mention above).
> > 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.
But you still have to generate the md5sum after the .postcfg has run.
And it's not actually that many packages -- only the ones with a postcfg
that creates/manipulates a files. Most of the files that are now
dpkg conffiles remain dpkg conffiles -- dconfig never touches them.
> > [regarding transferring configuration, and push installs]
> >
> > 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.
Yeah, there are some concerns about moving things on and off the
local list, but this is probably the right approach.
> > 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)?
Definitely. It just can't require X or svgalib -- it's got to be
runnable during a base install, and immediately after.
> 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).
My problem with this is that every package that uses dconfig now
*requires* a .postcfg, or that dconfig track and manipulate a lot of
files in a rather scary way. With my approach, the maintainer gets the
(fairly simple, I think) cfgtool references right (whether shell script,
or perl, or emacs), and it never gets touched, unless the user modifies
it. With sed, either the maintainer has to get a bunch of sed scripts
right (harder, in my experience), or dconfig applies sed
scripts to arbitrary files, which I think is a Bad Idea.
As for the user editing, I think a simple statement that says "anywhere
you see `cfgtool -get <something>` (or its equivalent in perl or emacs),
you can put in your own value" is pretty straight forward.
> > 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.
Likewise :-).
> > 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".
Steve Greenland
--
The Mole - I think, therefore I scream
"There *are* standards. If you can't see one, you *make* one and
stick to it come Hell or high water -- until you see a BETTER one."
-John Gaunt
[John Gaunt, aka GRIMJACK]
--
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: