(Illustration by Gaich Muramatsu)
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. -- JanReceived on 2005-02-24 15:03:48