Problem

Problems connecting to ACS servers on a remote machine: bad /etc/hosts

Solution

If you can work without problems on an ACS host, but you cannot run clients connecting to it from another host(for example a remote objexp cannot contact the Manager on your host), this is probably due to the configuration of the Linux or ZLegacy/ACS.VxWorks network services.

The IP address or the hostname (depending on some ORB configuration switches) are part of the IOR of CORBA objects, since IP resolution is needed to communicate with the object.

All IORs generated in ACS applications and tools use the IP address. However, external CORBA applications might use the hostname instead of the IP address.

In any case, to properly communicate between hosts it is necessary to be able to resolve a PC's own hostname with the real network IP address to be used for communication.

This means that it is necessary to have the /etc/hosts file in the following form:

  127.0.0.1 localhost.localdomain localhost
  134.171.12.202 te1.hq.eso.org te1

Notice that:

  1. The entry for localhost does not contain the hostname but only the localhost specification
  2. The entries for each host have the fully qualified form first and the short form after.

In particular we have seen two different kind of problems:

  • The RH installation procedure often creates (depending on the sequence of installation steps) an /etc/hosts file with the loopback entry looking like:
    127.0.0.1   <hostname> localhost

That is, the entry contains the explicit host name.
This works on a machine working in isolation, but it prevents CORBA objects from being properly contacted by remote hosts since their IIOP would contain 127.0.0.1 instead of the correct host IP address. CORBA would then try to contact the same machine via the loopback and not go back to the remote host.

  • On the VxWorks side we are not using the DNS but the local hosts table, filled in with the hostAdd command.
    It is therefore necessary that (if references to services are specified with hostname instead of the IP address)
    the same hostname is consistently used both in the host table and in the references.
    In the following example, long format is used both for the hostAdd and the MANAGER reference:
   ### bootScript entries: ###
   # maciManager runs on midnight-vml
   hostAdd "midnight-vml.aoc.nrao.edu","146.88.10.124"

   ### userScript entries: ###
   putenv "MANAGER_REFERENCE=corbaloc::midnight-vml.aoc.nrao.edu:3000/Manager"

Machines with multiple network interfaces and/or VPN

Notice that when a machine has multiple network interfaces, the first entry in /etc/hosts will normally be used. With JacORB you can easily tell the ORB to use a different mapping by editing the .jacorb_properties file and set the OAIAddr property to the desired IP.

This is useful when accessing the network through a VPN tunnel. Set the OAIAddr to the VPN IP and ACS Java clients and applications should be able to work fine through the VPN tunnel.



Possible side effects of manipulating /etc/hosts

On Fedora Core 2, the /etc/init.d/sendmail wouldn't start if /etc/hosts was edited as described above (e.g., if the $HOST was set to the actual IP). If sendmail doesn't start, mail can not be sent from the computer using the mail tool. System tools that rely on mail probably don't work either.



-- DavidFugate - 09 Aug 2004

Related articles

Related articles appear here based on the labels you select. Click to edit the macro and add or change labels.



Related issues