- Xymon - Xymon mailman web

RRDTool on RHEL 8
by erik＠schminke.us 18 Aug '20

18 Aug '20

For those of you in the future who may struggle with building Xymon on RHEL 8.. rrdtool-devel is not in the main repositories for RHEL 8. To install you need to enable the "CodeReady Builder for RHEL 8" repository. dnf config-manager --set-enabled codeready-builder-for-rhel-8-x86_64-rpms After doing this, a "dnf install rrdtool-devel" should be successful. Hope this saves someone some time. Erik

1 0

Xymon 4.3.30 Released
by cleaver＠terabithia.org 18 Aug '20

18 Aug '20

Xymon 4.3.30 has been released and is now available for download. 4.3.30 is mostly a bug-fix release, quashing issues stemming from the security fixes in 4.3.29, including improperly-tight restrictions on allowed characters in hostname for browsing along with several other parsing errors. Thanks in particular to Tom Schmidt for his assistance in tracking these down. Xymon should also now be more easily buildable on older GCC versions without the diagnostics pragma available. Xymon 4.3.30 is available from the Xymon SourceForge page at https://sourceforge.net/projects/xymon/ As always, thank you to all who have contributed code, ideas, and features to the project! Regards, Japheth "J.C." Cleaver

5 9

alerts.cfg GROUP not matching
by Tim.James＠navient.com 17 Aug '20

17 Aug '20

