You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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"



  • No labels