dhcp3-client: dhclient-script only sets resolv.conf when both new_domain_name and new_domain_name_servers exist

[Debian Bug Importer]

Automatically imported from Debian bug report #159529 http://bugs.debian.org/159529

[Tim Connors (tconnors)]

I just installed dhcp-client, and set it up to work on the network here.
It overwrote my resolv.conf file, which I thought was an extremeyl rude
thing to do. I search the Debian bugs, and realised that maybe
dhcp3-client fixes this up. But no - your post points me to the fact that
make_resolv_conf still, unbelievably, overwrite the resolv.conf file,
without asking the user, and without making a backup.

Your proposed patch would worsen this situation, by outright removing the
file straight away!

I want my resolv.conf to have a predefined search path, no matter what
network I am on, and I want it to look at 127.0.0.1 as a nameserver. If
instalation of dhcp{,3}-client is going to overwrite my settings, the
least it can do is warn me at install time - I wasn't exactly expecting to
lose my settings!

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/

Recursive: Adj. See Recursive.

[Matt Zimmerman (mdz)]

On Fri, Sep 20, 2002 at 01:11:48AM +1000, Tim Connors wrote:

> I just installed dhcp-client, and set it up to work on the network here.
> It overwrote my resolv.conf file, which I thought was an extremeyl rude
> thing to do. I search the Debian bugs, and realised that maybe
> dhcp3-client fixes this up. But no - your post points me to the fact that
> make_resolv_conf still, unbelievably, overwrite the resolv.conf file,
> without asking the user, and without making a backup.

This is expected behaviour if your DHCP server supplies DNS server
addresses. A DHCP client is expected to configure the system to use those
DNS servers by default.

> I want my resolv.conf to have a predefined search path, no matter what
> network I am on, and I want it to look at 127.0.0.1 as a nameserver. If
> instalation of dhcp{,3}-client is going to overwrite my settings, the
> least it can do is warn me at install time - I wasn't exactly expecting to
> lose my settings!

Add a line:

prepend domain-name-servers 127.0.0.1;

to /etc/dhcp3/dhclient.conf (or /etc/dhclient.conf for dhcp 2.x).

--
 - mdz

[Thomas Hood (jdthood-yahoo)]

T.C.: I just saw your comment in #159529:
> I want my resolv.conf to have a predefined search path
> no matter what network I am on, and I want it to look at
> 127.0.0.1 as a nameserver. If instalation of dhcp{,3}-client
> is going to overwrite my settings, the least it can do is warn
> me at install time - I wasn't exactly expecting to lose my
> settings!

resolv.conf management is a problem in debian. The resolvconf
package is the proposed answer. Instead of editing /etc/resolv.conf
themselves, interface configuration programs will call /sbin/resolvconf
to update /etc/resolv.conf . /sbin/resolvconf can then make use of all
the information available to write a sensible /etc/resolv.conf. Support
is there for running named as a cacheing nameserver. See the README
file downloadable from:
    http://alioth.debian.org/projects/update-resolv/
for more information. You can also download a tarball from which
you can easily build a deb.

Right now I am adding hook scripts to resolvconf (for v. 0.8) so that
dhcp3-client will do the right thing when resolvconf is installed.
The "right thing" is to refrain from writing to resolv.conf directly
and to send the information to resolvconf instead. Resolvconf will
then write the /var/run/resolvconf/resolv.conf file based on all
the information it has available. The user can then symlink
/etc/resolv.conf to /var/run/resolvconf/resolv.conf . With resolvconf,
the user has ultimate control over /etc/resolv.conf because
1) he can change the symlink
2) he can customize /etc/init.d/resolvconf which is what creates
   /var/run/resolvconf/resolv.conf .

I would welcome any comments you might wish to make about resolvconf.
--
Thomas Hood

[Thomas Hood (jdthood-yahoo)]

merge 171797 159529
thanks

Both of these reports report the fact that no /etc/resolv.conf file
is written if no domain name is returned.

Please follow up at #159529 .

[Michael Graham (oobermick-btinternet)]

Why hasn't this bug been fixed yet? (as of dhcp3_3.0+3.0.1rc11)

The original poster has given a perfectly good fix, although I prefer:

