August 2020 - Xymon - Xymon mailman web

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

alerts
by jeremy＠laidman.org 13 Aug '20

13 Aug '20

Hi Jean Alerts are sent by the xymond_alert module. You can find more information about debugging (eg the "--test") in the man page for this tool. The xymond_alert binary sends logs into a logfile, usually called alerts.log. On my system, this is /var/log/xymon/alerts.log. The alerts.cfg file has a "RECOVERED" keyword, which you might want to use. I would have thought that a flapping condition would be just as important to alert on as the underlying condition. I'd be interested to know your circumstances relating to this. You can also specify DURATION>30 to not send alerts until a fault condition is persistent for more than 30 minutes. This may prevent alerts for flapping conditions, in some cases. You can also adjust the global flap-detection parameters - see the man page for xymond. If you want more control over what alerts are sent out, you could implement your own alerting script that filters some alerts out (such as any for a flapping status). You would specify a "SCRIPT" recipient in alerts.cfg, and your script could ascertain whether flapping was present, either from the BBALPHAMSG environment variable, or by querying xymond using 'xymon xymondboard' or something similar. Cheers Jeremy On Tue, 19 May 2020 at 00:10, Hyppolite, Jean via Xymon <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: "Hyppolite, Jean" <Jean.Hyppolite at umm.edu> > To: "xymon at xymon.com" <xymon at xymon.com> > Cc: > Bcc: > Date: Mon, 18 May 2020 14:08:40 +0000 > Subject: alerts > > Hello, > > > > Our Xymon server is sending out a lot of excess and some false alerts. It > seems that when a server is not reachable it sends the alerts out, but when > the server recovers it never sends the recovery message, but keeps sending > the down critical messages. And idea what may be causing this? Is there a > way to look at exactly what alerts are being sent out from the xymon server > from xymon? Also is there a way to configure xymon not to send out email > alerts on flapping statuses? > > Our Xymon server version is: Xymon 4.3.30-1.el7.terabithia > > > > > > Thanks > > Jean > > > > > > > > > This e-mail and any accompanying attachments may be privileged, > confidential, contain protected health information about an identified > patient or be otherwise protected from disclosure. State and federal law > protect the confidentiality of this information. If the reader of this > message is not the intended recipient; you are prohibited from using, > disclosing, reproducing or distributing this information; you should > immediately notify the sender by telephone or e-mail and delete this > e-mail. > > > > ---------- Forwarded message ---------- > From: "Hyppolite, Jean via Xymon" <xymon at xymon.com> > To: "xymon at xymon.com" <xymon at xymon.com> > Cc: > Bcc: > Date: Mon, 18 May 2020 14:08:40 +0000 > Subject: [Xymon] alerts > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

1 0

SNMP issue
by patrik.vajda＠Getronics.com 12 Aug '20

12 Aug '20

Hello Team, We have an issue with Xymon monitoring tool. Do you support 3COM switches? SNMP is not working for two 3COM devices and we do not know where is the issue. Which SNMP version is supported? Xymon version: Xymon 4.3.28. Many thanks in advance for your help! Best Regards, Patrik Vajda | Network Security Engineer | Managed Network & Security - EUR2 Tel: +36707979512 [cid:image001.jpg at 01D6708B.6CB3B510] Upcoming annual leave : - Vajda Patrik | Network Security Engineer Getronics ________________________________ T. +36707979512 | M. +36707979512 | E. patrik.vajda at Getronics.com | W. www.getronics.com Getronics Magyarorsz?g Kft. - 1027 Budapest, Henger u. 2/B - Ad?sz?m: 10532782-2-44 - C?gjegyz?ksz?m: 01-09-071867 A tov?bb?tott inform?ci?t csak a c?mzett hasznos?thatja, ?s az tartalmazhat bizalmas ?s/vagy jogilag v?dett tartalmat. Az inform?ci? megismer?se, tov?bb?t?sa, nyilv?noss?gra hozatala, vagy egy?b felhaszn?l?sa, illetve a c?mzett?l elt?r? szem?ly ?s/vagy szervezet ezen inform?ci? alapj?n t?rt?n? b?rmilyen cselekedete tilos. Amennyiben t?ved?sb?l kapta, k?rj?k azonnal ?rtes?tse a felad?t ?s/vagy a c?mzettet, ?s t?r?lje ezt az ?zenetet. K?sz?nj?k! Jogi ?s etikai nyilatkozat: http://www.getronics.com/legal/

2 1

Analysis Not Working as expected
by companydavid49＠gmail.com 06 Aug '20

06 Aug '20

Hi, My analysis.cfg doesn't see to be working but host.domain.local still alerts at 82%. My understanding is that the yellow alert for this host should be 90 and the red 95. This is the first entry in the alerts file. HOST=host.domain.local MEMSWAP 90 95 MEMACT 90 95 MEMPHYS 90 95

3 2

Strange issue when using local scripts (in linux)
by davieb＠gmail.com 05 Aug '20

05 Aug '20

Hi, I've got a strange date issue. I've written some local scripts to pad information onto the combo message. Here is the background: 1. When you run the script by hand locally (take note of the date): [davieb at xymonsvr ~]$ ~xymon/client/local/dateinfo dhcp-common,4.3.6,18 Jul 2020 2. When I pull the information from xymon server: [davieb at xymonsvr ~]$ ~xymon/server/bin/xymon localhost "clientlog xymonsvr section=local:dateinfo" [local:dateinfo] dhcp-common,4.3.6,Jul 18 17:44:26 Notice how the date field gets modified? I can't figure out why. The only thing I can think of is something within the xymon code, but I don't know why it would? Here's the simple script: [davieb at xymonsvr ~]$ cat ~xymon/client/local/dateinfo #!/bin/sh OS=`uname -s` RPM=dhcp-common if [ ${OS} = "Linux" ]; then VERSION=`rpm -q ${RPM} --qf "%{VERSION}\n"` INSTALLED=`rpm -q ${RPM} --qf "%{INSTALLTIME:date}\n"|awk {'print $2" "$3" "$4'}` fi echo "${RPM},${VERSION},${INSTALLED}" Does anybody have any idea what is going on? Thanks, Dave

2 9