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) 371 200 0378.
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 <Neil.Simmonds at studio.co.uk> wrote:
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) 371 200 0378.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
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.
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
participants (4)
-
john.horne＠plymouth.ac.uk
-
mvanderw＠nd.edu
-
Neil.Simmonds＠studio.co.uk
-
phaleintx＠gmail.com