[ god i love straw men... ]

Greg Hudson said:
> Michael Graff said:
> > What do people think about an /etc/init.d/ file, either with or
> > without run levels?  I think run levels are mostly useless, but
> > others will certainly disagree.  I would consider writing an
> > /etc/init.d startup method if there was interest.  I really think
> > the /etc/rc.local method is just plain archaic, and each package
> > SHOULD have its own startup/shutdown script.

"here we go again!"


> Actually, I'd argue for a more radical step in the opposite direction.

Well, i'm glad the world is so black and white for you...


> I think /etc should only contain configuration files, and that means
> few or no shell scripts.  A lot of what shows up in /etc is not
> intended to be modified for specific machines (witness /etc/rc.local
> vs. /etc/rc), needs to be updated for new operating system revisions,
> etc..

I agree with you here.

I also agree with Michael that there should be an "init.d" and an
"rc.d" setup...

``but, but, but, those are "in the opposite direction" from
each other!!!''


How about a scheme like:

/sbin/init.d/*		the scripts
/etc/rc.d/*		symlinks to the scripts, with appropriate
			names so they'll get run right.

``but, but, but, symlinks to the scripts aren't configuration
items!  They don't belong in /etc!''


Wrong.  The order in which you run the init scripts, and whether or
not you run them at all, is _definitely_ configuration information.
configuration information doesn't have to be in a config file, you
know...

And, order that the scripts are run is _definitely_ something you want
to configure.  Consider the case of a diskless workstation, vs. the
case of a normal ("diskful"?) workstation.  on a diskless box, you may
want to do things (e.g. mounting or checking of file systems) in a
different way, or in a different order, or not at all.


> It evades me why people in the System V world decided that each
> package should have its own startup/shutdown script in /etc.  Why does
> all that hair belong in /etc, instead of in the executables for the
> packages themselves?

actually it's very simple.  I can understand why people would not want
to do it, but i cannot understand people who can't understand why it
would be done...

each script is a modular bit of software, that controls configuration
of a given subsystem.

It makes it easy to:
	(1) add subsystems,
	(2) remove subsystems,
	(3) replace the configuration for subsystems.

say you want to add something that _must_ be run before fsck,
with the current rc.local scheme.  how do you do it?  you modify
/etc/rc.  That's bad, because it makes upgrading a pain the the butt.

say you have to run some daemon, maybe to do packet filtering or some
form of authentication, before you start things like lpd and inetd.
how do you do it?  you modify /etc/rc.  That's bad, because it makes
upgrading a pain in the butt.


Consider, for instance, an environment where:
	(1) you have a vendor supplying binary releases of software, to
	    be upgraded to at various intervals,
	(2) you have a system administrator, or group of admins, who
	    maintains some parts of the system.
	(3) you want to tinker a bit with your workstation.

That environment corresponds somewhat to the environment in the group
that i work with here at CMU.  it's not unreasonable at all.

we currently run OSF/1 on most of our alphas, and they have the
following scripts in /sbin/init.d:

afs*               inet*              paging*            snmpd*
afsd*              inetd*             pdlsw*             startlmf*
afsd.old*          kmod*              preserve*          streams*
atm*               lpd*               presto*            striper*
audit*             mmdf*              quota*             syslog*
autosysconfig*     mop@               recpasswd*         timed*
common_agent*      motd*              rmtmpfiles*        wcab*
crashdc*           named*             route*             write*
cron*              netman@            rwho*              xdm*
decnetosi@         nfs*               savecore*          xntpd*
dfstrace*          nfsmount*          security*          zhm*
dli@               nis*               sendmail*
enlogin*           ntptimeset*        settime*
gateway*           osi_applications@  sia*

of those:
	(1) afs*, mmdf, and zhm are provided by the facilities
	    folks,
	(2) dfstrace, pdlsw, striper, and wcab are provided by
	    the group that i work with, and
	(3) the rest are provided by DEC.

The individual scripts are run at various times in the boot process,
not really correlated with which group provided them.

given a monolithic /etc/rc environment, and the requirements/usage
noted above, how would you manage this system?  how do you do upgrades
automatically, of certain software packages?

"you don't."  However, if things are split out into multiple scripts a
la init.d, then you can update various pieces _very_ easily.


why not put it in the executables, you asked?  how do you know when to
_run_ the executables?  really, nobody says that you can't make a
/sbin/init.d script be a binary, but i think it'd be silly to do so.
consider the 'init' scripts just like a part of the 



Realistically, once you get Your Own Working Environment set up on a
NetBSD box, it's not likely you'll change it drastically.  (I have
some config files in /etc on NetBSDD boxes of mine that date back to
1993...)  However, when you're setting up the system, or upgrading the
system, or using the system in an environment where change is
frequent, or using the system in an environment where there are
multiple "system managers" responsible for different parts of the
'basic' software, you can really use the extra flexibility.

If NetBSD is going to be widely used and "successful" from a "number
of users" point of view, it's going to _need_ to do something like
this, eventually.  the current /etc/rc scheme just isn't flexible
enough for many environments.



chris