[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 resolved, after 150 messages it was just made a little worse. One workaround is to undo the "solution" offered in this bug report: 1) In /etc/NetworkManager/NetworkManager.conf, comment out: # dns=dnsmasq 2) And in /etc/dnsmasq.d/network-manager, comment out: #bind-interfaces A better solution would be for Mathieu to create a separate package for the nm-spawned dnsmasq, one that would conflict with the real dnsmasq server so that it would be automatically uninstalled when the sysadmin would install the real dnsmasq. I can send a patch for that if it will be accepted. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 easier to see and fix. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 easier to see and fix. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 Saucy, but I'm running into what seems to be an NBD-related kernel bug, which I'm trying to commit bisect on the upstream kernel. Clients fail to boot, generating Error: socket failed: connection refused. It's off-topic, but this problem does not appear in Trusty? -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 that breaks everything. Removing that file makes tftp work again. Alkis, does it work properly if you change bind-interfaces to bind- dynamic? -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 Saucy, but I'm running into what seems to be an NBD-related kernel bug, which I'm trying to commit bisect on the upstream kernel. Clients fail to boot, generating Error: socket failed: connection refused. It's off-topic, but this problem does not appear in Trusty? -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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: udp0 0 127.0.0.1:690.0.0.0:* 954/dnsmasq udp6 0 0 ::1:69 :::* 954/dnsmasq ...and of course that breaks everything. Removing that file makes tftp work again. Mathieu, could you please package the modifications to /etc/NetworkManager/NetworkManager.conf and to /etc/dnsmasq.d/network-manager as a separate, network-manager-local-resolver.deb package, maybe even produced by the network manager source code, and Recommented: it from network-manager, ...so that people that want to use dnsmasq as a real server can just blacklist it without suffering on each new Ubuntu installation? E.g. for the 500+ schools we maintain here, we could then just Conflict: network-manager-local-resolver from our main package and forget the whole thing... Thanks, Alkis ** Changed in: network-manager (Ubuntu) Status: Fix Released = Confirmed -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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: udp0 0 127.0.0.1:690.0.0.0:* 954/dnsmasq udp6 0 0 ::1:69 :::* 954/dnsmasq ...and of course that breaks everything. Removing that file makes tftp work again. Mathieu, could you please package the modifications to /etc/NetworkManager/NetworkManager.conf and to /etc/dnsmasq.d/network-manager as a separate, network-manager-local-resolver.deb package, maybe even produced by the network manager source code, and Recommented: it from network-manager, ...so that people that want to use dnsmasq as a real server can just blacklist it without suffering on each new Ubuntu installation? E.g. for the 500+ schools we maintain here, we could then just Conflict: network-manager-local-resolver from our main package and forget the whole thing... Thanks, Alkis ** Changed in: network-manager (Ubuntu) Status: Fix Released = 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: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 fine again. For the 500+ schools that we're supporting here, we'll just continue commenting out #dns=dnsmasq because it doesn't cooperate with the regular dnsmasq installation, but if you want me to provide more info to troubleshoot this issue, I'd be glad to. I'm attaching the output of nm-tool. My effective dnsmasq.conf is: $ egrep -rv '^#|^$' /etc/dnsmasq.* /etc/dnsmasq.d/network-manager:bind-interfaces /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.160.67.0,proxy /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.161.254.0,proxy /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=192.168.67.20,192.168.67.250,8h /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:enable-tftp /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:tftp-root=/var/lib/tftpboot/ /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=17,/opt/ltsp/i386 /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=etherboot,Etherboot /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=pxe,PXEClient /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=ltsp,Linux ipconfig /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0 /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:etherboot,/ltsp/i386/nbi.img /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:ltsp,/ltsp/i386/lts.conf /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=vendor:pxe,6,2b /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-no-override ** Attachment added: nm-tool https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/959037/+attachment/3914785/+files/nm-tool -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 fine again. For the 500+ schools that we're supporting here, we'll just continue commenting out #dns=dnsmasq because it doesn't cooperate with the regular dnsmasq installation, but if you want me to provide more info to troubleshoot this issue, I'd be glad to. I'm attaching the output of nm-tool. My effective dnsmasq.conf is: $ egrep -rv '^#|^$' /etc/dnsmasq.* /etc/dnsmasq.d/network-manager:bind-interfaces /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.160.67.0,proxy /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=10.161.254.0,proxy /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-range=192.168.67.20,192.168.67.250,8h /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:enable-tftp /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:tftp-root=/var/lib/tftpboot/ /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=17,/opt/ltsp/i386 /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=etherboot,Etherboot /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=pxe,PXEClient /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-vendorclass=ltsp,Linux ipconfig /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:pxe,/ltsp/i386/pxelinux.0 /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:etherboot,/ltsp/i386/nbi.img /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-boot=net:ltsp,/ltsp/i386/lts.conf /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-option=vendor:pxe,6,2b /etc/dnsmasq.d/ltsp-server-dnsmasq.conf:dhcp-no-override ** Attachment added: nm-tool https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/959037/+attachment/3914785/+files/nm-tool -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 resolver listening there too.) It would be a nice feature,
sure. But, it's nm-dnsmasq is the one breaking away from standards in
ways that will break other packages, so I'm reporting the conflict here.
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.
--
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 bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving If there have already been discussions of per-user caching in Ubuntu then someone please give me the link. The only approach that I have seen so far is per-user nscd in Solaris and (I now see) FreeBSD. http://docs.oracle.com/cd/E19963-01/html/821-1462/nscd-1m.html http://www.unix.com/man-page/freebsd/8/NSCD -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 idea what the mechanism is there?
When I bring down an interface with NetworkManager, named does *not*
notice this right away.
--
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 bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. Just reported this in bug #1087228. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 resolver listening there too.) It would be a nice feature,
sure. But, it's nm-dnsmasq is the one breaking away from standards in
ways that will break other packages, so I'm reporting the conflict here.
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.
--
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:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns- resolving If there have already been discussions of per-user caching in Ubuntu then someone please give me the link. The only approach that I have seen so far is per-user nscd in Solaris and (I now see) FreeBSD. http://docs.oracle.com/cd/E19963-01/html/821-1462/nscd-1m.html http://www.unix.com/man-page/freebsd/8/NSCD -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 idea what the mechanism is there?
When I bring down an interface with NetworkManager, named does *not*
notice this right away.
--
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:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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, 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. Just reported this in bug #1087228. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 periodically scans the host's network interfaces. This
happens once each interface interval, which is 60 minutes by default. If
you know the host your name server runs on has no dynamic network
interfaces, you can disable scanning for new interfaces by setting the
interface interval to zero to avoid unnecessary hourly overhead:
options {
interface-interval 0;
};
On the other hand, if your host brings up or tears down network interfaces more
often than every hour, you may want to reduce the interval.
[/QUOTE]
But when I tried it, named noticed right away that I had brought up an
interface. Will investigate further.
--
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 bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 *need* to. To directly answer the question about something that conflicts: the internal resolver of the samba4 packages. They're beta right now, but the scheduled release date is December, and there's no parameter (yet) for altering the port or interfaces. This is actually the one that bit me originally. To answer what does it give us?, currently NM invokes a single dnsmasq instance that must be shared between all users. This isn't ideal, because NM connections can be per-user, and this could lead information disclosure at worst and oddly-rearranged DNS resolve orders at best. With an NSS module, you could spin up one dnsmasq instance for the system on a possibly priviliged port (but not 53) and one per user (above 1024), and link them together as forwarders so that only the user owning the connection will use the resolution they've specified in the GUI. It would require som tracking of which user's instance is on which port,and auto-invoking them when necessary, and shutting it down when the user logs out, but would allow for much more flexible and clean separation of user settings. For the record, I am happy to write the NSS plugin myself, but it would require some changes in NM core itself, so I would have to work with someone on the NM team to implement it. If you're interested, and know who that would be, please do let me know. I will also create a new bug report as requested. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 periodically scans the host's network interfaces. This
happens once each interface interval, which is 60 minutes by default. If
you know the host your name server runs on has no dynamic network
interfaces, you can disable scanning for new interfaces by setting the
interface interval to zero to avoid unnecessary hourly overhead:
options {
interface-interval 0;
};
On the other hand, if your host brings up or tears down network interfaces more
often than every hour, you may want to reduce the interval.
[/QUOTE]
But when I tried it, named noticed right away that I had brought up an
interface. Will investigate further.
--
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:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 *need* to. To directly answer the question about something that conflicts: the internal resolver of the samba4 packages. They're beta right now, but the scheduled release date is December, and there's no parameter (yet) for altering the port or interfaces. This is actually the one that bit me originally. To answer what does it give us?, currently NM invokes a single dnsmasq instance that must be shared between all users. This isn't ideal, because NM connections can be per-user, and this could lead information disclosure at worst and oddly-rearranged DNS resolve orders at best. With an NSS module, you could spin up one dnsmasq instance for the system on a possibly priviliged port (but not 53) and one per user (above 1024), and link them together as forwarders so that only the user owning the connection will use the resolution they've specified in the GUI. It would require som tracking of which user's instance is on which port,and auto-invoking them when necessary, and shutting it down when the user logs out, but would allow for much more flexible and clean separation of user settings. For the record, I am happy to write the NSS plugin myself, but it would require some changes in NM core itself, so I would have to work with someone on the NM team to implement it. If you're interested, and know who that would be, please do let me know. I will also create a new bug report as requested. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. The current solution is to run nm-dnsmasq at 127.0.1.1:53. This solution has already been rolled out and seems to be working well. (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.) Any alternative has to offer significant benefits if it's going to be considered for adoption, considering the amount of work and the risk involved. 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? Would the NSS-module approach make it easier to implement per-user caches, for example? (I see that Solaris provides per-user instances of nscd for this purpose.) Robin, please submit a version of your comment #129 as a new bug report against network-manager, requesting that the connection to nm-dnsmasq be implemented by means of a new NSS module. Give your arguments in favor. Then we can continue the discussion in an open bug report rather than in this fix-released one. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 only show up after 2 years. E.g. in 300 schools here we settled with disabling the nm-spawned dnsmasq from NetworkManager.conf, and haven't seen the implemented solution yet. Btw please don't backport the current solution to Precise, the bind-interfaces part will break all those existing setups. The nss-based solution does sound like it wouldn't cause any problems at all, though. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 list of listen addresses whenever network interfaces are configured and deconfigured. It appears to work well. In bind-dynamic mode, as in bind-interfaces mode, standalone dnsmasq is compatible with NM-dnsmasq listening at 127.0.1.1. I would suggest therefore that if the switch from 127.0.0.1 to 127.0.1.1 for NM-dnsmasq is backported to Precise then dnsmasq 2.63 should simultaneously be backported to Precise and dnsmasq should be forced into bind-dynamic mode rather than into bind-interfaces mode. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 see that in its default configuration named behaves just like dnsmasq in bind-dynamic mode. That is, it listens on port 53 at all addresses assigned to interfaces. When interfaces are created or configured, named starts listening on those as well. With this behavior, it shouldn't often (ever?) be necessary to configure named to listen on the wildcard address. Is there any nameserver out there that does still conflict with nm- dnsmasq listening at 127.0.1.1:53? -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. The current solution is to run nm-dnsmasq at 127.0.1.1:53. This solution has already been rolled out and seems to be working well. (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.) Any alternative has to offer significant benefits if it's going to be considered for adoption, considering the amount of work and the risk involved. 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? Would the NSS-module approach make it easier to implement per-user caches, for example? (I see that Solaris provides per-user instances of nscd for this purpose.) Robin, please submit a version of your comment #129 as a new bug report against network-manager, requesting that the connection to nm-dnsmasq be implemented by means of a new NSS module. Give your arguments in favor. Then we can continue the discussion in an open bug report rather than in this fix-released one. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 only show up after 2 years. E.g. in 300 schools here we settled with disabling the nm-spawned dnsmasq from NetworkManager.conf, and haven't seen the implemented solution yet. Btw please don't backport the current solution to Precise, the bind-interfaces part will break all those existing setups. The nss-based solution does sound like it wouldn't cause any problems at all, though. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 list of listen addresses whenever network interfaces are configured and deconfigured. It appears to work well. In bind-dynamic mode, as in bind-interfaces mode, standalone dnsmasq is compatible with NM-dnsmasq listening at 127.0.1.1. I would suggest therefore that if the switch from 127.0.0.1 to 127.0.1.1 for NM-dnsmasq is backported to Precise then dnsmasq 2.63 should simultaneously be backported to Precise and dnsmasq should be forced into bind-dynamic mode rather than into bind-interfaces mode. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 see that in its default configuration named behaves just like dnsmasq in bind-dynamic mode. That is, it listens on port 53 at all addresses assigned to interfaces. When interfaces are created or configured, named starts listening on those as well. With this behavior, it shouldn't often (ever?) be necessary to configure named to listen on the wildcard address. Is there any nameserver out there that does still conflict with nm- dnsmasq listening at 127.0.1.1:53? -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 /etc/resolv.conf for compatibility with the glibc resolver but I'd like to know whether or not, or to what extent, they also obey /etc/nsswitch.conf. I believe I understand your basic idea well enough. Instead of using resolv.conf to direct name queries to nm-dnsmasq, use a new NSS module. This new NSS module, foo, would be like the existing dns module except that it would only talk to nm-dnsmasq, or would allow other ports than 53 to be specified so that nm-dnsmasq could be talked to over another port than 53. The new module would be named on the hosts: line in /etc/nsswitch.conf instead of dns. (I don't see the point of listing both foo and dns, since foo *is* DNS.) But how much less work would this be than adapting the glibc code so that ports other than 53 can be specified, e.g., via a new config file with enhanced semantics that (if present) overrides resolv.conf? And how much less is the risk of breaking software that uses alternative resolver libraries? -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 NSS. This is because *everything* supports NSS. For instance, NIS and NIS+ hosts are done through NSS, and this is supported by essentially everything, because it's the standard. All of the enterprise directory services I've come across use an NSS plugin (usually the nis one). It's just simply the right way to do it. I wouldn't worry about resolver libraries that don't use glibc. They're typically DNS-specific, and are typically configured by their own files anyway. Dig, for instance, will use whatever server you tell it to, and ignore resolv.conf (though it uses it as a default). Same goes for the host tool -- they're used for querying specific DNS servers. However, those resolvers *also* ignore /etc/hosts, because that's referenced by the files NSS plugin. Any service that uses gethostbyname(3) is using glibc, and that's going to be everything except edge cases that are intentionally doing their own thing anyway. Things that try to emulate glibc behavior by first checking /etc/hosts and then /etc/resolv.conf are simply doing it wrong, and will miss (for instance) avahi, NIS, and any other directory service that may be installed. I'm surprised at the idea that it will be less work to modify glibc. Even if it's technically easier to make a change in the glibc code than to create your own NSS plugin, you have a myriad of problems: NM functionality would now have a dependency on a nonstandard patch of glibc, the documentation for /etc/resolv.conf will be inconsistent for only this distribution, there could (will) be resistance by the glibc folks, who knows what you'll break when you alter how glibc behaves, etc. However, with an NSS module, we have a huge number of advantages: * It's the standard way of achieving this type of thing and is hence supported by most everything * It's the standard way of achieving this type of thing so it's very well documented * It's the standard way of achieving this type of thing so it's very modularized and isolated, and if NM stops working it will continue along the chain without screwing up plugins further up like (unlike when dnsmasq dies with the proposed glibc change) * It's the standard way of achieving this type of things so the things that don't support it are, in general, doing it wrong and that's a bug on their end * It's the standard way of achieving this type of thing so there's already a package (libnss-mdns) that adds a hosts NSS module, meaning both that we know it works and that it is officially supported by ubuntu * It could be owned by the NM project instead of creating a dependency on a glibc patch that would not be taken up by distributions very quickly * You could make it do other interesting things like have static /etc/hosts-like entries per connection. You get the idea. If you want to see an example of an NSS hosts plugin packaged for ubuntu, that hooks into /etc/nsswitch.conf, look at the nss-mdns source package. The debian/libnss-mdns.postinst script that runs upon installation is what handles inserting it into /etc/nsswitch.conf, and can easily be adapted to handle inserting a NM plugin. If you want another example of an ubuntu package dealing with NSS plugins look at the auth-client-config package, though this one only handles the passwd, group, and shadow services. In short: An NSS plugin has vastly less risk of breaking software because Ubuntu already uses it and things aren't breaking (and it's also the standard, anyway), could actually be part of the NM project as opposed to owned by glibc, and will likely be easier than modifying glibc anyway due to fewer dependencies. This seems like win-win-win to me. To be clear, I'm advocating that we make a small NSS plugin wrapper around calls to a dnsmasq (or other) mini name server controlled by NM, that runs on a non-privileged port and can be spawned per-user. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 /etc/resolv.conf for compatibility with the glibc resolver but I'd like to know whether or not, or to what extent, they also obey /etc/nsswitch.conf. I believe I understand your basic idea well enough. Instead of using resolv.conf to direct name queries to nm-dnsmasq, use a new NSS module. This new NSS module, foo, would be like the existing dns module except that it would only talk to nm-dnsmasq, or would allow other ports than 53 to be specified so that nm-dnsmasq could be talked to over another port than 53. The new module would be named on the hosts: line in /etc/nsswitch.conf instead of dns. (I don't see the point of listing both foo and dns, since foo *is* DNS.) But how much less work would this be than adapting the glibc code so that ports other than 53 can be specified, e.g., via a new config file with enhanced semantics that (if present) overrides resolv.conf? And how much less is the risk of breaking software that uses alternative resolver libraries? -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 NSS. This is because *everything* supports NSS. For instance, NIS and NIS+ hosts are done through NSS, and this is supported by essentially everything, because it's the standard. All of the enterprise directory services I've come across use an NSS plugin (usually the nis one). It's just simply the right way to do it. I wouldn't worry about resolver libraries that don't use glibc. They're typically DNS-specific, and are typically configured by their own files anyway. Dig, for instance, will use whatever server you tell it to, and ignore resolv.conf (though it uses it as a default). Same goes for the host tool -- they're used for querying specific DNS servers. However, those resolvers *also* ignore /etc/hosts, because that's referenced by the files NSS plugin. Any service that uses gethostbyname(3) is using glibc, and that's going to be everything except edge cases that are intentionally doing their own thing anyway. Things that try to emulate glibc behavior by first checking /etc/hosts and then /etc/resolv.conf are simply doing it wrong, and will miss (for instance) avahi, NIS, and any other directory service that may be installed. I'm surprised at the idea that it will be less work to modify glibc. Even if it's technically easier to make a change in the glibc code than to create your own NSS plugin, you have a myriad of problems: NM functionality would now have a dependency on a nonstandard patch of glibc, the documentation for /etc/resolv.conf will be inconsistent for only this distribution, there could (will) be resistance by the glibc folks, who knows what you'll break when you alter how glibc behaves, etc. However, with an NSS module, we have a huge number of advantages: * It's the standard way of achieving this type of thing and is hence supported by most everything * It's the standard way of achieving this type of thing so it's very well documented * It's the standard way of achieving this type of thing so it's very modularized and isolated, and if NM stops working it will continue along the chain without screwing up plugins further up like (unlike when dnsmasq dies with the proposed glibc change) * It's the standard way of achieving this type of things so the things that don't support it are, in general, doing it wrong and that's a bug on their end * It's the standard way of achieving this type of thing so there's already a package (libnss-mdns) that adds a hosts NSS module, meaning both that we know it works and that it is officially supported by ubuntu * It could be owned by the NM project instead of creating a dependency on a glibc patch that would not be taken up by distributions very quickly * You could make it do other interesting things like have static /etc/hosts-like entries per connection. You get the idea. If you want to see an example of an NSS hosts plugin packaged for ubuntu, that hooks into /etc/nsswitch.conf, look at the nss-mdns source package. The debian/libnss-mdns.postinst script that runs upon installation is what handles inserting it into /etc/nsswitch.conf, and can easily be adapted to handle inserting a NM plugin. If you want another example of an ubuntu package dealing with NSS plugins look at the auth-client-config package, though this one only handles the passwd, group, and shadow services. In short: An NSS plugin has vastly less risk of breaking software because Ubuntu already uses it and things aren't breaking (and it's also the standard, anyway), could actually be part of the NM project as opposed to owned by glibc, and will likely be easier than modifying glibc anyway due to fewer dependencies. This seems like win-win-win to me. To be clear, I'm advocating that we make a small NSS plugin wrapper around calls to a dnsmasq (or other) mini name server controlled by NM, that runs on a non-privileged port and can be spawned per-user. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 successfully getting to the Lubuntu splash screen. I have now set up forwarding of the client syslog messages to the server, and the log always ends with a string of ntpd items, the last of which is ntpd[1314]: Listening on routing socket on fd #24 for interface updates I found this other Ubuntu Precise bug (#999725) https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/999725 which reports that ntp is being started before DNS resolution is available. A quick scan of the initial comments shows that the discussion revolves around network-manager's handling of network configuration. The bug is currently marked Expired due to inactivity. Bug #999725 seems to involve some of the same issues as the ones dealt with here. Comments? Troubleshooting? Workarounds? -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 not related. Unfortunately I don't have any idea why the second client hangs whereas the first one doesn't. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 successfully getting to the Lubuntu splash screen. I have now set up forwarding of the client syslog messages to the server, and the log always ends with a string of ntpd items, the last of which is ntpd[1314]: Listening on routing socket on fd #24 for interface updates I found this other Ubuntu Precise bug (#999725) https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/999725 which reports that ntp is being started before DNS resolution is available. A quick scan of the initial comments shows that the discussion revolves around network-manager's handling of network configuration. The bug is currently marked Expired due to inactivity. Bug #999725 seems to involve some of the same issues as the ones dealt with here. Comments? Troubleshooting? Workarounds? -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 not related. Unfortunately I don't have any idea why the second client hangs whereas the first one doesn't. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 PXE-E32: TFTP open timeout. To be more specific on the DHCP assignments, it identifies my hardware router as the DHCP server and the default gateway. It identifies the LTSP server as proxy and boot server. Is your LTSP server running Ubuntu and standalone dnsmasq? Then shouldn't the client use your LTSP server as the DHCP server? The LTSP server is running Lubuntu with the default network configuration, whatever that is. I understand you to be saying that this would be a standalone instance of dnsmasq started by an initscript, prepared to handle DHCP and TFTP. And apart from that, network-manager starts another instance of dnsmasq to handle DNS. Regarding whether the client should use the LTSP server as the DHCP server: I imagine that it is prepared to handle DHCP, and probably does in a standard LTSP setup with 2 NIC's and the client connected to the second NIC, but in this LTSP-PNP setup with a single NIC, the client is connected to the router, and the LTSP server defers to the router handling DHCP. -- Your explanation is very interesting because it explains why my blindly- applied work-around is effective. (And kudos to Simon Kelley who is working to make it possible for everything to work as configured right out of the box.) But 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. Apart from not understanding how the conflict arises, I wonder: Should this conflict be manifesting itself somehow? Everything seems to be working right now. And would disabling network-manager's DNS-handling instance of dnsmasq then result in the need to set up an alternative DNS handler? I'm willing to apply another solution blindly, as I did in removing /etc/dnsmasq.d/network-manager, but it would be nice to understand more about it. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 dnsmasq starts in bind-interfaces mode and only listens on the addresses assigned to configured network interfaces. This does not include 127.0.1.1, since 127.0.1.1 is not the address of any configured interface. So in this mode standalone dnsmasq does not conflict with NM- dnsmasq which listens on 127.0.1.1. (At most one process can listen on any given address:port combination.) Remove that file and standalone dnsmasq starts in a mode where it tries to listen at all addresses. But it can't do this if NM-dnsmasq is already listening at some address. Should this conflict be manifesting itself somehow? Everything seems to be working right now. Well, I am not sure which workaround, if any, you are currently relying on. If you commented out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf then there is no conflict because NM doesn't start the NM-dnsmasq process. And would disabling network-manager's DNS-handling instance of dnsmasq then result in the need to set up an alternative DNS handler? No. If NM-dnsmasq is enabled then resolv.conf contains nameserver 127.0.1.1 so that applications using the resolver library access NM- dnsmasq; NM-dnsmasq forwards queries to the upstream nameserver at the address A.A.A.A which was obtained via DHCP or otherwise. If NM-dnsmasq is disabled then resolv.conf simply contains nameserver A.A.A.A. I'm willing to apply another solution blindly, as I did in removing /etc/dnsmasq.d/network-manager, but it would be nice to understand more about it. If you are running Ubuntu 12.04 then the best solution for now is to * comment out the bind-interfaces line in /etc/dnsmasq.d/network-manager; * comment out the dns=dnsmasq line in /etc/NetworkManager/NetworkManager.conf. If you are running Ubuntu 12.10 and have dnsmasq version 2.63-1ubuntu1 then you can, instead, * replace the bind-interfaces line in /etc/dnsmasq.d/network-manager with a bind-dynamic line. The bind-dynamic mode is the new mode that I referred to above and which Simon referred to earlier in comment #94. Please test it! If it works well then it should become the default, as mentioned above in comments ##99, 102. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 not sure which workaround, if any, you are currently relying on. If you commented out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf then there is no conflict because NM doesn't start the NM-dnsmasq process. My workaround was simply to remove /etc/dnsmasq.d/network-manager. Everything seemed to work after that. I did not comment out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf, which apparently should have subjected the system to the conflict described above. But as I say, I saw no problems. Could this be due to some compensation made by the new dnsmasq, since I am in fact running v.2.63? Thanks also for the explanation of how disabling NM-dnsmasq does not break DNS. Since I have dnsmasq v2.63, I tried the experimental solution: I restored /etc/dnsmasq.d/network-manager and replaced the bind- interfaces line with a bind-dynamic line. As far as I can tell, everything works. Thank you! -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 and NM fell back to non-dnsmasq mode, which works fine. If this hypothesis is correct then there may be lines in the syslog that look like this: [date] [hostname] NetworkManager[pid]: info DNS: starting dnsmasq... [date] [hostname] dnsmasq[pid]: failed to create listening socket for 127.0.1.1: Address already in use -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 PXE-E32: TFTP open timeout. To be more specific on the DHCP assignments, it identifies my hardware router as the DHCP server and the default gateway. It identifies the LTSP server as proxy and boot server. Is your LTSP server running Ubuntu and standalone dnsmasq? Then shouldn't the client use your LTSP server as the DHCP server? The LTSP server is running Lubuntu with the default network configuration, whatever that is. I understand you to be saying that this would be a standalone instance of dnsmasq started by an initscript, prepared to handle DHCP and TFTP. And apart from that, network-manager starts another instance of dnsmasq to handle DNS. Regarding whether the client should use the LTSP server as the DHCP server: I imagine that it is prepared to handle DHCP, and probably does in a standard LTSP setup with 2 NIC's and the client connected to the second NIC, but in this LTSP-PNP setup with a single NIC, the client is connected to the router, and the LTSP server defers to the router handling DHCP. -- Your explanation is very interesting because it explains why my blindly- applied work-around is effective. (And kudos to Simon Kelley who is working to make it possible for everything to work as configured right out of the box.) But 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. Apart from not understanding how the conflict arises, I wonder: Should this conflict be manifesting itself somehow? Everything seems to be working right now. And would disabling network-manager's DNS-handling instance of dnsmasq then result in the need to set up an alternative DNS handler? I'm willing to apply another solution blindly, as I did in removing /etc/dnsmasq.d/network-manager, but it would be nice to understand more about it. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 dnsmasq starts in bind-interfaces mode and only listens on the addresses assigned to configured network interfaces. This does not include 127.0.1.1, since 127.0.1.1 is not the address of any configured interface. So in this mode standalone dnsmasq does not conflict with NM- dnsmasq which listens on 127.0.1.1. (At most one process can listen on any given address:port combination.) Remove that file and standalone dnsmasq starts in a mode where it tries to listen at all addresses. But it can't do this if NM-dnsmasq is already listening at some address. Should this conflict be manifesting itself somehow? Everything seems to be working right now. Well, I am not sure which workaround, if any, you are currently relying on. If you commented out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf then there is no conflict because NM doesn't start the NM-dnsmasq process. And would disabling network-manager's DNS-handling instance of dnsmasq then result in the need to set up an alternative DNS handler? No. If NM-dnsmasq is enabled then resolv.conf contains nameserver 127.0.1.1 so that applications using the resolver library access NM- dnsmasq; NM-dnsmasq forwards queries to the upstream nameserver at the address A.A.A.A which was obtained via DHCP or otherwise. If NM-dnsmasq is disabled then resolv.conf simply contains nameserver A.A.A.A. I'm willing to apply another solution blindly, as I did in removing /etc/dnsmasq.d/network-manager, but it would be nice to understand more about it. If you are running Ubuntu 12.04 then the best solution for now is to * comment out the bind-interfaces line in /etc/dnsmasq.d/network-manager; * comment out the dns=dnsmasq line in /etc/NetworkManager/NetworkManager.conf. If you are running Ubuntu 12.10 and have dnsmasq version 2.63-1ubuntu1 then you can, instead, * replace the bind-interfaces line in /etc/dnsmasq.d/network-manager with a bind-dynamic line. The bind-dynamic mode is the new mode that I referred to above and which Simon referred to earlier in comment #94. Please test it! If it works well then it should become the default, as mentioned above in comments ##99, 102. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 not sure which workaround, if any, you are currently relying on. If you commented out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf then there is no conflict because NM doesn't start the NM-dnsmasq process. My workaround was simply to remove /etc/dnsmasq.d/network-manager. Everything seemed to work after that. I did not comment out dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf, which apparently should have subjected the system to the conflict described above. But as I say, I saw no problems. Could this be due to some compensation made by the new dnsmasq, since I am in fact running v.2.63? Thanks also for the explanation of how disabling NM-dnsmasq does not break DNS. Since I have dnsmasq v2.63, I tried the experimental solution: I restored /etc/dnsmasq.d/network-manager and replaced the bind- interfaces line with a bind-dynamic line. As far as I can tell, everything works. Thank you! -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 and NM fell back to non-dnsmasq mode, which works fine. If this hypothesis is correct then there may be lines in the syslog that look like this: [date] [hostname] NetworkManager[pid]: info DNS: starting dnsmasq... [date] [hostname] dnsmasq[pid]: failed to create listening socket for 127.0.1.1: Address already in use -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 your client is DHCPing with a dnsmasq instance on an Ubuntu server then that dnsmasq instance is most probably a standalone instance, configured by means of files included in the dnsmasq package (not to be confused with the dnsmasq-base package which contains little more than the dnsmasq binary and which both the dnsmasq package and the network-manager package depend on) and started by an initscript, not by NetworkManager. In reading further into your text my understanding is hampered by the fact that I am not entirely sure which machine you are referring to at different points in your text. The problem is that the LTSP client, after successfully getting DHCP assignments, fails to download the pxelinux boot image. It reports PXE-E32: TFTP open timeout. To be more specific on the DHCP assignments, it identifies my hardware router as the DHCP server and the default gateway. It identifies the LTSP server as proxy and boot server. Is your LTSP server running Ubuntu and standalone dnsmasq? Then shouldn't the client use your LTSP server as the DHCP server? So dnsmasq is not binding to my server IP during boot. If I remove /etc/dnsmasq.d/network-manager (which issues the sole dnsmasq directive to bind all the interfaces instead of listening on 0.0.0.0) and restart the server it allows the client to boot normally. I think I know what is happening. The network-manager package causes (by means of the /etc/dnsmasq.d/network-manager file) the standalone dnsmasq to start in bind-interfaces mode. In that mode dnsmasq doesn't listen on the wildcard IP address; it only listens on the addresses assigned to interfaces that are up when it (dnsmasq) starts. At boot, dnsmasq starts before the external interface is configured via DHCP, so dnsmasq doesn't listen on the external interface. If dnsmasq is restarted after the external interface is configured then dnsmasq listens on that interface too. If you remove /etc/dnsmasq.d/network-manager then standalone dnsmasq listens on the wildcard address when it starts and all is well except that now standalone dnsmasq conflicts with the NetworkManager-controlled dnsmasq instance. To fix this you have to disable the latter. Edit /etc/NetworkManager/NetworkManager.conf and comment out the line dns=dnsmasq: put a '#' at the beginning of the line. In the future we hope that standalone dnsmasq running in bind-interfaces mode will be enhanced such that it listens on interfaces that are brought up after it (dnsmasq) starts. The author of dnsmasq, Simon Kelley, has already implemented this enhancement experimentally. Once that work is done it will be possible to run dnsmasq in bind-interfaces mode without causing the problem that you ran into. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 your client is DHCPing with a dnsmasq instance on an Ubuntu server then that dnsmasq instance is most probably a standalone instance, configured by means of files included in the dnsmasq package (not to be confused with the dnsmasq-base package which contains little more than the dnsmasq binary and which both the dnsmasq package and the network-manager package depend on) and started by an initscript, not by NetworkManager. In reading further into your text my understanding is hampered by the fact that I am not entirely sure which machine you are referring to at different points in your text. The problem is that the LTSP client, after successfully getting DHCP assignments, fails to download the pxelinux boot image. It reports PXE-E32: TFTP open timeout. To be more specific on the DHCP assignments, it identifies my hardware router as the DHCP server and the default gateway. It identifies the LTSP server as proxy and boot server. Is your LTSP server running Ubuntu and standalone dnsmasq? Then shouldn't the client use your LTSP server as the DHCP server? So dnsmasq is not binding to my server IP during boot. If I remove /etc/dnsmasq.d/network-manager (which issues the sole dnsmasq directive to bind all the interfaces instead of listening on 0.0.0.0) and restart the server it allows the client to boot normally. I think I know what is happening. The network-manager package causes (by means of the /etc/dnsmasq.d/network-manager file) the standalone dnsmasq to start in bind-interfaces mode. In that mode dnsmasq doesn't listen on the wildcard IP address; it only listens on the addresses assigned to interfaces that are up when it (dnsmasq) starts. At boot, dnsmasq starts before the external interface is configured via DHCP, so dnsmasq doesn't listen on the external interface. If dnsmasq is restarted after the external interface is configured then dnsmasq listens on that interface too. If you remove /etc/dnsmasq.d/network-manager then standalone dnsmasq listens on the wildcard address when it starts and all is well except that now standalone dnsmasq conflicts with the NetworkManager-controlled dnsmasq instance. To fix this you have to disable the latter. Edit /etc/NetworkManager/NetworkManager.conf and comment out the line dns=dnsmasq: put a '#' at the beginning of the line. In the future we hope that standalone dnsmasq running in bind-interfaces mode will be enhanced such that it listens on interfaces that are brought up after it (dnsmasq) starts. The author of dnsmasq, Simon Kelley, has already implemented this enhancement experimentally. Once that work is done it will be possible to run dnsmasq in bind-interfaces mode without causing the problem that you ran into. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 with a single NIC per https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp. The problem is that the LTSP client, after successfully getting DHCP assignments, fails to download the pxelinux boot image. It reports PXE-E32: TFTP open timeout. To be more specific on the DHCP assignments, it identifies my hardware router as the DHCP server and the default gateway. It identifies the LTSP server as proxy and boot server. I can also run this on the server itself to get a similar failure: $ cd /tmp $ tftp 192.168.1.102 -v -m binary -c get /ltsp/i386/pxelinux.0 mode set to octet Connected to 192.168.1.102 (192.168.1.102), port 69 getting from 192.168.1.102:/var/lib/tftpboot/ltsp/i386/pxelinux.0 to pxelinux.0 [octet] Transfer timed out. A CRITICAL NOTE: This is using the default network-manager configuration of the network interface (using the default DHCP configuration, and the connection is Available to all users). If I merely configure the network interface (again for DHCP) via /etc/network/interfaces, the TFTP error disappears and the LTSP client boots. But it introduces a new problem on both server and client: DNS resolution fails. I can fix the DNS resolution problem by creating /etc/resolvconf/resolv.conf.d/tail with contents: nameserver (my nameserver 1) nameserver (my nameserver 2) But trying to identify and perhaps work around the problem with network- manager and dnsmasq, I undid the changes to /etc/network/interfaces and deleted /etc/resolvconf/resolv.conf.d/tail. It turns out that if I merely $ sudo service dnsmasq restart then the LTSP client will boot normally. Hunting for some diagnostic information, I ran this command before and after restarting dnsmasq: $ sudo netstat -nap | grep dnsmasq Relevant output before restarting: udp0 0 127.0.0.1:690.0.0.0:* 887/dnsmasq After restarting: udp0 0 127.0.0.1:690.0.0.0:* 1967/dnsmasq udp0 0 192.168.1.102:690.0.0.0:* 1967/dnsmasq (where 192.168.1.102 is the server IP) So dnsmasq is not binding to my server IP during boot. If I remove /etc/dnsmasq.d/network-manager (which issues the sole dnsmasq directive to bind all the interfaces instead of listening on 0.0.0.0) and restart the server it allows the client to boot normally. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 with a single NIC per https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp. The problem is that the LTSP client, after successfully getting DHCP assignments, fails to download the pxelinux boot image. It reports PXE-E32: TFTP open timeout. To be more specific on the DHCP assignments, it identifies my hardware router as the DHCP server and the default gateway. It identifies the LTSP server as proxy and boot server. I can also run this on the server itself to get a similar failure: $ cd /tmp $ tftp 192.168.1.102 -v -m binary -c get /ltsp/i386/pxelinux.0 mode set to octet Connected to 192.168.1.102 (192.168.1.102), port 69 getting from 192.168.1.102:/var/lib/tftpboot/ltsp/i386/pxelinux.0 to pxelinux.0 [octet] Transfer timed out. A CRITICAL NOTE: This is using the default network-manager configuration of the network interface (using the default DHCP configuration, and the connection is Available to all users). If I merely configure the network interface (again for DHCP) via /etc/network/interfaces, the TFTP error disappears and the LTSP client boots. But it introduces a new problem on both server and client: DNS resolution fails. I can fix the DNS resolution problem by creating /etc/resolvconf/resolv.conf.d/tail with contents: nameserver (my nameserver 1) nameserver (my nameserver 2) But trying to identify and perhaps work around the problem with network- manager and dnsmasq, I undid the changes to /etc/network/interfaces and deleted /etc/resolvconf/resolv.conf.d/tail. It turns out that if I merely $ sudo service dnsmasq restart then the LTSP client will boot normally. Hunting for some diagnostic information, I ran this command before and after restarting dnsmasq: $ sudo netstat -nap | grep dnsmasq Relevant output before restarting: udp0 0 127.0.0.1:690.0.0.0:* 887/dnsmasq After restarting: udp0 0 127.0.0.1:690.0.0.0:* 1967/dnsmasq udp0 0 192.168.1.102:690.0.0.0:* 1967/dnsmasq (where 192.168.1.102 is the server IP) So dnsmasq is not binding to my server IP during boot. If I remove /etc/dnsmasq.d/network-manager (which issues the sole dnsmasq directive to bind all the interfaces instead of listening on 0.0.0.0) and restart the server it allows the client to boot normally. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 desktop situations. It doesn't honor lookups against the local, specified by DHCP, DNS servers- it goes out to the DNS roots and goes from there. Works FINE for JUST surfing the 'net. It's an EPIC FAIL for normal, typical DNS use right now because there's no honoring any internal only DNS entries with it as it is out of box. It's nice that you're trying to make it easier for VPN, etc. but in the corporate desktop story, you're using OpenVPN, PPTP, or something like Sonicwall's solution. This means it's going to re-direct DNS on you ANYHOW, defeating the nice thing you're attempting here. If you think you're changing their minds, think again. As it stands, I'm going off to cripple this less than well thought out design decision so that things MIGHT work better on my setups. I suggest thinking through *ALL* prospective use-cases of things before implementing something like this in the future- it really, really ticks people off when it doesn't work like it's supposed to. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
@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 installations that use internal DNS What do you mean by internal DNS? It doesn't honor lookups against the local, specified by DHCP, DNS servers [...] Ubuntu 12.04 *does* use DNS nameserver addresses provided by DHCP. Can you please explain what you are talking about here? OpenVPN, PPTP, or something like Sonicwall's solution [is] going to re-direct DNS on you ANYHOW If you think you're changing their minds, think again. Ubuntu software works properly in Ubuntu 12.04 (except where it doesn't --- see the BTS). Third party software may fail to work properly, but it's up to the third party to fix that. Third parties who think they can dictate how free host operating systems work can go fly a kite. Just my personal view. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 desktop situations. It doesn't honor lookups against the local, specified by DHCP, DNS servers- it goes out to the DNS roots and goes from there. Works FINE for JUST surfing the 'net. It's an EPIC FAIL for normal, typical DNS use right now because there's no honoring any internal only DNS entries with it as it is out of box. It's nice that you're trying to make it easier for VPN, etc. but in the corporate desktop story, you're using OpenVPN, PPTP, or something like Sonicwall's solution. This means it's going to re-direct DNS on you ANYHOW, defeating the nice thing you're attempting here. If you think you're changing their minds, think again. As it stands, I'm going off to cripple this less than well thought out design decision so that things MIGHT work better on my setups. I suggest thinking through *ALL* prospective use-cases of things before implementing something like this in the future- it really, really ticks people off when it doesn't work like it's supposed to. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
@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 installations that use internal DNS What do you mean by internal DNS? It doesn't honor lookups against the local, specified by DHCP, DNS servers [...] Ubuntu 12.04 *does* use DNS nameserver addresses provided by DHCP. Can you please explain what you are talking about here? OpenVPN, PPTP, or something like Sonicwall's solution [is] going to re-direct DNS on you ANYHOW If you think you're changing their minds, think again. Ubuntu software works properly in Ubuntu 12.04 (except where it doesn't --- see the BTS). Third party software may fail to work properly, but it's up to the third party to fix that. Third parties who think they can dictate how free host operating systems work can go fly a kite. Just my personal view. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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
either, but upon (mis)reading comments above I presumed without
verifying. Bad on me.
A question about the NSS plugin idea. Will this work only for software
that uses glibc? What about alternative resolver libraries?
Anything that uses the gethostbyname(3) call uses the NSS chain. That
means essentially everything that isn't a resolver itself uses
nsswitch.conf. DNS resolver libraries won't use NSS by design, because
they are the resolvers themselves that are *used* by NSS. This is why
there are no names in their respective configuration files, save for
what they're serving (remote addresses are specified by address). If
any DNS resolver itself reads nsswitch.conf, it's doing somethign Very
Wrong.
The idea of NSS is that the DNS resolvers aren't *supposed* to use it.
They are the exporters of NSS services, not the consumers. I don't know
of any of them that use NSS for their own resolution; they are just one
link in the NSS chain that is used by the (libc) name resolver
libraries. When you hit the DNS service itself, you really *don't* want
it to start the NSS chain over, because that would just lead to a loop.
My proposal for using NSS in place of NetworkManager's dnsmasq is to
create a new NSS plugin and place it earlier in the NSS chain than the
standard DNS resolver. For instance, a line like so:
hosts: files mdns4_minimal [NOTFOUND=return] network_manager
[NOTFOUND=return] dns mdns4
This is straight from my Precise install, with the addition of the
network_manager [NOTFOUND=return] stanza. It says that first you
check /etc/hosts (that's files), then a subset of avahi
(mdns4_minimal [NOTFOUND=return]), then your NM plugin
network_manager [NOTFOUND=return], plain old DNS (dns), then avahi
again (mdns4).
It would not conflict with any other NSS plugin, because they are all
tried in turn until a match is found. If you place it directly in front
of the DNS resolver plugin in nsswitch.conf, it will be used before the
standard DNS lookup, allowing you to do all the fancy connection-
specific magic you need to do, while returning Try Next for anything
non-connection specific, thus allowing the normal DNS resolver plugin
(which reads resolv.conf) to do things as normal. This is *instead* of
hooking in at resolv.conf, as you do now. People can install any
resolver they want, and it works as designed. This lets you listen on
high-numbered ports as well, *and* lets you have per-user dnsmasq
instances (per user vpns?), while still running Bind or a normal dnsmasq
instance on *:53.
Right now, the dnsmasq for NM basically hijacks resolv.conf, which means
it's hooking into the DNS NSS plugin's resolution (it's the plugin that
reads resolv.conf, not the applications, using code in libc). This is
causing conflicts, because in order to use resolv.conf, you need to be
running on port 53 -- and it would take re-writing parts of the DNS NSS
plugin (or libc!) to change this. But, you don't need to do that at
all. Just insert the NM NSS plugin *before* the DNS NSS plugin, and you
can do all the fancy things you want, without ever breaking any DNS
resolution at all. If you don't have anything special to do, return
notfound and DNS will do its thing. Alternatively, you can *replace*
the DNS NSS library with your own (add yours to nsswitch and remove the
dns one), and do all processing in there, which will likely involve
querying the local dnsmasq instance directly without even bothering with
resolv.conf.
Really, the Name Service Switch subsystem is the system designed to
handle Switching between multiple Name Service providers. That's where
such things need to be. See documentation:
http://www.gnu.org/software/libc/manual/html_node/Name-Service-
Switch.html
--
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 bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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
either, but upon (mis)reading comments above I presumed without
verifying. Bad on me.
A question about the NSS plugin idea. Will this work only for software
that uses glibc? What about alternative resolver libraries?
Anything that uses the gethostbyname(3) call uses the NSS chain. That
means essentially everything that isn't a resolver itself uses
nsswitch.conf. DNS resolver libraries won't use NSS by design, because
they are the resolvers themselves that are *used* by NSS. This is why
there are no names in their respective configuration files, save for
what they're serving (remote addresses are specified by address). If
any DNS resolver itself reads nsswitch.conf, it's doing somethign Very
Wrong.
The idea of NSS is that the DNS resolvers aren't *supposed* to use it.
They are the exporters of NSS services, not the consumers. I don't know
of any of them that use NSS for their own resolution; they are just one
link in the NSS chain that is used by the (libc) name resolver
libraries. When you hit the DNS service itself, you really *don't* want
it to start the NSS chain over, because that would just lead to a loop.
My proposal for using NSS in place of NetworkManager's dnsmasq is to
create a new NSS plugin and place it earlier in the NSS chain than the
standard DNS resolver. For instance, a line like so:
hosts: files mdns4_minimal [NOTFOUND=return] network_manager
[NOTFOUND=return] dns mdns4
This is straight from my Precise install, with the addition of the
network_manager [NOTFOUND=return] stanza. It says that first you
check /etc/hosts (that's files), then a subset of avahi
(mdns4_minimal [NOTFOUND=return]), then your NM plugin
network_manager [NOTFOUND=return], plain old DNS (dns), then avahi
again (mdns4).
It would not conflict with any other NSS plugin, because they are all
tried in turn until a match is found. If you place it directly in front
of the DNS resolver plugin in nsswitch.conf, it will be used before the
standard DNS lookup, allowing you to do all the fancy connection-
specific magic you need to do, while returning Try Next for anything
non-connection specific, thus allowing the normal DNS resolver plugin
(which reads resolv.conf) to do things as normal. This is *instead* of
hooking in at resolv.conf, as you do now. People can install any
resolver they want, and it works as designed. This lets you listen on
high-numbered ports as well, *and* lets you have per-user dnsmasq
instances (per user vpns?), while still running Bind or a normal dnsmasq
instance on *:53.
Right now, the dnsmasq for NM basically hijacks resolv.conf, which means
it's hooking into the DNS NSS plugin's resolution (it's the plugin that
reads resolv.conf, not the applications, using code in libc). This is
causing conflicts, because in order to use resolv.conf, you need to be
running on port 53 -- and it would take re-writing parts of the DNS NSS
plugin (or libc!) to change this. But, you don't need to do that at
all. Just insert the NM NSS plugin *before* the DNS NSS plugin, and you
can do all the fancy things you want, without ever breaking any DNS
resolution at all. If you don't have anything special to do, return
notfound and DNS will do its thing. Alternatively, you can *replace*
the DNS NSS library with your own (add yours to nsswitch and remove the
dns one), and do all processing in there, which will likely involve
querying the local dnsmasq instance directly without even bothering with
resolv.conf.
Really, the Name Service Switch subsystem is the system designed to
handle Switching between multiple Name Service providers. That's where
such things need to be. See documentation:
http://www.gnu.org/software/libc/manual/html_node/Name-Service-
Switch.html
--
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:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 listen on 127.0.0.1:53, but
still doesn't allow them to listen on ALL:53. Someone correct me if I'm
wrong.
With bind, this is okay, mostly, because you can say to listen
on everything for a particular interface
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.
(but then you can't listen on 127.0.0.1, because it's the same
interface as 127.0.1.1)
You don't listen on an interface, you listen on a socket --- an
address:port pair. So when nm-dnsmasq binds 127.0.1.1:53, others can
still bind lo:53, i.e., 127.0.0.1:53.
A question about the NSS plugin idea. Will this work only for software
that uses glibc? What about alternative resolver libraries? They all
read resolv.conf, but do they all read nsswitch.conf too? The djbdns
description
http://cr.yp.to/djbdns/blurb/library.html
for one doesn't mention this.
--
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 bug go to:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 listen on 127.0.0.1:53, but
still doesn't allow them to listen on ALL:53. Someone correct me if I'm
wrong.
With bind, this is okay, mostly, because you can say to listen
on everything for a particular interface
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.
(but then you can't listen on 127.0.0.1, because it's the same
interface as 127.0.1.1)
You don't listen on an interface, you listen on a socket --- an
address:port pair. So when nm-dnsmasq binds 127.0.1.1:53, others can
still bind lo:53, i.e., 127.0.0.1:53.
A question about the NSS plugin idea. Will this work only for software
that uses glibc? What about alternative resolver libraries? They all
read resolv.conf, but do they all read nsswitch.conf too? The djbdns
description
http://cr.yp.to/djbdns/blurb/library.html
for one doesn't mention this.
--
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:
https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 particular interface (but then you can't listen on 127.0.0.1, because it's the same interface as 127.0.1.1), but other servers only have per-address configurations. The NSS plugin idea is *exactly* what NSS was designed for, and literally doesn't conflict with any name resolver in any way. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 particular interface (but then you can't listen on 127.0.0.1, because it's the same interface as 127.0.1.1), but other servers only have per-address configurations. The NSS plugin idea is *exactly* what NSS was designed for, and literally doesn't conflict with any name resolver in any way. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 don't know if it has been mentioned earlier in this thread, but one drawback of the adopted solution (i.e., making nm-dnsmasq listen at another address than 127.0.0.1) is that it breaks name service on machines that have no /etc/resolv.conf. In that case the resolver acts as if nameserver 127.0.0.1 were specified. Granted, Ubuntu Precise and higher machines should *not* lack /etc/resolv.conf.) -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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) and placing it in front of (or instead of) dns on the hosts line in /etc/nsswitch.conf. This would not conflict at *all* with any local DNS servers, and would work for anything that used the libc resolver. It's also vastly cleaner than the let's change multiple upstream packages options I see listed above. For extra points, it's probably past time to make a dbus nss plugin, which could be configured to talk to NM, which in turn would ask its personal dnsmasq instance running on any available port, or however it decided to track such things in the future. This would be a clean interface, with all resolving going through libc, with a well-defined API chain (libc --NSS-- dbusplugin --DBUS-- NetworkManager --DNS-- dnsmasq), and allow for NetworkManager to change the last step (DNS protocol to dnsmasq) to whatever in the future without re-architecting anything underneath. Or have the NSS plugin directly access dnsmasq and have NetworkManager manage its configuration, to follow dnsmasq port changes or what have you. It's not as future-proof, but it still gets the job done without conflicting with any resolvers. -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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) and placing it in front of (or instead of) dns on the hosts line in /etc/nsswitch.conf. This would not conflict at *all* with any local DNS servers, and would work for anything that used the libc resolver. It's also vastly cleaner than the let's change multiple upstream packages options I see listed above. For extra points, it's probably past time to make a dbus nss plugin, which could be configured to talk to NM, which in turn would ask its personal dnsmasq instance running on any available port, or however it decided to track such things in the future. This would be a clean interface, with all resolving going through libc, with a well-defined API chain (libc --NSS-- dbusplugin --DBUS-- NetworkManager --DNS-- dnsmasq), and allow for NetworkManager to change the last step (DNS protocol to dnsmasq) to whatever in the future without re-architecting anything underneath. Or have the NSS plugin directly access dnsmasq and have NetworkManager manage its configuration, to follow dnsmasq port changes or what have you. It's not as future-proof, but it still gets the job done without conflicting with any resolvers. -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 route cache entry notification; etc. dnsmasq will still need to be updated to ship the dbus file in dnsmasq- base isntead of dnsmasq, and the biggest, most time-consuming issue is that the dbus name changing patch needs to be adapted to apply to Precise's dnsmasq. ** Changed in: network-manager (Ubuntu Precise) Assignee: (unassigned) = Mathieu Trudel-Lapierre (mathieu-tl) -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 in: dnsmasq (Ubuntu Precise) Status: Confirmed = Triaged ** Changed in: dnsmasq (Ubuntu Precise) Assignee: (unassigned) = Mathieu Trudel-Lapierre (mathieu-tl) ** Changed in: network-manager (Ubuntu Precise) Importance: Low = High -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 route cache entry notification; etc. dnsmasq will still need to be updated to ship the dbus file in dnsmasq- base isntead of dnsmasq, and the biggest, most time-consuming issue is that the dbus name changing patch needs to be adapted to apply to Precise's dnsmasq. ** Changed in: network-manager (Ubuntu Precise) Assignee: (unassigned) = Mathieu Trudel-Lapierre (mathieu-tl) -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 in: dnsmasq (Ubuntu Precise) Status: Confirmed = Triaged ** Changed in: dnsmasq (Ubuntu Precise) Assignee: (unassigned) = Mathieu Trudel-Lapierre (mathieu-tl) ** Changed in: network-manager (Ubuntu Precise) Importance: Low = High -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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. https://bugs.launchpad.net/bugs/959037 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 Title: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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: NM-controlled dnsmasq prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: 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 nm-dnsmasq at 127.0.0.1. $ dpkg -l dnsmasq network-manager|grep ^ii ii dnsmasq 2.62-3 Small caching DNS proxy and DHCP/TFTP server ii network-manager 0.9.6.0~git201207161259.00297f4-0ubuntu1 network management framework (daemon and userspace tools) $ cat /etc/dnsmasq.d/network-manager # Tell any system-wide dnsmasq instance to not bind to the loopback interface. # WARNING: changes to this file will get lost if network-manager is removed. bind-interfaces except-interface=lo $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search [redacted] $ cat /var/run/dnsmasq/resolv.conf nameserver 127.0.0.1 $ cat /var/run/nm-dns-dnsmasq.conf server=192.168.1.254 server=195.241.76.55 server=195.241.76.58 $ sudo netstat -nl4p |grep :53 tcp0 0 192.168.1.20:53 0.0.0.0:* LISTEN 7039/dnsmasq tcp0 0 192.168.1.21:53 0.0.0.0:* LISTEN 7039/dnsmasq tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 6282/dnsmasq udp0 0 192.168.1.20:53 0.0.0.0:* 7039/dnsmasq udp0 0 192.168.1.21:53 0.0.0.0:* 7039/dnsmasq udp0 0 127.0.0.1:530.0.0.0:* 6282/dnsmasq udp0 0 0.0.0.0:53530.0.0.0:* 1103/avahi-daemon: -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 prevents other DNS servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
... 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: 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 nm-dnsmasq at 127.0.0.1. $ dpkg -l dnsmasq network-manager|grep ^ii ii dnsmasq 2.62-3 Small caching DNS proxy and DHCP/TFTP server ii network-manager 0.9.6.0~git201207161259.00297f4-0ubuntu1 network management framework (daemon and userspace tools) $ cat /etc/dnsmasq.d/network-manager # Tell any system-wide dnsmasq instance to not bind to the loopback interface. # WARNING: changes to this file will get lost if network-manager is removed. bind-interfaces except-interface=lo $ cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.0.1 search [redacted] $ cat /var/run/dnsmasq/resolv.conf nameserver 127.0.0.1 $ cat /var/run/nm-dns-dnsmasq.conf server=192.168.1.254 server=195.241.76.55 server=195.241.76.58 $ sudo netstat -nl4p |grep :53 tcp0 0 192.168.1.20:53 0.0.0.0:* LISTEN 7039/dnsmasq tcp0 0 192.168.1.21:53 0.0.0.0:* LISTEN 7039/dnsmasq tcp0 0 127.0.0.1:530.0.0.0:* LISTEN 6282/dnsmasq udp0 0 192.168.1.20:53 0.0.0.0:* 7039/dnsmasq udp0 0 192.168.1.21:53 0.0.0.0:* 7039/dnsmasq udp0 0 127.0.0.1:530.0.0.0:* 6282/dnsmasq udp0 0 0.0.0.0:53530.0.0.0:* 1103/avahi-daemon: -- 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: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 servers from starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
... 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
** 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 starting To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
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 Donovan ] * debian/source_network-manager.py: port package hook to python3. (LP: #1013171) [ Mathieu Trudel-Lapierre ] * debian/patches/lp292054_tune_supplicant_timeout_60s.patch: disable the patch. It adds unnecessary delays to things like detecting that hidden networks are not in range, and since Jaunty drivers have changed a lot. If we're still seeing timing issues with the supplicant, then perhaps the drivers should be fixed instead, or we'll re-enable the patch. (LP: #446623) * debian/network-manager.dnsmasq, debian/rules: install a config file to /etc/dnsmasq.d to avoid system-wide instances of dnsmasq to bind to 0.0.0.0 and the loopback interface, so that the NM- spawned instance can claim an IP on lo and provide local resolution. (LP: #959037) * debian/patches/add-veth-support.diff: add support for the veth* virtual ethernet devices. Thanks to Stéphane Graber for the patch. * debian/patches/nm-ip6-rs.patch: dropped, applied upstream. * debian/libnm-util2.symbols: add symbols: + nm_utils_file_is_pkcs12@Base * debian/control: move policykit-1 from Recommends to Depends: without it calls to the backend (e.g. when starting nm-tool), will fail. Thanks to Stéphane Graber for the testing and solution. * debian/rules: fix clean to properly remove m4/intltool.m4. * debian/tests/control, debian/tests/nm: add an autopkgtest control file and initial test to verify that NM works once installed. * debian/control: add XS-Testsuite: autopkgtest. -- Mathieu Trudel-Lapierre mathieu...@ubuntu.com Mon, 16 Jul 2012 17:17:51 -0400 ** Changed in: network-manager (Ubuntu) Status: Triaged = Fix Released -- 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 bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 959037] Re: NM-controlled dnsmasq prevents other DNS servers from starting
** 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 notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/djbdns/+bug/959037/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
