[Bug 526386] Re: dnsmasq exits using --interface if the interface does not exist yet

[Simon Kelley]

Emmet Hikory wrote:
>>From a brief look at the code, it appears that the relevant section is
> in src/dnsmasq.c : 169-189.  In this mode, if unable to access an
> interface because it doesn't exist, dnsmasq should poll the interface
> for a configurable timeout to see if it becomes available before
> quitting.  As there may be multiple interfaces, implementing this as a
> push-to-back-of-queue delay until there is only one interface polling
> will ensure that the majority of intentionally specified interfaces come
> up as quickly as if all interfaces existed.
> 

[This covers 231060 too, they're basically the same problem.]

Such code would be possible, but shouldn't be necessary. Going back to 
the original bug report, there are two problems, the first is the 
race-condition in libvirt, which could be fixed (I assume) by a delay 
between the synchronous creation of the virtual interface and the 
starting of dnsmasq.

The second problem is, paraphrasing, "we have problems with network 
interfaces which are created ad-hoc, come and go, and change IP address 
over time." It's for precisely this use case that I carefully coded the 
standard (ie not --bind-interfaces") network mode in dnsmasq, many years 
ago. Without bind-interfaces, dnsmasq works exactly as you wish in these 
circumstances. Many people have been using it with ad-hoc interfaces and 
don't have any problems. This is a non-problem, _except_ that lib-virt 
insists on running a private instance of dnsmasq, and therefore needs 
the --bind-interfaces command.

Adding polling hackery to get something like the sane behaviour which is 
available _by_default_ does seem like a bad idea, if there are other 
alternatives.

Can we try and enumerate exactly what services libvirt wants from 
dnsmasq on the virtual network? I think it should be possible to express 
that as some configuration fragments that libvirt can drop into 
/etc/dnsmasq.d and have a high confidence of not affecting any other 
existing configuration on a "system" dnsmasq, or accidentally providing 
services to non-virtual networks unless they are explicitly configured.
That way, libvirt can start up a dnsmasq instance a "system" dnsmasq is 
not running, but defer to the system dnsmasq if it is.

The trick here would be for libvirt to start dnsmasq as

if <system dnsmasq is not installed or enabled>
     dnsmasq --interface=virt0 --bind-interfaces
else
     /etc/init.d/dnsmasq restart


That would inhibit the usual dnsmasq behaviour of offering service on 
every interface unless configured otherwise. The --bind-interfaces means 
that it will work even if the system is running eg BIND on port 53 of 
other interfaces. By putting these on the command line, they won't be 
seen when a system dnsmasq is installed.

The rest of the configuration could be dropped in /etc/dnsmasq.d and 
suitably tagged so that it only applied to requests from virt0 (or 
whatever it's called). That way they will be picked up by a system 
dnsmasq and suitable service supplied to the virtual network by a system 
dnsmasq.


Note the pid-file of the libvirt dnsmasq should be the same as a system 
one, so that installing a system dnsmasq will stop the libvirt dnsmasq 
before starting the system one. For removing dnsmasq on a system which 
has libvirt installed, some code in post-rm of the dnsmasq package can 
poke libvirt to restart its private instance.


The only problem I can see with this so far goes like this.

Consider a "system" dnsmasq install, that just does the default, ie it 
provides a DNS service, but no DHCP service. Now install libvirt, which 
configures DHCP for virt0 with

dhcp-range=<stuff>

That actually enables DHCP on every interface (no command-line 
--interface flag, here, it's a system instance.) DHCP requests on other 
interfaces will fail, because there won't be a suitable dhcp-range, but 
there will be log messages to that effect, and general unpleasantness, 
there's also the remote possibility that the libvirt address range could 
overlap with a real interface and then DHCP service would be provided on 
a real interface.

To fix this, lets add to dhcp-range

dhcp-range=interface:virt0,<stuff>

The semantics of this is to _only_ provide and DHCP service on virt0
_unless_ there's another dhcp-range line without an 
interface;<interface> part, when the original sematics rule.


How does that sound?

Simon.

-- 
dnsmasq exits using --interface if the interface does not exist yet
https://bugs.launchpad.net/bugs/526386
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in ubuntu.