The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: djbdns (Ubuntu Precise)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: network-manager (Ubuntu Precise)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The Precise Pangolin has reached end of life, so this bug will not be
fixed for that release
** Changed in: dnsmasq (Ubuntu Precise)
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The network-manager package still ships /etc/dnsmasq.d/network-manager
with "bind-interfaces" in it
and that breaks the TFTP server of dnsmasq
and sometimes even the DNS server of dnsmasq.
"bind-dynamic" is a little better, but too unreliable to be used in
production.
So this bug is still not
What is the status of this as at 16.04?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about
Now that we can use bind-dynamic, I have nothing against setting that
value instead of bind-interfaces, if it indeed solves the latest issues
that were reported.
However, I'd really appreciate if separate bugs could be opened rather
than reopening this bug, it would make each individual issue
Mathieu, I reopened this bug because it was never resolved... not just for the
TFTP issue.
Please see my #143 comment.
If you want more feedback tell me what to send, but DNS never worked properly
for me when dnsmasq and nm-dnsmasq are both running.
--
You received this bug notification
Now that we can use bind-dynamic, I have nothing against setting that
value instead of bind-interfaces, if it indeed solves the latest issues
that were reported.
However, I'd really appreciate if separate bugs could be opened rather
than reopening this bug, it would make each individual issue
Mathieu, I reopened this bug because it was never resolved... not just for the
TFTP issue.
Please see my #143 comment.
If you want more feedback tell me what to send, but DNS never worked properly
for me when dnsmasq and nm-dnsmasq are both running.
--
You received this bug notification
Thomas, yup, TFTP appears to be working fine with bind-dynamic.
I'll test if re-enabling dns=dnsmasq in
/etc/NetworkManager/NetworkManager.conf along with bind-dynamic allows
dnsmasq co-exist with nm-dnsmasq, and report back.
Thanks!
--
You received this bug notification because you are a
Through Raring and Saucy, my two modifications to the given LTSP-PNP
setup have been:
In /etc/dnsmasq.d/network-manager replace the bind-interfaces line
with a bind-dynamic line.
Edit /etc/dnsmasq.d/ltsp-server-dnsmasq.conf: comment out the port=0
line
And those two mods still work for me in
I just tried Trusty (dnsmasq 2.68-1), and network manager ships
/etc/dnsmasq.d/network-manager with:
bind-interfaces
So now dnsmasq only binds 127.0.0.1 for its tftp service:
udp 0 0 127.0.0.1:69 0.0.0.0:* 954/dnsmasq
udp6 0 0 ::1:69 :::* 954/dnsmasq
...and of course
Thomas, yup, TFTP appears to be working fine with bind-dynamic.
I'll test if re-enabling dns=dnsmasq in
/etc/NetworkManager/NetworkManager.conf along with bind-dynamic allows
dnsmasq co-exist with nm-dnsmasq, and report back.
Thanks!
--
You received this bug notification because you are a
Through Raring and Saucy, my two modifications to the given LTSP-PNP
setup have been:
In /etc/dnsmasq.d/network-manager replace the bind-interfaces line
with a bind-dynamic line.
Edit /etc/dnsmasq.d/ltsp-server-dnsmasq.conf: comment out the port=0
line
And those two mods still work for me in
The fix for this issue caused another regression, dnsmasq now doesn't
function correctly as a tftp server either.
I just tried Trusty (dnsmasq 2.68-1), and network manager ships
/etc/dnsmasq.d/network-manager with:
bind-interfaces
So now dnsmasq only binds 127.0.0.1 for its tftp service:
udp
Or better yet, ltsp-server-standalone could Conflict: network-manager-
local-resolver so that all LTSP sysadmins that use dnsmasq don't bother
searching for a solution and manually editing configuration files...
--
You received this bug notification because you are a member of Ubuntu
Server
The fix for this issue caused another regression, dnsmasq now doesn't
function correctly as a tftp server either.
I just tried Trusty (dnsmasq 2.68-1), and network manager ships
/etc/dnsmasq.d/network-manager with:
bind-interfaces
So now dnsmasq only binds 127.0.0.1 for its tftp service:
udp
Or better yet, ltsp-server-standalone could Conflict: network-manager-
local-resolver so that all LTSP sysadmins that use dnsmasq don't bother
searching for a solution and manually editing configuration files...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
I'm still having problems with this on 14.04.
After the default installation, I installed dnsmasq and DNS stopped
working until system restart.
Now it's only working for a few seconds after each network-manager
restart!
If I comment out
#dns=dnsmasq
in NetworkManager.conf, then everything is
I'm still having problems with this on 14.04.
After the default installation, I installed dnsmasq and DNS stopped
working until system restart.
Now it's only working for a few seconds after each network-manager
restart!
If I comment out
#dns=dnsmasq
in NetworkManager.conf, then everything is
something that conflicts: the internal resolver of the samba4 packages
Please file another report against samba4 describing the conflict with
nm-dnsmasq.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
I would if I considered it a bug. (I didn't fully describe the current
state of samba4, because I figured it was irrelevant: You can alter the
interfaces it binds to, but not for *only* the dns resolver -- so
currently, if you want samba4 listening on the wildcard address you'll
need the dns
If libnss-nm-dns would make it easier to introduce per-user caching
and/or if it improved security then those would be important benefits.
Currently nm-dnsmasq has caching disabled because of concerns about
cache poisoning and information leakage.
Btw, named immediately notices because of the
/etc/network/if-{up,down}.d/bind9 scripts that trigger
rndc reconfig when an interface goes up or down.
Ah, yes. There is also a hook at /etc/ppp/ip-{up,down}.d/bind9.
But named also notices immediately when I bring up an with
NetworkManager. Any
Whoa. When an interface is brought up with NM the scripts in
/etc/network/if-up.d/ somehow get run (how?) but when an interface is
downed with NM, the scripts in /etc/network/if-down.d/ don't get run
(inconsistent!).
--
You received this bug notification because you are a member of Ubuntu
Server
Aha. /etc/NetworkManager/dispatcher.d/01ifupdown run-partses
/etc/network/if-up.d/ on up and /etc/network/if-post-down.d/ on down
(which is actually post-down in ifupdown terminology). And there is
no /etc/network/if-post-down.d/bind9 so named doesn't get nudged when NM
takes down an interface.
something that conflicts: the internal resolver of the samba4 packages
Please file another report against samba4 describing the conflict with
nm-dnsmasq.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I would if I considered it a bug. (I didn't fully describe the current
state of samba4, because I figured it was irrelevant: You can alter the
interfaces it binds to, but not for *only* the dns resolver -- so
currently, if you want samba4 listening on the wildcard address you'll
need the dns
If libnss-nm-dns would make it easier to introduce per-user caching
and/or if it improved security then those would be important benefits.
Currently nm-dnsmasq has caching disabled because of concerns about
cache poisoning and information leakage.
Btw, named immediately notices because of the
/etc/network/if-{up,down}.d/bind9 scripts that trigger
rndc reconfig when an interface goes up or down.
Ah, yes. There is also a hook at /etc/ppp/ip-{up,down}.d/bind9.
But named also notices immediately when I bring up an with
NetworkManager. Any
Whoa. When an interface is brought up with NM the scripts in
/etc/network/if-up.d/ somehow get run (how?) but when an interface is
downed with NM, the scripts in /etc/network/if-down.d/ don't get run
(inconsistent!).
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Aha. /etc/NetworkManager/dispatcher.d/01ifupdown run-partses
/etc/network/if-up.d/ on up and /etc/network/if-post-down.d/ on down
(which is actually post-down in ifupdown terminology). And there is
no /etc/network/if-post-down.d/bind9 so named doesn't get nudged when NM
takes down an interface.
The O'Reilly book _DNS and BIND_ says:
[QUOTE]
10.4.3.2 Interface interval
We've said already that BIND, by default, listens on all of a host's
network interfaces. BIND 8 is actually smart enough to notice when a
network interface on the host it's running on comes up or goes down. To
do this, it
In response to #131 and #134 by Thomas:
I would argue that will it conflict with anything that exists? is the
wrong question, here. Certainly it will conflict in the future, and
removing the users ability to run a DNS service on the wildcard address
is suboptimal at best, even if they don't
The O'Reilly book _DNS and BIND_ says:
[QUOTE]
10.4.3.2 Interface interval
We've said already that BIND, by default, listens on all of a host's
network interfaces. BIND 8 is actually smart enough to notice when a
network interface on the host it's running on comes up or goes down. To
do this, it
In response to #131 and #134 by Thomas:
I would argue that will it conflict with anything that exists? is the
wrong question, here. Certainly it will conflict in the future, and
removing the users ability to run a DNS service on the wildcard address
is suboptimal at best, even if they don't
You may be right that developing a new nm-dns module would be easier
than trying to enhance the existing dns module to support nonstandard
ports.
But the more immediately relevant comparison is the comparison between
the current solution and any solution involving a new or an enhanced NSS
module.
To my own surprise I haven't seen any complaints related to the switch
from 127.0.0.1 to 127.0.1.1, even though I have been following AskUbuntu
and ubuntuforums.
It's possible that a large portion of Ubuntu users that are using dnsmasq as a
DNS server, only use LTS releases, so complains might
Btw please don't backport the current solution to Precise
In comment #110 MTL said that backporting the fix to Precise *is*
planned.
Quantal includes dnsmasq 2.63 which has the new bind-dynamic option.
In bind-dynamic mode dnsmasq works as it does in bind-interfaces mode
but also updates its
I wrote in comment #131:
What benefits would the nm-dns module or the enhanced
dns module give us relative to what we have now? One is:
the ability to run nm-dnsmasq on another port, freeing up
port 53 for BIND named listening on ALL:53. What else?
I just installed bind9 and was surprised to
You may be right that developing a new nm-dns module would be easier
than trying to enhance the existing dns module to support nonstandard
ports.
But the more immediately relevant comparison is the comparison between
the current solution and any solution involving a new or an enhanced NSS
module.
To my own surprise I haven't seen any complaints related to the switch
from 127.0.0.1 to 127.0.1.1, even though I have been following AskUbuntu
and ubuntuforums.
It's possible that a large portion of Ubuntu users that are using dnsmasq as a
DNS server, only use LTS releases, so complains might
Btw please don't backport the current solution to Precise
In comment #110 MTL said that backporting the fix to Precise *is*
planned.
Quantal includes dnsmasq 2.63 which has the new bind-dynamic option.
In bind-dynamic mode dnsmasq works as it does in bind-interfaces mode
but also updates its
I wrote in comment #131:
What benefits would the nm-dns module or the enhanced
dns module give us relative to what we have now? One is:
the ability to run nm-dnsmasq on another port, freeing up
port 53 for BIND named listening on ALL:53. What else?
I just installed bind9 and was surprised to
Belated reply to Robin Battey's #116.
My question in #115 was about alternative resolver libraries, not about
DNS resolver libraries. There are libraries that play the same role as
the whole glibc resolver. Generally these alternative resolver libraries
include DNS resolvers and read
You've got the basic idea. The nsswitch.conf file is where Name Service
services are configured, and hosts is one of them. DNS is *one* way
to look up hosts, but so is files (/etc/hosts) and mdns4 (avahi).
Anything that extends how names are translated to addresses should,
imnho, be done through
alan_a...@yahoo.com
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this
Belated reply to Robin Battey's #116.
My question in #115 was about alternative resolver libraries, not about
DNS resolver libraries. There are libraries that play the same role as
the whole glibc resolver. Generally these alternative resolver libraries
include DNS resolvers and read
You've got the basic idea. The nsswitch.conf file is where Name Service
services are configured, and hosts is one of them. DNS is *one* way
to look up hosts, but so is files (/etc/hosts) and mdns4 (avahi).
Anything that extends how names are translated to addresses should,
imnho, be done through
alan_a...@yahoo.com
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage notifications about this bug go to:
I thought I was done with this kind of issue, but I may be back for
more.
It turns out that the only LTSP client that boots normally is the one
that I was doing all of the above troubleshooting on. Others that I
have tried in my little 2-PC setup all stop at a blank/black screen
after
That the last syslog entries are made by ntpd doesn't necessarily mean
that the machine is hanging because of ntpd. It could be hanging at the
next step, for example.
Bug #999725 reports that ntp doesn't work properly when it is started
before NIS, which is not to be confused with DNS. Probably
Agreed. And I had hoped that I could eliminate ntpd as the source of
the problem by using a simple switch in the LTSP configuration to turn
it off for the client. Unfortunately that does not seem to be effective
in disabling ntpd. Troubleshooting that elsewhere .
--
You received this bug
I thought I was done with this kind of issue, but I may be back for
more.
It turns out that the only LTSP client that boots normally is the one
that I was doing all of the above troubleshooting on. Others that I
have tried in my little 2-PC setup all stop at a blank/black screen
after
That the last syslog entries are made by ntpd doesn't necessarily mean
that the machine is hanging because of ntpd. It could be hanging at the
next step, for example.
Bug #999725 reports that ntp doesn't work properly when it is started
before NIS, which is not to be confused with DNS. Probably
Agreed. And I had hoped that I could eliminate ntpd as the source of
the problem by using a simple switch in the LTSP configuration to turn
it off for the client. Unfortunately that does not seem to be effective
in disabling ntpd. Troubleshooting that elsewhere .
--
You received this bug
RE Thomas Hood's #120: That is very interesting, though I admit it is
near the outer limits of my current understanding.
To address the only questions above:
The problem is that the LTSP client, after successfully getting
DHCP assignments, fails to download the pxelinux boot image.
It reports
the LTSP server defers to the router handling DHCP.
OK, I get it.
I don't understand what you said about standalone dnsmasq
conflicting with network-manager's instance of dnsmasq
when /etc/dnsmasq.d/network-manager is removed.
When /etc/dnsmasq.d/network-manager is present, standalone
Thanks for the explanation of how removal of /etc/dnsmasq.d/network-
manager sets up a conflict between standalone dnsmasq and NM-dnsmasq.
(But also see my surprising observation below.)
Should this conflict be manifesting itself somehow?
Everything seems to be working right now.
Well, I am
Question: Why did everything work on your machine when standalone
dnsmasq wasn't in bind-interfaces mode but /etc/NM/NM.conf contained
dns=dnsmasq?
Hypothesis: Standalone dnsmasq started first; network-manager second. NM
tried to start NM-dnsmasq but this failed because of the address
conflict
RE Thomas Hood's #120: That is very interesting, though I admit it is
near the outer limits of my current understanding.
To address the only questions above:
The problem is that the LTSP client, after successfully getting
DHCP assignments, fails to download the pxelinux boot image.
It reports
the LTSP server defers to the router handling DHCP.
OK, I get it.
I don't understand what you said about standalone dnsmasq
conflicting with network-manager's instance of dnsmasq
when /etc/dnsmasq.d/network-manager is removed.
When /etc/dnsmasq.d/network-manager is present, standalone
Thanks for the explanation of how removal of /etc/dnsmasq.d/network-
manager sets up a conflict between standalone dnsmasq and NM-dnsmasq.
(But also see my surprising observation below.)
Should this conflict be manifesting itself somehow?
Everything seems to be working right now.
Well, I am
Question: Why did everything work on your machine when standalone
dnsmasq wasn't in bind-interfaces mode but /etc/NM/NM.conf contained
dns=dnsmasq?
Hypothesis: Standalone dnsmasq started first; network-manager second. NM
tried to start NM-dnsmasq but this failed because of the address
conflict
the current default installation wherein network-manager starts
an instance of dnsmasq to act as a DHCP, DNS and TFTP server.
NetworkManager starts an instance of dnsmasq to act only as a non-
caching DNS nameserver forwarder. This instance listens only on the
loopback interface 127.0.1.1.
If
the current default installation wherein network-manager starts
an instance of dnsmasq to act as a DHCP, DNS and TFTP server.
NetworkManager starts an instance of dnsmasq to act only as a non-
caching DNS nameserver forwarder. This instance listens only on the
loopback interface 127.0.1.1.
If
I don't know how my case enters this discussion, but it is certainly
connected to the current default installation wherein network-manager
starts an instance of dnsmasq to act as a DHCP, DNS and TFTP server.
I was troubleshooting an LTSP-PNP client boot problem under Lubuntu
Quantal. I installed
I don't know how my case enters this discussion, but it is certainly
connected to the current default installation wherein network-manager
starts an instance of dnsmasq to act as a DHCP, DNS and TFTP server.
I was troubleshooting an LTSP-PNP client boot problem under Lubuntu
Quantal. I installed
This is a bad idea as it's been implemented, guys- there's tons of local
installations that use internal DNS (My CenturyLink router or my day-
job's setup, for example...) that this flatly breaks out of box. You've
got to do a bunch of manual interventions for MANY corporate desktop and
home
@Svartalf: Can you please describe in more technical detail what fails
to work on the machines in question, and share with us what you know
about the causes of these malfunctionings? Once we have some idea what
you're talking about we can help you further.
You wrote:
there's tons of local
This is a bad idea as it's been implemented, guys- there's tons of local
installations that use internal DNS (My CenturyLink router or my day-
job's setup, for example...) that this flatly breaks out of box. You've
got to do a bunch of manual interventions for MANY corporate desktop and
home
@Svartalf: Can you please describe in more technical detail what fails
to work on the machines in question, and share with us what you know
about the causes of these malfunctionings? Once we have some idea what
you're talking about we can help you further.
You wrote:
there's tons of local
Are you sure? I am only aware of named.conf's listen-on { IP_ADDRESS;
}. If there is a feature such as you describe then presumably named
binds ALL:53 and then filters according to the addresses on the
specified interfaces.
Nope, I just verified, you're quite correct. I hadn't heard of it
Are you sure? I am only aware of named.conf's listen-on { IP_ADDRESS;
}. If there is a feature such as you describe then presumably named
binds ALL:53 and then filters according to the addresses on the
specified interfaces.
Nope, I just verified, you're quite correct. I hadn't heard of it
Yes, the 127.0.1.1:53 solution works so long as dnsmasq and others are
run in bind-interfaces (or equivalent) mode.
NM-dnsmasq currently (12.04) listens at 127.0.01:53 which prevents
others from listening on either ALL:53 or lo:53, i.e., 127.0.0.1:53.
The new (12.10) behavior allows others to
Yes, the 127.0.1.1:53 solution works so long as dnsmasq and others are
run in bind-interfaces (or equivalent) mode.
NM-dnsmasq currently (12.04) listens at 127.0.01:53 which prevents
others from listening on either ALL:53 or lo:53, i.e., 127.0.0.1:53.
The new (12.10) behavior allows others to
Another drawback is that you still need to manually configure bind (and
others) to only listen on particular addresses. If you're using dhcp
this presents a problem, because you don't actually know the address.
With bind, this is okay, mostly, because you can say to listen on
everything for a
Another drawback is that you still need to manually configure bind (and
others) to only listen on particular addresses. If you're using dhcp
this presents a problem, because you don't actually know the address.
With bind, this is okay, mostly, because you can say to listen on
everything for a
Yes, writing an NSS plugin would have been the next resort. It's
certainly easier than getting glibc and all other resolver libraries to
support ports other than 53. But it's more difficult than the solution
that was actually adopted, namely, to make nm-dnsmasq listen at
127.0.1.1.
(BTW, I
I just read this entire chain, and I'm surprised not to see mention of
using an NSS plugin, like Avahi (and ldap and NIS and /etc/hosts and DNS
itself). I expect it would be simple enough to write a small NSS plugin
that merely calls the NM-dnsmasq (running on localhost on a port other
than 53)
I just read this entire chain, and I'm surprised not to see mention of
using an NSS plugin, like Avahi (and ldap and NIS and /etc/hosts and DNS
itself). I expect it would be simple enough to write a small NSS plugin
that merely calls the NM-dnsmasq (running on localhost on a port other
than 53)
Yes, it is. I'll provide a package with a bunch of related changes from
Quantal; namely:
- using dbus instead of a config file;
- using a different dbus name than the default for dnsmasq;
- restarting dnsmasq less often (fixed in using dbus, basically)
- avoid refreshing interface config on every
AFAIK this is fixed in Quantal for dnsmasq as well as NetworkManager;
barring a minor issue with NM that I'm about to upload a fix for...
** Changed in: dnsmasq (Ubuntu)
Status: Confirmed = Fix Released
** Changed in: dnsmasq (Ubuntu Precise)
Importance: Undecided = High
** Changed
Yes, it is. I'll provide a package with a bunch of related changes from
Quantal; namely:
- using dbus instead of a config file;
- using a different dbus name than the default for dnsmasq;
- restarting dnsmasq less often (fixed in using dbus, basically)
- avoid refreshing interface config on every
AFAIK this is fixed in Quantal for dnsmasq as well as NetworkManager;
barring a minor issue with NM that I'm about to upload a fix for...
** Changed in: dnsmasq (Ubuntu)
Status: Confirmed = Fix Released
** Changed in: dnsmasq (Ubuntu Precise)
Importance: Undecided = High
** Changed
Is it really still a goal to get these fixes into Precise?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from
Is it really still a goal to get these fixes into Precise?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: djbdns (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: djbdns (Ubuntu Precise)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: djbdns (Ubuntu Precise)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: djbdns (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
Note: the dnsmasq.d file included in the new n-m release includes both
bind-interfaces and except-interface=lo.
This is already a big improvement. It allows standalone dnsmasq to run
on a system with NM and nm-dnsmasq: standalone dnsmasq listens on
interfaces other than lo and forwards queries to
Changing status to in progress in case we still want to implement the
idea in comment #88.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq
... would be what I suggest (but can't do myself). :)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
Note: the dnsmasq.d file included in the new n-m release includes both
bind-interfaces and except-interface=lo.
This is already a big improvement. It allows standalone dnsmasq to run
on a system with NM and nm-dnsmasq: standalone dnsmasq listens on
interfaces other than lo and forwards queries to
Changing status to in progress in case we still want to implement the
idea in comment #88.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS
... would be what I suggest (but can't do myself). :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage
** Branch linked: lp:~network-manager/network-manager/ubuntu
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from
This bug was fixed in the package network-manager -
0.9.6.0~git201207161259.00297f4-0ubuntu1
---
network-manager (0.9.6.0~git201207161259.00297f4-0ubuntu1) quantal; urgency=low
* upstream snapshot 2012-07-16 12:59:59 (GMT)
+ 00297f49fbbe05c51c02da43cda254c35e053589
[ Edward
** Branch linked: lp:~network-manager/network-manager/ubuntu
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled dnsmasq prevents other DNS servers from starting
To manage
1 - 100 of 177 matches
Mail list logo
