[Xymon] Terebithia RPM's vs Build.

[phaleintx at gmail.com]

All,

We encountered the same issue when we migrated our Xymon servers up to
RHEL 8.  I went ahead and just built a copy of the ntpdate command from
source and installed it into the /usr/local/ directory stucture on the
xymon servers. Works fine once you do that.

Phil


-----Original Message-----
From: John Horne <john.horne at plymouth.ac.uk>
To: xymon at xymon.com <xymon at xymon.com>
Subject: Re: [Xymon] Terebithia RPM's vs Build.
Date: Fri, 8 Apr 2022 17:45:56 +0000

On Wed, 2022-03-30 at 09:51 -0400, Matt VanderWerf wrote:
> 
> One thing to note if you're using NTP checks is that Xymon uses
> ntpdate by
> default for these checks but ntpdate doesn't exist at all in any RHEL
> 8 repos
> at all (neither does ntp), nor does it exist in any trusted third-
> party
> repos, as it was completely replaced by chrony in RHEL 8 (chronyc is
> the
> client tool). chrony also requires you make certain changes in the
> chrony.conf file on any clients you use the NTP check on to allow the
> chronyc
> remote commands to work.
> 
> You can change the binary/path for what is used for the NTP checks
> and the
> options used (NTPDATE and NTPDATEOPTS in xymonserver.cfg) but there
> are also
> some hard coded parts in the source code which go by what it assumes
> the
> ntpdate command output format looks like, which doesn't match chronyc
> output
> at all. So if you use NTP checks, you'll need to figure out a way to
> extract
> the chronyc output to match the ntpdate output or do without the NTP
> checks.
> Note this is the same issue regardless if you're using the Xymon
> source or
> the Terabithia RPMs. (See past discussion on this here and here.)
> 
Hello,

Yes, I noticed myself the lack of ntpdate in RHEL 8 based
distributions. We are
slowly moving our servers from CentOS 7 to Rocky Linux 8. As you say
using
chrony on a client server is not a problem. The problem is using chrony
on the
Xymon server itself.

It is possible to get output from chrony containing some information by
using:

=====
chronyd -Q 'server <name or addr> iburst'
2022-04-08T17:33:22Z chronyd version 4.1 starting (+CMDMON +NTP
+REFCLOCK +RTC
+PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 +DEBUG)
2022-04-08T17:33:22Z Disabled control of system clock
2022-04-08T17:33:27Z System clock wrong by 0.000660 seconds (ignored)
2022-04-08T17:33:27Z chronyd exiting
=====
This works as a non-privileged user.
So the above 'system clock wrong' bit is equivalent to the ntpdate
offset
value.

Looking at the Xymon source, the ntp test already supports output
formats from
sntp and ntpdate. It should therefore be able to add in another section
for the
'chronyd' output.

I have also found that under Fedora 35, but not RHEL 8, Debian 11 or
CentOS
Stream 9, there is an 'ntpcheck' package which provides various NTP
utility
commands. One of those replicates 'ntpdate' (again it works as a non-
privileged
user):

========
ntpcheck utils ntpdate -s 10.10.10.10

Server: 10.10.10.10:123, Stratum: 2, Requests 3
Last Request:
Offset: -0.000438s (-438us) | Delay: 0.028902s (28902us)
Correct Time is 2022-04-08 18:07:55.767783923 +0100 BST

Average (3 requests):
Offset: -0.000519s (-519us) | Delay: 0.028867s (28867us)
========

I would say that if Xymon is to be modified, then it might be useful to
cater
for the 'ntpcheck' output as well. (The code itself seems to be
relatively new;
started in 2020 it seems on github.)

In our case we already make a small modification to Xymon such that if
the
client stratum goes above a per-host configured value, then the test
turns red.
The problem is that the chrony output does not show the stratum value!
I will have to think about this, but options look like build from
source
ntp/ntpdate (it is only the ntpdate command itself that we need);
rebuild the
ntpcheck package for Rocky 8; or modify the chronyd output so as to
include the
stratum value. (Really don't fancy doing that, and will need to check
the very
latest chrony code and site to see if this is already something in the
pipeline.



John.

--
John Horne | Senior Operations Analyst | Technology and Information
Services
University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
________________________________
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass
>

This email and any files with it are confidential and intended solely
for the use of the recipient to whom it is addressed. If you are not
the intended recipient then copying, distribution or other use of the
information contained is strictly prohibited and you should not rely on
it. If you have received this email in error please let the sender know
immediately and delete it from your system(s). Internet emails are not
necessarily secure. While we take every care, University of Plymouth
accepts no responsibility for viruses and it is your responsibility to
scan emails and their attachments. University of Plymouth does not
accept responsibility for any changes made after it was sent. Nothing
in this email or its attachments constitutes an order for goods or
services unless accompanied by an official order form.
_______________________________________________
Xymon mailing list
Xymon at xymon.com
http://lists.xymon.com/mailman/listinfo/xymon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20220408/e79a8915/attachment.htm>