(Illustration by Gaich Muramatsu)
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'). JanReceived on 2005-01-24 17:14:33