Jan Harkes <jaharkes_at_cs.cmu.edu> writes:

> I agree, everything should have the correct /etc/services by now since
> these ports were approved by IANA about 7-8 years ago.

OK, so how about we remove coda-setup-ports from the source tree, and
make venus-setup not call it.  Add README.ports with a note that these
should be present already and the lines.  If the code does the normal
lookup/use-hardcoded then it won't matter.

> 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.

Well, venus-setup also does a mkdir of /usr/coda/spool or some such,
and venus complains about the missing directory for the pid file, so
something like that is still needed.   If you take out the
coda-setup-ports call from it (and don't install coda-setup-ports)
then it drops of my 'packaging problem' list.

> should have individual coda-client-check and coda-server-check scripts
> that can perform post-install checks for /etc/services ports,

Why do we need this at all?  Isn't it a nicety, rather than a
necessity, and IMHO it's past time to cater to broken systems if it
doesn't impede getting things running

> /dev/cfs0
> character devices, if the kernel module is installed (and loadable) and
> other things.

These could all go in venus-setup, with if/case on OS.

> 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.

That would be very nice; they really shouldn't be root.

> 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.

In BSD pkgsrc land, having a common package with files that belong on
any coda system is not hard.  But it is better if it isn't needed.

> '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.

But can you run it on a server w/o a venus running?

> 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').

That's good enough for me.  Can you remove au from SSBIN then?

-- 
        Greg Troxel <gdt_at_ir.bbn.com>