[1949] in Kerberos_V5_Development
Re: Configuration directories
daemon@ATHENA.MIT.EDU (mhpower@MIT.EDU)
Tue Nov 12 23:08:37 1996
From: mhpower@MIT.EDU
To: ghudson@MIT.EDU
Cc: source-developers@MIT.EDU, krbdev@MIT.EDU
In-Reply-To: "[0028] in Source_Developers",
"[1930] in Kerberos_V5_Development"
Date: Tue, 12 Nov 1996 23:08:30 EST
>I'd like to solicit people's opinions on the question of where Athena
>packages should look for their configuration files.
I think they should look in /etc/athena if it's likely that an
operating-system vendor might ship a version of the package with
conflicting functionality, and in /etc otherwise. I mostly agree with
the reasons listed for (1), except I think it's important to consider
the case where the vendor version already has the configuration file
in /etc. Let's suppose Athena develops a syslog package, which we
expect to be used on all public workstations but only on some private
workstations. It differs from the standard syslog in that it encrypts
data before logging it, and the configuration file has an extra field
to specify the public key for encryption. I think the configuration
file belongs in /etc/athena/syslog.conf, so that users who choose to
run the vendor version can start off with the standard vendor
configuration file in /etc/syslog.conf. I think the configuration file
doesn't belong in, say, /etc/nsyslog.conf, since a filename like that
tends to get lost in the morass of files in /etc, it's very unlikely
that someone would initially guess that that's the correct name, and
thus configuring syslog would likely end up at the level of "lore".
I think (3) and (4) are wrong because if you happen to have copies of
the file in both /etc and @sysconfdir@, and the @sysconfdir@ version
becomes different (perhaps no one bothers keeping it up-to-date, since
it isn't normally important), and the version in /etc happens to get
deleted (perhaps it goes away during a run of fsck), then the software
will continue to work but in some arbitrarily different manner.
Depending on the package, this different operation may be insecure,
disruptive, or have other serious problems. If there's a single
location for the configuration file, and the file is found to not
exist, then it may be appropriate for the software to simply exit.
(For example, arguably attach should simply exit if attach.conf is not
found.) This failure behavior can't be implemented if multiple
locations are possible, since the software has no way of knowing
whether the file is missing from one of the locations intentionally
or by accident. (Well, you could have another configuration file that
listed the expected locations, but this doesn't really help.)
I think (3) and (4) look nice in an ideal world of reliable
filesystems, reliable operating systems, and reliable system
administrators -- but in the real world they're counterproductive.
> Should we consider it a requirement that packages accept an
> environment variable telling them where to look for
> configuration data?
No, I think it should be the role of the developer of any particular
package to decide on and justify whether or not the environment ought
to be used. Suppose there's an olc package that normally reads a
configuration file in /etc/olc.conf, which would include the line
"server: matisse.mit.edu". I think it might be justified for the
deployed olc client to be able to read its configuration only from
/etc/olc.conf. Athena might not want to provide any easy way for users
to select a nonstandard configuration and thus be unable to get help
from Athena's olc. Athena might not want a class to tell users to type
"setenv OLC_CONF /mit/6.039/etc/olc.conf" for fear that some users
might put it in their .environment file. (I'm intentionally ignoring
the issue of the OLCD_HOST and OLCD_PORT environment variables that
are used by the current version of olc.) There are many other examples
where Athena might not want ordinary users to reconfigure software
trivially, because the standard configuration might have parameters
that were intentionally chosen to interact equitably with other
machines on the network (e.g., parameters that would affect packet
sizes, rates of connections to servers, or server load balancing).
Users who know what they're doing and actually need a different
configuration could edit the file in /etc, if it's on their own
private workstation, or compile their own version of the software.
Matt
