- Xymon - Xymon mailman web

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

alerts.cfg DURATION rule being ignored
by clovis＠ipost.com 05 Aug '20

05 Aug '20

Hello, Our Xymon server is monitoring about a hundred hosts and has been doing so nicely for years.? However DURATION rule is being ignored. I have several lines like this in alerts.cfg: SCRIPT <script location> <email address> SERVICE=replication DURATION>30m REPEAT=30d COLOR=red,purple Replication is a custom check. But the alert (scripted email) is being sent as soon as the check goes red, not 30 minutes later. Any suggestions as to why this could be? Using Xymon 4.3.30.

3 9

Xymon 4.3.30 Released
by earle＠isolar.DynDNS.ORG 04 Aug '20

04 Aug '20

On 31 Jul 2020, at 7:27, Japheth Cleaver <cleaver at terabithia.org> wrote: >> Japheth, >> >> Will 4.3.31 be out soon or will it jump to 4.4? > > I'm looking at the XSS report and sorting through a variety of the > patches since this release now. > > There will be a 4.3.31 release with this as well as other updates, as > well as a 4.4 pre-release. Due to there being a longish gap, a > maintenance release is appropriate. We haven't yet gotten a formal 4.3.30 Terabithia RPM release for Fedora 31 (it's still in "testing") much less Fedora 32 (not even one in "testing"). Could you get those out to production before moving on to doing a 4.3.31? - Greg

1 0

Multiple xymon clients behind same IP
by vadud3＠gmail.com 01 Aug '20

01 Aug '20

I have multiple xymon clients (multiple devices at home) and the xymon server is at cloud. The outgoing IP is same for all the xymon clients. How do I monitor them? -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

3 3

xymondboard error
by dl1025＠att.com 30 Jul '20

30 Jul '20

I recently started seeing these error messages in my log file periodically. When these messages appeared, I noticed that some of the tests turned red and white status but not all. Could you point me in the right direction of how I can trouble shoot this error messages? 2020-07-29 12:30:13.241732 Whoops ! Failed to send message (timeout) 2020-07-29 12:30:13.456322 -> 2020-07-29 12:30:13.456362 -> Recipient x.x.x.x, timeout 15 2020-07-29 12:30:13.456375 -> 1st line: 'xymondboard fields=hostname,testname,color,flags,lastchange,logtime,validtime,acktime,disabletime,sender,cookie,line1,acklist ' 2020-07-29 12:30:13.456394 xymond status-board not available, code 7 2020-07-29 12:30:13.456409 Failed to load current Xymon status, aborting page-update

2 2

Xymon and XSS vulnerability
by gatis.anee＠gmail.com 30 Jul '20

30 Jul '20

Hi, Looking for help. Does anyone know something about this rather old XSS vulnerability? https://infosec.rm-it.de/2012/04/08/xss-in-xymon/ It is kind of still there in the 4.3.30 version. Any ideas how can it be solved? Regards Gatis

2 1

mq.sh script
by neilsimmonds1808＠gmail.com 29 Jul '20

29 Jul '20

I've already tried running it with a set -x in the script and get the following in the log, + rm /xymon/client/tmp/mq-server_name.11677 + TMPFILE=/xymon/client/tmp/mq-server_name.11684 + touch /xymon/client/tmp/mq-server_name.11684 + echo 'client server_name.mqcollect mqcollect' + '[' 1 '!=' 0 ']' + QMGR=PPIM01 + shift + sudo -u mqm mqsc PPIM01 'display qstatus(*) curdepth msgage lgetdate lgettime' + '[' 0 '!=' 0 ']' + /xymon/client/bin/xymon ukclamon01 @ log:/opt/IBM/MDMPIM/logs/workflowengine_server_name/db_manager.log:10240 log:`find -L /opt/IBM/MDMPIM/logs/\w*server_name/\w*.log -maxdepth 1 -type f ! -size 0`:10240 log:/applogs/mdmpim/logs/appsvr_server_name/default.log:10240 log:/opt/IBM/MDMPIM/logs/workflowengine_server_name/customegl.log:20480 log:/opt/IBM/MDMPIM/logs/workflowengine_server_name/default.log:20480 ignore INFO trigger internal error file:`find /applogs/mdmpim/dump -name *.txt` file:`find /applogs/mdmpim/dump -name *.phd`` >From there I can see that it appears to be the line that sends the message to Xymon that's doing it but U can't see why. The line in question is underlined and BOLD below (copied the whole script for context) TMPFILE="$XYMONTMP/mq-$MACHINE.$$" touch $TMPFILE echo "client $MACHINE.mqcollect mqcollect" >$TMPFILE # while [ $# != 0 ] do QMGR=$1; shift sudo -u mqm mqsc $QMGR 'display qstatus(*) curdepth msgage lgetdate lgettime' >> $TMPFILE ##(echo 'dis ql(*) curdepth'; echo 'dis chs(*)'; echo 'end') | su - mqm -c "runmqsc $QMGR" >> $TMPFILE done # *$XYMON $XYMSRV "@" < $TMPFILE* rm $TMPFILE exit 0 On Mon, Jul 27, 2020 at 5:54 PM Damien Martins via Xymon <xymon at xymon.com> wrote: > > > > ---------- Forwarded message ---------- > From: Damien Martins <damien at makelofine.org> > To: xymon at xymon.com > Cc: > Bcc: > Date: Mon, 27 Jul 2020 18:44:19 +0200 > Subject: Re: [Xymon] mq.sh script > > Hello, > > I'm not using this script, but you may run it using: > > bash -x $XYMONCLIENTHOME/ext/mq.sh queuemanagername > > replace $XYMONCLIENTHOME with the correct path. > > Bash will generate output debug info, so you may see what it is doing. > > Also, you may check if the log destination is hardcoded in the script. > > > Le 27/07/2020 ? 16:39, Neil Simmonds a ?crit : > > Hi all, I'm seeing some really strange behaviour from the MQ.SH script/ > > We have the standard mq.sh script that comes with Xymon and we have it > setup in /xymon/client/etc/clientlaunch.cfg as follows > > [mq] > ENVFILE $XYMONCLIENTHOME/etc/xymonclient.cfg > CMD $XYMONCLIENTHOME/ext/mq.sh queuemanagername > LOGFILE $XYMONCLIENTLOGS/xymonmq2client.log > INTERVAL 1m > > The behaviour that we are seeing is that,as expected MQ.SH writes nothing > in the way of errors into xymonmq2client.log but what it does write into > there is the contents of /xymon/client/tmp/logfetch.hostname.cfg > > (i.e. > log:/applogs/broker/broker.log:20480 > ignore MARK > ) > > I'm at a loss to explain this so am reaching out to the list to see if > anyone has come across this > > Regards, > Neil. > > _______________________________________________ > Xymon mailing listXymon at xymon.comhttp://lists.xymon.com/mailman/listinfo/xymon > > > > > ---------- Forwarded message ---------- > From: Damien Martins via Xymon <xymon at xymon.com> > To: xymon at xymon.com > Cc: > Bcc: > Date: Mon, 27 Jul 2020 18:44:19 +0200 > Subject: Re: [Xymon] mq.sh script > _______________________________________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/mailman/listinfo/xymon >

2 1