make_resolv_conf() {
   if [ "x$new_domain_name_servers" != x ] || ["x$new_domain_name" != x
] ; then
     rm -f /etc/resolv.conf
     if [ "x$new_domain_name" != x ]; then
       echo search $new_domain_name >/etc/resolv.conf
     fi
     if [ "x$new_domain_name_servers" != x ]; then
       for nameserver in $new_domain_name_servers; do
         echo nameserver $nameserver >>/etc/resolv.conf
       done
     fi
     chmod 644 /etc/resolv.conf
   fi
}

Since it makes new_domain_name_servers and new_domain_name independent.

Anyway, back to the point. Is there a reason why this bug has not been
fixed?

[Switch (switch-ono)]

Package: dhcp3-client
Version: 3.0+3.0.1rc11-5
Severity: normal
Followup-For: Bug #159529

dhclient-script does not check if /etc/resolv.conf exists.
If /etc/resolv.conf exists, and is lost for any reason, the script won't
re-create it until domain name or dns's change.

There are two solutions to this problem:
1.- Always re-create /etc/resolv.conf (Fast and bad solution)
2.- Enable a modifier to allow users to create or not /etc/resolv.conf.
This could be enablede by default.

Commenting "if ... " and "fi" lines on dhclient-script makes it work for
me.

Greetings.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux wanda 2.4.22-ac4 #1 sáb oct 11 14:34:04 CEST 2003 i686
Locale: LANG=es, LC_CTYPE=es (ignored: LC_ALL set to es_ES@euro)

Versions of packages dhcp3-client depends on:
ii debconf 1.3.20 Debian configuration management sy
ii debianutils 2.6 Miscellaneous utilities specific t
ii dhcp3-common 3.0+3.0.1rc11-5 Common files used by all the dhcp3
ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an

-- no debconf information

[Christopher Martin (christopher-martin)]

Hmmm, for the second time now I ran into this problem. This time it
was with a Linksys home router (the first time was with a Netgear
wireless setup). Interestingly, the person who called upon me for
help hadn't had this problem with the old v2 dhcp client, but had
upgraded to v3 with their new 2.6 kernel.

Since this can be an extremely irritating problem, indeed possibly a
showstopper for someone who doesn't know where to look for the
work-around, and solutions have been posted, I'd like to request
again that this bug be fixed as soon as possible.

Thanks very much,
Christopher Martin

[Paul Kremer (paulkremer)]

Package: dhcp3-client
Version: 3.0+3.0.1rc13-1
Severity: normal
Followup-For: Bug #159529

Hi,
this is a very old issues that should be fairly easy to correct by
making the if a boolean OR relation and by keeping old nameservers if no
new ones were provided. At least, that should work for 99% of the
people, at least more than it currently does.

The argument stating that the DHCP-server has to respond with a domain
name, is a bit invalid, as there are many proprietary hardware routers
(e.g. DSL modems...) out there which don't do that.

here is my patch (requires 'sed' to be installed, don't know if that is
a problem):

