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.
--
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
