Terebithia RPM's vs Build. 🔗 link

Hi all,

Can anyone tell me what the difference is for Xymon Server between compiling from source and installing the Terabithia RPM's?

Also, I noticed there seems to be at least rrd-devel packages that are outside of the main Repos for RHEL 8, are there any other considerations of that nature for RHEL 8.5?

I'm looking at building a new Xymon server as our current one is CentOS 5.6 and Xymon 4.3.4 so a bit ancient and very overdue a rebuild to more modern versions.

I'd like to build with RHEL 8.5 and Xymon 4.3.30 and I'd like to build using the Terebithia RPM's but I know I'm going to get questions from our Cyber team regarding the differences and any nonstandard Repo's I need so I'd like to be prepared with some answers.

Also, I'd just like to check that Xymon is still being developed? I notice 4.3.30 seems to be 2.5 years old and while I remember some talk about Version 5, I haven't seen any news on that yet.

Kind Regards,

Neil.

Neil Simmonds
Senior Platform & Middleware Engineer (Unix).


Studio is a trading name of Studio Retail Ltd which is authorised and regulated by the Financial Conduct Authority for consumer credit and general insurance. Studio Retail Ltd are members of the Finance and Leasing Association (FLA). Registered in England. No: 718151. Registered Office: Church Bridge House, Henry Street, Accrington, BB5 4EE NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Studio Retail Ltd and the recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. Any views or opinions presented are solely those of the author and do not necessarily represent those of Studio Retail Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. Studio Retail Ltd reserves the right to monitor all e-mail communications through its internal and external networks. If you have received this email in error, please notify our careline on +44(0) XXX XXX XXXX.

Hi Neil,

I know there are differences with what's in the Terabithia RPMs and in
upstream Xymon source. The Terabithia RPMs add extra patches on top of the
source with various enhancements. I believe the creator of those RPMs was
working on getting all the extra changes incorporated into upstream but not
sure how far he got in that process. I know there are some differences that
still exist. I believe he changed jobs and hasn't been able to dedicate as
much (volunteer) time to the Xymon project as he used to. I would take a
look at the README (Terabithia RPMS)
<https://terabithia.org/xymon/xymon.README.terabithia>; and CHANGES
(Terabithia RPMS) <https://terabithia.org/xymon/xymon.CHANGES.terabithia>;
files found on the Terabithia RPM main page (https://terabithia.org/xymon/)
<https://terabithia.org/xymon/>; for more information on the differences.

I've been running a Xymon server using the Terabithia RPMs on RHEL 7 for 7+
years now with no significant issues (that hadn't been addressed). Note you
will need EPEL if you use the Terabithia RPMs (RHEL 7 or 8), but ONLY on
the Xymon server itself. The xymon-client Terabithia RPM package doesn't
require anything outside the normal RHEL repositories (for RHEL 6/7/8).

I am actually in the process of moving our Xymon server from RHEL 7 to RHEL
8 now as well and based on my testing *so far*, I haven't found any issues
with the RHEL 8 Terabithia Xymon server RPMs (been using the RHEL 8
xymon-client RPM on clients for a long time with no issues).

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
<https://lists.xymon.com/pipermail/xymon/2020-June/047190.html>; and here
<https://lists.xymon.com/pipermail/xymon/2020-June/047191.html>;.)

This is something I would *love* if it was fixed in the Xymon source code,
but not sure the likelihood of it happening anytime soon (*note to Xymon
maintianers!*).

Hope this helps!

Thanks.

-- 
Matt Vander Werf


On Wed, Mar 30, 2022 at 8:51 AM Neil Simmonds <user-884b0aec6dbf@xymon.invalid>

wrote:

On Wed, 2022-03-30 at 09:51 -0400, Matt VanderWerf wrote:

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.

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 <user-e95f1ec2f147@xymon.invalid>
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:

at all (neither does ntp), nor does it exist in any trusted third-
party

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.