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 Ubuntu
Server Team, which is subscribed to dnsmasq 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
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 Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/959037
Title:
NM-controlled
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 Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
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
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 Ubuntu
Server Team, which is
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 Ubuntu
Server Team, 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
** 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 Ubuntu
Server Team,
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
