About 2 minutes after I posted, I found an older post from you explaining
that same error number to another newbie, so I apologize for not finding
that previously. Based on that earlier posting, I added these two machines
into my DNS domain and configured the machines appropriately.
Network-wise, the two machines can ping each other at .4ms, they are on the
same hub, in the same DNS domain, and I can perform forward and reverse
nslookups on both machines from both machines.
I still get the same client error after correcting the name resolution.
Question: before I mixed DNS into this, I was using plain hosts files, using
unqualified hostnames. My coda server names (vice-setup and venus-setup)
are using the non-qualified hostnames.... I can ping each box using the
unqualified hostname, but do I perhaps need to re-initialize the coda server
and/or client using the fully-qualified hostname instead? Does that sound
plausible?
Doug Apel
Sr. Network Administrator
Omnipoint Technologies, Inc.
[EMAIL PROTECTED]
719-884-2571
-----Original Message-----
From: Jan Harkes [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 08, 2000 4:54 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: RH62 client access problem
On Thu, Jun 08, 2000 at 04:36:30PM -0600, [EMAIL PROTECTED] wrote:
> Greetings. I have a small problem with a RedHat 6.2 client, using the
5.3.7
> client RPM.
>
> I get the same client error when accessing both testserver.coda.cs.cmu.edu
> and my local coda server.
>
> On the client, it appears to be working, gets to "Venus starting...",
gives
> me the standard downcall message, and then quits with
> "Failure of coda_cname_make for root: error -110"
That's ETIMEDOUT, the client has failed to fetch the directory contents
from the server. Is there some (masquerading) firewall or unusual network
between the client and server?
> cmon from both the server to itself, and from the client to the server,
both
> report the same info, so it sure as heck looks like the client is talking
to
> the server....
Yup, that is a good test for the RPC2 connectivity, the problem is most
likely related to the SFTP side-effects that fail.
Jan
