Re: init script config files
On Fri, Jul 07, 2000 at 04:49:29PM -0700, Joey Hess wrote:
> tony mancill wrote:
> > While we're discussing this, I'd like to hear comments on the idea of
> > using an /etc/rc.config.d/$package scheme, like that in HP-UX. This file
> > is a shell script that gets sourced by the /etc/init.d/$package. It
> > normally has no real code in it, merely environment variables. What this
> > buys us is the ability to let the end user modify the rc.config.d file and
> > not mess with the init.d script.
>
> In fact, Debian already has such a thing, although only a few packages
> (libc6, icecast-server, sysvinit) actually use it. See the /etc/default/
> directory and its contents.
Not only that, it's used by other popular UNIX-alikes, such as Solaris.
> 1. The files should include nothing but simple shell variables, to prevent
> horrible redhat-esque messes. (Although I want to note that we cannot set
> policy for the admin, so they're welcome to edit it to something more
> complicated, and on their head be it if it breaks.)
I would restrict this even further to say that the files should only include
name-value pairs of the form 'NAME=VALUE' and shell-style comments.
Eliminating other shell conventions would make it possible for the files to be
trivially parsed by programs other than the shell (including, say, a
configuration tool).
> 3. We should use debconf.
>
> In response to this: no, we should not. Debconf is concerned with the set
> of questions you need to ask a user to install a package and get it
> basically configured. It does not try to deal with the whole space of
> modifying configuration files, or settings that a user may want to make
> after a package is installed. While some of the stuff in these files may
> be prompted for by debconf, it's really orthagonal to how the files are
> set up, so can we just ignore that can of worms for now?
We can ignore debconf itself, and agree that it is not debconf's job to handle
actual configuration of packages, but there is a mapping between debconf's
database of configuration data and actual configuration files that, I think,
can be organized to some extent.
For instance, there is a whole class of "Should I start at boot time?"
questions that will be asked by many packages, whose answers will be used by
init scripts. It would be nice if all of these packages did their
configuration in the same manner.
> /etc/init.d/foo:
>
> #!/bin/sh
> # Don't touch these ..
> FOO=bar
> NEWVAR=/tmp/killme
> # .. edit this file instead!
> if [ -f /etc/default/foo ]; then
> . /etc/default/foo
> fi
> #
> rm -rf /$NEWVAR
> start-stop-daemon foo -- $FOO
>
> So the point is, init scripts could set all the variables to sane
> settings, and allow sourcing the file to overwrite those settings, and
> this becomes a non-problem.
Another idea (presented elsewhere in this thread) would be to have defaults
and overrides side-by-side in the configuration directory, e.g.:
/etc/default/package.default
/etc/default/package.override
...where both files have the same syntax, package.override is a conffile, and
package.default is not. This would solve the problem of supplying defaults for
new variables.
--
- mdz
Reply to: