On Sat, Jan 18, 2003 at 04:19:32PM +0000, Mark Phalan wrote:
> I'm having some problems with Coda CVS (I'm only using it because the latest
> stable version causes clog to segfault with kerberos5 support). I can fully
> understand if Coda in CVS is unworkable or broken, that is often the nature of
> using such "bleeding edge" code. The CVS version builds perfectly with crypto
> support, installs fine. Venus seems to run perfectly now that I've applied the
> kernel patches but I can't seem to be able to create files on /coda at all.

The current CVS code adds something that is often called 'realms' or
'cells'. A realm is an administrative domain, so it allows a Coda client
to connect to multiple independent server groups. For instance,
coda.cs.cmu.edu and coda.cs.wwu.edu do not share users or volumes but I
can access them both and authenticate to either realm. You're not
supposed to be able to create files in the root of /coda, that directory
is filled in on the fly as different realms are accessed.

A realm is discovered using SRV records in DNS. These are documented in
RFC 2782, but the gist is as follows. Let's say we are trying to find
the Coda servers in the testserver.coda.cs.cmu.edu realm. In this case
the user would do 'ls /coda/testserver.coda.cs.cmu.edu'.

First we check /etc/coda/realms for a possible override, this works
similar to /etc/hosts and lists the realmname followed by the names of
the Coda rootservers for that realm. If there are no rootservers listed,
the search is terminated. This is useful because Windows tends to do
lookups for 'Recycled Files' and similar things in the top level
directory of any mounted filesystem, and we don't want to do lookups for
such non-existant realms all the time.

If we don't have anything yet, we do a DNS lookup for the SRV records of
_codasrv._udp.testserver.coda.cs.cmu.edu. This lookup can return several
results, each of which is assumed to be the hostname and ip of one of
the realm's Coda servers. Not all servers within a realm need to be
specified this way, just a couple are sufficient. The found servers are
only used for authentication and volume location queries, Venus will
find the others based on the result of the volume location rpc.

If we fail to find SRV records for the realm, we fall back to A records
i.e. we simply try to map the realm name to a single ip address.

Finally we try to connect to the found servers, and if the connection
setup succeeds an entry for the newly discovered realm is dynamically
created in the /coda directory. Once a client has expired all objects
and volumes from some realm, this entry is removed from /coda.

You can set a default realm in /etc/coda/venus.conf. This is really only
used by clog and cunlog. Without a default realm entry, you have to
specify the realm to authenticate to as follows 'clog <username>@<realm>'.

> I've set up my local user (uid = 1000) to be the admin user and am using the
> default password of "changeme".  When I run clog -coda (the README.kerberos
> should probably be fixed - it mentions "-codaauth"), and put in my password
> it seems to work.  Yet when I run ctokens I get

Because we can now have multiple user identities depending on what
realms we are authenticated with, ctokens was changed a bit. You can
query the tokens for a specific realm using 'ctokens @<realm>', but if
ctokens is used without arguments it should show the tokens for all
realms that it can find in /coda.

> The output of 
> 	cfs la /coda
> is
> 	/coda: No such device

Hmm, that is actually a typical indication that venus is not accepting
upcalls from the kernel module. It probably crashed and is running in an
infinite loop waiting for a debugger, check /usr/coda/etc or
/var/log/coda for venus.log and venus.err files. I'd be interested to
know why it died. The most likely cause is that you started the new
venus without reinitializing RVM, the old data structures have a
different layout and as such venus will crash as soon as it tries to
look at an object, but then it shouldn't have gotten to the point of
mounting /coda...

Jan