Bug 474858

Summary: dhclient only honors the first domain from the domain-name option
Product: [Fedora] Fedora Reporter: Andrew McNabb <amcnabb>
Component: anacondaAssignee: David Cantrell <dcantrell>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 10CC: anaconda-maint-list, dcantrell, edfriedmangvs, wwoods
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-16 20:32:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
full dhcpd.conf
none
ifcfg-eth0 none

Description Andrew McNabb 2008-12-05 16:52:29 UTC
Description of problem:

If the dhcp server provides a the domain-name option, dhclient only honors the first domain in the list.


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

dhclient-4.0.0-30.fc10.x86_64


How reproducible:

every time


Steps to Reproduce:
1. dhcpd.conf contains the line:
    option domain-name "aml.cs.byu.edu cs.byu.edu";
2. chkconfig NetworkManager off; chkconfig network on; (I have not tested with NetworkManager to see if it has the same behavior as the network init script)
3. start the network on the client
4. cat /etc/resolv.conf


Actual results:

On Fedora 10 machines, resolv.conf is:
; generated by /sbin/dhclient-script
search aml.cs.byu.edu
nameserver 10.0.0.10
nameserver 128.187.80.20
nameserver 128.187.80.21


Expected results:

On Fedora 9 machines on the same network, resolv.conf is:
; generated by /sbin/dhclient-script
search aml.cs.byu.edu cs.byu.edu
nameserver 10.0.0.10
nameserver 128.187.80.20
nameserver 128.187.80.21


Additional info:

Comment 1 David Cantrell 2008-12-05 20:19:35 UTC
Can you attach your entire dhcpd.conf file as well as the ifcfg-eth0 file for the client (or whatever the device file is).

Comment 2 Andrew McNabb 2008-12-05 21:34:25 UTC
Created attachment 325913 [details]
full dhcpd.conf

Comment 3 Andrew McNabb 2008-12-05 21:37:20 UTC
Created attachment 325914 [details]
ifcfg-eth0

As I started to add the ifcfg-eth0, I noted the following line, which is almost surely responsible:

SEARCH="aml.cs.byu.edu"

This must have been added automatically during installation.  I suppose this is the real bug.  If the installation uses DHCP, shouldn't the auto-generated ifcfg-eth0 leave out any parameters that were provided by dhcp?

Thanks.

Comment 4 David Cantrell 2008-12-05 21:48:19 UTC
Yep, the SEARCH line is doing it.  See this block from /sbin/dhclient-script (in the make_resolv_conf function):

        if [ -n "${SEARCH}" ]; then
            echo "search ${SEARCH}" >> $rscf
        else
            if [ -n "${new_domain_search}" ]; then
                echo "search ${new_domain_search//\\032/ }" >> ${rscf}
            elif [ -n "${new_domain_name}" ]; then
                echo "search ${new_domain_name//\\032/ }" >> ${rscf}
            fi
        fi

We take SEARCH if you have that in the ifcfg file, otherwise we take what the DHCP server gives us.

In anaconda, we are writing out the SEARCH line in the ifcfg file (line 585 of network.py):

        if self.domains != ['localdomain'] and self.domains:
            searchLine = string.joinfields(self.domains, ' ')
            f.write("SEARCH=\"%s\"\n" % (searchLine,))

Which will only ever contain the first domain name we see because that's all we pick up during installation.  We actually pull the domain off the FQDN during installation, so we will only ever see one.  It's probably best for us not to write the SEARCH line out in anaconda.

This bug will only affect you if you are using the network service instead of NetworkManager.

Reassigning to anaconda since that's where the fix should be.

Comment 5 David Cantrell 2008-12-08 23:16:37 UTC
Patch committed to anaconda git repository.  The next build of anaconda in rawhide will include this fix.  Please test when anaconda-11.4.1.59-1 appears in rawhide.

Comment 6 Andrew McNabb 2008-12-09 00:15:46 UTC
What's the best way to test it?  Will I have to roll my own initrd, or will there be a new one posted somewhere?  Thanks for the fix.

Comment 7 David Cantrell 2008-12-09 09:56:26 UTC
You will need to grab boot.iso (or the netboot images if you have a boot server) for rawhide when anaconda-11.4.1.59-1 appears in the tree, burn the image, boot it, and do a fresh install.  More information:

    https://fedoraproject.org/wiki/Releases/Rawhide

To check the version of anaconda in rawhide, use this command:

    repoquery --repoid=rawhide anaconda

The yum-utils package contains repoquery, if you don't have it installed.

Comment 8 Bill Nottingham 2009-01-12 21:06:42 UTC
*** Bug 477051 has been marked as a duplicate of this bug. ***