Patch: ntpdate option -p deprecated 🔗 link

On 12/2/2024 1:14 am, Roland Rosenfeld wrote:

Hi!

In Debian ntpdate from ntpsec package throws a warning that "-p is no
longer supported".  So it may be a good idea to remove the "-p 1" from
NTPDATEOPTS="-u -q -p 1"                        # Standard options to ntpdate
in xymond/etcfiles/xymonserver.cfg.DIST.

The attached patch solves this issue.

Greetings
Roland

On Mon, 12 Feb 2024, Brian Scott wrote:

The -p 1 option is still desirable for standard ntpd. The default is
to do 4 probes which is overkill for xymon.

I have just checked a fresh install of ntpsec from source and can't see
ntpdate being installed. Found this on the ntpsec site under Security
Improvements:

 * The deprecated and vulnerability-prone ntpdate program has been
   replaced with a shell wrapper around ntpdig. Its -e and -p options
   are not implemented. It is no longer documented, but can be found in
   the attic/ directory of the source distribution.

I notice that in the script the behaviour when it finds the -p option is to
simply warn and ignore it:

p) echo "ntpdate: -p is no longer supported." >&2;;

So it's just a neatness thing. The script is undocumented (debian may have
pinched their man page from standard ntp) and unlikely to ever be updated.

Not sure where this leaves us. I know others had similar problems when
distros moved to chrony for ntp. Maybe we need a more generalised approach
to different ntp implementations going forward.

On 12/2/2024 8:08 pm, Roland Rosenfeld wrote:

Hi Brian!

On Mon, 12 Feb 2024, Brian Scott wrote:

The -p 1 option is still desirable for standard ntpd. The default is
to do 4 probes which is overkill for xymon.

You are right, but I'm not sure, whether there are still current
systems using the original ntpd.

I have just checked a fresh install of ntpsec from source and can't see
ntpdate being installed. Found this on the ntpsec site under Security
Improvements:

  * The deprecated and vulnerability-prone ntpdate program has been
    replaced with a shell wrapper around ntpdig. Its -e and -p options
    are not implemented. It is no longer documented, but can be found in
    the attic/ directory of the source distribution.

I notice that in the script the behaviour when it finds the -p option is to
simply warn and ignore it:

p) echo "ntpdate: -p is no longer supported." >&2;;

So it's just a neatness thing. The script is undocumented (debian may have
pinched their man page from standard ntp) and unlikely to ever be updated.

Not sure where this leaves us. I know others had similar problems when
distros moved to chrony for ntp. Maybe we need a more generalised approach
to different ntp implementations going forward.

Maybe the best way for ntpsec users is to replace the ntpdate call
with a final ntpdig call (which saves one shell script call).
As far as I can see "ntpdate -u -q foo" with ntpsec-ntpdate wrapper
simply calls "ntpdig -t 1 foo", so why not directly use this?

On Tue, 13 Feb 2024 at 00:07, Brian Scott <user-b09d5329b577@xymon.invalid> 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.

On Mon, February 12, 2024 14:05, Jeremy Laidman wrote:

On Tue, 13 Feb 2024 at 00:07, Brian Scott <user-b09d5329b577@xymon.invalid> 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.

On 13/2/2024 9:05 am, Jeremy Laidman wrote:

On Tue, 13 Feb 2024 at 00:07, Brian Scott <user-b09d5329b577@xymon.invalid> 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.

On Tue, 13 Feb 2024 at 10:57, Brian Scott <user-b09d5329b577@xymon.invalid> wrote:

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.