--- dhclient-script.orig 2004-04-22 21:56:56.000000000 +0200
+++ dhclient-script 2004-04-22 22:16:42.000000000 +0200
@@ -7,15 +7,19 @@
 # The alias handling in here probably still sucks. -mdz

 make_resolv_conf() {
- if [ -n "$new_domain_name" -a -n "$new_domain_name_servers" ]; then
+ if [ -n "$new_domain_name" -o -n "$new_domain_name_servers" ]; then
         local new_resolv_conf=/etc/resolv.conf.dhclient-new
         rm -f $new_resolv_conf
         if [ -n "$new_domain_name" ]; then
             echo search $new_domain_name >>$new_resolv_conf
         fi
- for nameserver in $new_domain_name_servers; do
- echo nameserver $nameserver >>$new_resolv_conf
- done
+ if [ -n "$new_domain_name_servers" ]; then
+ for nameserver in $new_domain_name_servers; do
+ echo nameserver $nameserver >>$new_resolv_conf
+ done
+ else # keep 'old' nameservers
+ sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p /etc/resolv.conf >>$new_resolv_conf
+ fi
         chown --reference=/etc/resolv.conf $new_resolv_conf
         chmod --reference=/etc/resolv.conf $new_resolv_conf
         mv $new_resolv_conf /etc/resolv.conf

-- System Information:
Debian Release: sarge
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.24-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

Versions of packages dhcp3-client depends on:
ii debconf 1.4.22 Debian configuration management sy
ii debianutils 2.8.1 Miscellaneous utilities specific t
ii dhcp3-common 3.0+3.0.1rc13-1 Common files used by all the dhcp3
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an

-- no debconf information

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #159529 http://bugs.debian.org/159529

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 3 Sep 2002 16:30:56 -0700 (PDT)
From: Chun-Chung Chen <[e-mail]>
To: <email address hidden>
Subject: dhcp3-client: dhclient-script only sets resolv.conf when both
 new_domain_name and new_domain_name_servers exist

Package: dhcp3-client
Version: 3.0+3.0.1rc9-5
Severity: normal

When "new_domain_name_servers" exists but "new_domain_name" doesn't,
dhclient-script doesn't setup the new nameserver entries in "resolv.conf".
This prevents the system to work properly on networks that don't provide
"new_domain_name" on DHCP requests.

Proposed change to make_resolv_conf():

make_resolv_conf() {
  if [ "x$new_domain_name_servers" != x ]; then
    rm -f /etc/resolv.conf
    if [ "x$new_domain_name" != x ]; then
      echo search $new_domain_name >/etc/resolv.conf
    fi
    for nameserver in $new_domain_name_servers; do
      echo nameserver $nameserver >>/etc/resolv.conf
    done
    chmod 644 /etc/resolv.conf
  fi
}

--
 Chun-Chung Chen

-- System Information
Debian Release: testing/unstable
Kernel Version: Linux air 2.4.19 #4 Sat Aug 3 20:37:45 PDT 2002 i686 unknown unknown GNU/Linux

Versions of the packages dhcp3-client depends on:
ii debconf 1.1.28 Debian configuration management system
ii debianutils 1.16.3 Miscellaneous utilities specific to Debian.
ii dhcp3-common 3.0+3.0.1rc9-5 Common files used by all the dhcp3* packages
ii libc6 2.2.5-14 GNU C Library: Shared libraries and Timezone

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 20 Sep 2002 01:11:48 +1000 (EST)
From: Tim Connors <email address hidden>
To: <email address hidden>
Subject: dhcp3-client: dhclient-script only sets resolv.conf when both
 new_domain_name and new_domain_name_servers exist

I just installed dhcp-client, and set it up to work on the network here.
It overwrote my resolv.conf file, which I thought was an extremeyl rude
thing to do. I search the Debian bugs, and realised that maybe
dhcp3-client fixes this up. But no - your post points me to the fact that
make_resolv_conf still, unbelievably, overwrite the resolv.conf file,
without asking the user, and without making a backup.

Your proposed patch would worsen this situation, by outright removing the
file straight away!

I want my resolv.conf to have a predefined search path, no matter what
network I am on, and I want it to look at 127.0.0.1 as a nameserver. If
instalation of dhcp{,3}-client is going to overwrite my settings, the
least it can do is warn me at install time - I wasn't exactly expecting to
lose my settings!

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/

Recursive: Adj. See Recursive.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 19 Sep 2002 11:23:39 -0400
From: Matt Zimmerman <email address hidden>
To: Tim Connors <email address hidden>, <email address hidden>
Subject: Re: Bug#159529: dhcp3-client: dhclient-script only sets resolv.conf when both
 new_domain_name and new_domain_name_servers exist

On Fri, Sep 20, 2002 at 01:11:48AM +1000, Tim Connors wrote:

> I just installed dhcp-client, and set it up to work on the network here.
> It overwrote my resolv.conf file, which I thought was an extremeyl rude
> thing to do. I search the Debian bugs, and realised that maybe
> dhcp3-client fixes this up. But no - your post points me to the fact that
> make_resolv_conf still, unbelievably, overwrite the resolv.conf file,
> without asking the user, and without making a backup.

This is expected behaviour if your DHCP server supplies DNS server
addresses. A DHCP client is expected to configure the system to use those
DNS servers by default.

> I want my resolv.conf to have a predefined search path, no matter what
> network I am on, and I want it to look at 127.0.0.1 as a nameserver. If
> instalation of dhcp{,3}-client is going to overwrite my settings, the
> least it can do is warn me at install time - I wasn't exactly expecting to
> lose my settings!

Add a line:

prepend domain-name-servers 127.0.0.1;

to /etc/dhcp3/dhclient.conf (or /etc/dhclient.conf for dhcp 2.x).

--
 - mdz

[Debian Bug Importer (debzilla)]

Message-Id: <1054978802.15847.274.camel@thanatos>
Date: 07 Jun 2003 11:40:04 +0200
From: Thomas Hood <email address hidden>
To: Tim Connors <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: dhcp3-client stomping on resolv.conf

T.C.: I just saw your comment in #159529:
> I want my resolv.conf to have a predefined search path
> no matter what network I am on, and I want it to look at
> 127.0.0.1 as a nameserver. If instalation of dhcp{,3}-client
> is going to overwrite my settings, the least it can do is warn
> me at install time - I wasn't exactly expecting to lose my
> settings!

resolv.conf management is a problem in debian. The resolvconf
package is the proposed answer. Instead of editing /etc/resolv.conf
themselves, interface configuration programs will call /sbin/resolvconf
to update /etc/resolv.conf . /sbin/resolvconf can then make use of all
the information available to write a sensible /etc/resolv.conf. Support
is there for running named as a cacheing nameserver. See the README
file downloadable from:
    http://alioth.debian.org/projects/update-resolv/
for more information. You can also download a tarball from which
you can easily build a deb.

Right now I am adding hook scripts to resolvconf (for v. 0.8) so that
dhcp3-client will do the right thing when resolvconf is installed.
The "right thing" is to refrain from writing to resolv.conf directly
and to send the information to resolvconf instead. Resolvconf will
then write the /var/run/resolvconf/resolv.conf file based on all
the information it has available. The user can then symlink
/etc/resolv.conf to /var/run/resolvconf/resolv.conf . With resolvconf,
the user has ultimate control over /etc/resolv.conf because
1) he can change the symlink
2) he can customize /etc/init.d/resolvconf which is what creates
   /var/run/resolvconf/resolv.conf .

