OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
as follows.
1. Either we accept that nm-dnsmasq is incompatible with every standalone
nameserver and enforce this in a better way;
2. or we force every standalone nameserver into bind-interfaces mode and move
nm-dnsmasq's
On 13/06/12 11:07, Thomas Hood wrote:
OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
as follows.
1. Either we accept that nm-dnsmasq is incompatible with every standalone
nameserver and enforce this in a better way;
2. or we force every standalone nameserver into
On 13/06/12 11:07, Thomas Hood wrote:
OK, so the ::1 idea fails as a quick hack. The alternatives seem to be
as follows.
1. Either we accept that nm-dnsmasq is incompatible with every standalone
nameserver and enforce this in a better way;
2. or we force every standalone nameserver into
In reply to #58, sorry, defining multiple except-interface= directives
works fine in my 2.59-4 after all, I think I might have used except-
interfaces, plural.
Solution #2 sounds good to me too. :)
If I understand well, a dnsmasq-base SRU is in order for 12.04 anyway to fix
the tftp issue, so
Simon:
If you can make #2 happen without breaking things, that would seem to be
worth doing
Indeed, primum non nocere. Standalone dnsmasq works fine in the absence
of NM+dnsmasq and vice versa and this must continue to be the case when
we are done. :)
I guess the main problem is that you
so dropping a file there containing bind-interfaces
and doing the relevant restart in postinst should
make this automatic in most cases.
I notice that libvirt has just used this mechanism to solve a comparable
problem (see ##928524). Libvirt includes the file /etc/dnsmasq.d/libvirt-bin
Note that while bind-interfaces can be specified multiple times,
defining except-interfaces more than once is a syntax error in my
dnsmasq 2.59-4.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
It just occurred to me that if we are going to change someone's listen
address then it might be better to give 127.0.0.1 to nm-dnsmasq and
127.0.1.1 to the standalone nameserver.
Consider the case where nm-dnsmasq is running on a machine, nemo, that
happens to run the nameserver for the LAN.
Alkis: Suppose your host, foo, has external IP address 10.1.2.3 and runs
a standalone nameserver which listens on eth0. Configure things such
that nm-dnsmasq on foo uses 10.1.2.3 as its upstream nameserver;
configure the standalone nameserver on foo not to listen on lo. If it's
dnsmasq, start it
Hmm, just tested this myself. You can't use except-interface=lo; it
seems you have to use listen-address=10.1.2.3. Perhaps Simon knows a
better way.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
Aha, you have to use except-interface=lo together with bind-
interfaces. Sorry for all the messages!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
I tested bind-interfaces and except-interface=lo in the past (comment
#26), it worked as advertised. I haven't yet tested them in the chained
dnsmasq mode, but I guess it would work if I'm using a static IP (which
isn't always the case for LTSP servers, some teachers use their laptops
for LTSP
Alkis wrote in #51:
Note that while bind-interfaces can be specified multiple times,
defining except-interfaces more than once is a syntax error in
my dnsmasq 2.59-4.
Multiple except-interface options are accepted by dnsmasq 2.62-2.
--
You received this bug notification because you are a
On 12/06/12 10:05, Alkis Georgopoulos wrote:
Note that while bind-interfaces can be specified multiple times,
defining except-interfaces more than once is a syntax error in my
dnsmasq 2.59-4.
Are you sure? That should be allowed.
Simon.
--
You received this bug notification because you
On 12/06/12 11:24, Thomas Hood wrote:
Hmm, just tested this myself. You can't use except-interface=lo; it
seems you have to use listen-address=10.1.2.3. Perhaps Simon knows a
better way.
If you want to listen on an address which doesn't appear on an interface
(ie 127.0.1.1) then you have
(Executive summary of the following: I think we should fix this by
making nm-dnsmasq listen at ::1.)
Thanks for your much-needed help, Simon.
It is good to know that the except-interface avenue is available. We
want, however, to be able to enjoy the advantages of non-bind-interfaces
mode
On 12/06/12 20:31, Thomas Hood wrote:
(Executive summary of the following: I think we should fix this by
making nm-dnsmasq listen at ::1.)
Thanks for your much-needed help, Simon.
It is good to know that the except-interface avenue is available. We
want, however, to be able to enjoy the
Alkis wrote:
If nm + resolvconf managed to properly chain the 2 dnsmasq instances so that
the NM-spawned dnsmasq was contacted first
I think that this configuration should be supported, whether or not it's
the best solution to the present problem (#959037).
Resolvconf can handle this with a
On 11/06/12 19:57, Thomas Hood wrote:
But, second, there is a problem connecting the resolver to the NM-
controlled dnsmasq such that the latter stays out of the way of the
general local nameserver which currently wants to listen on the IPv4
wildcard address. Using address ::1 for nm-dnsmasq
Aha, I had tried this and it didn't work... in version 2.57. But I see
that quantal already has 2.62.
Another instance of dnsmasq will run without interfering with that,
providing only that --bind-interfaces is set.
Just to make sure I understand correctly: Do you mean here that --bind-
On 11/06/12 20:41, Thomas Hood wrote:
Aha, I had tried this and it didn't work... in version 2.57. But I see
that quantal already has 2.62.
Another instance of dnsmasq will run without interfering with that,
providing only that --bind-interfaces is set.
Just to make sure I understand
Another idea:
* Change NM such that it causes its slave dnsmasq to listen on ::1
instead of 127.0.0.1
But I guess the problem will just arise again if the standalone dnsmasq
is changed to listen on the wildcard IPv6 address.
--
You received this bug notification because you are a member of
* Change NM such that it causes its slave dnsmasq to listen on ::1
instead of 127.0.0.1
Personally, when I install dnsmasq, I *don't want* to use the NM-spawned
dnsmasq, because it disables caching etc etc. So it wouldn't matter if
it listened on another address, on a socket or wherever else; I
Alkis wrote:
I wouldn't want it as my default resolver.
But some people might. It's better to eliminate the behavioral
conflict, if we can, than to formalize that conflict as a packaging
dependency.
--
You received this bug notification because you are a member of Desktop
Packages, which is
It's better to eliminate the behavioral conflict, if we can, than to
formalize that conflict as a packaging dependency.
I was about to say this:
But then the main problem which caused me to report this bug would remain:
When I install the dnsmasq package, it wouldn't work.
I'd configure my
I meantioned Wicd and Netconf above. While investigating another
problem I stumbled across Connman
http://connman.net
which appears to be another alternative to NetworkManager worth
watching.
--
You received this bug notification because you are a member of Desktop
Packages, which is
** Summary changed:
- NM-controlled dnsmasq prevents other DNS servers from running
+ NM-controlled dnsmasq prevents other DNS servers from running, yet
network-manager doesn't Conflict with their packages
--
You received this bug notification because you are a member of Desktop
Packages,
But enough dreaming. Given the world as it is, the immediate challenge
is to make NM+dnsmasq compatible with standalone nameservers.
(Otherwise network-manager should Conflict with those nameservers'
packages.)
Solutions mentioned earlier:
* Tell the administrator to comment out dns=dnsmasq in
28 matches
Mail list logo