I had all of this working and "something" changed and now the majority of my groups defined in my analysis.cfg file no longer alert. I'm hoping it wasn't when I upgraded from 4.3.28 to 4.3.30 but I'm not ruling anything out. I have sanitized the server name to foo.bar.com Analysis.cfg snippet: HOST=foo* DISK /opt/sas 90 95 GROUP=sas_support DISK /opt/sas/9.4 90 95 GROUP=sas_support DISK /opt/sas/9.4/depot2 90 95 GROUP=sas_support DISK /opt/sas/saslanding 90 95 GROUP=sas_support DISK /opt/sas/saslanding/in 90 95 GROUP=sas_support DISK /opt/sas/saslanding/out 90 95 GROUP=sas_support DISK /opt/sas/sasmain 90 99 GROUP=sas_support DISK /opt/sas/sassecure 90 99 GROUP=sas_support DISK /opt/sas/sassecure/modelingcrm 95 98 GROUP=sas_support DISK /opt/sas/sassecure/servicing 95 99 GROUP=sas_support DISK /opt/sas/sassecure/servicing/SCRA/MOENDs 90 95 GROUP=sas_support DISK /opt/sas/saswork 50 70 GROUP=sas_support Alerts.cfg snippet: GROUP=sas_support SERVICE=disk COLOR=red # SAS Application support team SCRIPT /usr/local/xymon-server/server/ext/Create_SN_Ticket_From_Xymon-YP2-RP1.sh sas_support FORMAT=SMS DURATION>30 REPEAT=24h stop GROUP=sas_support SERVICE=disk COLOR=yellow # SAS Application support team MAIL helpdesk at foo.com FORMAT=SMS DURATION<20 REPEAT=24h stop Obligatory test from the terminal: [/usr/local/xymon-server/server/etc] --> ../bin/xymoncmd xymond_alert --test foo.bar.com disk --color=yellow --group=sas_support 00103435 2020-08-14 23:11:06 Matching host:service:dgroup:page 'foo.bar.com:disk:NONE:PROD/PSAS' against rule line 165 00103435 2020-08-14 23:11:06 Failed 'GROUP=sas_support SERVICE=disk COLOR=red' (group not in include list) 00103435 2020-08-14 23:11:06 Matching host:service:dgroup:page 'foo.bar.com:disk:NONE:PROD/PSAS' against rule line 168 00103435 2020-08-14 23:11:06 Failed 'GROUP=sas_support SERVICE=disk COLOR=yellow' (group not in include list) --> ../bin/xymoncmd xymond_alert --test foo.bar.com disk --group=sas_support 00104898 2020-08-14 23:26:59 Matching host:service:dgroup:page 'foo.bar.com:disk:NONE:PROD/PSAS' against rule line 165 00104898 2020-08-14 23:26:59 Failed 'GROUP=sas_support SERVICE=disk COLOR=red' (group not in include list) 00104898 2020-08-14 23:26:59 Matching host:service:dgroup:page 'foo.bar.com:disk:NONE:PROD/PSAS' against rule line 168 00104898 2020-08-14 23:26:59 Failed 'GROUP=sas_support SERVICE=disk COLOR=yellow' (group not in include list) However the "red" second test, does match further along in the alerts file, just not with a GROUP definition, and the failure there is expected as I didn't specify the duration. 00104898 2020-08-14 23:26:59 Matching host:service:dgroup:page 'foo.bar.com:disk:NONE:PROD/PSAS' against rule line 304 00104898 2020-08-14 23:26:59 *** Match with 'HOST=%^.* SERVICE=disk COLOR=red' *** 00104898 2020-08-14 23:26:59 Matching host:service:dgroup:page 'foo.bar.com:disk:NONE:PROD/PSAS' against rule line 305 00104898 2020-08-14 23:26:59 Failed 'SCRIPT /usr/local/xymon-server/server/ext/Create_SN_Ticket_From_Xymon-YP2-RP1.sh UNIX FORMAT=SMS DURATION>5 REPEAT=25h' (min. duration 0<301) Now get this. Here are two more examples from the alerts.cfg file: GROUP=satellite SERVICE=disk #test comment MAIL coworker at foo.com FORMAT=SCRIPT stop GROUP=unix # Linux Team support (default contact) MAIL unix-alert at lists.foo.com FORMAT=SMS DURATION<20 stop And the respective tests from the terminal: ../bin/xymoncmd xymond_alert --test foo.bar.com disk --color=yellow --group=satellite 00104439 2020-08-14 23:21:49 Matching host:service:dgroup:page foo.bar.com:disk:NONE:PROD/PSAS' against rule line 147 00104439 2020-08-14 23:21:49 Failed 'GROUP=satellite SERVICE=disk' (group not in include list) ../bin/xymoncmd xymond_alert --test foo.bar.com disk --color=yellow --group=unix 00104535 2020-08-14 23:23:08 Matching host:service:dgroup:page 'foo.bar.com:disk:NONE:PROD/PSAS' against rule line 150 00104535 2020-08-14 23:23:08 *** Match with 'GROUP=unix' *** 00104535 2020-08-14 23:23:08 Matching host:service:dgroup:page 'foo.bar.com:disk:NONE:PROD/PSAS' against rule line 151 00104535 2020-08-14 23:23:08 *** Match with 'MAIL unix-alert at lists.foo.com FORMAT=SMS DURATION<20 stop' *** 00104535 2020-08-14 23:23:08 Mail alert with command 'mail unix-alert at lists.foo.com I'm stumped. Anyone out there have any idea what might be incorrect? Tim James Senior System Administrator Navient

1 1

No service to check.
by zahir.au＠gmail.com 17 Aug '20

17 Aug '20

Hi, I have recently set upped xymon. Everything looks okay except the svcs. Which do not list any services. The page is always green no matter what and shows following message ?No service to check?. I have added to monitor for SQL service under analysis.d but it does nothing. Please help. Regards Zahirul Alam

2 1

Monitoring AWS
by damien＠makelofine.org 15 Aug '20

15 Aug '20