I would welcome any comments you might wish to make about resolvconf.
--
Thomas Hood

[Debian Bug Importer (debzilla)]

Message-Id: <1054979090.15855.279.camel@thanatos>
Date: 07 Jun 2003 11:44:51 +0200
From: Thomas Hood <email address hidden>
To: <email address hidden>, <email address hidden>
Subject: merge 171797 159529

merge 171797 159529
thanks

Both of these reports report the fact that no /etc/resolv.conf file
is written if no domain name is returned.

Please follow up at #159529 .

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 20 Sep 2003 13:52:30 +0100
From: Michael Graham <email address hidden>
To: <email address hidden>
Subject: dhcp3-client: dhclient-script only sets resolv.conf when both new_domain_name
 and new_domain_name_servers exist

--------------enigF4D55694864FF34E33219754
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Why hasn't this bug been fixed yet? (as of dhcp3_3.0+3.0.1rc11)

The original poster has given a perfectly good fix, although I prefer:

make_resolv_conf() {
   if [ "x$new_domain_name_servers" != x ] || ["x$new_domain_name" != x
] ; then
     rm -f /etc/resolv.conf
     if [ "x$new_domain_name" != x ]; then
       echo search $new_domain_name >/etc/resolv.conf
     fi
     if [ "x$new_domain_name_servers" != x ]; then
       for nameserver in $new_domain_name_servers; do
         echo nameserver $nameserver >>/etc/resolv.conf
       done
     fi
     chmod 644 /etc/resolv.conf
   fi
}

Since it makes new_domain_name_servers and new_domain_name independent.

Anyway, back to the point. Is there a reason why this bug has not been
fixed?

--------------enigF4D55694864FF34E33219754
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQE/bE2YoD6zcgMLTPgRAkGQAJ9IhWVjd686OagmXYAgcb0tgr3/6ACfUAZ7
ncms0OVIozaBUOhNRmyi4g8=
=KPgM
-----END PGP SIGNATURE-----

