On Wed, Mar 09, 2005 at 06:53:17PM +0100, Ivan Popov wrote:
> > patch.no-daemonize
> >     Should be fixed, you're not applying those anymore either.
> 
> Right. On the other side, I run venus in my startup script with ampersand
> anyway, to let the system start even if venus hangs/crashes during startup.
> The script waits for Coda being available for 4 minutes, then times out.

Ah, venus only forks when /coda is available, it returns a 0 errorcode
indicating success. If anything went wrong (hang/crash) it should return
errorcode 1 or something.

I needed this behaviour because web, ftp and cvs daemons are serving files
directly from Coda and had trouble starting if /coda wasn't available
and I always had to log in once the machine was booted and restart most
of these services. They start after the Coda client init script and
everything comes up nicely.

> > patch.nokrb4
> >     I don't know why configure picks up kerberos4. I could split the
> >     with-crypto flag into separate -openssl -krb4 and -krb5 flags if you
> >     want more control over which libraries get linked in.
> 
> My point of view is that we should never use kerberos 4.
> The modular clog does not support that, and I doubt anyone runs Coda
> with kerberos 4 authentication anyway.
> Anybody here who does?

Ehhh, I think CMU does, but we aren't actually using kerberos on our
Coda servers (maybe they migrated everything to krb5 by now). I guess
splitting up into separate krb4 and krb5 options is a better choice, the
more they are independent of each other the simpler it will be to remove
krb4 at some point.

> > btw. the openssl dependency isn't necessary, we only link against it for
> > the md5 and sha1 checksum functions. If the library isn't found we use
> > a generic C implementation (I believe the original reference
> > implementation). openssl could be providing some optimized assembly
> > version for your platform, but I don't think we use these functions
> > often enough that that will result in a measurable difference.
> 
> Then I'd rather omit openssl for clarity, though I _hope_ we _will_ need it
> for cryptography!

In that case it would probably get linked against librpc2, except if we
implement the crypto hooks in the form of a set of callbacks which the
application registers when it initializes the RPC2 library.

Jan