On Mon, 3 Apr 2000, Robert Elz wrote:

#     Date:        Sat, 1 Apr 2000 23:14:53 -0800 (PST)
#     From:        Greywolf <greywolf@starwolf.com>
#     Message-ID:  <Pine.NEB.4.21.0004012306280.2237-100000@starwolf.com>
# 
#   | Splitting up security access among individuals is asking for that same
#   | bunch of problems.  Get a competent sysadmin and stop dicking with
#   | splintered access.
# 
# Hmm ... here we have something of the order of a hundred systems to
# administer (maybe 200, I don't keep count) (quite a few NetBSD, though
# various other stuff as well), and depending upon just who you count,
# perhaps 5 sysadmins.  The work gets broken down by function - people do
# different things, and not all of those 5 know root passwds (almost) anywhere
# at all (the almost is to allow for toy systems build mostly for play).
# 
# "Get a competent sysadmin" isn't an answer for us, and is actually insulting.

You have my apologies in full -- I think I was typing while late and not
thinking (yes, I -know- I'm opinionated, but really, I don't mean to come
off as coarse-grit sandpaper).

On the other hand, /etc/rc.conf should dictate policy while individual
.conf files could potentially override it...

i.e. in /etc/rc.conf (pardon the variables, please - I'm open to
suggestion):

CONF_OVERRIDES_SUBCONF=YES	# rc.conf overrides the subconfig, printing
				# a notice if they differ.

CONF_OVERRIDES_SUBCONF=NO	# The subconfig overrides rc.conf, printing
				# a notice that things differ.

CONF_MISSING_OK=YES		# Allow extraneities in the subconfigs to
				# run, even if they're missing from rc.conf

CONF_MISSING_OK=NO		# Print a warning that something is ready to
				# go, but rc.conf did not enable it, therefore
				# it is disabled by default.

[I'd have defaults set to NO and YES, respectively, but that's just me.]

# It isn't an answer for lots of other people either - a NetBSD system only
# costs a couple of thousand (for a good current system - let alone how cleaply
# you can pick up out of date hardware that will function fine) - that much
# will only buy a competent sysadmin for a couple of weeks.  For some functions
# an organisation might be better off buying an accountant with an adding
# machine than a computer if a competent sysadmin were to be a requirement.

Well, that's really begging the question, now, isn't it?  If you have a
computer on site, you must have someone capable of running the behind-the-
scenes stuff to a certain degree, or you are doomed to fail at some point.

# There isn't a lot that can be done for the people who really want a single
# (old style) /etc/rc (not that there ever really was one, since rc.local
# always existed as well).   But for those who prefer to keep rc.conf I
# have a suggestion that might work, and be fairly simple for everyone (including
# those of us who would prefer not to have to continually fiddle that file).
# 
# That is, perhaps the rc.d file could start (for some facility called "frogs")
# 
# 	frogs=NO		# or YES, depending upon whether NetBSD
# 				# feels it should be enabled by default
# 	frog_flags="-feed"
# 
# 	. /etc/rc.conf		# fetch RC_PATH and other noise
# 
# 	test -r /etc/options/frogs && {
# 	    frogs=`sed -n '/^frogs=/s/frogs=\([A-Za-z01]*\).*/\1/p'`
# 	    frog_flags=`sed -n '/^frog_flags=/s/frog_flags=\([^;]*\)/\1/p'`
# 	}
# 
# and then the rest of the script.  (If sed isn't going to be in /bin, then
# for this task, "while read line; do case "$line" ..." type operations will
# work almost as well.)

No, let's not make the mistake of putting /usr stuff in /bin.

# Then, if you really like munging rc.conf, you can simply not have an
# /etc/options directory at all, and stick "frogs=YES" and "frog_flags=-squash"
# in rc.conf and everything will work.

I had more the idea that /etc/rc.conf would set the initial config, and if
/etc/conf.d/subsystem were present, it would override rc.ocnf (with a warning
if anything was previously defined in rc.conf).  This would be noted
AFTER all the messages were printed for the category of daemon.

# Alternatively, if you prefer separate files, then you stick lines like
# 
# 	frogs=YES
# 	frog_flags=-squash
# 
# in /etc/options/frogs (perhaps with a bunch of comments about what the
# frogs actually do, and what alternatives there are to squashing them)

:-)

# and
# that will work as well.
# 
# Because the default state of all the various options is in the rc.d file,
# nothing (aside from a few settings like rc_configured and RC_PATH) needs to
# be in rc.conf or /etc/options to get the NetBSD defined default bahaviour
# (put the test lines in a function defined in rc.subr and it even gets to be
# trivial to have the default depend upon the settings of other options).
# But a grepable comment on the "frogs=YES" line in the rc.d script, and you
# can "grep DEFAULT /etc/rc.d/*" to discover the default states of all the
# standard included startups.

Going and editing all the files you want to change instead of doing a single
one is still more trouble than it's worth.

# This way you even get to keep rc.conf if you want...

But you've just crippled the hell out of it; why bother at that point?
I think rc.conf should hold SYSTEM STARTUP DEFAULTS.  Third-party stuff
would be subject to the policy in rc.conf that says whether the
third-party stuff could just run, or whether it has to be manually placed
into /etc/rc.

Personally, I don't mind the idea that something can drop in and run.
I think there are those people who follow a different paradigm, and they
_don't_ think stuff should just drop in and run -- they want to explicitly
enable it.

We deserve to have that choice, especially since that choice may vary
from machine to machine on the same site, or even the same desktop!

#, while allowing pkg_install
# to create /etc/options/frogs for you if some package thinks it a good idea
# to do that (perhaps with =NO set, but some good options in casse you do
# want to turn it on).  Then if you prefer to keep rc.conf, you can just
# copy the lines from that file into rc.conf (which you would have had to do
# under the old system anyway - assuming rc.conf was used at all) and delete
# the option file.   Or, if you're like me and prefer separate enable files,
# you just change NO to YES in the file, and it is done.

But that's really only practical if you're configuring only one service.
If you're configuring a machine for the first time, the splintered rc.conf
would really suck, there.

# kre

				--*greywolf;
--
BSD: My Computer Works!