On Thu, Feb 24, 2005 at 01:14:58AM -0800, Leung Hoang wrote:
> I'm new to this coda stuff so please bear with me.
> 
> I went through the vice-setup on a fedora core3 machine, and
> everything seem to go fine.  I setup a client on a OS X machine.  I
> didn't bother with any domain name.
> 
> On the client:
> venus-setup 192.168.1.6 40000 
	      ^^^^^^^^^^^
This is just the 'authentication realm'. In other words, it is for lazy
people like myself who don't want to type the complete realm name
everytime I need to get tokens (aka. 'clog jaharkes_at_coda.cs.cmu.edu').
With that entry I can just run 'clog' and it picks my login account as
the username and grabs the @coda.cs.cmu.edu part from venus.conf. That
value isn't actually used anywhere in venus, only by some of the
authentication related applications (clog/cpasswd).

> But when I tried to connect, i.e.:
> cd /coda/192.168.1.6
> It said Removing realm 192.168.1.6 and /coda/192.168.1.6 didn't exist.

The 'cd /coda/192.168.1.6' operation forces a lookup for the missing
directory entry '192.168.1.6', this causes venus to jump through a bunch
of hoops and finally come up with the object that is at the root of the
volume that is considered the 'rootvolume' by the (group of) server(s)
which are responsible for the 192.168.1.6 realm. As you can see, a lot
of dependencies and any one of them may be the cause of the failure.

The only way to figure this out it to retrace venus's steps,

The first thing it does is try to look up 192.168.1.6 in
/etc/coda/realms, it probably isn't in there. It probably skips the DNS
SRV record lookup since it is an IP address and not a domain name. So
then we end up with a list of rootservers consisting of a single entry. 
We then try to connects to the rootserver(s) and asks what the name of
the rootvolume is, newer versions of venus probably skip this step and
go straight to the next step. The server responds with '/' or whatever
you picked as the name of the rootvolume when running vice-setup, newer
versions of vice-setup never asked for the name and picked '/' for you.

Then the client asks the rootserver(s) where the volume named '/' (or
whatever name you picked) is located. And the server returns a list of
IP addresses where replicas of that volume are available, which if
you're just setting things up for the first time is probably
192.168.1.6.

-- However this is something that often goes wrong. The server somehow
has to figure out what it's own IP address is, so it uses DNS resolution
and looks up the address of 'hostname()'. Since you clearly do not have
DNS it might have fallen back on /etc/hosts and gotten something like
127.0.0.1, which is a fine address to reach the server _if you are the
server_, but it it pretty useless for the client. The easiest way to
find out if this is the case is to run 'getvolinfo 192.168.1.6 /',
which is probably install in /usr/sbin on your server. --

If that wasn't the problem, we continue with tracing venus's steps and
the next thing it does is connect to the server(s) where the volume
replicas are located and tries to connect to the rootvolume. Once the
connection succeeds it gets the attributes of the first object in this
volume and we're done and can successfully complete mounting the volume
on the client.

-- Again lots can be wrong here, for one the volume might not actually
exist on the server. The vice-setup script left some things up to the
user, since we didn't know when a server was actually up and running and
ready to accept commands such a 'create the rootvolume'. Now servers
daemonize automatically once they are up and running and vice-setup
tries to finish the whole bootstrap for you, but then again this is all
new and probably not 100% tested/bugfree. However if the volume creation
failed, the getvolinfo thing probably wouldn't have worked either. --

Jan