RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 607766 - Check /etc/dhcp/dhclient-*.conf too
Summary: Check /etc/dhcp/dhclient-*.conf too
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: Alex Sersen
URL: http://www.redhat.com/archives/anacon...
Whiteboard:
Depends On:
Blocks: 607741 607759
TreeView+ depends on / blocked
 
Reported: 2010-06-24 18:27 UTC by Bill Nottingham
Modified: 2014-03-17 03:24 UTC (History)
13 users (show)

Fixed In Version: initscripts-9.03.10-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 607764
Environment:
Last Closed: 2010-11-10 20:40:31 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bill Nottingham 2010-06-24 18:27:13 UTC
+++ This bug was initially created as a clone of Bug #607764 +++

+++ This bug was initially created as a clone of Bug #468436 +++

Apparently introduced with NetworkManager. Anaconda no longer generates a default vendor class id in DHCP request for network installs.

Additionally, the dhcpclass= option appears to have no affect.

--- Additional comment from dcantrell on 2008-10-24 18:11:34 EDT ---

Since we're using NetworkManager in anaconda now, the proper way to get the dhcpclass= parameter to dhclient is to add a line to /etc/dhclient-DEVICE.conf and let NetworkManager pick that up.

I've patched anaconda to do just this.  This change will be in anaconda-11.4.1.51-1.  Once that appears in rawhide, can you test it out and if it works, and report findings here?

Thanks.

--- Additional comment from fedora-triage-list on 2008-11-25 23:12:36 EST ---


This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from curtis on 2008-11-28 20:54:49 EST ---

Verified fixed in f10. Now dhcpclass= works. And is *required* for legacy behavior of DHCP option 60.

--- Additional comment from curtis on 2009-10-11 22:30:45 EDT ---

Re-opening. This bug is back in Rawhide.

Even with dhcpclass=anaconda there is no more Option 60 in the lease request.

--- Additional comment from dcantrell on 2009-10-12 22:17:37 EDT ---

This is now a problem in NetworkManager.  When NM builds /var/run/nm-dhclient-ethX.conf, it's not copying over the settings from /etc/dhcp/dhclient-ethX.conf.  Here's a patch for NetworkManager:

diff --git a/src/dhcp-manager/nm-dhcp-dhclient.c b/src/dhcp-manager/nm-dhcp-dhcl
index ac7d9f5..c1f76c2 100644
--- a/src/dhcp-manager/nm-dhcp-dhclient.c
+++ b/src/dhcp-manager/nm-dhcp-dhclient.c
@@ -405,7 +405,9 @@ create_dhclient_config (NMDHCPDevice *device,
 
        g_return_val_if_fail (device != NULL, FALSE);
 
-#if defined(TARGET_SUSE)
+#if defined(TARGET_REDHAT)
+       orig = g_strdup (SYSCONFDIR "/dhcp/dhclient-%s.conf", device->iface);
+#elif defined(TARGET_SUSE)
        orig = g_strdup (SYSCONFDIR "/dhclient.conf");
 #elif defined(TARGET_DEBIAN)
        orig = g_strdup (SYSCONFDIR "/dhcp3/dhclient.conf");

This is my fault.  When I owned the dhcp package, I reorganized it to keep all dhclient and dhcpd configuration files in /etc/dhcp rather than /etc.  I did this to reduce clutter in /etc.  Problem is, I needed to teach NetworkManager about this new location on Fedora.

Dan, fix should be simple enough for NM.  In loader, I am writing out /etc/dhcp/dhclient-DEVICE.conf with a single line that is "send vendor-class-identifier ...;" based on what the user provides.  Actually, there's always a vendor class identifier even if the user doesn't override it.

--- Additional comment from curtis on 2009-10-13 12:45:17 EDT ---

It would be nice if we went back to legacy behavior with "anaconda" in the default. Then we'd only need dhcpclass= option to override and set something else.

--- Additional comment from dcantrell on 2009-10-13 15:58:23 EDT ---

(In reply to comment #6)
> It would be nice if we went back to legacy behavior with "anaconda" in the
> default. Then we'd only need dhcpclass= option to override and set something
> else.  

The interface in anaconda isn't changing.  You will still just pass dhcpclass= on the boot line to override the vendor class identifier used during installation.  How that works underneath the installer is where the bug is, hence reassigning it to anaconda.

--- Additional comment from fedora-triage-list on 2009-11-16 04:33:18 EST ---


This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from dcbw on 2010-06-15 12:10:28 EDT ---

David, dhclient has afaik always used /etc/dhclient-ethX.conf.  Does anaconda use a different location?

    # allow users to use generic '/etc/dhcp/dhclient.conf' (as documented in manpage!)
    # if per-device file doesn't exist or is empty
    if [ -s /etc/dhclient-${DEVICE}.conf ]; then
       DHCLIENTCONF="-cf /etc/dhclient-${DEVICE}.conf";
    else
       DHCLIENTCONF='';
    fi;

is there some reason it's now /etc/dhcp/dhclient-<iface>.conf?

--- Additional comment from dcbw on 2010-06-23 18:29:48 EDT ---

Ok, is there any reason why the loader uses /etc/dhcp/dhclient-<iface>.conf while the rest of anaconda uses /etc/dhclient-<iface>.conf?

loader/net.c:        /* remove dhclient-DEVICE.conf if we have it */
loader/net.c:        if (asprintf(&ofile, "/etc/dhcp/dhclient-%s.conf", devs[i]->device) == -1) {
loader/net.c:    if (asprintf(&ofile, "/etc/dhcp/dhclient-%s.conf", iface->device) == -1) {
network.py:        # /etc/dhclient-DEVICE.conf
network.py:            dhclientfile = os.path.join("/etc/dhclient-%s.conf" % devName)
network.py:            self._copyFileToPath(dhclientfile, instPath)
packages.py:                glob.glob('/etc/dhclient-*.conf')

I can make NM check both locations I guess...

--- Additional comment from dcantrell on 2010-06-24 13:13:46 EDT ---

(In reply to comment #10)
> Ok, is there any reason why the loader uses /etc/dhcp/dhclient-<iface>.conf
> while the rest of anaconda uses /etc/dhclient-<iface>.conf?

The dhcp package moved configuration files to /etc/dhcp at the end of 2008:

* Thu Dec 18 2008 David Cantrell <dcantrell> - 12:4.0.0-34
- Move /etc/dhclient.conf to /etc/dhcp/dhclient.conf
- Move /etc/dhcpd.conf to /etc/dhcp/dhcpd.conf

The incorrect references in anaconda need to be changed.

--- Additional comment from dcbw on 2010-06-24 14:11:48 EDT ---

And we  need to  make sure that initscripts are updated too.

Comment 3 RHEL Program Management 2010-06-24 18:52:58 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 6 releng-rhel@redhat.com 2010-11-10 20:40:31 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.