On Sat, 8 Apr 2000, Robert Elz wrote:

#     From:        jnemeth@victoria.tc.ca (John Nemeth)
# 
#   | That's nice.  However, there are a bunch of us that want it to
#   | stay, because removing it would make our lives as administrator's far
#   | more difficult.
# 
# I actually doubt that, once you got a little used to it.

What would you rather be able to edit, as an administrator:  One big
file or bunches of little ones?

I suppose it's something of an "it depends", but really, if you have
to edit more than one preference, it's far easier to have them all
in one file as opposed to having to edit bunches of little files.

#   | I know it would make mine far more difficult (I've
#   | used most versions of SysV and it is a pain in the neck to
#   | administrate).
# 
# No-one (well not me anyway) is proposing that NetBSD emulate SysV.
# You're right, SysV is painful to manage, and that isn't where I would
# like to go.   But the way that all of this is done on SusV is nothing
# like what is suggested, there the decision is made by a combination
# of linking the startup script to a weirdly named file in another directory,
# and then by arranging for the system to enter a particular run level.

Well, actually, IRIX is the biggest PITA precedent for this:  They threw
everything into rc.d/*.conf files and did away with rc.conf altogether.

That is precisely what I would wish to _be able to_ avoid.  That is,
I think it would be easier to write the code to make this solution more
selectable than it would have been for /etc/rc.d vs. /etc/rc.  Here
we have the chance to make the config format selectable on a per-
administrator basis.  I strongly suggest we do so.  You like the config-
file-per-service, I (and others) like the single-point-of-configuration.

There is NO REASON we can't make this selectable.

# I certainly hope that isn't what I have been suggesting.

Run-levels are a different array of pointers to functions returning pointers
to arrays of cans of worms.

#   | Why should your needs and/or desires take precedence
#   | over other peoples?
# 
# Of themselves, they shouldn't, nor should yours.
# 
#   |      Says who?  As of this moment, you're not even on the list of
#   | contributors (although you are listed as contributing to CSRG) much
#   | less being listed as having any kind of authority.  I just checked at
#   | http://www.netbsd.org/People/ .
# 
# You're right, I have no authority in NetBSD at all.   You can take some
# heart at that if you like (that is, it isn't likely, or even possible,
# for me to make this change).   I haven't had time to do as much NetBSD
# development work as I'd like.   One day maybe.   But even if that happens
# I won't be included in the list of contributers, I prefer to avoid
# such noise as much as possible.
# 
#   |      reductio ab absurdum!
# 
# Exactly.

On this tack, I think Robert is keeping a fairly level head at this ac-
cusation.  While true, I don't think it really has a place in the discussion.
Much of this is opinion, and opinions are like ... well, everyone has one
but nobody wants to look at the other guy's.

I can certainly think of other individuals who would turn this into a further
flamefest, and that's something this discussion DOES NOT need.

#   | ssh, apache, amanda, and Xserver are all
#   | applications, not part of the OS.  Their configs don't belong in rc.conf
#   | which is an OS config file.  Nobody is arguing for a "Registry".
# 
# rc.conf is an OS config file?   My OS config file, last time I looked,
# was in /sys/arch/`uname -m`/conf/NAME
# 
# Or is it that you're saying that syslog, cron, named, ntp, sendmail,
# xdm, gated ... are all "part of the OS" ?

There are command-line arguments for these programs which lie outside
the configuration file, and that is what goes into rc.conf.

Or, if _you_ want to, rc.d/$prog.conf.  Just please don't force ME to
use those individual config files.

# And if so, why aren't you wanting their config files to be merged into
# rc.conf ?   They all have separate config files that you have to manage
# separately from rc.conf, and they're all also listed in rc.conf as well.

(see above)

#   |      That's your opinion.  Stop stating your opinions as fact.

# Yes, of course, it is all my opinion.  What you write is your opinion.
# This is an area where everything is opinion...

Wups.  Guess I said that above. :-)

#   | I'm not saying that
#   | when you have a team of sysadmins that all members should have the root
#   | password; but, if you have a team of only a half dozen members and you
#   | can't trust each of them with general sudo access then something is
#   | wrong!
# 
# sudo to run any reasonable editor on a root owned file is equlivaent
# to sudo permission to run a shell - and is general root access.

This is a very good point, actually.  _In such an environment_, it
might be desirable to split up the config.

# And it isn't an issue of trust, it is an issue of avoiding mistakes.
# Even if it was reasonable to let people edit the combinaed rc.conf
# file, I would prefer not to - it is too easy there for someone to
# accidentally break something which they dn't really understand,

...in which case you educate your sysadmins! :-)

# And last, for most of the NetBSD systems around here, no administrator
# ever goes near them directly, the systems update themselves based
# upon scripts installed by admins on servers that the client systems
# just run as they're needed.   And I can assure you that it is much easier,
# and breaks far less often, when the update script does
# 	cp proto-file /path/to/dest
# than when it attempts to edit a common config file (and you can treat
# that as fact or opinion as you like).

Parsing rc.conf _can_ get a bit dicey, especially when it comes to trying
to edit it with a script:  Where do you put things?  Does it come before
this or after that except on odd tuesdays in which this is installed?

There are points for going either ways, but, again, it should be a selectable
option!

#   |      As long as the file keeps a defined format, this isn't true.  If
#   | somebody violates the defined format, then they probably don't care
#   | about automated tools.
# 
# The "defined format" for rc.conf is that it's a shell script that
# contains only variable settings and comments.   Aside from that, it
# looks as if almost anything goes, just consider this fragment...

Yeah, there's defined formats for BASIC, too -- as many as there are
programs :-).

# While I guess you could write something that can figure out what is
# going on there, parse it, and re-create it, I think I'd prefer not
# to have to.

"What he said."

# And while I could write a dedicated application which knows that for
# the NFS server, as well as "nfs_server" there's also "nfsd_flags"
# (not "nfs_server_flags" as the general rule would imply) but also
# "mountd_flags" to be set, I think it would be nicer for everyone for
# a general application to simply be able to read an option script, and
# allow the user the option to set all of the variables defined in the
# script when they come to ask to "config nfsd" (or nfs_server, whichever
# it is to be)

They shouldn't be reading the script; they should be SOURCING it and
seeing what gets set.

# And all this is ignoring the possibility of actually allowing both
# options to continue to exist - letting you keep all your settings in
# rc.conf if you like, but also allowing them to be in individual files.

Aha!  I missed this!  The Great KRE agrees!

# And even the latter is "all in one place" really for those who claim
# that is what they need - it's just that the "place" is a directory
# rather than a file.

But you can't run a text editor on a directory, and switching files is
a minor hemorrhoid.

# kre

				--*greywolf;
--
BSD: An Operating System For Everyone