a small comment on isc dhcp

[John Wobus]

On Feb 28, 2007, at 10:40 AM, Tim Peiffer wrote:
> Luc,
>
> I wrote the '-t' option into dhcpd many years ago because too many
> people had their fingers into the running config and it was easy to
> botch..  The thought on how to use '-t' goes as follows:
>
> 1) keep known working configurations pristine.
> 2) build or copy configurations into a working scratchpad space
> 3) verify syntactically correct in the scratchpad space.
>     a) veto if bad.
>     b) copy good scratch configuration into pristine space.
> 4) stop/start dhcpd
>
> Your note tends to indicate that  dhcpd should be more forgiving of
> mistakes.. without '-t' option I might agree with you.  On the 
> contrary,
> with '-t' you should change your configuration process and move along
> with best practices rather than continuing with the 'old way'.
>
> Regards,
> Tim Peiffer
> University of Minnesota

Adding to what Tim said:

We do exactly this, even though our DHCP configs are generated from our 
own database, installed,
and the daemon restarted, by our own script.  Script-generated configs 
reduce the chance of
random syntax errors, but we still use the -t option as a final sanity 
check before stopping
the service for reconfiguration.  I don't recall when this ever 
happened on our production
system, but it's dead simple to implement and comforting insurance.  I 
have no doubt
many other sites do this as well.

Even if you maintain DHCP configs by hand, you can easily write a very 
short "restart the
dhcp server" script that prechecks the new config and leaves the server 
running
as before, should there be any problem.  If your site has the discipline
to stick to using a designated script for all dhcp daemon restarts, 
this prevents accidents, and you
can include any other sanity check that strikes your fancy.  For 
example, I like to incorporate
a minimum allowable config file length as an additional sanity check. A 
zero-length config file,
for example, does not pass.  It can also be useful to have a list of 
strings that you demand to see
in any new config file before it is allowed to run.

When a file has a "small" syntax error and is run with software written 
to "work around" syntax errors,
it's not clear that the software will read your intentions adequately.  
Of course, syntactically-correct
config files could still have mistakes and do something you really 
really don't want to happen,
but a syntactically incorrect file definitely has a mistake.

John Wobus
Cornell CIT