--------------enigF4D55694864FF34E33219754--

[Debian Bug Importer (debzilla)]

Message-Id: <E1AJDdS-0002oS-00@wanda>
Date: Mon, 10 Nov 2003 16:07:22 +0100
From: Switch <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: dhcp3-client: It should also chech if /etc/resolv.conf exists

Package: dhcp3-client
Version: 3.0+3.0.1rc11-5
Severity: normal
Followup-For: Bug #159529

dhclient-script does not check if /etc/resolv.conf exists.
If /etc/resolv.conf exists, and is lost for any reason, the script won't
re-create it until domain name or dns's change.

There are two solutions to this problem:
1.- Always re-create /etc/resolv.conf (Fast and bad solution)
2.- Enable a modifier to allow users to create or not /etc/resolv.conf.
This could be enablede by default.

Commenting "if ... " and "fi" lines on dhclient-script makes it work for
me.

Greetings.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux wanda 2.4.22-ac4 #1 s�oct 11 14:34:04 CEST 2003 i686
Locale: LANG=es, LC_CTYPE=es (ignored: LC_ALL set to es_ES@euro)

Versions of packages dhcp3-client depends on:
ii debconf 1.3.20 Debian configuration management sy
ii debianutils 2.6 Miscellaneous utilities specific t
ii dhcp3-common 3.0+3.0.1rc11-5 Common files used by all the dhcp3
ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Sun, 7 Mar 2004 14:47:58 -0500
From: Christopher Martin <email address hidden>
To: <email address hidden>
Subject: Yet again...

Hmmm, for the second time now I ran into this problem. This time it
was with a Linksys home router (the first time was with a Netgear
wireless setup). Interestingly, the person who called upon me for
help hadn't had this problem with the old v2 dhcp client, but had
upgraded to v3 with their new 2.6 kernel.

Since this can be an extremely irritating problem, indeed possibly a
showstopper for someone who doesn't know where to look for the
work-around, and solutions have been posted, I'd like to request
again that this bug be fixed as soon as possible.

Thanks very much,
Christopher Martin

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 22 Apr 2004 22:21:51 +0200
From: Paul Kremer <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: dhcp3-client: suggested patch

Package: dhcp3-client
Version: 3.0+3.0.1rc13-1
Severity: normal
Followup-For: Bug #159529

Hi,
this is a very old issues that should be fairly easy to correct by
making the if a boolean OR relation and by keeping old nameservers if no
new ones were provided. At least, that should work for 99% of the
people, at least more than it currently does.

The argument stating that the DHCP-server has to respond with a domain
name, is a bit invalid, as there are many proprietary hardware routers
(e.g. DSL modems...) out there which don't do that.

here is my patch (requires 'sed' to be installed, don't know if that is
a problem):

