[Nagiosplug-devel] Re: check_ntp plugin on the same host.

[Paul L. Allen]

Subhendu Ghosh writes: 

> I didn't get any feedback on that - I think I'll go ahead and patch it
> with default behavior going to ntpq.

Note that ntpdate is deprecated and has been for quite a long time.  At
some point in the future, ntpdate will cease to be included in the
NTP distribution (I know David Mills has been saying that for years,
but one day he may actually do it). 

> This will break existing usage against any Windows boxes....

I avoid Windows boxes as far as possible.  However, I think the Unix
design principles of "backwards compatibility" and "least surprise"
mean that you should make the existing behaviour the default.  Or, at
least, if the existing behaviour is not made the default the new behaviour
should be such that somebody with ntpdate but without ntpq will have a
working plugin (that is, it *looks* like the existing behaviour to a
naive user).  A switch to force existing behaviour is a bad idea
because it will break a lot of existing configs.  A switch to force new
behaviour is a bad idea because one day ntpdate will go away and then
there will be unnecessary switches in config files. 

Perhaps a better fix than a switch would be to determine what is
available at make time.  Check which of ntqp and ntpdate are available
and use ntpq if available else use ntpdate (or don't build the plugin if
neither are there).  There is one major advantage to doing this test
at run time (it works if you copy the plugin over to a different machine
with different commands available) and one minor disadvantage to doing
it at run time (the extra time required might just push a borderline
response time into a time-out).  Eiher way, defaulting to trying the
deprecated and less functional ntpdate first seems like a bad idea. 

Of course, the people who build on one machine then copy the plugins around
could get bitten by choosing at build time.  Then again, in most
organizations large enough to need Nagios, any one of several people could
have built a specific machine or the build could have been tailored for
many different reasons. I *always* build on the target machine because I
cannot guarantee what is there if others built it or if it needed a
tailored install for some reason or another.  It's easier for me to build
on the target machine than to try to keep track of the idiosyncracies of
every machine I might come into contact with so I can know which ones I can
safely copy stuff over to. 

Just thinking of the dependencies of various Nagios plugins is bad enough -
if some dependencies are missing on a target machine I want to know by the
plugin not being built, not spend time investigating why a plugin I copied
over isn't working only to find a dependency is missing.  If you build
on the target machine it's fairly easy for a newbie to notice that a
particular plugin is not there at all; if you copy plugins over it can be
hard even for the experienced to figure out there's a missing dependency. 

So my first choice is pick ntpq or ntpdate at build time.  My second
choice is try ntqp at run time and if it doesn't work then try
ntpdate.  But, whatever you do, it should behave (as far as externally-
observable behaviour goes) like the present version and not require
switches. 

-- 
Paul Allen
Softflare Support