Comment 14 for bug 231060

Revision history for this message
Emmet Hikory (persia) wrote :

@Simon, Thanks for the guidance. Of the options:

1) This seems least invasive in the short-term

2) There's a few potential issues here.

a) Install order, because defaults need to be adjusted, and services may need to restart. Some of this can be handled by triggers, but it requires cooperation (perhaps having some way that dnsmasq-base requires users to drop some file that dns-base can use to restart all users when new ones are installed, or similar awkwardnesses).

b) Removal independence: similar to install issues, the packages need to be able to coordinate uninstallation.

c) This interferes with use cases where a user wants to use dnsmasq to provide nameservice inside libvirt and to do dhcp/tftp on a local network simultaneously or similar cases: using a single demon makes having multiple configurations difficult.

3) The big item that struck me looking at this was that dnsmasq exits if unable to bind to every interface in wildcard mode: having this instead check error conditoins from bind failures and either internally drop the interface/address from the list of interfaces on which to listen or poll on the interface being available depending on the nature of the bind failue would significantly ease the difficulties of running multiple instances, especially one wildcard instance and one or more bound instances. It also eases the race condition identified in comment #11.

Another option would be to extend the D-Bus interface to permit D-Bus to be used to remove addresses or interfaces from the wildcard set to reserve them for use by a non-wildcard dnsmasq, preferably in combination with a D-Bus query on startup to automatically enter non-wildcard mode if there is already a wildcard server active and specifically exclude any addresses or interfaces already claimed by another instance.

This seems a lot of longer-term work though.

4) sounds kinda cool, but needing a lot more investigation and code than any of the other options.

    So, my plan is as follows:

1) Add a dpkg trigger subscription to dnsmasq that calls the initscript with force-reload if new configuration snippets are installed

2) Add a configuration snipped to libvirt that switches to bind-interface by default, and excludes virbr0

    This compeltely ignores the race condition between startng virbr0 adn starting dnsmasq, and it doesn't help for any sort of complex configuration (of either libvirt or dnsmasq), but it seems the least impact path to enable simultaneous operation without crippling either tool or needing extensive coding.