Date:        Sat, 8 Apr 2000 01:24:38 -0700
    From:        jnemeth@victoria.tc.ca (John Nemeth)
    Message-ID:  <200004080824.BAA25991@vtn1.victoria.tc.ca>

  | 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.

  | 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.

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

  | 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.

  | 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" ?

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.

  |      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...

  | 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.

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,

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 youlike).

  |      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...

# NFS daemons and parameters
nfs_client=NO                                   # enable client daemons
                        nfsiod_flags="-n 4"
nfs_server=NO                                   # enable server daemons
                        mountd_flags=""
                        nfsd_flags="-tun 4"
lockd=NO                lockd_flags=""
statd=NO                statd_flags=""
amd=NO                  amd_flags="-l syslog -x error,noinfo,nostats"
                        amd_dir=/amd                    # mount dir
                        amd_master=/etc/amd/master      # master map

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.

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)

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.

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.

kre