[ On Monday, May 1, 2000 at 10:11:32 (-0700), Eduardo Horvath wrote: ]
> Subject: Re: Proposed rc.d changes....
>
> I still think that the ON/OFF part should be handled by the script's
> presence or absence in the rc.d directory.  Put the scripts in an init.d
> directory and copy them into rc.d to enable them.  That should get rid of
> at least half of rc.conf, since most of that is turning services on and
> off.

There are advantages and disadvantages to both schemes.

First I'll reiterate that I prefer the "scripts in /etc/init.d with
(hard) links to /etc/rc.d to trigger execution" method.  It's certainly
faster and a *lot* simpler.  It's also more likely to be understood "on
sight" by the majority of generic "unix" system administrators.

However the primary reason I like having a *single* "rc.conf" file is
that it's one hell of a lot easier to do at least minimal change control
(eg. with existing tools such as RCS) than it is to do with any other
method (yes I could write a script that re-creates *all* of the links in
/etc/rc.d and then track changes in that script, but why should I have
to do that -- why not supply such a tool with the system?).


BTW, note that if you have a /etc/init.d and /etc/rc.d then you can also
have a /etc/shutdown.d and be done with the need for some special hack
in each script that shutdown can use to avoid doing anything special on
a system shutdown vs. when the admin purposefully runs the script with a
"stop" argument.  Furthermore this gives the admin control over which
scripts actually do something on shutdown without forcing them to edit
the actual script.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>