> So, maybe /etc has become a sort of "catch all" place (with scripts
> and various configuration files).  What's the harm in that?

	* /etc includes both vital machine configuration information,
	  and pedestrian operating system programs (just because it's
	  implemented in /bin/sh doesn't mean it's not a program).
	  When you upgrade your system, you want to save the vital
	  configuration information, but you may need to update the
	  operating system components just like you need to update
	  /bin.

	* Because of the confusion, package and operating system
	  distributors often seem to feel that it's acceptable to have
	  people "configure" software by writing code (editing a
	  /bin/sh script).  This makes Unix harder to use.

(This isn't to say that I am opposed to packages which are
programmably extensible; I am opposed to encoding routine
configuration parameters in shell scripts or other kinds of programs
rather than in real configuration files.)

Mark Eichin wrote:
> The config-file changes (/etc/services is the one that comes to
> mind, I'm not talking about the things that need site input like
> krb.conf) are handled by a script; the startup and shutdown are
> handled by dropping a script in the right directory.

... so you wind up with a script in /etc which came from the Kerberos
distribution and isn't supposed to be changed, and is therefore not a
configuration file.  (Or if you are supposed to change it, you then
have to merge it in with a new version the next time there's a
Kerberos release.)

You should be able to start up the kerberos server simply by running
/usr/sbin/kerberos; it should read a configuration file for any
necessary parameters.

Once that is done, you just need to tell the system when to run
/usr/sbin/kerberos.  A well-designed configuration file can be at
least as flexible and powerful as symlinks in directories is, and
easier to look at.