Hello Seb, To be honnest, due to the lack of responses, I postponed it. However, I started to work on a project that is related to AWS, and requires monitoring. So I'm changing my plans to work on the monitoring part first. I'll post my homework on github. If you have an account on Github and would like to contribute, share your username, and I'll add you as a collaborator. Regards, Le 14/08/2020 ? 14:40, SebA a ?crit?: > Hi Damien, > > Have you made any progress with this?? Even the instance checks alone > would have value. > > Kind regards, > > SebA > > > > On Wed, 29 Jan 2020 at 19:43, Damien Martins <damien at makelofine.org > <mailto:damien at makelofine.org>> wrote: > > Thanks for your suggestions. They are now part of the todo list ;) > > Le 29/01/2020 ? 20:06, SebA a ?crit?: >> Hi Damien, >> >> That looks like a pretty good list!? In case you haven't included >> it in EC2 and RDS: >> 1. upcoming scheduled AWS maintenance affecting your instances; >> 2. EC2 instance running low on, and/or predicted to run out of >> CPU credits based on utilization over the last x hours. >> >> I wish you all the best in your endeavors. >> >> Kind regards, >> >> SebA >> >> >> >> On Tue, 28 Jan 2020 at 08:45, Damien Martins >> <damien at makelofine.org <mailto:damien at makelofine.org>> wrote: >> >> Hi all, >> >> I'm starting to work on a set of Xymon client extensions to >> monitor >> Amazon Web Services (AWS) resources. >> >> As my own use case is not very representative, could you let >> me know >> what is missing in this list ? >> >> -EC2 instances checks (only the infrastructure layer, as the >> OS can >> easily run genuine xymon client) >> >> -RDS instances >> >> -CloudWatch metrics/logs (most important, as it can be used >> as a central >> point) >> >> -CloudTrail events >> >> -S3 usage >> >> -IAM users/roles/policies (to ensure nothing changed) >> >> -CloudFormation (check stacks are not drifting from template) >> >> >> Feel free to tell me what service are missing, and explain >> the use case, >> the important things to check. >> >> This could be a long work, so do not expect to have something >> delivered >> before Q2. >> >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com <mailto:Xymon at xymon.com> >> http://lists.xymon.com/mailman/listinfo/xymon >>

1 0

RE Xymon 4.3.30 Released - SNMP support
by bferrell＠baywinds.org 15 Aug '20

15 Aug '20

I've managed to built the SNMP support When xymon-snmpcollector run, it fails with the following error: 2020-08-15 02:28:13.179227 Cannot open configuration files (?8?: running it with strace shows: open("(\3508\321:", O_RDONLY)?????????? = -1 ENOENT (No such file or directory) I can't for the life of me figure where it's looking for it's config file list or what this odd file it can't open is. Thoughts?

2 1

apache.conf
by Brian.Scott＠bunyatech.com.au 14 Aug '20

14 Aug '20

Hi List, I was just setting up Xymon at a new job and noticed something odd about the xymon-apache.conf file as installed. For the modern apache permissions model there is an effective 'Require all granted' or-ed with 'Require valid-user' for the cgi-secure directory. This means that by default access is granted because the 'Require all granted' is always true. The simple answer is to remove the: <IfModule mod_authz_core.c> ??????? # Apache 2.4+ ??????? Require all granted </IfModule> section. Trivial diff attached. Cheers, Brian

2 1

Limiting items in rrd graphs
by jeremy＠laidman.org 13 Aug '20

13 Aug '20

John On Thu, 30 Apr 2020 at 22:14, Rothlisberger, John R. via Xymon < xymon at xymon.com> wrote: > > Does anyone know how to limit how many items are placed into a single rrd > graph? > > > > Ex. Graphs for ifstat can have (what appears to be) 6 different interfaces > and the lines can get obscured behind other lines if the data is similar. > How could I limit how many interfaces end up in a single graph? > Multi-line graphs or multigraphs are a feature of the svcstatus.cgi code - see man svcstatus.cgi for more info. The options for svcstatus.cgi are set by the CGI_SVC_OPTS defined in cgioptions.cfg, and typically "--multigraphs" includes things like disk and if_load. The default, if not specified, is to enable multigraphs for "disk,inode,qtree,quotas,snapshot,TblSpace,if_load". This causes graphs for the relevant tests to have multiple lines on the one graph, up to 5, and if there are more than 5 then it creates a second graph and shares the lines between them, up to 10, and so on. However the multigraph behaviour can be manipulated, in the GRAPHS definition in xymonserver.cfg. For example, including "if_load::1" means to create a graph with lines for only one RRD file (ie interface) per graph rather than up to 5. The number after the double-colon indicates how many RRD files are to be included on each graph. As the default --multigraphs setting does not include ifstat, I wouldn't expect you to be seeing multiline graphs. However it appears that they are showing up that way anyway, perhaps because the [ifstat] definition in graphs.cfg contains a "FNPATTERN" so it does this automatically. Otherwise I would have suggested removing "ifstat" from "--multigraphs". I suspect changing "ifstat" in the GRAPHS definition to "ifstat::1" (or ::2 or whatever is your preference) will help. Cheers Jeremy

