On Tue, Dec 05, 2006 at 11:00:32AM +0100, Achim Stumpf wrote:
> I have done the installation as it is described in 
> http://linuxplanet.com/linuxplanet/tutorials/4481/1/
> 
> That should be the most uptodate documentation.

That is an excellent tutorial, but it was written at a time when we did
not have support for realms.

Here is an email that explains some of the technical background,

    http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2003/4830.html

> # clog coda
> username: coda_at_clusty1
> Unable to resolve addresses for Coda auth2 servers in realm 'clusty1'
> Password:
> Invalid login (RPC2_FAIL (F)).

Coda realms only resolve as fully qualified domain names. The usage
scenario is oriented on mobile clients that hop on and off various
networks. And clusty1 is an address that only exists when someone
queries your local dns servers. If your client would set up the realm
based on that name and you went off and tried to use Coda at a local
coffeeshop, or when you are giving a talk (on Coda ;) somewhere you
wouldn't be able to access your files.

So there are some heuristics built into the system that try to make sure
that realms are (most likely) names which work anywhere.

Something like coda_at_clusty1.my.local.domain.de

> like that it works:
> # clog -host clusty1 coda
> username: coda_at_clusty1
> Password:

In this case you're telling clog that you know better and force it to
use a specific host to get the tokens from, which succeeds. Then it
passes the identity (coda_at_clusty1) and the received token to the Coda
client. However the client realizes that clusty1 is not a valid realm
name so it doesn't create the /coda/clusty1 entry.

> If i try to list my token:
> # ctokens
> Tokens held by the Cache Manager for root:

ctokens without arguments checks for tokens for every 'realm' that is
visible in the top level /coda directory. But there are none.

> like that it works:
> # ctokens @clusty1
> Tokens held by the Cache Manager for root:
>    @clusty1
>        Coda user id:    500
>        Expiration time: Wed Dec  6 11:47:38 2006
>
> Why behaves it like that. As mentioned in the documentation it should 
> work with "clog coda" and "ctokens"!!! Why does it not???

In this case you are checking for a specific realm, venus did store the
token, but it is mostly useless since it won't show a realm of that
name.

> # cfs lv /coda
>  Status of volume ff000001 (4278190081) named "CodaRoot"
>  Volume type is Backup
>  Connection State is Connected
>  Reintegration age: 0 sec, hogtime 0.000 sec
>  Minimum quota is 0, maximum quota is unlimited
>  Current blocks used are 0
>  The partition has 0 blocks available out of 0

To support multiple realms, the top-level directory is dynamically
generated. It contains an entry for every valid realm that the client
knows about. New entries are created by either having a token for a
valid realm (clog user_at_realm) or instantiated as a result of a lookup
operation for a valid realm name (ls /coda/testserver.coda.cs.cmu.edu).

We don't allow creation/deletion type operations, so the volume is
marked as read-only and backup volumes have the same type. Really it
should say "Volume type is a readonly replica", but that may be too
technical, "Volume is readonly" may be about as confusing as saying it
is Backup.

> So it does not surprise that I have no write access on /coda. But what 
> did I miss. I have installed it already several times with different 
> versions and always i get the same thing as described.

Your client seems to be working fine, but you want to address your
server based on the fully qualified domain name. If you cannot connect
to your own server using it's FQDN, you can always try to access our
testserver to make sure that your client is working correctly,

    ls /coda/testserver.coda.cs.cmu.edu

Jan