Re: [libvirt] [PATCH 1/6] v6-6: put dnsmasq parameters into a file
On 11/09/2012 08:39 AM, Gene Czarcinski wrote:
On 11/09/2012 07:36 AM, Guido Günther wrote:
> On Thu, Nov 08, 2012 at 04:13:41PM -0500, Gene Czarcinski wrote:
>> >This patch changes how parameters are passed to dnsmasq. Instead of
>> >being on the command line, the parameters are put into a file (one
>> >parameter per line) and a commandline --conf-file= specifies the
>> >location of the file. The file is located in the same directory as
>> >the leases file.
> It'd be great if the commit message would state_why_ this is useful.
> Cheers,
Much as it pains me to admit it but you have a valid point. I have
been working on this for some time and the usefulness of this is
"obvious" to me. While one of the first objectives was to remove the
command line clutter by moving the dnsmasq parameters into a
conf-file, it is with some planned (by me) future
additions/enhancements where it becomes more important.
1. Specify a second conf-file which will initially be allocated as a
zero-length file. This file will not be deleted when the network is
destroyed. The purpose here is to be able to add log-queries and/or
log-dhcp parameters to turn on dnsmasq logging. This can produce a
log of clutter in syslog so it should be used onlt when necessary.
But, when it it needed, it can be the only way to figure out what is
happening.
I thought that we had determined this wouldn't work, because dnsmasq has
its capabilities/privileges dropped as soon as it does the initial read
of its config, and so it can't re-read its config files?
Even if that isn't the case and dnsmasq *is* able to reread this config
file, we can't allow that until we have a "network tainting" system in
place similar to what we currently have for domains. This is needed to
make it plainly clear that a configuration is operating "outside the
box" and therefore all troubleshooting assumptions are invalid (this is
what happens to a domain when, for example, a direct qemu-monitor
command is sent to the domain, a "generic ethernet" device with a script
file is attached, or an arbitrary commandline option is added to the
qemu commandline).
As a matter of fact, I think the more proper method of implementing this
is to, as we've done in qemu, introduce a special dnsmasq namespace to
the network xml, and allow specifying arbitrary command args via xml in
that namespace. This way all of the config is still available in a
single location, so there's never a question during debugging of whether
or not extra command args were given to dnsmasq.
2. A previous patch I submitted which was accepted involved adding the
local=/<domain-name>/ parameter. With this parameter, dnsmasq will
not forward queries for the domain it handles. However, currently it
will forward reverse lookup queries for it subnetwork. The fix is to
add more local=/<ip4>.in-addr-arpa/ for IPv6 and
local=/<ip6>.ip6.arpa/. And "<ip6>.ip6.arpa" expands into a forty
four character string.
I also find it a lot easier to look and and understand a conf-file
than looking at the the command line.
It's the above reasons that are most compelling to me.
In addition, the rest of the string of submitted updates all assume
this this one is applied.
And lastly, from what I have observed, configuration files are
preferred to command line parameters.
Well, we do call qemu with a big hairy long commandline... :-)