12:49 p.m.
(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.
2:33 p.m.
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
10:14 p.m.
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/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
6:35 p.m.
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
2:24 p.m.
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 arequipeno(a)gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================
2:46 p.m.
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
9:24 a.m.
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
9:37 a.m.
2011/8/25 Paul Wouters <paul(a)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.moschny(a)gmail.com>
9:56 a.m.
On Thu, 25 Aug 2011, Thomas Moschny wrote:
2011/8/25 Paul Wouters <paul(a)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
9:57 a.m.
On Thu, Aug 25, 2011 at 04:37:26PM +0200, Thomas Moschny wrote:
2011/8/25 Paul Wouters <paul(a)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
tcp 0 0 192.168.123.1:53 0.0.0.0:* LISTEN
14230/dnsmasq
tcp 0 0 192.168.124.1:53 0.0.0.0:* LISTEN
14208/dnsmasq
tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN
14007/dnsmasq
udp 0 0 192.168.123.1:53 0.0.0.0:*
14230/dnsmasq
udp 0 0 192.168.124.1:53 0.0.0.0:*
14208/dnsmasq
udp 0 0 192.168.122.1:53 0.0.0.0:*
14007/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:*
14230/dnsmasq
udp 0 0 0.0.0.0:67 0.0.0.0:*
14208/dnsmasq
udp 0 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 :|
10:15 a.m.
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
9:37 a.m.
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
9:54 a.m.
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
9:40 a.m.
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>
<name>default</name>
<uuid>6229892b-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 nobody 6u 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 (tom(a)compton.nu)
http://compton.nu/
4634
days inactive
4637
days old
13 comments
10 participants
participants (10)
-
Daniel P. Berrange -
Daniel Veillard -
Douglas Schilling Landgraf -
Ian Pilcher -
Josh Stone -
Paul Wouters -
Stephen Gallagher -
Thomas Moschny -
Tom Hughes -
Tomas Mraz