[Bug 1385010] Re: Unexpected behavior: make_resolv_conf is not undefined if /etc/resolv.conf is not a symlink

Thomas Hood 1385010 at bugs.launchpad.net
Mon Oct 27 19:43:43 UTC 2014


** Description changed:

  The resolvconf package comes with /etc/dhcp/dhclient-enter-
- hooks.d/resolvconf which, if /sbin/resolvconf is present, undefines
- make_resolv_conf() (previously defined by dhclient-script) and calls
- resolvconf.
+ hooks.d/resolvconf which, if /sbin/resolvconf is present, redefines the
+ make_resolv_conf function (previously defined by dhclient-script) to
+ send nameserver information to resolvconf instead of writing it directly
+ to /etc/resolv.conf.
  
- However, the hook checks if /etc/resolv.conf is a symlink even though
- /sbin/resolvconf already handles this.
+ However, the hook also checks if /etc/resolv.conf is a symlink. This is
+ problematic because if /etc/resolv.conf is not a symlink then the script
+ does not redefine make_resolv_conf() and so dhclient will overwrite
+ /etc/resolv.conf when it configures an interface, even though the
+ resolvconf package is installed.
  
- This is problematic because it never undefines the make_resolv_conf
- function which dhclient-script defines itself.
+ The behavior I would expect would be /etc/resolv.conf never changing if
+ resolvconf is installed and /etc/resolv.conf is not a symlink.
  
- For me, the expected behavior would be /etc/resolv.conf never changing
- if resolvconf is installed and /etc/resolv.conf is not a symlink.
+ Debian implements the behavior I would expect.
  
- At the very least, I think this behavior should be documented in the man
- pages for resolvconf.  Furthermore, debian does not implement this patch
- and it exists starting in 12.04 until current.
+ At the very least, I think that the different behavior in Ubuntu should
+ be documented in the man pages for resolvconf.
  
- As far as I can tell, there's absolutely no reason to check it twice if
- resolvconf already implements it.
+ As far as I can tell, there's no reason to check for /etc/resolv.conf
+ being a symlink when resolvconf itself already does that.
  
- It was introduced by: http://bazaar.launchpad.net/~ubuntu-
+ The patch was introduced by: http://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/trusty/resolvconf/trusty/revision/32/etc/dhcp/dhclient-
  enter-hooks.d/resolvconf

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to resolvconf in Ubuntu.
https://bugs.launchpad.net/bugs/1385010

Title:
  Unexpected behavior: make_resolv_conf is not undefined if
  /etc/resolv.conf is not a symlink

Status in “resolvconf” package in Ubuntu:
  New

Bug description:
  The resolvconf package comes with /etc/dhcp/dhclient-enter-
  hooks.d/resolvconf which, if /sbin/resolvconf is present, redefines
  the make_resolv_conf function (previously defined by dhclient-script)
  to send nameserver information to resolvconf instead of writing it
  directly to /etc/resolv.conf.

  However, the hook also checks if /etc/resolv.conf is a symlink. This
  is problematic because if /etc/resolv.conf is not a symlink then the
  script does not redefine make_resolv_conf() and so dhclient will
  overwrite /etc/resolv.conf when it configures an interface, even
  though the resolvconf package is installed.

  The behavior I would expect would be /etc/resolv.conf never changing
  if resolvconf is installed and /etc/resolv.conf is not a symlink.

  Debian implements the behavior I would expect.

  At the very least, I think that the different behavior in Ubuntu
  should be documented in the man pages for resolvconf.

  As far as I can tell, there's no reason to check for /etc/resolv.conf
  being a symlink when resolvconf itself already does that.

  The patch was introduced by: http://bazaar.launchpad.net/~ubuntu-
  branches/ubuntu/trusty/resolvconf/trusty/revision/32/etc/dhcp
  /dhclient-enter-hooks.d/resolvconf

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1385010/+subscriptions



More information about the foundations-bugs mailing list