Malformed 'search' entry in /etc/resolv.conf on network install

Bug #973794 reported by Daniel Manrique on 2012-04-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
casper (Ubuntu)
High
Stéphane Graber

Bug Description

Package: casper 1.312, also this is present in lp:ubuntu/casper as of rev 1010.

Steps to reproduce:
- Do a netboot of the Ubuntu desktop CD on a network that hands out configuration via DHCP.
- Switch to a console once the installer has booted (ctrl-alt-f1)
- Look in /etc/resolv.conf.

What I expected to happen: valid entries in /etc/resolv.conf.

What happened instead: the search entry in /etc/resolv.conf has two values and a stray single-quote at the end, which looks wrong and may cause problems while installing some other packages.

More details about this problem:

In a testing environment, we do network installs using the daily and Precise milestone images. On these, due to a "manual" entry created by 23networking in /etc/interfaces, NetworkManager is disabled.

23networking parses the /tmp/net-${DEVICE}.conf file and takes the DNSDOMAIN value to fill up both the domain and search entries in resolv.conf, as well as the IPV4DNS{0,1} entries for the DNS servers. It ignores the rest of the values in the conf file. The ipconfig utility, which generates /tmp/net-${DEVICE}.conf files based on DHCP information, adds single quotes around the values. Files look like this:

DEVICE='eth0'
IPV4ADDR='10.153.104.249'
IPV4BROADCAST='10.153.104.255'
IPV4NETMASK='255.255.255.0'
IPV4GATEWAY='10.153.104.1'
IPV4DNS0='10.153.104.60'
IPV4DNS1='0.0.0.0'
HOSTNAME=''
DNSDOMAIN='canonical.com'
NISDOMAIN=''
ROOTSERVER='10.153.104.60'
ROOTPATH=''
filename='/precise-desktop-i386/pxelinux.0'

23networking tries to strip away the quotes using regexes, but doesn't do so correctly, and thus generates a file in /run/resolvconf/interface/casper that looks like this:

# /etc/resolv.conf
# Autogenerated by casper
search canonical.com
domain canonical.com'
nameserver 10.153.104.60

This is then processed by resolvconf (changes introduced in casper rev 990), and ends up generating a /etc/resolv.conf file that looks like this:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.153.104.60
search canonical.com canonical.com'

This bug is not usually apparent because most installations use NetworkManager, which invokes resolvconf with DHCP information, which it doesn't quote, unlike ipconfig.

This is similar to bugs 809885 and 709364, which generated invalid resolv.conf due to mishandling of the quotes around domain names. This new failure may have been exposed/triggered when Ubuntu started using resolvconf by default / on the Live CD environment.

A possible solution for this is to correctly strip away the single quotes by some means.

Bug 809885 has a patch based on a suggestion by Colin Watson, involving sourcing the /tmp/net-${DEVICE}.conf file and then simply using the resulting environment variables; this is the intended use of that file, as described in that bug. The patch may need some work to apply cleanly to the latest version of casper.

Related branches

Changed in casper (Ubuntu):
importance: Undecided → High
Stéphane Graber (stgraber) wrote :

I'll have a look, the bug is pretty clear but completely changing the handling doesn't seem appropriate at this point. I'd rather we fix the sed call.

Changed in casper (Ubuntu):
assignee: nobody → Stéphane Graber (stgraber)
Daniel Manrique (roadmr) wrote :

Hi Stéphane,

Yes, I understand that the change may be risky at this point.

Still, maybe this can be kept in the radar for 12.10, so the "correct" way of doing it eventually makes it in and this bug stops reappearing? (this is the third time it surfaces! hehehe)

Thanks for looking at this!

Stéphane Graber (stgraber) wrote :

sourcing the output of ipconfig brings its own set of problems, I had to deal with that in LTSP and it wasn't pleasant.
I'm planning on landing a fix for this bug in 12.04, but likely as a change on how we parse the output of it.

Longer term, we probably should move to udhcpc like LTSP did which brings better control of the dhcp client and gives you a dhcp client that actually renews its leases ;)

Stéphane Graber (stgraber) wrote :

The gstreamer pipeline similar to ubiquity's seems to work:
gst-launch-0.10 v4l2src ! video/x-raw-rgb,width=640,height=480 ! ffmpegcolorspace ! xvimagesink

So that'd indicate a bug in camerabin/camerabin2

Stéphane Graber (stgraber) wrote :

oh, interesting, please ignore that previous comment, it was obviously meant for another bug :)
That's the issue when all your tabs are LP bugs...

I'm now looking at this bug again, hoping to have a fix later today.

Stéphane Graber (stgraber) wrote :

I just fixed the sed call and reworked the resolv.conf generation a little for it to always generate clean resolv.conf

I tried with your ipconfig, some variations of it and mine (including multiple domain/search) and always got the expected result.

Changed in casper (Ubuntu):
status: New → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package casper - 1.315

---------------
casper (1.315) precise; urgency=low

  * Fix sed call for rc_domain (LP: #973794)
  * Ensure resulting resolv.conf is always clean and valid.
 -- Stephane Graber <email address hidden> Wed, 18 Apr 2012 11:33:49 +0200

Changed in casper (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers