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