[Xymon] Patch: ntpdate option -p deprecated

[Brian Scott]

On 13/2/2024 9:05 am, Jeremy Laidman wrote:
> On Tue, 13 Feb 2024 at 00:07, Brian Scott <bscott at bunyatech.com.au> wrote:
>
>
>     i think using a discouraged wrapper like this makes no sense.
>
>     However, we still need some way to deal with the cases where the
>     default
>     is still the old ntp.
>
>     > The attached rewritten patch implements this.
>
>     Would you mind if I tried to generalise your patch to automatically
>     detect which version to use and pick the correct options
>     accordingly? A
>     quick look at the code suggests changes to configure.server, a new
>     script under build/ to detect which type of ntp is installed, and
>     possibly changes to the various build/Makefile.* to set a per-OS
>     default. Also I notice that the defaults when nothing is set in
>     xymonserver.cfg are established in lib/environ.c but they would be
>     quite
>     messy to tinker with.
>
>
> I don't think this should be done at compile/build time. The build 
> server might not use the same NTP package, or even the same version of 
> distro, or the same distro, or even the same OS.
>
> The xymonserver.cfg config file has NTPDATE and NTPDATEOPTS values 
> that can be modified by the sysadmin, to use ntpdig, chronyd, or 
> whatever is installed onto the Xymon server at the time. If ntpdate is 
> deprecated, perhaps these variables should now be adjusted to reflect 
> a more commonly installed NTP client.
>
> I'm not sure if the Xymon server does anything with the results of the 
> ntpdate query. If it does, then we need to be mindful that the parser 
> might not recognise the format of ntpdig output. In which case, a 
> wrapper might actually be the best solution. Perhaps the Xymon source 
> should provide a few different wrapper scripts called ntpdate-chrony, 
> ntpdate-ntpsec, etc, and the sysadmin can simply adjust NTPDATE to use 
> the appropriate wrapper script.

I think Xymon only cares about the success of the command (i.e. is the 
ntp* server running). ntpdig and ntpdate produce quite different output 
(I don't have a copy of chronyd around to check). All Xymon does is run 
the command and displays the output; no parsing is needed. This simply 
answers the question "Is an ntp service running?" and shouldn't be 
regarded as proper test of the ntp service ("Is it providing sane 
answers?", "Is it synced to a reasonable stratum level?", "Is it 
stable?", ...). Time offset (the only thing reliably given by the 
various commands) is better handled (but less accurately) by the normal 
Xymon process reading the client data since that doesn't require the 
client to be an ntp server.

I think the question what a 'proper' ntp test does doesn't matter until 
somebody with spare time writes a more complete and cross platform test 
then posts it on xymonton.

Cheers,

Brian

(BTW: ntpdig supports the -p option and it seems to work well with it - 
the problem is the wrapper script that doesn't pass it on)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20240213/bf874cce/attachment.htm>