(Illustration by Gaich Muramatsu)
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. JanReceived on 2004-03-26 14:26:49