2 1

upgrade recommendations
by stella＠rider.edu 13 Aug '20

13 Aug '20

We have an old instance running 4.3.24 under RHEL6 and in an old physical server. Would like a complete upgrade including moving he server to our VM cluster. What would you recommend? P2V, OS upgrade to RHEL7, and Xymon upgrade? Or complete new installation including possibly using Terabithia's RPMs and migrating logs and such? Since we have several local clients reporting back, it'll have to be the same original IP address. Test new server, down old one and change IP address? Welcome any/all suggestions. TIA. -- ?(((=((===???(((================================================

4 3

Integer underflow in FILE mtime/ctime/atime check
by abe＠deuxchevaux.org 13 Aug '20

13 Aug '20

Hi, at least in Xymon 4.2.28 (plus recent CVE patches, i.e. as currently in Debian Stable) there is an issue with an integer underflow in the FILE mtime/ctime/atime check which basically seems to happen when finding the file to check takes a moment (seconds) and the file in question has been modified after the search for the file has been started. In such cases this integer underflow happens and causes a falso positive due to instead of the time difference being negative, it's insanely huge: [red] /nf/2020/08/12/nfcapd.202008122015 File was modified 4294967289 seconds ago - should be <360 File was modified 4294967289 seconds ago - should be <960 So far for me this only happened, when * client-local.cfg contains `...` commands to find the file, in our example it is file:`ls -1 $(ls -1d /nf/2???/??/??/ | tail -1)* | tail -1` to find the newest file under /nf/20??/ by first looking for the most recent directory and then finding the most recent file (both by just sorting them alphabetically) as listing all files would take much too long, hence the nested `... $() ...`. The corresponding entries in analysis.cfg are FILE %/nf/[0-9]*/[0-9]*/[0-9]*/nfcapd.[0-9]* MTIME<360 SIZE>9000000 yellow FILE %/nf/[0-9]*/[0-9]*/[0-9]*/nfcapd.[0-9]* MTIME<960 SIZE>1500 red * On a machine with slow I/O, in our case on a not that strong VM used for testing. I tried to reproduce this on a Raspberry Pi with a much simpler setup and Xymon 4.3.30, but failed so far and don't know, why: * client-local.cfg entry: file:`sleep 90; echo /run/xymon-integer-underflow-bug` * analysis.cfg entries: FILE /run/xymon-integer-underflow-bug red mtime<61 FILE /run/xymon-integer-underflow-bug yellow mtime>0 * I then setup a cron job, touching the file every minute. Hence the 61 in the checks above. Unfortunately this didn't suffice to trigger this issue. It is unclear to me why as the only explanation I have is the additional time needed to find the appropriate file to test. And the relevant code doesn't seem to have changed between 4.3.28 and 4.3.30... So I cheated a bit and setup the cron job to always set the file stamp to one hour in the future using "touch -d 'next hour' . Then I at least could trigger that integer underflow: red /run/xymon-integer-underflow-bug File was modified 4294963714 seconds ago - should be <61 I think there are several ways to fix this: * Move capturing the "now" timestamp just before checking the files timestamps, not before finding that file. Haven't noticed where the actual stat call is, though. * Use an signed instead of an unsigned integer to properly handle negative time differences. Tried to implement this as a patch as it seemed easy enough. So far I managed to get this far: [red] /run/xymon-integer-underflow-bug File was modified -3592 seconds ago - should be <61 So I guess that patch still needs more finetuning. Will send it once I got it fully working as I expect. But if there's interest in the incomplete patch already, I'm happy to send it anyways. (Respectively it is already online at https://salsa.debian.org/debian/xymon/-/blob/files-integer-undeflow/debian/…) 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/

2 2