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