[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

init script config files

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

if [ ! -f /etc/default/rcS ]
        #       Install sample rcS file.
        cp /usr/doc/sysvinit/examples/default.rcS /etc/default/rcS
        #       Change GMT=-u to UTC=yes etc in existing rcS file.
        if grep -q ^GMT /etc/default/rcS
                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 ]
                        rm -f /etc/default/rcS.TMP

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:


# Don't touch these ..
# .. edit this file instead!
if [ -f /etc/default/foo ]; then
	. /etc/default/foo
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

Reply to: