Bug 474858 - dhclient only honors the first domain from the domain-name option
dhclient only honors the first domain from the domain-name option
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
:
: 477051 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-05 11:52 EST by Andrew McNabb
Modified: 2009-02-16 15:32 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-16 15:32:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
full dhcpd.conf (3.48 KB, text/plain)
2008-12-05 16:34 EST, Andrew McNabb
no flags Details
ifcfg-eth0 (228 bytes, text/plain)
2008-12-05 16:37 EST, Andrew McNabb
no flags Details

  None (edit)
Description Andrew McNabb 2008-12-05 11:52:29 EST
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 15:19:35 EST
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 16:34:25 EST
Created attachment 325913 [details]
full dhcpd.conf
Comment 3 Andrew McNabb 2008-12-05 16:37:20 EST
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 16:48:19 EST
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 18:16:37 EST
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-08 19:15:46 EST
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 04:56:26 EST
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 16:06:42 EST
*** Bug 477051 has been marked as a duplicate of this bug. ***

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