a small comment on isc dhcp
jw354 at cornell.edu
Wed Feb 28 17:25:14 UTC 2007
On Feb 28, 2007, at 10:40 AM, Tim Peiffer wrote:
> 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
> with '-t' you should change your configuration process and move along
> with best practices rather than continuing with the 'old way'.
> 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
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.
More information about the dhcp-users