Bug 1350602
| Summary: | Change to initscripts causes dhclient to always send hostname to server via -H, even if it was not set | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Steve Muskiewicz <steve.muskiewicz> | |
| Component: | initscripts | Assignee: | David Kaspar // Dee'Kej <deekej> | |
| Status: | CLOSED ERRATA | QA Contact: | Jan Ščotka <jscotka> | |
| Severity: | urgent | Docs Contact: | Clayton Spicer <cspicer> | |
| Priority: | urgent | |||
| Version: | 6.8 | CC: | cspicer, deekej, jscotka, mganisin | |
| Target Milestone: | rc | Keywords: | Regression, TestBlocker | |
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | initscripts-9.03.57-1 | Doc Type: | Bug Fix | |
| Doc Text: |
The "dhclient" command no longer incorrectly uses `localhost` when `hostname` is not set
The "dhclient" command incorrectly sent `localhost` to the DHCP server as the host name when the `hostname` variable was not set. This has been fixed, and "dhclient" no longer sends an incorrect host name in these situations.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1398686 (view as bug list) | Environment: | ||
| Last Closed: | 2017-03-21 11:53:35 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1356047, 1385492, 1398686, 1410429 | |||
Yeah we should change the behavior, maybe we can hook it with need_hostname and don't send the hostname if it return true. devel_Ack for 6.9 Fix proposed for review: https://github.com/fedora-sysv/initscripts/pull/35 Pull-request merged: https://github.com/fedora-sysv/initscripts/pull/38 *** Bug 1396940 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2017-0786.html |
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"