(Illustration by Gaich Muramatsu)
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... JanReceived on 2003-01-18 12:41:35