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.
> As an example: For sendmail, I'd like to have the package loaded on
> workstations, but don't want to run the daemon there, so I'd set
> "RUN_DAEMON=0" in /etc/rc.config.d/sendmail. This way, I don't have to
> muck with /etc/init.d/sendmail to get the functionality I desire, and new
> versions of the init.d script can be installed without disturbing the
> administrator with having to accept the new version and edit it.
>
> I realize that this makes more sense for production admins and folks that
> have to take care of lots of systems, but it doesn't seem like it would
> harm anything either.
Agreed. I know other people who want this.
I'll try to summarize the rest of the thread:
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.)
2. If we move to this type of file, we have to worry about what happens if a
user modified it, it is a conffile, and a new version of a package adds a
variable to it; the user meanwhile has no such variable in their modified
file, and things die a horrible flaming death (eg, rm -rf /$NEWVAR)
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?
Moving back to point #2, take a look at this code from sysvinit's
postinst:
if [ ! -f /etc/default/rcS ]
then
#
# Install sample rcS file.
#
cp /usr/doc/sysvinit/examples/default.rcS /etc/default/rcS
else
#
# Change GMT=-u to UTC=yes etc in existing rcS file.
#
if grep -q ^GMT /etc/default/rcS
then
cp /etc/default/rcS /etc/default/rcS.TMP
sed -e "s/^GMT=.*\(-u\|--utc\).*/UTC=yes/" \
-e "s/^GMT=.*/UTC=no/" \
-e 's/# Set GMT="-u".*/# Set UTC to yes or no/' \
< /etc/default/rcS.TMP > /etc/default/rcS
if [ -s /etc/default/rcS ]
then
rm -f /etc/default/rcS.TMP
fi
fi
fi
So it's really not that bad to go in and edit stuff if something has changed.
This doesn't address the problem of what happens if an essential new variable
needs to be added though. But I have a simple solution:
/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.
I have one further concern -- why is it called /etc/default? The answer
is probably lost in the mists of time (Miquel, do you know?), but if we
start putting the actual defaults in the init scripts, and just reading
in the config files to override, it's a really bad name. Perhaps we
should find a better one -- /etc/rc.config.d/? Well, perhaps, unless
more thasn init scripts end up using the directory. I can imagine it's
be useful for /etc/cron.foo/ scripts too.
Anyway, I've crossposted to debian-policy, because the policy manual
doesn't currently mention this at all, and I think it should. I think we
should come up with a policy proposal integrating the ideas from the
thread. I'll try to work something up tonight.
--
see shy jo
