[omniORB] Can't connect to server when launched from Linux?!?

[John D. Heintz]

Thanks so much Sai-Lai,

That fixed our problem.  We were running on a Debian box.  I don't know 
if I added that configuration or if it installed that way.

John

Sai-Lai Lo wrote:

> This is another frequently encountered problem with recent redhat
> installations. I don't know if other installations do the same. IMO, it is
> not how one should configure a networked machine.
> 
> Redhat always put something like this in your /etc/hosts:
> 
> 127.0.0.1    foo localhost.localdomain localhost
> 
> This is ok if yours is a home machine with just a dialup interface.
> But on a networked machine, if you have that entry and one do a name to
> address lookup for "foo", what you get is 127.0.0.1. In other words, one
> cannot find out what the real IP address of your host is.
> 
> By default, omniORB always try to use the IP address, instead of the
> hostname in the IORs it gives out. So it uses host to address lookup.
> And it gets 127.0.0.1. Being a local loopback network interface, the
> address obviously cannot work on other machines.
> 
> The solution is either:
> 
> 1. Remove "foo" from the /etc/hosts, (PREFERRED)
> 2. Start your server with this ORB option:
>       $./eg2_impl -ORBpoa_iiop_name_port "foo"
> 
> Regards,
> 
> Sai-Lai
> 
> 
> 
> 
>>>>>> John D Heintz writes:
>>>>> 
> 
>> Hello,every one:
>> Our system setup is pretty simple and common.
> 
> 
>> We are launching an "omniNames -logdir <somewhere>" and our Python
>> server script with
>> "python launch.py -ORBInitRef NameService=corbaname::localhost".
> 
> 
>> This script creates a servant and object reference, gets a ref to the
>> NameService, and binds (actually rebinds) a string name to the object
>> reference.
> 
> 
>> A client test script uses "corbaname::hostname#ServerName" to connect.
> 
> 
>> This works perfectly for localhost client and server, it works for
>> windows based server and any client, it does not work for linux based
>> server and any non-localhost clients!
> 
> 
>> We have also checked our hosts.allow and hosts.deny files, ultimately
>> trying "ALL : ALL" in hosts.allow just to be sure.
> 
> 
>> Here is the trace from the failing client connection, followed by the
>> start where the successful client connections pick up and continue.



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | jheintz@isogen.com

w w w . d a t a c h a n n e l . c o m