On Fri, Mar 26, 2004 at 06:05:39PM +0000, paul.rogers_at_mowlem.com wrote:
> Stephen wrote:
> > Have you created a root volume and configured it on the server?
> 
> I have run creatvol_rep codaroot E0000100 /vicepa and everything seems
> to be ok.

Hmm, there was this little testprogram I added a while ago that can be
used to do the same lookups as the client is doing,

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

> Mark wrote:
> > Try adding the realm to /etc/coda/realms
> 
> Sorry Mark, I knew there was something else I\'d forgotten to include
> in the last e mail.  My coda realms file contains:
...
> # Mowlem Realms
> edm.mowlem.com      edm_bfhxx_wb005.edm.mowlem.com

Ok, technically this shouldn't really be necessary, it just creates a
alternative name for looking up the servers that are responsible for
your realm and gives you the ability to move the Coda servers to a
different host without directly affecting pathnames in /coda.

i.e. without the entry in the realms file you should be able to access
the 'realm' using the path /coda/edm_bfhxx_wb005.edm.mowlem.com/ 

> Stephen wrote:
> > Is the server itself accessible as \"edm.mowlem.com\" (ie, does that map
> > to its IP address?
> 
> I think this may be where the problem lies, ie in my understanding of
> the realms.  Because we use MS WINS there is no domain ( within our
> network at least) with the name edm.mowlem.com.  The only reference to

Admittedly realms are quite DNS centric, because I wanted to
achieve/maintain a globally unique namespace. But as long as you can
'ping edm_bfhxx_wb005.edm.mowlem.com' it should work. 

The only problem then is that we used to append a '.' to the realm name
before passing it down to gethostbyname/getaddrinfo which works like a
charm for DNS lookups, but makes the /etc/hosts lookup fail.

> cannot be mapped to an IP address via edm.mowlem.com.  I thought
> edm.mowlem.com was the name of the realm.  Have I misunderstood
> something?
> 
> What should the edm.mowlem.com point to, the server or the realm?

No, I think you are correct. edm.mowlem.com _could_ be a hostname. But
if you want the ability to move to another server without having to
change scripts to adapt to the new server name, or have multiple servers
available to handle authentication and volume location queries, then the
setup would be to map the 'realm' name to one or more servers with
either IN SRV records in DNS or the /etc/coda/realms file.

> Jan wrote:
> > That would typically indicate that either the resolution failed, or it
> > couldn\'t reach the server. I\'m not sure how verbose the messages are,
> > but /usr/coda/etc/console (or /var/log/coda/venus.err) should contain
> > the message \"Resolved realm \'edm.mowlem.com\'\" when it successfully
> > mapped the name to an IP-address. If that message is there the problem
> > is reaching the server. When the message is not there it should be a
> > name resolution problem.
> 
> /usr/coda/etc/console contains:
...
> 08:52:17 Starting RealmDB scan
> 08:52:17        Found 3 realms
> 08:52:17 starting VDB scan
> 08:52:17        2 volume replicas
...
> 08:52:17 starting FSDB scan (1666, 40000) (25, 75, 4)
> 08:52:17        3 cache files in table (0 blocks)
...
> 08:52:44 root acquiring Coda tokens!

I thought it always showed the message, but maybe the verbosity of the
message only got bumped up recently (6.0.4/5).

But still interesting. First of all, I see you managed to get tokens.
Clog is using the identical code to resolve a realm to a group of
servers. So if clog worked, we can pretty much assume that venus is
doing the right thing as well.

3 realms... We always have 1 fake realm in the system. It is called
'localhost' and contains the volume/directory that we see as /coda, as
well as the volumes used for repair expansion. So I really would expect
only 2 realms in your RealmDB. We might have entries for failed lookups
which should be expired whenever some internal housekeeping thread
wanders by.

There are 2 volumes, one of which is clearly the volume that is mounted
as /coda ('CodaRoot'), the other is used by local/global repair
('Repair').

The 3 objects are probably, top-level directories for both the CodaRoot
and Repair volumes, and the mountlink object that represents the
edm.mowlem.com entry in /coda.

> I assume the three realms it has found are those in the realms file.
> I assume that means it is OK?

The realms file is not loaded into memory, if you're really curious run
'vutil stats' as root and look in the /usr/coda/etc/venus.log file.

> /var/log/coda/venus.err doesn\'t exist.  Is this a problem?

Nope, it is the same as /usr/coda/etc/console, but I've tried to be a
bit more 'standard compliant' with the Debian packages and moved things
around to more appropriate places,

/usr/coda/etc/console   -> /var/log/coda/venus.err
/usr/coda/etc/venus.log -> /var/log/coda/venus.log
/usr/coda/venus.cache   -> /var/lib/coda/venus.cache
/usr/coda/LOG		-> /var/lib/coda/LOG
/usr/coda/DATA		-> /var/lib/coda/DATA
/usr/coda/spool		-> /var/lib/coda/spool

I think there is only a /usr/coda/tmp at the moment, I'm not really sure
what it is used for, or whether it is used at all.

(venus cache is in /var/lib instead of /var/cache because the container
files cannot be arbitrarily removed without reinitializing the client).

> Should I try and update to 6.05 and see if it resolves the problem?
> 
> Any other suggestions?

Right now it is looking more and more like a server-side problem. If
clog works we're 99% there as far as the client is concerned.

Try the 'getvolinfo' program and check the /vice/srv/SrvLog for possible
errors indicating that volume lookups are failing.

Jan