Re: [PATCH 1/6] v6-6: put dnsmasq parameters into a file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]