[Bug 231060] Re: packages dnsmasq and libvirt-bin conflict with each other

[Simon Kelley]

Thierry Carrez wrote:
> @Simon: what are the options from a dnsmasq perspective ?
> 

Some background: dnsmasq can run in two modes.

Default mode: dnsmasq binds the wildcard address and does network magic 
to determine which interface request packets actually come from, so that 
the results can be send back with the correct source address. This has 
the advantage that network interfaces can come and go and change IP 
address and dnsmasq will keep working. It's possible to restrict dnsmasq 
to only reply to requests on some interfaces; requests from other 
interfaces will be read by dnsmasq and then silently dropped. Telling 
dnsmasq to use an interface which doesn't exist but might in the future 
will result in a logged warning, but dnsmasq will still start and when 
the interface comes up it will work.

Bind-interfaces mode: This is the traditional way to do UDP servers. At 
startup dnsmasq enumerates all the extant interfaces and then opens a 
socket for each one, listening on the interfaces's IP address. 
Interfaces may be skipped if excluded by the --interface and 
--except-interface flags, and any interface specified in --interface 
which doesn't exist at start-up will generate a fatal error.


In almost all cases, default mode is better: --bind-interfaces is only 
there to cope with old platforms which don't support enough socket 
options to do default mode.

The only time when --bind-interfaces works better is when it's desirable 
to run more than one instance of dnsmasq. This is not possible in 
default mode, but it does work in bind-interfaces mode, providing than 
_all_ instances are in bind-interfaces mode, and that they listen on a 
disjoint set of interfaces. This is what the libvirt package attempts to 
do, as I understand it: it starts its own dnsmasq in --bind-interfaces 
mode listening on a virtual interface and it forces any "system" dnsmasq 
into --bind-interfaces mode and away from the the virtual interface by 
dropping a configuration fragment into /etc/dnsmasq.d

This method brings the disadvantages of --bind-interfaces to the private 
libvirt dnsmasq instance (the race condition at start-up) and to the 
"system" dnsmasq (which will no longer cope with changes to network 
interfaces.)


Options.

1) Keep doing what you're doing, work around the race condition and 
accept that installing libvirt will limit the functionality of a system 
dnsmasq by forcing it into --bind-interfaces mode.

2) Arrange that if libvirt and a "system" dnsmasq co-exist, libvirt uses 
the system dnsmasq, rather than starting its own. It should be possible 
to drop some configuration to make the system dnsmasq do what is needed 
  for libvirt. There's a problem here if libvirt is installed alone and 
using a private dnsmasq, and then subsequently a system dnsmasq is 
installed.

3) Make some changes to dnsmasq to improve the situation when two 
instances are running. This may be possible, but I don't have many clues 
what could be done.

4) Look at some sort of partitioning in the kernel so that the virtual 
interface is in some sort of separate partition with effectively two 
network stacks. A sort of chroot for networking. I don't know if this 
exists in the Linux container stuff, or could be done. It's not really 
my area.


HTH


Simon.

-- 
packages dnsmasq and libvirt-bin conflict with each other
https://bugs.launchpad.net/bugs/231060
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in ubuntu.