--- dhclient-script.orig 2004-04-22 21:56:56.000000000 +0200
+++ dhclient-script 2004-04-22 22:16:42.000000000 +0200
@@ -7,15 +7,19 @@
 # The alias handling in here probably still sucks. -mdz

 make_resolv_conf() {
- if [ -n "$new_domain_name" -a -n "$new_domain_name_servers" ]; then
+ if [ -n "$new_domain_name" -o -n "$new_domain_name_servers" ]; then
         local new_resolv_conf=/etc/resolv.conf.dhclient-new
         rm -f $new_resolv_conf
         if [ -n "$new_domain_name" ]; then
             echo search $new_domain_name >>$new_resolv_conf
         fi
- for nameserver in $new_domain_name_servers; do
- echo nameserver $nameserver >>$new_resolv_conf
- done
+ if [ -n "$new_domain_name_servers" ]; then
+ for nameserver in $new_domain_name_servers; do
+ echo nameserver $nameserver >>$new_resolv_conf
+ done
+ else # keep 'old' nameservers
+ sed -n /^\w*[Nn][Aa][Mm][Ee][Ss][Ee][Rr][Vv][Ee][Rr]/p /etc/resolv.conf >>$new_resolv_conf
+ fi
         chown --reference=/etc/resolv.conf $new_resolv_conf
         chmod --reference=/etc/resolv.conf $new_resolv_conf
         mv $new_resolv_conf /etc/resolv.conf

-- System Information:
Debian Release: sarge
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.24-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8

Versions of packages dhcp3-client depends on:
ii debconf 1.4.22 Debian configuration management sy
ii debianutils 2.8.1 Miscellaneous utilities specific t
ii dhcp3-common 3.0+3.0.1rc13-1 Common files used by all the dhcp3
ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an

-- no debconf information

[Matt Zimmerman (mdz)]

*** Bug 8630 has been marked as a duplicate of this bug. ***

[Matt Zimmerman (mdz)]

This seems to be becoming a FAQ, and should be fixable with minimal risk, so
we'll see about fixing it for Warty

[Daniel Stone (daniels)]

Some thoughts I elaborated on IRC, but haven't heard back about:
  * When writing out file, write out '## This file written by dhcp3-client', or
the traditional '## OMGDEBCONFBONG' markers.
  * Don't molest file if it's present, sans these markers.
  * If it (the file) is present, only molest it if markers are present -- either
replacing or appending, depending on whether we run with the former or latter
marker option.
  * Should make pon do something similar.

Matt, thoughts? I'm happy to claim this one.

[Matt Zimmerman (mdz)]

The thing is, in order for DHCP to do what the user expects, it does need to
clobber the file. resolvconf or something like it is probably the right
long-term solution, but for Warty, let's only fix the immediate bug. It should
DTRT if only one of the domain and nameservers is specified by the DHCP server.
Something like the supplied patch, but without the excessive sed action

[Daniel Stone (daniels)]

Yah, grep was invented for a reason. :) Will take care of this one tonight.

[Daniel Stone (daniels)]

Fixed in 3.0+3.0.1rc14-1ubuntu1, just uploaded.

[Matt Zimmerman (mdz)]

reassign 287693 dhcp3-client
merge 287693 159529
thanks

> Bug#159529: dhcp3-client: dhclient-script only sets resolv.conf when both new_domain_name and new_domain_name_servers exist
> Bug#287693: resolv.conf not written if server sends no domain name
> Mismatch - only Bugs in same state can be merged:
> Values for `package' don't match:
> #159529 has `dhcp3-client';
> #287693 has `dhcp3'
>
> > thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
>
> Debian bug tracking system administrator
> (administrator, Debian Bugs database)

--
 - mdz

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 29 Dec 2004 11:05:08 -0800
From: Matt Zimmerman <email address hidden>
To: <email address hidden>
Subject: Re: Processed: Re: Bug#287693: resolv.conf not written if server sends no domain name

reassign 287693 dhcp3-client
merge 287693 159529
thanks

> Bug#159529: dhcp3-client: dhclient-script only sets resolv.conf when both new_domain_name and new_domain_name_servers exist
> Bug#287693: resolv.conf not written if server sends no domain name
> Mismatch - only Bugs in same state can be merged:
> Values for `package' don't match:
> #159529 has `dhcp3-client';
> #287693 has `dhcp3'
>
> > thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
>
> Debian bug tracking system administrator
> (administrator, Debian Bugs database)

--
 - mdz

[Andrew Pollock (apollock)]

Hi Eloy,

Any chance this bug can be resolved (no pun intended) before the release of
sarge? I've personally been bitten by it.

regards

Andrew

--
linux.conf.au 2005 - http://linux.conf.au/ - Birthplace of Tux
April 18th to 23rd - http://linux.conf.au/ - LINUX
Canberra, Australia - http://linux.conf.au/ - Get bitten!

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 18 Feb 2005 11:30:37 +1100
From: Andrew Pollock <email address hidden>
To: <email address hidden>
Subject: Status update?

--5LiOUhUlsRX0HDkW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Eloy,

Any chance this bug can be resolved (no pun intended) before the release of
sarge? I've personally been bitten by it.

regards

Andrew

--=20
linux.conf.au 2005 - http://linux.conf.au/ - Birthplace of Tux
April 18th to 23rd - http://linux.conf.au/ - LINUX
Canberra, Australia - http://linux.conf.au/ - Get bitten!

