On Fri, May 25, 2007 at 03:12:35AM -0400, Davor Ocelic wrote:
> On Thu, May 24, 2007 at 03:18:27PM +0200, PROYECTO SOLIDARIO (Eric Van Buggenhaut) wrote:
> > 
> > Until now it's been unsuccesful, first of all I think because of 
> > discrepancies between documentation. I mainly looked at:
> > 
> > http://coda.wikidev.net
> > http://www.coda.cs.cmu.edu/doc/html/coda-howto.html
> > http://www.coda.cs.cmu.edu/doc/html/manual/index.html
> > http://linuxplanet.com/linuxplanet/tutorials/4481
> > 
> > All documents refer for example to the venus-setup script, which isn't 
> > shipped in cmu's debian packages, and I didn't find alternatives to it.
> 
> Actually I think that venus-setup is shipped with Debian GNU packages,
> but that script is not important anyway. It just tunes your
> venus.conf file, which you can open and edit manually.

Correct, venus-setup used to do some additional things like making sure
some directories existed, and that the coda related portnumbers were
added to /etc/services. But all of that is done by the debian package
postinstall script.

The other half of the venus-setup functionality (specifying default
realm and cache size) is done by dpkg-reconfigure. But the settings are
at a low priority so most people don't get asked those questions and it
just uses the defaults (no default realm and a 100MB cache size).

So on Debian it is possible to run 'dpkg-reconfigure coda-client'. The
only gotcha is that the new cachesize isn't picked up until the client
is reinitialized which happens when the Coda client is started with
'venus -init'.

> > Also some documentation (linuxplanet) tells me to edit the VSGDB file 
> > which I can find on my systems (/vice/db/VSGDB)
> 
> Yes, the name of this file was changed.

The VSGDB file essentially defined ipv4 multicast addresses for groups
of servers, but the multicast code in rpc2 was unmaintained (I've never
used it) and by now should be completely removed.

Internally the client still tracks groups of servers as a volume storage
group, but it creates the groups as needed.

> > So when I try to create replicated volumes like
> > 
> > createvol_rep codaroot E0000100 /vicepa

Instead of having the indirection where E0000100 is mapped to 'server1
server2', we now specifiy the servers explicitly, i.e.

    createvol_rep codaroot server1/vicepa server2/vicepa

And if the servers only have a single data store (i.e. only /vicepa) we
don't even have to specify the location and it becomes,

    createvol_rep codaroot server1 server2

> > I get:
> > 
> > Server E0000100 not in servers file

The script thought you were trying to create the volume on a server
named E0000100, and a server with no name.

> > Last but no least, some doc indicates the use of:
> > 
> > cfs lv / cfs uk

I think cfs uk is a Windows specific function to unload the kernel
module, similar to 'rmmod coda' on Linux.

    cfs lv -> cfs listvolume <path>

	Shows the volume information of the volume that is located at
	the specified path. It doesn't create a mountpoint it just
	follows existing ones.

    cfs mkm -> cfs makemount <path> <volume>

	Creates a new volume mountpoint. Really a volume mountpoint is a
	magic symlink where the link contents is set to '#volumename.'
	When we notice such a link during a lookup the client will
	contact the server and asks for the volume information. This
	way we know how many replicas the volume has and where they are
	located. The client then connects to the replica servers and
	fetches the top-level directory of the new volume and return
	that object instead of the mountlink.

    cfs rmm -> cfs removemount <path>

	Removes the volume mountpoint. It first makes sure the magic
	link is no longer covered and then removes the entry from the
	directory.


I guess some of the confusion comes from the fact that the root of a
realm is not found by traversing a magic mountlink. The /coda directory
is special, it starts off with no content, but when we see a lookup for
a non-existant entry in that volume, the client will try to instantiate
the path passed to lookup as a new realm,

First we check /etc/coda/realms, which contains realm-name -> server
mappings. If we do we can skip the DNS SRV record lookup.

After this there is a quick check to avoid sending really bad names as
DNS queries. The name needs to look be a fully qualified domain name,
but at the moment the only requirement is that the name contains at
least one period.

Then we try a SRV record lookup in DNS which can return a list of server
names that will be considered the realm's root servers. If there is no
SRV record we assume that the realm-name is the host name of a single
server.

Now we can resolve the server names we found to ip-addresses. We filter
out any addresses that are possibly problematic (loopback address,
multicast addresses, 0.0.0.0). The main reason these are filtered out is
because these used to be the single most common reason for installation
problems. A client running on the same machine as the server would work
fine, but all other clients failed because the server was reporting it's
own loopback address as the server address.

Finally we connect to one of the realm's servers and ask for the name of
the root volume. The server reads this from /vice/db/ROOTVOLUME, if that
file doesn't exist it returns the default '/'.

And if all of that succeeds we're at the point where we have all the
information to create a magic mountlink for the new realm, and we add it
to the /coda directory.

Any lookup for a non existant name in /coda triggers this, i.e.

    cd /coda/testserver.coda.cs.cmu.edu
    ls /coda/testserver.coda.cs.cmu.edu
    cfs listvol /coda/testserver.coda.cs.cmu.edu

Once the realm has been resolved any following lookups will find the
mountlink entry we created so we don't have to resolve the realm's root
servers all the time.

Jan