** Also affects: resolvconf (Nexenta Operating System)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1085756
Title:
/etc/ppp/ip-up.d/000resolvconf doesn't
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
** Changed in: resolvconf (Ubuntu)
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1085756
Title:
/etc/ppp/ip-up.d/000resolvconf doesn't check if envvar USEPE
Resolvconf 1.69 has been released.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1085756
Title:
/etc/ppp/ip-up.d/000resolvconf doesn't check if envvar USEPEERDNS is
set
To manage notifications ab
William wrote:
> I have implemented this with " [ "$USEPEERDNS" ] || exit 0"
> and found that the behavior is now appropriate.
Thanks, I'll go ahead and release Debian resolvconf 1.69 with that
change then.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is s
Thomas--
I have implemented this with " [ "$USEPEERDNS" ] || exit 0" and found
that the behavior is now appropriate.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1085756
Title:
/etc/ppp/ip-up.d/00
@William McCall: Can you please test with the current version of the ppp
package? If you put the following
[ "$USEPEERDNS" ] || exit 0
near the top of /etc/ppp/ip-up.d/000resolvconf does that suffice to
prevent the malfunction that you reported? Or does it have to be the
following?
[ "$U
I just stumbled across Debian bug report #367715 which has the following
title.
ppp: overwrites /etc/resolv.conf despite "usepeerdns" being unset
The report says about Debian ppp 2.4.4b1-1 that
pppd sets the environment variable USEPEERDNS regardless
of the option 'usepeerdns' being
I will fix this in Debian with
[ "$USEPEERDNS" ] || exit 0
for consistency with /etc/ppp/ip-up.d/usepeerdns. This fix will
appear in 1.69 which will be released well before the 13.04 merge-pulse.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
I had configured the peer without usepeerdns and the addresses were
negotiated during IPCP via ms-dns1 and ms-dns2 TLVs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1085756
Title:
/etc/ppp/ip-up.d
By the way, how did this bug manifest itself in practice?
Is it the case that you disabled usepeerdns mode and found that
nameserver addresses were still submitted to resolvconf? What were those
addresses and where to you think they came from?
--
You received this bug notification because you ar
I can see the ambiguity of that section, but the quoted section provided
in the report does not guarantee that the var is NOT set failing
"usepeerdns" and instead offers a second definition without reference to
"usepeerdns"
I've reached out to the ppp devs to get their thoughts on updating the
man
The relevant code in /etc/ppp/ip-up.d/usepeerdns (ppp version
2.4.5-5ubuntu2) is the following.
[ "$USEPEERDNS" ] || exit 0
That is, it only checks that the variable has some value, not that the
value is 1. Interesting.
Should 000resolvconf do the same, or the following?
[ "$USEPEE
First of all, thanks for the report.
> but manpage clearly indicates it will set this envvar regardless
I don't see where the manpage clearly states this. Its formulation is a
material implication:
The addresses supplied by the peer (if any) are passed
to the /etc/ppp/ip-up script in t
14 matches
Mail list logo
