[Dnsmasq-discuss] Feature Requests - logrotate / mysql / pam style config dir and SIGUSR2 to reload config

[Simon Kelley]

Aaron Tygart wrote:
> First off, I've been using dnsmasq for a little while now to manage
> the dns/dhcp configuration for the Beocat cluster here at Kansas State
> University.  I think it's a very nice bit of code, keeps my management
> down to a minimum with its simple configuration directives and
> all-in-one dns/dhcp features. So, many thanks to Simon Kelley (and I'm
> sure others) for his hard work.
> 
> There's two features that I would like to see that would make adding
> new nodes and updating configurations a total walk in the park.
>  1 - A logrotate / mysql / pam style configuration directory.  I'd
> like to see a /etc/dnsmasq.d directory to store configuration info
> like the aforementioned programs do.  Presently, I have external files
> for keeping different parts of the cluster separate for easier
> management.  I would like to not have to put another entry into
> /etc/dnsmasq.conf for each separate config file, it would be nice to
> just have to put a new file in /etc/dnsmasq.d and it would get picked
> up.  I could patch the init script to just read that directory and add
> --config-file=$file to the program before it starts, but having this
> built-in fits better with my next request.
>  2 - SIGUSR2 reloads the configuration file.  Right now, when I want
> to make configuration changes, I have to restart the init script,
> resulting in a tiny (but bothers me) bit of downtime. I'd like to be
> able to send SIGUSR2 and have it reload the configuration.
> 
> So there's my requests.  If you know of a better way / think it's too
> much work / think these features are useless, don't hesitate to tell
> me and I'll figure out something else or just deal with it.
> 

Aaron,

Your first suggestion looks very sensible and quite straighforward to 
do:  I'll look into that further.

The second suggestion (reload config on signal) has two problems, one is 
can be got round with enough programming, the other is much more difficult.

The show-stopper is that dnsmasq usually starts up running as root, and 
then throws away the root priviledges and runs as an ordinary userid. 
This is a security feature: it greatly limits the damage should a 
code-execution exploit be found (none ever has, BTW). Root is needed to 
do things like binding sockets to low ports. Since dnsmasq would have 
thrown away root by the time it got SIGUSR2, this creates a situation in 
which a perfectly legal configuration (which would work fine if starting 
dnsmasq from scratch) could cause an error on a reload. A simple example 
would be turning on DHCP and sending SIGUSR2. dnsmasq fails to bind port 
68 and DHCP won't work.

The other problem is simply that the data-structures derived from the 
configuration information get very tangled up with other stuff as 
dnsmasq runs: it's very difficult to simply replace that information 
without all sorts of strange states and dangling pointers. This problem 
is found in the existing code which changes the virtual dhcp-host 
entries created  by re-reading /etc/hosts and /etc/ethers, and it's not 
quite right even in that simple case (it's improved in the next release.)

The best that one could really do would be to have an always-root 
process which runs the real dnsmasq process as a child, and kills and 
restarts it in SIGUSR2, but that's just re-implementing what the startup 
script does anyway.

Cheers,

Simon.