[Bug 1085756] Re: /etc/ppp/ip-up.d/000resolvconf doesn't check if envvar USEPEERDNS is set

[Launchpad Bug Tracker]

This bug was fixed in the package resolvconf - 1.69ubuntu1

---------------
resolvconf (1.69ubuntu1) raring; urgency=low

  * Merge from Debian. Remaining changes: (LP: #1085756)
    - Make /etc/resolv.conf a relative symlink so that it works when
      setting up chroots.
    - Instead of throwing an error that aborts the upgrade when
      /etc/resolv.conf is immutable, pop a debconf error message to let the
      user know what's happening, then clear the immutable flag and continue
      with the installation.  LP: #989585.
    - debian/config, debian/templates, debian/postinst: if we don't know that
      /etc/resolv.conf was being dynamically managed before install (in at
      least some cases), link the original contents of /etc/resolv.conf to
      /etc/resolvconf/resolv.conf.d/tail so that any statically configured
      nameservers aren't lost.  LP: #923685.
    - Use an upstart job instead of sysvinit script.
    - Pre-Depend on the /run-providing version of initscripts instead of
      depending, so that the preinst does the right thing when creating
      /run/resolvconf/interfaces instead of getting clobbered later by a bind
      mount on initscripts upgrade.  LP: #922491.
    - Completely drop the standard_run_subdirs_created helper function from
      debian/postinst, since it serves no purpose here.
    - postinst: Set resolvconf/linkify-resolvconf to false after initial
      conversion, ensuring upgrades won't convert /etc/resolv.conf to
      a symlink if the user manually converted it back to plain text.
      (LP: #922677)
    - Move the #DEBHELPER# token in debian/postinst to after the resolv.conf
      symlink is set, so the init script can actually start (since it expects
      /etc/resolv.conf to be a symlink).
    - Eliminate all references to /etc/resolvconf/run.  This should all be done
      directly in /run, there is no reason to support making any of this
      configurable with a symlink since we already have a versioned dependency
      on the version of initscripts that introduces the /run transition.
    - Also remove debian/triggers to avoid needlessly calling resolvconf's
      postinst. (LP: #931335)
  * Fix previous mis-merge of debian/postinst as well as the few other comments
    from the bug report. (LP: #1085862)

resolvconf (1.69) unstable; urgency=low

  * [276fc24] Bump Standards-Version; no changes required
  * [6982da6] README: Name packages that clobber /etc/resolv.conf
  * [4cb082a] README: Update
  * [044e9a3] ip-up.d/000resolvconf: Do nothing if USEPEERDNS not set
  * [d988a9e] if-up.d/000resolvconf: Silently (for now) accept option
    name 'dns-nameserver' as a synonym for 'dns-nameservers' in
    anticipation of support in ifupdown (no sooner than wheezy+1) for
    duplicate options in a stanza, after which it will make sense to
    specify multiple nameserver addresses on equally many
    "dns-nameserver" lines
  * [e0db2cb] Deal with obsolete conf files (Closes: #687507, #681623)
 -- Stephane Graber <stgraber at ubuntu.com>   Fri, 18 Jan 2013 11:52:10 -0500

** Changed in: resolvconf (Ubuntu)
       Status: Fix Committed => Fix Released

-- 
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/1085756

Title:
  /etc/ppp/ip-up.d/000resolvconf doesn't check if envvar USEPEERDNS is
  set

Status in “resolvconf” package in Ubuntu:
  Fix Released

Bug description:
  Description:
  When running pppd without "usepeerdns", resolvconf's scripts will take the DNS information from the IPCP.
  In the script, it just checks to see if the DNS envvars are set and ignores whether or not we actually want to use it.
  In the PPP provided script 0000dns, it checks the USEPEERDNS envvar and prevents this from happening.

  Per PPP manpage:
  "
  Scripts
  [..]
  DNS1
  If the peer supplies DNS server addresses, this variable is set to the first DNS server address supplied.
  DNS2
  If the peer supplies DNS server addresses, this variable is set to the second DNS server address supplied.
  "

  The script makes an assumption that DNS1 and DNS2 are only set if
  "usepeerdns" is enabled, but manpage clearly indicates it will set
  this envvar regardless of "usepeerdns" if IPCP receives them.

  Conditions:
  "usepeerdns" is not configured and IPCP provides DNS servers

  Workaround:
  chmod -x /etc/ppp/ip-up.d/000resolvconf 

  
  Affected versions:
  Tested in precise but verified scripts the same in more recent releases.

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