Re: Orphaning dnsmasq
On Wed, 24 Aug 2011, Ian Pilcher wrote: On 08/22/2011 06:35 PM, Paul Wouters wrote: If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on. Are you talking about dnsmasq or the way that libvirt uses dnsmasq? I am talking about livirtd's usage. It's confusing and bad for various reasons, but most importantly: 1) Prevents other DNS resolvers from listening (eg DNSSEC aware ones) 2) service dnsmasq stop fails because it is not started as a regular service When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers. Here the issue is: 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it) The biggest problem for me is wanting to run a DNSSEC aware resolver, and the libvirtd/dnsmasq is preventing me from doing a simple yum install unbound|bind by stealing port 53. Especially on my laptop with libvirtd Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 2011-08-25 at 10:24 -0400, Paul Wouters wrote: On Wed, 24 Aug 2011, Ian Pilcher wrote: On 08/22/2011 06:35 PM, Paul Wouters wrote: If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on. Are you talking about dnsmasq or the way that libvirt uses dnsmasq? I am talking about livirtd's usage. It's confusing and bad for various reasons, but most importantly: 1) Prevents other DNS resolvers from listening (eg DNSSEC aware ones) 2) service dnsmasq stop fails because it is not started as a regular service When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers. Here the issue is: 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it) On a non-bridged setup it listens just on the virbr private interface address so at least in such setups it does not conflict with bind running as a local caching nameserver. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
2011/8/25 Paul Wouters p...@xelerance.com: Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free. Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53? In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces. - Thomas [1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces. -- Thomas Moschny thomas.mosc...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On 25/08/11 15:24, Paul Wouters wrote: Here the issue is: 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it) The biggest problem for me is wanting to run a DNSSEC aware resolver, and the libvirtd/dnsmasq is preventing me from doing a simple yum install unbound|bind by stealing port 53. Especially on my laptop with libvirtd I think you've got something odd going on I'm using a bridged setup with libvirt and although I do have a dnsmasq running it is for the private network defined in libvirt (which I'm not using) and it is only listing on that private network's address. So when I list networks I just have the default one: virsh # net-list Name State Autostart - default active yes and it is defined over a private address range: virsh # net-dumpxml default network namedefault/name uuid6229892b-486a-4c48-961a-20298d585e47/uuid forward mode='nat'/ bridge name='virbr0' stp='on' delay='0' / mac address='52:54:00:37:0B:C2'/ ip address='192.168.122.1' netmask='255.255.255.0' dhcp range start='192.168.122.2' end='192.168.122.254' / /dhcp /ip /network and that is what lsof shows dnsmasq as listening on: dnsmasq 2229 nobody6u IPv4 23692 0t0 TCP 192.168.122.1:domain (LISTEN) Though like I say, I don't actually use that as I have br0 setup as a bridge to my ethernet card and use bridged networking with that instead. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 25 Aug 2011, Tomas Mraz wrote: 3) I mostly don't need/want any DNS/DHCP in my bridged setup, but it still configures and starts dnsmasq (at least on F14 using virt-manager) (eg I have a /28 bridges to eth1 with static IPs, I don't want it) On a non-bridged setup it listens just on the virbr private interface address so at least in such setups it does not conflict with bind running as a local caching nameserver. Okay, good to know. Though I'd guess most people (esp on laptops) would bridge their VMs to the local ethX/wlanX to provide connectivity. If the NATed setup, those VM's could go out but would not be reachable by a local IP. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 25 Aug 2011, Thomas Moschny wrote: 2011/8/25 Paul Wouters p...@xelerance.com: Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free. Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53? In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces. - Thomas [1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces. I'll double check with f16 alpha on some iron and if it is still a problem, get back and file a bug to formalise talking about this. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, Aug 25, 2011 at 04:37:26PM +0200, Thomas Moschny wrote: 2011/8/25 Paul Wouters p...@xelerance.com: Again, this is based on f14, not f15/f16. I am not sure how much this has been addressed. But if we want DNSSEC validation on the endnode, at the very least 127.0.0.1:53 needs to be left free. Are you sure the dnsmasq instance started by libvirt is really grabbing 127.0.0.1:53? libvirt's dnsmasq will never be grabbing any 127.0.0.1 address. It is configured to only bind to the IP addresses directly associated with the bridge of the virtual network. # netstat -a -n -p | grep dnsmasq tcp0 0 192.168.123.1:530.0.0.0:* LISTEN 14230/dnsmasq tcp0 0 192.168.124.1:530.0.0.0:* LISTEN 14208/dnsmasq tcp0 0 192.168.122.1:530.0.0.0:* LISTEN 14007/dnsmasq udp0 0 192.168.123.1:530.0.0.0:* 14230/dnsmasq udp0 0 192.168.124.1:530.0.0.0:* 14208/dnsmasq udp0 0 192.168.122.1:530.0.0.0:* 14007/dnsmasq udp0 0 0.0.0.0:67 0.0.0.0:* 14230/dnsmasq udp0 0 0.0.0.0:67 0.0.0.0:* 14208/dnsmasq udp0 0 0.0.0.0:67 0.0.0.0:* 14007/dnsmasq # ip addr | grep 192 inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 inet 192.168.124.1/24 brd 192.168.124.255 scope global virbr2 inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr1 The wildcard bind on the UDP port number 67 there is not a problem because dnsmasq will only reply to requests coming in on the interface that it is configured to use. In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces. Yeah, that is the normal problem people see. The default dnsmasq configuration is to bind to all interfaces, which obviously blocks libvirt. other DNS local servers may also exhibit the same problem of binding to all interfaces, and need to be configured to only bind to specific ones. [1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces. For interoperability with libvirt, any dnsmasq instance *must* use the --bind-interfaces argumement, in combination with either '--interface=XXX' or '--listen-address=XX.XX.XX.XX' Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Thu, 25 Aug 2011, Daniel P. Berrange wrote: libvirt's dnsmasq will never be grabbing any 127.0.0.1 address. It is In my experiments it did not, and the issue instead was that the other DNS server [1] wanted to grab port 53 on *all* interfaces. Yeah, that is the normal problem people see. The default dnsmasq configuration is to bind to all interfaces, which obviously blocks libvirt. other DNS local servers may also exhibit the same problem of binding to all interfaces, and need to be configured to only bind to specific ones. [1] In my case that was a second instance of dnsmasq, and I had to set --interface=lo and --bind-interfaces. unbound and bind both only grab 127.0.0.1:53 and ::1:53 on their default installs. So it looks like this problem has been solved or went away. Thanks for the answers everyone! Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On 08/22/2011 06:35 PM, Paul Wouters wrote: If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on. Are you talking about dnsmasq or the way that libvirt uses dnsmasq? The interfaces on which dnsmasq listens are configurable with the 'interface' and 'listen-address' parameters in /etc/dnsmasq.conf. When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers. -- Ian Pilcher arequip...@gmail.com If you're going to shift my paradigm ... at least buy me dinner first. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On 08/24/2011 12:24 PM, Ian Pilcher wrote: When libvirt starts dnsmasq, it tells it to ignore the configuration file and passes all of the parameters on the command line. If you want dnsmasq to not listen on 0.0.0.0:53 when it's started by libvirt, you'll have to take that up with the libvirt developers. At least for a NAT network, it does bind tightly, e.g. I see: --bind-interfaces --except-interface lo --listen-address 192.168.122.1 Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
Hello Stephen, On 08/22/2011 01:49 PM, Stephen Gallagher wrote: (Sent on behalf of jima, the former owner) The dnsmasq package in Fedora has now been orphaned. This package is in need of a new maintainer and should not be allowed to lapse, as it is a critical component of the virtualization features. It is used by libvirt to manage DNS/dhcp for client VMs hosted on a machine, and as such is a mandatory piece of the virtualization puzzle. It would probably then be best if one of the libvirt developers took ownership. I took. -- Cheers Douglas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Mon, 22 Aug 2011, Stephen Gallagher wrote: (Sent on behalf of jima, the former owner) The dnsmasq package in Fedora has now been orphaned. This package is in need of a new maintainer and should not be allowed to lapse, as it is a critical component of the virtualization features. It is used by libvirt to manage DNS/dhcp for client VMs hosted on a machine, and as such is a mandatory piece of the virtualization puzzle. It would probably then be best if one of the libvirt developers took ownership. If it could also not grab port 0.0.0.0:53 in the future, that would be great. I'd like to work with whichever libvirt developer takes this package on. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning dnsmasq
On Mon, Aug 22, 2011 at 03:33:58PM -0400, Douglas Landgraf wrote: Hello Stephen, On 08/22/2011 01:49 PM, Stephen Gallagher wrote: (Sent on behalf of jima, the former owner) The dnsmasq package in Fedora has now been orphaned. This package is in need of a new maintainer and should not be allowed to lapse, as it is a critical component of the virtualization features. It is used by libvirt to manage DNS/dhcp for client VMs hosted on a machine, and as such is a mandatory piece of the virtualization puzzle. It would probably then be best if one of the libvirt developers took ownership. I took. Thanks, I certainly watch the package, but I'm happy to delegate this :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
