Greg, Here is what I got on server(s04) where LUS is running:
[r...@s04 ~]# netstat -an | grep LISTEN tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:47754 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN tcp 0 0 :::4160 :::* LISTEN my /etc/hosts on the worker machine(s03)look like this: 192.168.0.4 s04.meng.com s04 127.0.0.1 localhost.localdomain localhost 192.168.0.3 s03 s03 My question is, if s03 can successfully get registrar back from s04, why does the registrar.lookup() bind to localhost instead of s04? Thanks, Andrew > Date: Wed, 14 Oct 2009 14:09:22 -0500 > From: [email protected] > To: [email protected] > Subject: Re: Multicase problem. > > This points at a common linux misconfiguration where the /etc/hosts file ends > up > having bad values in it that map the hostname to 127.0.0.1 and vice-versa. > > The end result is that the LUS binds to localhost instead of the interface > address for a network interface, and then tells you this is where it is > bound, > which of course you can not connect to. > > If you will do a "netstat -an |grep LISTEN" on the server that the LUS is > running on, you should see that there is no external LISTEN on 4160, only a > localhost binding. > > You are finding the service via multicast, but then getting back an address > that > you can't connect to it with I am guessing. > > Gregg Wonderly > > Patrick Wright wrote: > > This reminds me of a situation where some of our BasicObjectEndpoints > > were ending up with the loopback address. When a remote server would > > try to contact on that endpoint, it of course wouldn't find us. > > > > HTH > > Patrick > > > _________________________________________________________________ New! Get to Messenger faster: Sign-in here now! http://go.microsoft.com/?linkid=9677407