--5LiOUhUlsRX0HDkW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCFTctIblXXKfZFgIRAvT9AJ9I5s8tPDDITifwM9bNt2nfqPhUuwCgiTKd
y5ZfyOB2rqwTsenSQcVztyc=
=xBLu
-----END PGP SIGNATURE-----

--5LiOUhUlsRX0HDkW--

[Andrew Pollock (apollock)]

Source: dhcp3
Source-Version: 3.0.1-2

We believe that the bug you reported is fixed in the latest version of
dhcp3, which is due to be installed in the Debian FTP archive:

dhcp3-client-udeb_3.0.1-2_i386.udeb
  to pool/main/d/dhcp3/dhcp3-client-udeb_3.0.1-2_i386.udeb
dhcp3-client_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-client_3.0.1-2_i386.deb
dhcp3-common_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-common_3.0.1-2_i386.deb
dhcp3-dev_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-dev_3.0.1-2_i386.deb
dhcp3-relay_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-relay_3.0.1-2_i386.deb
dhcp3-server_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-server_3.0.1-2_i386.deb
dhcp3_3.0.1-2.diff.gz
  to pool/main/d/dhcp3/dhcp3_3.0.1-2.diff.gz
dhcp3_3.0.1-2.dsc
  to pool/main/d/dhcp3/dhcp3_3.0.1-2.dsc

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andrew Pollock <email address hidden> (supplier of updated dhcp3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 28 Feb 2005 22:24:47 +1100
Source: dhcp3
Binary: dhcp3-client-udeb dhcp3-common dhcp3-relay dhcp3-dev dhcp3-client dhcp3-server
Architecture: source i386
Version: 3.0.1-2
Distribution: unstable
Urgency: high
Maintainer: Eloy A. Paris <email address hidden>
Changed-By: Andrew Pollock <email address hidden>
Description:
 dhcp3-client - DHCP Client
 dhcp3-client-udeb - DHCP Client for debian-installer (udeb)
 dhcp3-common - Common files used by all the dhcp3* packages
 dhcp3-dev - API for accessing and modifying the DHCP server and client state
 dhcp3-relay - DHCP Relay
 dhcp3-server - DHCP server for automatic IP address assignment
Closes: 159529 171797 269014 286011 287693
Changes:
 dhcp3 (3.0.1-2) unstable; urgency=high
 .
   * The "Let's fix those really old and annoying bugs" release
   * urgency=high because I'd like this to make sarge before any potential
     freezing of udebs for d-i rc3 (but I've probably missed the boat anyway)
   * debian/control: Adding myself to Uploaders:
   * debian/dhclient-script: Remove useless checks for kernel versions that
     this doesn't even work with, and causes errors on systems that mount /usr
     via NFS (closes: #269014, #286011)
   * debian/dhclient-script: Applied patch from Paul Kremer to update
     /etc/resolv.conf if only a nameserver is provided (closes: #159529,
     #171797, #287693)
   * debian/control: rephrased description synopsis for dhcp3-common
Files:
 dcaa440a13d977228d98f6e7a44229b4 743 net optional dhcp3_3.0.1-2.dsc
 bfcd4837ffd533f1a8c9cef0322d273a 36840 net optional dhcp3_3.0.1-2.diff.gz
 e90e19e14398e99064fb6566bc7fe388 509428 net optional dhcp3-server_3.0.1-2_i386.deb
 e4c446853587795cc8e0bc99c8b0b4ab 174186 net optional dhcp3-common_3.0.1-2_i386...

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 03 Mar 2005 05:02:21 -0500
From: Andrew Pollock <email address hidden>
To: <email address hidden>
Subject: Bug#159529: fixed in dhcp3 3.0.1-2

Source: dhcp3
Source-Version: 3.0.1-2

We believe that the bug you reported is fixed in the latest version of
dhcp3, which is due to be installed in the Debian FTP archive:

dhcp3-client-udeb_3.0.1-2_i386.udeb
  to pool/main/d/dhcp3/dhcp3-client-udeb_3.0.1-2_i386.udeb
dhcp3-client_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-client_3.0.1-2_i386.deb
dhcp3-common_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-common_3.0.1-2_i386.deb
dhcp3-dev_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-dev_3.0.1-2_i386.deb
dhcp3-relay_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-relay_3.0.1-2_i386.deb
dhcp3-server_3.0.1-2_i386.deb
  to pool/main/d/dhcp3/dhcp3-server_3.0.1-2_i386.deb
dhcp3_3.0.1-2.diff.gz
  to pool/main/d/dhcp3/dhcp3_3.0.1-2.diff.gz
dhcp3_3.0.1-2.dsc
  to pool/main/d/dhcp3/dhcp3_3.0.1-2.dsc

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Andrew Pollock <email address hidden> (supplier of updated dhcp3 package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 28 Feb 2005 22:24:47 +1100
Source: dhcp3
Binary: dhcp3-client-udeb dhcp3-common dhcp3-relay dhcp3-dev dhcp3-client dhcp3-server
Architecture: source i386
Version: 3.0.1-2
Distribution: unstable
Urgency: high
Maintainer: Eloy A. Paris <email address hidden>
Changed-By: Andrew Pollock <email address hidden>
Description:
 dhcp3-client - DHCP Client
 dhcp3-client-udeb - DHCP Client for debian-installer (udeb)
 dhcp3-common - Common files used by all the dhcp3* packages
 dhcp3-dev - API for accessing and modifying the DHCP server and client state
 dhcp3-relay - DHCP Relay
 dhcp3-server - DHCP server for automatic IP address assignment
Closes: 159529 171797 269014 286011 287693
Changes:
 dhcp3 (3.0.1-2) unstable; urgency=high
 .
   * The "Let's fix those really old and annoying bugs" release
   * urgency=high because I'd like this to make sarge before any potential
     freezing of udebs for d-i rc3 (but I've probably missed the boat anyway)
   * debian/control: Adding myself to Uploaders:
   * debian/dhclient-script: Remove useless checks for kernel versions that
     this doesn't even work with, and causes errors on systems that mount /usr
     via NFS (closes: #269014, #286011)
   * debian/dhclient-script: Applied patch from Paul Kremer to update
     /etc/resolv.conf if only a nameserver is provided (closes: #159529,
     #171797, #287693)
   * debian/control: rephrased description synopsis for dhcp3-common
Files:
 dcaa440a13d977228d98f6e7a44229b4 743 net optional dhcp3_3.0.1-2.dsc
 bfcd4837ffd533f1a8c9cef0322...

[Andrew Pollock (apollock)]

reopen 159529
tags 159529 + sarge
reopen 171797
tags 171797 + sarge
reopen 287693
tags 287693 + sarge
reopen 269014
tags 269014 + sarge
reopen 286011
tags 286011 + sarge
thanks

This bug has been fixed in unstable, but unless there is another delay with
releasing sarge, will probably remain in sarge, as the dhcp3 package has
been prevented from entering sarge due to its interaction with d-i, and the
fact that d-i rc3 has been frozen.

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 18 Mar 2005 16:23:22 +1100
From: Andrew Pollock <email address hidden>
To: <email address hidden>
Subject: reopening and tagging as sarge-specific

--e5bfZ/T2xnjpUIbw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

reopen 159529
tags 159529 + sarge
reopen 171797
tags 171797 + sarge
reopen 287693
tags 287693 + sarge
reopen 269014
tags 269014 + sarge
reopen 286011
tags 286011 + sarge
thanks

This bug has been fixed in unstable, but unless there is another delay with
releasing sarge, will probably remain in sarge, as the dhcp3 package has
been prevented from entering sarge due to its interaction with d-i, and the
fact that d-i rc3 has been frozen.

--e5bfZ/T2xnjpUIbw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCOmXKIblXXKfZFgIRArq1AJ9KdVLBbQRMK868RitE2DNXPKJ3rQCfZ/VU
XN+HRBh2tIFccmOm76vFNzA=
=UtVa
-----END PGP SIGNATURE-----

--e5bfZ/T2xnjpUIbw--

[Andrew Pollock (apollock)]

This bug was fixed in 3.0.1-2, but reopened when it didn't look like this
version was going to enter Sarge.

As it happens, this version did make it into Sarge, so all is now right with
the world.

regards

Andrew