HPUX and ntp issues

[Rick Garland]

Hi all:

We have a number of HPUX and Linux systems throughout our enterprise. HPUX versions range from 11.0 to 11.31 and Linux ranges from RHEL4 to RHEL6. Various hardware types as well. The issue I am seeing with the HPUX appears to be version and hardware independent.

The issue I see is when an employee connects to the business via VPN. That system is assigned an IP address from DHCP pool - the hostname remains the same.

Some people have not changed their hostname on the Linux or OS X system that they are using, it remains as 'localhost'. The result is that when these systems connect via VPN the localhost entry in DNS is replaced with the IP that was just assigned to the VPN connection. (The DNS server is a WIN server)

I have been watching, looking & anticipating problems from the systems not correctly resolving localhost, but the only issue I have found thus far is with ntp. And it is only with the HPUX systems, the Linux systems are unaffected, or appear to be unaffected.

The ntp is configured with multiple servers and multiple peers. I have checks of ntp occur throughout the day via nagios and the checks are looking at localhost.  (check_ntp -H localhost ...)

This check has been kind of nice in that it also tells us when the HPUX systems can no longer resolve localhost.

I have verified /etc/hosts having the 127.0.0.1 localhost loopback entry as the 1st uncommented line. I have checked /etc/nsswitch.conf and files is listed 1st.  (On 1 HPUX server, the nsswitch.conf lists only files - no DNS. But it still complains about the localhost resolution.) Essentially, the configs are the same on Linux and HPUX.

What am I missing? Why are the Linux systems not reporting the same problem? As mentioned, it is only our HPUX servers.

Any help is greatly appreciated.

Many thanks!

[Matti_Kurkela]

I guess the changing "localhost" DNS entry is the entry of "localhost.your.domain". This is a recommended entry on all DNS domains, but at least on my BIND nameserver there is also a standard entry for "localhost." - with a dot at the end, or in other words, "localhost" explicitly as a top level name. Due to the structure of DNS, these are two separate DNS records, and changing one does not necessarily mean the other is changed.

If the changing DNS entry is "localhost." <with a dot>, then the dynamic DNS update permissions on the DNS server are very, very wrong: even though every DNS server should have a master zone for "localhost." <with a dot>, that zone should never allow dynamic updates.

The applications that are successfully resolving localhost even while the "localhost.your.domain" entry is not pointing to 127.0.0.1 might be explicitly looking for "localhost." <with a dot> instead of just "localhost" <domain unqualified>. Alternatively, the check_ntp process might explicitly append the local DNS domain name to unqualified name (in this case "localhost") to make the name fully qualified before making the query.

Another factor is that on HP-UX (at least on versions 11.23 and older; not sure about 11.31) the files /etc/hosts and /etc/nsswitch.conf are read by each process as it starts up, and then never again. A long-lived process may be using an old configuration as it existed at the time it was started up, not the current configuration you see when you inspect the system.

And as a sanity check, on the HP-UX host that has nsswitch.conf specified as "files" only - please make sure that /etc/hosts, /etc/nsswitch.conf and /etc/resolv.conf are readable by everyone. If a process cannot read the file when starting up, it will fall back to libc's factory default name resolution settings. I've seen somewhat similar hostname/username lookup oddities before, and in those cases, the cause has been accidental (or intentional but misguided) file ownership/permission changes in /etc.

As to the difference between HP-UX and Linux: RHEL installer almost forces you to set the hostname in FQDN form, which ensures that the system also knows the correct local DNS domain suffix as a side effect. As HP-UX has historically had a strict limit on hostname length, the HP-UX hostname is usually configured in unqualified form. Configuring the domain suffix (as a "domain" or "search" line in /etc/resolv.conf, even if only "hosts: files" setting is used in nsswitch.conf) is not absolutely required, and I've seen cases where this has not been done. This would lead the DNS resolver to behave differently on HP-UX vs. Linux unless the HP-UX sysadmin is careful.

[Rick Garland]

MK

Many thanks