Coda File System

Re: configuration style

From: Jan Harkes <>
Date: Mon, 14 Jan 2002 17:15:29 -0500
On Sat, Jan 12, 2002 at 09:25:04PM +0100, Ivan Popov wrote:
> In short - I'm advocating for an environment variable to locate the *.conf
> file. Cheap to implement, easy to use, breaks nothing, it will be much
> easier to manipulate configurations.

Good idea, I've implemented it and it's committed to CVS.

I'm using the environment variable "CODACONFPATH", if it isn't found it
defaults to "@sysconfdir@:/usr/local/etc/coda:/etc/coda", where
sysconfdir is the current location we look for the venus.conf and
server.conf configuration files.

The only thing I wasn't sure of was whether to read all found
configuration files, or whether to stop on the first successful load.

By continuing the search it would be possible to have a global shared
config file (shared using NFS or rdist/cfengine copying), but have
machine/system-specific tweaks in a small local file.

However stopping at the first found file is possibly a bit more
intuitive, so I went for this solution, doing the other way is actually
1 line less code-wise (simply removing a break statement). But as later
found files override options set in the earlier ones the search path
should then be reversed from what you would expect.
(eg. /etc/coda:/usr/local/etc/coda:@sysconfdir@)

> (note that binaries do not have to be present in the same tree, but it is
> not a big deal if they are, a couple of symlinks from the tree would make
> it possible to place binaries independently. the important part is to not
> "hardcode" paths as it is now - I have to clean the scripts manually...).
> (The current script-editing by configure and make breaks easily - breaks
> for me at any rate - as it relies on certain assumptions that just happen
> to be valid "most of the time").

I haven't hacked the scripts, so they aren't as well behaved yet. I
could create a variant to codaconfedit that can be used to look up
configuration variables as well as setting them which should simplify
the work done in the scripts.

> Of course, no hardcoded paths should be present. There are a couple of
> places with /vice as the only choice - in scripts (in norton too?), but in
> general the source seems to be rather consequent about reading the file.
> A small change now would make a big gain.

Yup, I'd like to find and remove the last users of hardcoded paths,
so that at some point hardcoded paths are only used as default fallbacks
whenever there is no environment variable or config file setting that
initializes them.

Received on 2002-01-14 17:17:07