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
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 w
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 i
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 i
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 li
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 enjo
(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 ("unb
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
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 yo
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 m
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 serv
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.
https://
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:
NM-contr
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
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. /etc
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.
https://bugs.lau
> 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
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 understan
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-
interf
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-dnsm
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
> 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 dnsma
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 s
> * 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
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 Desk
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 subs
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
** 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, which
28 matches
Mail list logo
