Description of problem:
It appears that an update to initscripts from RHEL 6.7 to 6.8 changed the behavior of dhclient.  Previously if the hostname was not set, the -H <hostname> option was not included in the dhclient args, but now it looks like it always (??) is, which can result in "localhost" getting sent to the DHCP server as a hostname.   Not sure if this is the desired behavior.  

It is possible this is a result of how our provisioning environment works.  What we do is clone a VM that does not have a hostname defined, then rely on a DHCP reservation (based on MAC address) to set the proper IP address.  Then when the VM comes up, it does a reverse DNS lookup and the hostname ends up getting set as expected.  With the update to RHEL 6.8, this still works, *however* I'm guessing that the logic that sets the hostname from the IP address is happening *after* the dhclient args are determined, because even though the hostname is set as expected, I still see the dhclient args as "dhclient -H localhost ... " AND I end up with the DNS PTR record of "localhost" pointing back to the IP address.  So then if I reboot the VM again, it now comes up as "localhost" due to the PTR record change.  (Yes I know that's a little loosy goosy allowing DNS records to get overwritten but that's how our DNS infra is now)


Version-Release number of selected component (if applicable):
initscripts-9.03.53-1

How reproducible:

100%

Steps to Reproduce:
1. Setup RHEL install with no hostname set in /etc/sysconfig/network (also make sure there is no DHCP_HOSTNAME defined in /etc/sysconfig/network-scripts/ifcfg-ethX)
2. Ensure it gets a known IP address that reverse maps to a valid hostname in DNS
3. Boot RHEL, the hostname is set properly from the reverse lookup, BUT the dhclient args are still "dhclient -H localhost  ..." and the PTR record has changed to "localhost"
4. Reboot again, now the hostname is "localhost" instead of the expected name from the DNS reverse lookup

Actual results:

dhclient sends "localhost" as its name to the DHCP server

Expected results:

dhclient should either send the hostname it used from the reverse lookup -or- not send the '-H <name>' argument at all.

Additional info:

Looks like this line in network-scripts/ifup-eth is responsible for the change:

    DHCLIENTARGS="${DHCLIENTARGS} -H ${DHCP_HOSTNAME:-${HOSTNAME%%.*}} ${ONESHOT} -q ${DHCLIENTCONF} -lf /var/lib/dhclient/dhclient-${DEVICE}.leases -pf /var/run/dhclient-${DEVICE}.pid"