On Sat, Jan 22, 2005 at 03:38:01PM -0500, Greg Troxel wrote:
> venus-setup decides when to call coda-setup-ports by omitting the call
> on debian.  It should omit it on NetBSD also, and perhaps in general,
> and we should add systems on which to run it; systems without coda in
> /etc/services are in 2005 deficient.

I agree, everything should have the correct /etc/services by now since
these ports were approved by IANA about 7-8 years ago. There is only one
system that I know which is still missing the services entries, the base
install of CMU's facilitized Linux distribution, initially /etc/services
doesn't contain the Coda entries until at least the next depot update
runs at which point they get added correctly. But except for Windows
there probably isn't much use for coda-setup-ports.

> Also, since this is a shared venus/vice thing, perhaps the check on
> whether to do anything belongs in the coda-setup-ports script itself.

Actually, on debian I don't even include venus-setup or coda-setup-ports
in the binary package, everything is either already correct, or it is
configured when the package postinstall script is run. Venus used to
need a lot of setup, but because we have the automatic realm discovery
the only configuration really is what the local cache size should be and
whether the user wants to use a default authentication realm for clog.

> Thoughts, Jan?  I can send a patch, but only want to do that in the
> direction you are willing to take.

I guess venus-setup is still useful when building from CVS or a tarball,
but maybe it should simply not call coda-setup-ports, or possibly we
should have individual coda-client-check and coda-server-check scripts
that can perform post-install checks for /etc/services ports, /dev/cfs0
character devices, if the kernel module is installed (and loadable) and
other things. This could even be used to correct things after an
upgrade, for instance if we want to run venus or codasrv as non-root we
might need to create a user/group and fix up permissions of various
files.

> This seems to be one of those files that is installed for both client
> and server.

Those are a pain, especially for binary packages. In the debian binary
packages the only common file between client and server is codaconfedit,
and I'm using some redirections to make the packages install cleanly.
The backup and server packages have no common files, but really should
have at least volutil in common. On the other hand I think the Amanda
backups are working better so I will probably end up merging the voldump
munging tools back into the coda-server package and dropping the backup
scripts.

'au' has been a tool that has been bouncing between coda-client and
coda-server, I'm still not sure where it belongs but my current thinking
is that it is a client utility. So the creation of users and volumes
happen on the server (with pdbtool and createvol_rep), while activating
them happens on the client (using 'au nu' and 'cfs mkm/cfs sa').

Jan