[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 listen address to something other than 127.0.0.1; 3. or we make nm-dnsmasq listen on another port number (using the --port option) and enhance glibc to support accessing nameservers at ports other than 53. Have I forgotten any? #3 is the most attractive option but requires the most work and won't happen soon. In the short term the choice is between #1 and #2. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 bind-interfaces mode and move nm-dnsmasq's listen address to something other than 127.0.0.1; 3. or we make nm-dnsmasq listen on another port number (using the --port option) and enhance glibc to support accessing nameservers at ports other than 53. Have I forgotten any? #3 is the most attractive option but requires the most work and won't happen soon. In the short term the choice is between #1 and #2. For completeness, there's a #4 which is to dump bind-interfaces except-interface=lo into /etc/dnsmasq.d, but that won't work for other nameservers (though something analogous would, I expect) If you can make #2 happen without breaking things, that would seem to be worth doing, I guess the main problem is that you need dnsmasq 2.61 or a backport of the relevant code to 2.59. Simon. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 bind-interfaces mode and move nm-dnsmasq's listen address to something other than 127.0.0.1; 3. or we make nm-dnsmasq listen on another port number (using the --port option) and enhance glibc to support accessing nameservers at ports other than 53. Have I forgotten any? #3 is the most attractive option but requires the most work and won't happen soon. In the short term the choice is between #1 and #2. Further to #2 and getting dnsmasq support. I found a bug last night that means that dnsmasq --listen-address=ip addr where ip addr is not on an interface, will listen on port 69 of ip addr even if tftp is not enabled. The fix is in git but not a release, but should be backported if you do #2. It's trivial: one line. Simon. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 why not fix it in quantal and backport 2.62-3 to precise. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 need dnsmasq 2.61 As this issue has low importance I imagine it will only be fixed in quantal? Simon: Further to #2 and getting dnsmasq support. I found a bug last night that means that dnsmasq --listen-address=ip addr where ip addr is not on an interface, will listen on port 69 of ip addr even if tftp is not enabled I just changed the lines in NetworkManager C code: s/127.0.0.1/127.0.0.2/. With this change nm-dnsmasq does indeed not listen... unless address 127.0.0.2 is added to lo. But then standalone dnsmasq --bind-interfaces won't start unless that address is removed from lo again. Once they have both been started in this way they both work --- standalone dnsmasq forwarding to nm-dnsmasq and the latter forwarding to the upstream nameservers. The reason they cascade in this order is that dnsmasq registers 127.0.0.1 under the name lo.dnsmasq which has a high priority according to /etc/resolvconf/interface-order; it thus appears in resolv.conf. NM registers 127.0.0.2 with resolvconf and this is given to standalone dnsmasq by /etc/resolvconf/update.d/dnsmasq as its forwarding address. Nm-dnsmasq is given the addresses of the upstream nameservers by NM in /var/run/nm-dns-dnsmasq.conf. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 with the following contents. bind-interfaces except-interface=virbr0 -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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/hosts on nemo contains either 127.0.0.1 localhost 127.0.1.1 nemo or 127.0.0.1 localhost 10.1.2.3 nemo where 10.1.2.3 is nemo's external IP address. Other machines in the LAN access nemo via 10.1.2.3 for their general name service. If they are Ubuntu machines they also access their local nm-dnsmasq instances via the loopback address. It's nicely symmetrical if processes on nemo itself also use the loopback address to access the local nm-dnsmasq and use either the public address, 10.1.2.3 or its substitute, 127.0.1.1, for general name service. Perhaps this is only an aesthetic question. Simon: Can we arrange by means of the file in /etc/dnsmasq.d/ that the standalone dnsmasq listens on 127.0.1.1 rather than 127.0.0.1? -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 with --except-interface=lo. Does this do what you want? If so then this may be a very simple way to deal with #959037, at least with respect to dnsmasq. Network-manager simply drops a file with except-interface=lo into /etc/dnsmasq.d/. NM can still use the local standalone dnsmasq via the external network interface, the address of which it may receive from the DHCP server, for example. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 servers). With a dynamic IP, I'd have to open the NM-connection editor all the time to update my primary DNS server. So a loopback address for the dnsmasq service would be preferred locally, while the non-loopback one would again be required for the LTSP clients. Network-manager simply drops a file with except-interface=lo What I meant in comment #51 is that libvirt then won't be able to ship with except-interface=lxcbr0 because it's a syntax error to specify 2 except-interface directives. Maybe it could be allowed in some future dnsmasq version, with the list of declared interfaces being merged. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 to use --listen-address. The rules for 127.0.0.1 are slightly arcane too: If you use -interface and --except-interface, then dnsmasq will assume that you want it to listen on the address of any loopback interfaces it finds as well. In practise that means 127.0.0.1 So dnsmasq --interface=eth0 will listen on the address(es) of eth0 and 127.0.0.1. If you use --listen-address, then dnsmasq assumes you want more control and only uses the addresses you actually give so dnsmasq --listen-address=127.0.1.1 will _not_ listen on 127.0.0.1 Given this, it makes sense to use 127.0.1.1 (or any address in 127.0.0.0/8 that doesn't appear on lo) for nm-dnsmasq. Because 127.0.1.1 doesn't appear on lo, another dnsmasq instance will not try and listen on it, and the only thing required to get the two dnsmasq instances to co-exist is --bind-interfaces. Cheers, Simon. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
(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 (unbound mode??) in standalone dnsmasq insofar as we can. Certainly standalone dnsmasq should continue to run in unbound mode when n-m is not installed or when nm-dnsmasq is not in use; so ideally we would ensure that /etc/NetworkManager/NetworkManager.conf contains dns=dnsmasq if and only if /etc/dnsmasq.d/nm-dnsmasq contains bind- interfaces except-interface=lo. I don't see a very easy way to ensure this. In any case it would be better if we never had to force dnsmasq into bind-interfaces mode. So instead of switching the nm-dnsmasq listen address from 127.0.0.1 to 127.0.1.1 it seems better to switch that address to ::1: no more difficult, yet in the latter case standalone dnsmasq can continue to run in unbound mode as it has traditionally done (unless forced into bind- interfaces mode by something like libvirt-bin, of course). Implementing the change to ::1 shouldn't be too hard. * It's a one-line change to network-manager where it starts dnsmasq and another one-line change where it register's the latter's address with resolvconf. On a system with n-m and no standalone dnsmasq this will result in /etc/resolv.conf containing nameserver ::1 and the resolver will connect to nm-dnsmasq. On a system with standalone dnsmasq and no n-m this will be no different from the traditional state of affairs, with /etc/resolv.conf containing nameserver 127.0.0.1 and the resolver connecting to standalone dnsmasq. On a system with both n-m and standalone dnsmasq this will *also* result in /etc/resolv.conf containing nameserver 127.0.0.1 and the resolver connecting to standalone dnsmasq. This is probably unwanted, but is easily fixed by * changing network-manager so that it registers the ::1 address under the name nm-dnsmasq (name open to discussion) instead of under the name NetworkManager (which can still be used for registering external nameserver information in the dns!=dnsmasq case); * changing resolvconf so that it includes the pattern nm-dns at the top of /etc/resolvconf/interface-order. Then on a system with both n-m and dnsmasq, /etc/resolv.conf will contain nameserver ::1 and the resolver will use nm-dnsmasq. The remaining challenge then is to see to it that NM sends the address 127.0.0.1 to nm-dnsmasq via /var/run/nm-dns-dnsmasq.conf when there is a local nameserver running that provides general name service. This would probably have to be configurable via the GUI since it's hard to tell whether or not a locally running nameserver provides general name service. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 advantages of non-bind-interfaces mode (unbound mode??) in standalone dnsmasq insofar as we can. Certainly standalone dnsmasq should continue to run in unbound mode when n-m is not installed or when nm-dnsmasq is not in use; so ideally we would ensure that /etc/NetworkManager/NetworkManager.conf contains dns=dnsmasq if and only if /etc/dnsmasq.d/nm-dnsmasq contains bind- interfaces except-interface=lo. I don't see a very easy way to ensure this. In any case it would be better if we never had to force dnsmasq into bind-interfaces mode. So instead of switching the nm-dnsmasq listen address from 127.0.0.1 to 127.0.1.1 it seems better to switch that address to ::1: no more difficult, yet in the latter case standalone dnsmasq can continue to run in unbound mode as it has traditionally done (unless forced into bind- interfaces mode by something like libvirt-bin, of course). I don't think that's true. In unbound mode, the standalone dnsmasq will bind the IPv6 wildcard address, which will stop the nm-dnsmasq from binding ::1 There's no escape in IPv6 land. Indeed the situation is worse, because as far a I know, you can't use any address in the defined subnet for loopback, it has to be ::1, so except-interface=lo is required. I think the 127.0.1.1 (or whatever) answer is the best. Unfortunately there's no way round having to set --bind-interfaces on the standalone dnsmasq, but except-interface=lo is not required as long as the 127.0.0.0/8 address in use by nm-dnsmasq doesn't appear on the lo interface. Simon. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 little tweaking. The general local nameserver registers its listen-address, 127.0.0.1, with resolvconf under a name like lo.dnsmasq which has a high priority according to interface-order(5). NM currently registers its slave nameserver's address under the name NetworkManager which has a very low priority. To implement Alkis's idea, the ordering would have to be adjusted so that the NM address has a higher priority than the other addresses. If we decide to implement Alkis's idea then I'll change the Debian package to add something like lo.nm-dnsmasq before the other lo.* patterns in the default interface-order. Then network-manager should be changed so that it registers its slave's address under that name. 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 is a quick hack which might work without further ado But even if it works it clearly isn't a permanent solution. More satisfactory would be to use an another port than 53 for the special purpose of connecting the resolver with nm-dnsmasq. Currently the GNU C Library resolver doesn't support using another port. Interestingly, OpenBSD does support it. Here's an extract from the OpenBSD resolv.conf man page. nameserver IPv4 address (in dot notation) or IPv6 address (in hex-and- colon notation) of a name server that the resolver should query. Scoped IPv6 address notation is accepted as well (see inet6(4) for details). A non-standard port may be specified using [host]:port syntax. Mac OS X has a similar feature. That doesn't immediately help us, of course, but it does set a precedent for a similar enhancement of the GNU C Library. Perhaps we could implement ::1 for now and also start work on getting the aforementioned enhancement into glibc. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 is a quick hack which might work without further ado But even if it works it clearly isn't a permanent solution. More satisfactory would be to use an another port than 53 for the special purpose of connecting the resolver with nm-dnsmasq. Another option is to use another address in 127.0.0.0/8, any will work. You'll need dnsmasq 2.61 or later for this to be a viable option. You could have the nm-dnsmasq run with --bind-interfaces --listen-address=127.0.100.1 and put 127.0.100.1 in /etc/resolv.conf. Another instance of dnsmasq will run without interfering with that, providing only that --bind-interfaces is set. Simon. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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- interfaces has to be set on both instances of dnsmasq? Or will one instance (the NM-controlled one) with --bind-interfaces coexist nicely with another (the standalone dnsmasq) which doesn't use that option and listens on 0.0.0.0? NM already runs dnsmasq with --bind-interfaces and --listen-address (specifically, --listen-address=127.0.0.1) so we would only be changing the address. Mathieu mentioned earlier the possibility of using 127.0.1.1 which happens to be the address assigned (in /etc/hosts) to the system hostname on some (but not all) systems. Is there any advantage to using 127.0.1.1 as opposed to another 127.* address? -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
Re: [Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 correctly: Do you mean here that --bind- interfaces has to be set on both instances of dnsmasq? Or will one instance (the NM-controlled one) with --bind-interfaces coexist nicely with another (the standalone dnsmasq) which doesn't use that option and listens on 0.0.0.0? It has to be set in both instances of dnsmasq. dnsmasq started as a system daemon reads config from /etc/dnsmasq.d/* so dropping a file there containing bind-interfaces and doing the relevant restart in postinst should make this automatic in most cases. NM already runs dnsmasq with --bind-interfaces and --listen-address (specifically, --listen-address=127.0.0.1) so we would only be changing the address. Mathieu mentioned earlier the possibility of using 127.0.1.1 which happens to be the address assigned (in /etc/hosts) to the system hostname on some (but not all) systems. Is there any advantage to using 127.0.1.1 as opposed to another 127.* address? I don't think so: they're all equivalent. Simon. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
* 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 wouldn't want it as my default resolver. I still think that the best idea is to make the local resolver a separate package that conflicts with all DNS servers, so that it's automatically uninstalled when one of them gets installed, until the problem is solved within libc. There are a lot of methods for interprocess communication, I'm sure some of them can solve the problem properly. That way all people would benefit, now the solution is only for those using Ubuntu+Network manager+resolvconf. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 dnsmasq, then put 127.0.0.1 as the DNS server for my LTSP client sessions on the server, and another dnsmasq would answer which wouldn't contain my configuration, my A or MX records or whatever else I'd put in my configuration file. ...but then I thought of this, which if it worked, I wouldn't have problems: If nm + resolvconf managed to properly chain the 2 dnsmasq instances, so that the NM-spawned dnsmasq was contacted first in another address or port or IPv6 or whatever, and then the NM-spawned dnsmasq contacted my real dnsmasq at 127.0.0.1, since it's the DNS server I declared at my connection properties, then it would at least work as expected, with just a small additional overhead. I wouldn't mind about that. And it would work with any DNS server too, not with just dnsmasq. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
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 subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages
** 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 is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their 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 /etc/NetworkManager/NetworkManager.conf after installing dnsmasq or another DNS server package. * Change NM so that it acts as if dns=dnsmasq is absent if a DNS server package is installed. * Change standalone dnsmasq such that it doesn't listen on 0.0.0.0:53, doesn't listen on 127.0.1.1:53 and change NM so that its dnsmasq listens only on 127.0.1.1:53. Here's a new idea. * Enhance the resolver(3) so that nameservers can be specified in resolv.conf using the address:port notation * Change NM such that it causes its slave dnsmasq to listen on another (than 53) port number P and sends nameserver 127.0.0.1:P to resolvconf. -- 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-controlled dnsmasq prevents other DNS servers from running, yet network-manager doesn't Conflict with their packages Status in “djbdns” package in Ubuntu: New Status in “dnsmasq” package in Ubuntu: Confirmed Status in “network-manager” package in Ubuntu: Triaged Bug description: As described in https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving, network manager now starts a dnsmasq instance for local DNS resolving. That breaks the default bind9 and dnsmasq installations, for people that actually want to install a DNS server. Having to manually comment out #dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf doesn't sound good, and if it stays that way, it should be moved to the bind9 and dnsmasq postinst scripts. Please make network-manager smarter so that it checks if bind9 or dnsmasq are installed, so that it doesn't start the local resolver in that case. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
