Update on 4.4 (Alpha1 release) 🔗 link

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!

As this is an alpha release, this is absolutely NOT suitable for
production use and is intended mainly for smoketesting by source
users.

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.

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.

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.

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/Changes
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

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-alpha1.tar.gz


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

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).

On Tue, Sep 26, 2023, 1:28 PM J.C. Cleaver <user-87556346d4af@xymon.invalid> 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

On Wed, Sep 20, 2023 at 2:38?PM J.C. Cleaver <user-87556346d4af@xymon.invalid> 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-alpha1.tar.gz


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

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 first
patches released for 4.4-alpha2.

Tom Schmidt

On Tue, Oct 3, 2023 at 11:12?PM J.C. Cleaver <user-87556346d4af@xymon.invalid> 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 first
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

On Tue, Oct 3, 2023 at 10:34?PM Ralph M <user-00a5e44c48c0@xymon.invalid> 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 <user-87556346d4af@xymon.invalid>
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
first
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

On Wed, Oct 4, 2023 at 8:11?AM Tom Schmidt <user-d34f6118b459@xymon.invalid> 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 <user-00a5e44c48c0@xymon.invalid> 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 <user-87556346d4af@xymon.invalid>
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
first
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

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