[Xymon] Terebithia RPM's vs Build.

[John Horne]

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.