Atu wierdness ...

Michael Bell michael.bell at stanford.edu
Wed Sep 11 15:25:08 PDT 2002


Interestingly when I tested functionality on Rosen it seems that traceroute
doesn't work to snf.stanford.edu on that machine either. So that may have nothing
to do with the fact that the clients aren't running.  Pings to SNF work correctly
from both machines. See below.

<<< Log from rosen.stanford.edu started September 11, 2002, 15:14:55 >>>
rosen [~] # ping snf.stanford.edu
snf.stanford.edu is alive
rosen [~] # traceroute snf.stanford.edu
traceroute: Warning: ckecksums disabled
traceroute: Warning: Multiple interfaces found; using 192.168.0.11 @ hme0
traceroute to snf.stanford.edu (171.64.100.112), 30 hops max, 40 byte packets
 1  * * *
^C

<<< Log from atu.stanford.edu started September 11, 2002, 15:17:49 >>>
 ping snf.stanford.edu
snf.stanford.edu is alive
bash-2.03$ traceroute  snf.stanford.edu
traceroute: Warning: Multiple interfaces found; using 171.64.101.174 @ qfe2:1
traceroute to snf.stanford.edu (171.64.100.112), 30 hops max, 40 byte packets
 1  * * *
 2 ^C

John Shott wrote:

> Bill and Mike:
>
> I still have been unable to get local coral clients to run on any machine
> other than atu itself (although I can get the remote client to run) ... it
> clearly makes it impossible to switch over to the atu servers until this
> problem is resolved as clients have to be able to run from sunray. (I've tried
> to run a local coral-dev client from both shott and from bopeep with the same
> results ...)
>
> It seems to be able to get the IOR from the web page, then says "Bound to
> AdminServer" ... which I know only means that it is going to try to reach the
> admin server, and not that it succeeded, and then it gets CORBA timeouts. It
> seems to me that the IOR that it gets must be OK or clients on atu or remote
> clients wouldn't run. Correct?
>
> One other thing that seems a bit suspicious is that '/usr/sbin/traceroute
> snf.stanford.edu'
> can't find snf.stanford.edu when run from atu ... although it can find
> rosen.stanford.edu and all of the machines behind the firewall.  I don't know
> whether this means that we have some sort of a network problem ... but that is
> what my suspicion is.
>
> Finally, paths don't seem to be set up properly ... for make (for root at
> least) it finds /usr/ccs/bin/make (which doesn't work for us ...) instead of
> /usr/local/bin/make.
>
> Thanks,
>
> John




More information about the coral mailing list