Hello all! Just wanted to update everyone on a few things.
Going through the 4.x codebase re-familiarizing myself again with the state of everything, I recalled that I'd actually built a release artifact before development was paused, including a testing RPM that has actually been running unbeknownst on a VM for quite a while. Unfortunately, while validating that compiles from source worked I ran into what looked like showstopper bugs. These weren't showing up in the package, so I had to pore through a lot more code* than I expected to try to figure out where the package was accidentally fixing it.
(*message-sending code, which changes a lot in 4.4 to support compression, TLS, HTTP, and size-prefixed messages)
Fortunately, it ended up being a relatively simple issue (isn't it always?), with easy-enough validation and workaround (given below). Although more fixes could be put in (and I'm sure will be needed!), I believe there's some benefit to having a stable starting point using a build artifact from 2019.
As a result, I'm pleased to announce the first alpha for Xymon 4.4! As this is an alpha release, this is absolutely NOT suitable for production use and is intended mainly for smoketesting by source users. (And I expect there will be smoke.) The release tarball is available now at:
https://sourceforge.net/projects/xymon/files/Xymon/4.4-alpha/xymon-4.4-alpha...
Major improvements are too many to list here but are noted in the Changes and RELEASENOTES files. README documents for compression, TLS, and IPv6 are in progress.
Some of the changes and improvements other than TLS support have been in the Terabithia packages (to some extent) for a while, so there will be less of a delta for those users to this alpha.
For the moment, I'd like to focus on source tarball users and others running xymon from scratch to help fix underlying issues and any smoketest failures, which I expect may crop up particularly on untested non-Linux platforms. Once the lower-hanging fruit is fixed and more patches are upstreamed and cleaned up, I'll release an alpha2 release at which point packages may be released to help with testing iteration and downstream distributors.
Please flag bug reports or patches as related to "alpha1" in the subject line to help keep things clear.
Thank you to everyone in the community for remaining part of it -- and xymon users! -- during this interregnum. Restarting development has been a process, but I'm glad to take this important first step to our next release.
Regards, -jc
*** KNOWN ISSUES -- IMPORTANT ***
The configure script is likely setting XYMONHOME/XYMONCLIENTHOME and XYMSRV/XYMSERVERS/XYMONSERVERS incorrectly, which will prevent xymonlaunch from correctly launching anything. Double check the xymon environment files (xymonserver/xymonclient.cfg) before starting either the server or client.
The tools/xymon-client.default and tools/xymonlaunch files may be placed into /etc/{sysconfig,default}/{xymon-client,xymonlaunch} to more easily set $XYMONSERVERS
Revealed by the above issue is a bug causing a crash in the client (or anywhere) when given an empty string as the destination argument (instead of 0, 127.0.0.1 or no variable set). Don't do this --> [ xymon '' "ping" ]
The client and logfetch binary may be being re-compiled during 'make install'
Compilation may fail if c-ares and at least one compression library is not present (lzo/lz4/zlib are all options). xxHash libraries are also highly recommended as the plan is for xxhash to replace md5 for checksumming functionality. libtirpc may be necessary on some platforms, and it's possible the build code is still expecting traditional (Sun) RPC
Hi,
On Wed, Sep 20, 2023 at 01:37:50PM -0700, J.C. Cleaver wrote:
As a result, I'm pleased to announce the first alpha for Xymon 4.4!
Yep, noticed with great joy on SF a few days ago!
As this is an alpha release, this is absolutely NOT suitable for production use and is intended mainly for smoketesting by source users.
I plan to upload it to Debian Experimental soon-ish. I'm currently on sick leave, so not very active on the free software front either, but will take care once I feel better again.
So far I came until checking which Debian patches need updating, but haven't been able to update them yet.
Major improvements are too many to list here but are noted in the Changes and RELEASENOTES files. README documents for compression, TLS, and IPv6 are in progress.
Especially the announcement of the latter two were received with great happiness by my coworkers.
Please flag bug reports or patches as related to "alpha1" in the subject line to help keep things clear.
A question I have been wondering about 4.4a1:
4.4a1's changelog bumps directly from 4.3.27 to 4.4a1. Are the changes from 4.3.28, 4.3.29 and 4.3.30 included in 4.4a1, too?
And there's one other thing which I hoped for in this alpha release but didn't seem present: It's the move away from PCRE1 (aka libpcre3 in Debian and Ubuntu) to PCRE2 (aka libpcre2 in Debian and Ubuntu).
This is kinda urgent as Xymon already has been kicked out of Debian Testing for not supporting PCRE2 a month or two ago. Most distributions are currently trying to get rid of PCRE1. (Actually Ubuntu and Debian for years, but this release cycle, they unsheathe.
Some details on this:
Old (long deprecated, but currently used) PCRE1 API: https://www.pcre.org/original/doc/html/
New/current PCRE2 API to migrate to: https://www.pcre.org/current/doc/html/
Bug report in Debian about it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999921
Context about Debian's transition (actually seems to have been planned for an release earlier): https://lists.debian.org/debian-devel/2021/11/msg00176.html
Unfortunately despite PCRE2 is there for nearly a decade, there's still no migration guide, just hints from other project's patches: https://github.com/PCRE2Project/pcre2/issues/51
:-/
I (and probably most who use packages coming from Linux distributions) would be happy if this nevertheless could fixed in at least in the 4.4 branch, but wouldn't mind a patch set for the 4.3 stable branch either unless 4.4 is considered stable (or at least usable in production) within a year, i.e. in time for Debian's next stable release.
Thank you to everyone in the community for remaining part of it -- and xymon users! -- during this interregnum. Restarting development has been a process, but I'm glad to take this important first step to our next release.
Thanks for restarting developement again! Given how often we see production or setup questions here on the list, there seem quite some organisations relying on Xymon. And TLS and IPv6 gets more and more important.
I myself can speak for at least for my workplace (2 Xymon servers), the Linux User Group Switzerland (1 Xymon server) and my private infrastructure (2 Xymon servers).
Where TLS and/or IPv6 is needed, I so far use 4.3 with an stunnel-based TLS tunnel (https://www.stunnel.org/, which is dualstack by default and hence provides IPv6 for free, too), usually on port 1983. Works, but stunnel occasionally crashes making the hosts submitting via it purple after a while, so it's usually obvious what happened.
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
On Thu, September 21, 2023 02:32, Axel Beckert wrote:
Hi,
A question I have been wondering about 4.4a1:
4.4a1's changelog bumps directly from 4.3.27 to 4.4a1. Are the changes from 4.3.28, 4.3.29 and 4.3.30 included in 4.4a1, too?
Checking back, this appears to be an oversight of mine, yeah. I imported the base file https://sourceforge.net/p/xymon/code/8119/log/?path=/branches/4.x-master/Cha... but didn't bring the entries for updates when forward-porting 4.3.x fixes like https://sourceforge.net/p/xymon/code/8091/
They are there, though. I'll bring that up to date.
And there's one other thing which I hoped for in this alpha release but didn't seem present: It's the move away from PCRE1 (aka libpcre3 in Debian and Ubuntu) to PCRE2 (aka libpcre2 in Debian and Ubuntu).
This is kinda urgent as Xymon already has been kicked out of Debian Testing for not supporting PCRE2 a month or two ago. Most distributions are currently trying to get rid of PCRE1. (Actually Ubuntu and Debian for years, but this release cycle, they unsheathe.
Oi. Yeah, I remember seeing this push a while back in the Fedora side. Deprecation has come first (https://fedoraproject.org/wiki/Changes/PcreDeprecation ) and removal will be in a release or two.
Some details on this:
Old (long deprecated, but currently used) PCRE1 API: https://www.pcre.org/original/doc/html/
New/current PCRE2 API to migrate to: https://www.pcre.org/current/doc/html/
Bug report in Debian about it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999921
Context about Debian's transition (actually seems to have been planned for an release earlier): https://lists.debian.org/debian-devel/2021/11/msg00176.html
Unfortunately despite PCRE2 is there for nearly a decade, there's still no migration guide, just hints from other project's patches: https://github.com/PCRE2Project/pcre2/issues/51
:-/
Looking through what API guides there are, I'm not sure there's a great way to wrap these with flag defines, unfortunately.
I (and probably most who use packages coming from Linux distributions) would be happy if this nevertheless could fixed in at least in the 4.4 branch, but wouldn't mind a patch set for the 4.3 stable branch either unless 4.4 is considered stable (or at least usable in production) within a year, i.e. in time for Debian's next stable release.
This will be a bit ugly, but does need to be done and probably should be considered a blocker for a final 4.4 release. xymond_client, rrd, and report/display routines look to make up the bulk of the code in question, but there's a lot of it.
Fortunately, none of this code seems to have changed between 4.3 and 4.x although some of the configure/Makefile lines have. That means it should be easier to test out this change in isolation there and then apply to 4.x without much separate breakage going on.
Since the client doesn't require PCRE at all except for "local" mode where the clientlog is parsed by xymond_client, it might be helpful (if you're not doing that already) to separate this and its configs into a separate "xymon-client-local" package, that way at least the dependency can be removed from the main client package.
-jc
Awesome news! Many thanks J.C for your incredible work! Bruno
On 22.09.2023 01:33, J.C. Cleaver wrote:
On Thu, September 21, 2023 02:32, Axel Beckert wrote:
Hi, A question I have been wondering about 4.4a1:
4.4a1's changelog bumps directly from 4.3.27 to 4.4a1. Are the changes from 4.3.28, 4.3.29 and 4.3.30 included in 4.4a1, too?
Checking back, this appears to be an oversight of mine, yeah. I imported the base file https://sourceforge.net/p/xymon/code/8119/log/?path=/branches/4.x-master/Cha... but didn't bring the entries for updates when forward-porting 4.3.x fixes likehttps://sourceforge.net/p/xymon/code/8091/
They are there, though. I'll bring that up to date.
And there's one other thing which I hoped for in this alpha release but didn't seem present: It's the move away from PCRE1 (aka libpcre3 in Debian and Ubuntu) to PCRE2 (aka libpcre2 in Debian and Ubuntu).
This is kinda urgent as Xymon already has been kicked out of Debian Testing for not supporting PCRE2 a month or two ago. Most distributions are currently trying to get rid of PCRE1. (Actually Ubuntu and Debian for years, but this release cycle, they unsheathe. Oi. Yeah, I remember seeing this push a while back in the Fedora side. Deprecation has come first (https://fedoraproject.org/wiki/Changes/PcreDeprecation ) and removal will be in a release or two.
Some details on this:
Old (long deprecated, but currently used) PCRE1 API: https://www.pcre.org/original/doc/html/
New/current PCRE2 API to migrate to: https://www.pcre.org/current/doc/html/
Bug report in Debian about it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999921
Context about Debian's transition (actually seems to have been planned for an release earlier): https://lists.debian.org/debian-devel/2021/11/msg00176.html
Unfortunately despite PCRE2 is there for nearly a decade, there's still no migration guide, just hints from other project's patches: https://github.com/PCRE2Project/pcre2/issues/51
:-/
Looking through what API guides there are, I'm not sure there's a great way to wrap these with flag defines, unfortunately.
I (and probably most who use packages coming from Linux distributions) would be happy if this nevertheless could fixed in at least in the 4.4 branch, but wouldn't mind a patch set for the 4.3 stable branch either unless 4.4 is considered stable (or at least usable in production) within a year, i.e. in time for Debian's next stable release. This will be a bit ugly, but does need to be done? and probably should be considered a blocker for a final 4.4 release. xymond_client, rrd, and report/display routines look to make up the bulk of the code in question, but there's a lot of it.
Fortunately, none of this code seems to have changed between 4.3 and 4.x although some of the configure/Makefile lines have. That means it should be easier to test out this change in isolation there and then apply to 4.x without much separate breakage going on.
Since the client doesn't require PCRE at all except for "local" mode where the clientlog is parsed by xymond_client, it might be helpful (if you're not doing that already) to separate this and its configs into a separate "xymon-client-local" package, that way at least the dependency can be removed from the main client package.
-jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
These are excellent news, JC!
I'm about to discuss Xymon as the central monitoring solution with a new customer, and the PoC was almost cancelled as the project seems to be dead from their standpoint. In these days something looks insecure and outdated very fast even if the framework is quite mature and stable and much more flexible as a lot of other, feature overloaded solutions imho. Especially the announcement of encrypted communication will help a lot for the discussion with customer. I'm looking forward for the 4.4. beta and will compile and implement it immediately at my test envs once it is available.
I wonder if xymonton is still the only (and preferred) place to add custom extension scripts and howtos? It also looks quite silent but I can add several addons and some hints for customization for the GUI and so on, based on my experience with dozens of implementations (up to 20k servers).
Keep the momentum and thx for the great work!
Norbert
Am Mi., 20. Sept. 2023 um 22:38 Uhr schrieb J.C. Cleaver < cleaver at terabithia.org>:
Hello all! Just wanted to update everyone on a few things.
Going through the 4.x codebase re-familiarizing myself again with the state of everything, I recalled that I'd actually built a release artifact before development was paused, including a testing RPM that has actually been running unbeknownst on a VM for quite a while. Unfortunately, while validating that compiles from source worked I ran into what looked like showstopper bugs. These weren't showing up in the package, so I had to pore through a lot more code* than I expected to try to figure out where the package was accidentally fixing it.
(*message-sending code, which changes a lot in 4.4 to support compression, TLS, HTTP, and size-prefixed messages)
Fortunately, it ended up being a relatively simple issue (isn't it always?), with easy-enough validation and workaround (given below). Although more fixes could be put in (and I'm sure will be needed!), I believe there's some benefit to having a stable starting point using a build artifact from 2019.
As a result, I'm pleased to announce the first alpha for Xymon 4.4! As this is an alpha release, this is absolutely NOT suitable for production use and is intended mainly for smoketesting by source users. (And I expect there will be smoke.) The release tarball is available now at:
https://sourceforge.net/projects/xymon/files/Xymon/4.4-alpha/xymon-4.4-alpha...
Major improvements are too many to list here but are noted in the Changes and RELEASENOTES files. README documents for compression, TLS, and IPv6 are in progress.
Some of the changes and improvements other than TLS support have been in the Terabithia packages (to some extent) for a while, so there will be less of a delta for those users to this alpha.
For the moment, I'd like to focus on source tarball users and others running xymon from scratch to help fix underlying issues and any smoketest failures, which I expect may crop up particularly on untested non-Linux platforms. Once the lower-hanging fruit is fixed and more patches are upstreamed and cleaned up, I'll release an alpha2 release at which point packages may be released to help with testing iteration and downstream distributors.
Please flag bug reports or patches as related to "alpha1" in the subject line to help keep things clear.
Thank you to everyone in the community for remaining part of it -- and xymon users! -- during this interregnum. Restarting development has been a process, but I'm glad to take this important first step to our next release.
Regards, -jc
*** KNOWN ISSUES -- IMPORTANT ***
The configure script is likely setting XYMONHOME/XYMONCLIENTHOME and XYMSRV/XYMSERVERS/XYMONSERVERS incorrectly, which will prevent xymonlaunch from correctly launching anything. Double check the xymon environment files (xymonserver/xymonclient.cfg) before starting either the server or client.
The tools/xymon-client.default and tools/xymonlaunch files may be placed into /etc/{sysconfig,default}/{xymon-client,xymonlaunch} to more easily set $XYMONSERVERS
Revealed by the above issue is a bug causing a crash in the client (or anywhere) when given an empty string as the destination argument (instead of 0, 127.0.0.1 or no variable set). Don't do this --> [ xymon '' "ping" ]
The client and logfetch binary may be being re-compiled during 'make install'
Compilation may fail if c-ares and at least one compression library is not present (lzo/lz4/zlib are all options). xxHash libraries are also highly recommended as the plan is for xxhash to replace md5 for checksumming functionality. libtirpc may be necessary on some platforms, and it's possible the build code is still expecting traditional (Sun) RPC
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On Mon, September 25, 2023 13:59, nor krie wrote:
These are excellent news, JC!
I'm about to discuss Xymon as the central monitoring solution with a new customer, and the PoC was almost cancelled as the project seems to be dead from their standpoint. In these days something looks insecure and outdated very fast even if the framework is quite mature and stable and much more flexible as a lot of other, feature overloaded solutions imho. Especially the announcement of encrypted communication will help a lot for the discussion with customer. I'm looking forward for the 4.4. beta and will compile and implement it immediately at my test envs once it is available.
I wonder if xymonton is still the only (and preferred) place to add custom extension scripts and howtos? It also looks quite silent but I can add several addons and some hints for customization for the GUI and so on, based on my experience with dozens of implementations (up to 20k servers).
Figuring out how best to organize information is indeed a question.
I believe Galen is still running xymonton.org, and additional monitors and scripts are always welcome. Between that, the guides at https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon , the man-page archive you would find at https://xymon.com/help/manpages/ , the webpage at https://xymon.sourceforge.io/, and the actual SF resources at https://sourceforge.net/projects/xymon/, and this mailing list at https://lists.xymon.com/ , that's a lot of disparate sources of info.
Still very open to ideas on how to best combine these resources in a way that makes sense to neophytes (and everyone else). I think a wiki absolutely has to be a part of it, as community knowledge is often driven by use-cases and solution write-ups, which kind of go hand-in-hand with monitors and plugins as posted to xymonton.
Regards, -jc
I still maintain xymonton as best I can.
=G=
On Tue, Sep 26, 2023, 1:28 PM J.C. Cleaver <cleaver at terabithia.org> wrote:
On Mon, September 25, 2023 13:59, nor krie wrote:
These are excellent news, JC!
I'm about to discuss Xymon as the central monitoring solution with a new customer, and the PoC was almost cancelled as the project seems to be dead from their standpoint. In these days something looks insecure and outdated very fast even if the framework is quite mature and stable and much more flexible as a lot of other, feature overloaded solutions imho. Especially the announcement of encrypted communication will help a lot for the discussion with customer. I'm looking forward for the 4.4. beta and will compile and implement it immediately at my test envs once it is available.
I wonder if xymonton is still the only (and preferred) place to add custom extension scripts and howtos? It also looks quite silent but I can add several addons and some hints for customization for the GUI and so on, based on my experience with dozens of implementations (up to 20k servers).
Figuring out how best to organize information is indeed a question.
I believe Galen is still running xymonton.org, and additional monitors and scripts are always welcome. Between that, the guides at https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon , the man-page archive you would find at https://xymon.com/help/manpages/ , the webpage at https://xymon.sourceforge.io/, and the actual SF resources at https://sourceforge.net/projects/xymon/, and this mailing list at https://lists.xymon.com/ , that's a lot of disparate sources of info.
Still very open to ideas on how to best combine these resources in a way that makes sense to neophytes (and everyone else). I think a wiki absolutely has to be a part of it, as community knowledge is often driven by use-cases and solution write-ups, which kind of go hand-in-hand with monitors and plugins as posted to xymonton.
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
J.C., Thank you again J.C. for reviving the updates for Xymon. I am willing to help update it as well, even though I am now retired and only have a small install of Xymon 4.3.30 at home for my home network. I have contributed to Xymon several times in the past when I had it installed in a large corporate environment before I retired.
J.C. and 4.4-alpha1 testers, I have done a little bit of testing of 4.4-alpha1 on Rocky Linux 8.8 (server and client) and on a busybox Linux install on a NAS. I looked into the gcc 8.5.0 compiler warnings that I got on Rocky Linux, and have corrected them, or silenced the ones that should not be an issue. Attached are two context diff patch files, one to fix the compiler warnings, and one to make a couple updates that I had applied to 4.3.30 previously. My updates fix the busybox Linux client build, and enhance the temperature graph to optionally display both Celsius and Fahrenheit readings.
I have not fully tested 4.4-alpha1 yet, but wanted to get these firstpatches released for 4.4-alpha2.
Tom Schmidt
On Wed, Sep 20, 2023 at 2:38?PM J.C. Cleaver <cleaver at terabithia.org> wrote:
Hello all! Just wanted to update everyone on a few things.
Going through the 4.x codebase re-familiarizing myself again with the state of everything, I recalled that I'd actually built a release artifact before development was paused, including a testing RPM that has actually been running unbeknownst on a VM for quite a while. Unfortunately, while validating that compiles from source worked I ran into what looked like showstopper bugs. These weren't showing up in the package, so I had to pore through a lot more code* than I expected to try to figure out where the package was accidentally fixing it.
(*message-sending code, which changes a lot in 4.4 to support compression, TLS, HTTP, and size-prefixed messages)
Fortunately, it ended up being a relatively simple issue (isn't it always?), with easy-enough validation and workaround (given below). Although more fixes could be put in (and I'm sure will be needed!), I believe there's some benefit to having a stable starting point using a build artifact from 2019.
As a result, I'm pleased to announce the first alpha for Xymon 4.4! As this is an alpha release, this is absolutely NOT suitable for production use and is intended mainly for smoketesting by source users. (And I expect there will be smoke.) The release tarball is available now at:
https://sourceforge.net/projects/xymon/files/Xymon/4.4-alpha/xymon-4.4-alpha...
Major improvements are too many to list here but are noted in the Changes and RELEASENOTES files. README documents for compression, TLS, and IPv6 are in progress.
Some of the changes and improvements other than TLS support have been in the Terabithia packages (to some extent) for a while, so there will be less of a delta for those users to this alpha.
For the moment, I'd like to focus on source tarball users and others running xymon from scratch to help fix underlying issues and any smoketest failures, which I expect may crop up particularly on untested non-Linux platforms. Once the lower-hanging fruit is fixed and more patches are upstreamed and cleaned up, I'll release an alpha2 release at which point packages may be released to help with testing iteration and downstream distributors.
Please flag bug reports or patches as related to "alpha1" in the subject line to help keep things clear.
Thank you to everyone in the community for remaining part of it -- and xymon users! -- during this interregnum. Restarting development has been a process, but I'm glad to take this important first step to our next release.
Regards, -jc
*** KNOWN ISSUES -- IMPORTANT ***
The configure script is likely setting XYMONHOME/XYMONCLIENTHOME and XYMSRV/XYMSERVERS/XYMONSERVERS incorrectly, which will prevent xymonlaunch from correctly launching anything. Double check the xymon environment files (xymonserver/xymonclient.cfg) before starting either the server or client.
The tools/xymon-client.default and tools/xymonlaunch files may be placed into /etc/{sysconfig,default}/{xymon-client,xymonlaunch} to more easily set $XYMONSERVERS
Revealed by the above issue is a bug causing a crash in the client (or anywhere) when given an empty string as the destination argument (instead of 0, 127.0.0.1 or no variable set). Don't do this --> [ xymon '' "ping" ]
The client and logfetch binary may be being re-compiled during 'make install'
Compilation may fail if c-ares and at least one compression library is not present (lzo/lz4/zlib are all options). xxHash libraries are also highly recommended as the plan is for xxhash to replace md5 for checksumming functionality. libtirpc may be necessary on some platforms, and it's possible the build code is still expecting traditional (Sun) RPC
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On Tue, October 3, 2023 13:06, Tom Schmidt wrote:
J.C. and 4.4-alpha1 testers, I have done a little bit of testing of 4.4-alpha1 on Rocky Linux 8.8 (server and client) and on a busybox Linux install on a NAS. I looked into the gcc 8.5.0 compiler warnings that I got on Rocky Linux, and have corrected them, or silenced the ones that should not be an issue. Attached are two context diff patch files, one to fix the compiler warnings, and one to make a couple updates that I had applied to 4.3.30 previously. My updates fix the busybox Linux client build, and enhance the temperature graph to optionally display both Celsius and Fahrenheit readings.
I have not fully tested 4.4-alpha1 yet, but wanted to get these firstpatches released for 4.4-alpha2.
Tom Schmidt
Thanks for the patches!
Yes, the build errors had been a concern for me as well; determining which sections were protected by correct math and which weren't was going to take some time, and this is quite helpful.
I've created a 4.3.31 branch for similar concerns and many of these are just as applicable there. There's also a corruption bug on some loads that is crashing on F28 (and F29), so that release will probably just be build fixes for the stable tree.
Regards, -jc
Tom,
I realise that you're working with Rocky 8, but I just want to note that the lib/tcplib.c patch breaks compilation on RHEL7.
The function ASN1_STRING_get0_data() appears in openssl-1.1, but not in RHEL7 / openssl-1.0.
I found that there's an openssl version number in the openssl/opensslv.h include file, which allows the attached patch to select the correct function. With this modification to your patch, the compilation completes on RHEL7, RHEL8 and RHEL9.
Regards,
Ralph Mitchell
On Tue, Oct 3, 2023 at 11:12?PM J.C. Cleaver <cleaver at terabithia.org> wrote:
On Tue, October 3, 2023 13:06, Tom Schmidt wrote:
J.C. and 4.4-alpha1 testers, I have done a little bit of testing of 4.4-alpha1 on Rocky Linux 8.8 (server and client) and on a busybox Linux install on a NAS. I looked into the gcc 8.5.0 compiler warnings that I got on Rocky Linux, and have corrected them, or silenced the ones that should not be an issue. Attached are two context diff patch files, one to fix the compiler warnings, and one to make a couple updates that I had applied to 4.3.30 previously. My updates fix the busybox Linux client build, and enhance the temperature graph to optionally display both Celsius and Fahrenheit readings.
I have not fully tested 4.4-alpha1 yet, but wanted to get these firstpatches released for 4.4-alpha2.
Tom Schmidt
Thanks for the patches!
Yes, the build errors had been a concern for me as well; determining which sections were protected by correct math and which weren't was going to take some time, and this is quite helpful.
I've created a 4.3.31 branch for similar concerns and many of these are just as applicable there. There's also a corruption bug on some loads that is crashing on F28 (and F29), so that release will probably just be build fixes for the stable tree.
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Hi JC,
At work I maintain a Xymon install with around 3000 hosts and 90000 checks. We have a lot of custom checks, some of which I want to share in the community in the future including a quite comprehensive Python client library.
One of the things we have is a set of automated checks that check the smart status of every drive we have. (Some hosts have 120 drives.) It generates a number of checks per host like ?smart-sda?, ?smart-sdb? and also a combo test called ?smarts?. I have a patch that I always apply to the Xymon source that allows me to use a regexp in the ?group-except? directive in hosts.cfg, so I can hide ?%smart-.*|othertest?, rather than having to specify ?smart-sda|smart-sdb|othertest? and any other drive that may appear.
I think this patch may be useful for more people than just me, so can we please include this?
Kind regards
Mark
PS: I am also happy to help with testing of new releases and features at home or at work on a larger data set.
Ralph, thanks for catching and fixing this for the OpenSSL version.
Tom Schmidt
On Tue, Oct 3, 2023 at 10:34?PM Ralph M <ralphmitchell at gmail.com> wrote:
Tom,
I realise that you're working with Rocky 8, but I just want to note that the lib/tcplib.c patch breaks compilation on RHEL7.
The function ASN1_STRING_get0_data() appears in openssl-1.1, but not in RHEL7 / openssl-1.0.
I found that there's an openssl version number in the openssl/opensslv.h include file, which allows the attached patch to select the correct function. With this modification to your patch, the compilation completes on RHEL7, RHEL8 and RHEL9.
Regards,
Ralph Mitchell
On Tue, Oct 3, 2023 at 11:12?PM J.C. Cleaver <cleaver at terabithia.org> wrote:
On Tue, October 3, 2023 13:06, Tom Schmidt wrote:
J.C. and 4.4-alpha1 testers, I have done a little bit of testing of 4.4-alpha1 on Rocky Linux 8.8 (server and client) and on a busybox Linux install on a NAS. I looked into the gcc 8.5.0 compiler warnings that I got on Rocky Linux, and have corrected them, or silenced the ones that should not be an issue. Attached are two context diff patch files, one to fix the compiler warnings, and one to make a couple updates that I had applied to 4.3.30 previously. My updates fix the busybox Linux client build, and enhance the temperature graph to optionally display both Celsius and Fahrenheit readings.
I have not fully tested 4.4-alpha1 yet, but wanted to get thesefirst
patches released for 4.4-alpha2.
Tom Schmidt
Thanks for the patches!
Yes, the build errors had been a concern for me as well; determining which sections were protected by correct math and which weren't was going to take some time, and this is quite helpful.
I've created a 4.3.31 branch for similar concerns and many of these are just as applicable there. There's also a corruption bug on some loads that is crashing on F28 (and F29), so that release will probably just be build fixes for the stable tree.
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
J.C., Sorry for the delay, but I have some updated patches for xymon 4.4 alpha1. I have compiled it on Rocky Linux 8 and 9 64-bit systems. The first set of patches corrects gcc warnings seen on gcc 8.5 (RL8) and 11.4.1 (RL9). I previously sent some patches for these when I tested on RL8 gcc 8.5, but have improved and/or corrected the patches based on RL9 gcc 11.4.1. The second set of patches includes some other bug fixes and enhancements, including:
- build/Makefile.Linux: Check for existence of replacement rpc
- build/Makefile.rules: Add XYMONRUNDIR to CFLAGS
- lib/compression.c: Handle LZ4 versions syntax change
- xymond/client/snmpcollect.c: Initialize nslsects
- xymond/etcfiles/tasks.cfg.DIST: Add IPv6 to admin-senders
- xymond/Makefile: correct missing variable substitutions
- xymond/webfiles/hostgraphs_header: remove XYMWEBHOST hyperlinks
- xymond/xymonfetch.c: Fix gcc warning
- xymond/wwwfiles/gifs/xymonbody.css: Add table td/th classes, tooltips
As a side note, I have also been trying to get a xymon 4.4a1 client to work on an Arm-based NAS system that I have, which the xymon 4.3.30 client is working fine on. I may have more patches to submit once I figure out how to fix it.
Thanks again! Tom Schmidt
On Wed, Oct 4, 2023 at 8:11?AM Tom Schmidt <tom at 4schmidts.com> wrote:
Ralph, thanks for catching and fixing this for the OpenSSL version.
Tom Schmidt
On Tue, Oct 3, 2023 at 10:34?PM Ralph M <ralphmitchell at gmail.com> wrote:
Tom,
I realise that you're working with Rocky 8, but I just want to note that the lib/tcplib.c patch breaks compilation on RHEL7.
The function ASN1_STRING_get0_data() appears in openssl-1.1, but not in RHEL7 / openssl-1.0.
I found that there's an openssl version number in the openssl/opensslv.h include file, which allows the attached patch to select the correct function. With this modification to your patch, the compilation completes on RHEL7, RHEL8 and RHEL9.
Regards,
Ralph Mitchell
On Tue, Oct 3, 2023 at 11:12?PM J.C. Cleaver <cleaver at terabithia.org> wrote:
On Tue, October 3, 2023 13:06, Tom Schmidt wrote:
J.C. and 4.4-alpha1 testers, I have done a little bit of testing of 4.4-alpha1 on Rocky Linux
8.8
(server and client) and on a busybox Linux install on a NAS. I looked into the gcc 8.5.0 compiler warnings that I got on Rocky Linux, and have corrected them, or silenced the ones that should not be an issue. Attached are two context diff patch files, one to fix the compiler warnings, and one to make a couple updates that I had applied to 4.3.30 previously. My updates fix the busybox Linux client build, and enhance the temperature graph to optionally display both Celsius and Fahrenheit readings.
I have not fully tested 4.4-alpha1 yet, but wanted to get thesefirst patches released for 4.4-alpha2.
Tom Schmidt
Thanks for the patches!
Yes, the build errors had been a concern for me as well; determining which sections were protected by correct math and which weren't was going to take some time, and this is quite helpful.
I've created a 4.3.31 branch for similar concerns and many of these are just as applicable there. There's also a corruption bug on some loads that is crashing on F28 (and F29), so that release will probably just be build fixes for the stable tree.
Regards, -jc
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
the procs check is the usual out-of-the-box every-five-minutes check done automagically by xymon of course.
If one was to update analysis.cfg on the xymon server is there a way to immediately force a procs check rather than wait several minutes for the check to be run?
didds
participants (9)
-
abe＠deuxchevaux.org
-
bruno.manzoni＠ubi-network.ch
-
cleaver＠terabithia.org
-
didds3＠yahoo.co.uk
-
mark＠stitson.com
-
norkrie＠gmail.com
-
ralphmitchell＠gmail.com
-
solitaryr＠gmail.com
-
tom＠4schmidts.com