[libvirt] [PATCH] bridge_driver: use conffile for dnsmasq if it exists

[Daniel P. Berrange]

On Tue, Dec 21, 2010 at 09:47:10PM -0700, Eric Blake wrote:
> On 12/21/2010 03:40 PM, Paweł Krześniak wrote:
> > By default dnsmasq is spawned with option --conf-file="" which disables
> > reading of global configuration file -- this is fine for most situations.
> 
> In fact, the libvirt policy is that it is essential to NOT allow the use
> of global configuration files - if it is worth changing, it is worth
> calling out directly in the XML directly.  Why?  Because if you run your
> guest today, then someone edits the global config file, and you run your
> guest tomorrow, you have no explainable reason logged in libvirt's
> generated qemu/dnsmasq/... command line that explains the difference in
> behavior, if those differences are hidden inside a global config file of
> an external tool.  Furthermore, from the security perspective, sVirt
> requires that separate domains cannot share resources, and that should
> include common host config files.
> 
> > This patch adds possibility to run customized DNS/DHCP environment, by
> > spawning dnsmasq with alternative configuration file if such file exists.
> > This allows you to set any parameter described in dnsmasq(8).
> > Configuration file is expected to be located in file named
> > "<network_name>-dnsmasq.conf" in DNSMASQ_STATE_DIR directory.
> > If configuration file doesn't exists dnsmasq is spawned as before.
> 
> You'll want to wait for danpb or DV to comment, but I'm thinking this
> might be rejected, and that instead, we should consider addressing the
> issue of what dnsmasq parameters you want to affect, and how we can
> encode that into the libvirt XML without having to rely on an external
> dnsmasq conf file.

Correct. dnsmasq is the current linux specific implementation
detail. The fact that we use dnsmasq is not a guarenteed part
of the public API/ABI and as such dnsmasq specific bits should
not be part of the XML. If there are further configuration
params that are required we need to model them in the XML
formally.

NB, there was a discussion with the dnsmsaq maintainer a few
months back now about changing the dnsmasq architecture such
that we only need one dnsmasq process. We would be hard
pressed to do such a change if we allowed arbitrary dnsmasq
config files to be passed in the XML because we cannot see
what the implications would be.

So, NACK to this patch

Regards,
Daniel