October 2015 - Xymon - Xymon mailman web

Fix for RDP tests
by steuer＠hotmail.com 19 Oct '15

19 Oct '15

Hi Ryan – I tested with Windows 2003 server successfully. Anything older really shouldn’t be in operation anymore anyway. From: Novosielski, Ryan [mailto:novosirj at ca.rutgers.edu] Sent: Monday, October 19, 2015 1:34 PM To: J.C. Cleaver Cc: Rob Steuer; xymon at xymon.com; Kenneth S. Petersen Subject: Re: [Xymon] Fix for RDP tests Is it possible that this makes the test not work for older RDP servers? ____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences* || \\UTGERS <file:///\\UTGERS> |---------------------*O*--------------------- ||_// Biomedical | Ryan Novosielski - Senior Technologist || \\ and Health | novosirj at rutgers.edu- 973/972.0922 (2x0922) || \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark `' On Oct 19, 2015, at 06:12, J.C. Cleaver <cleaver at terabithia.org> wrote: On Sun, October 18, 2015 10:22 pm, Kenneth S. Petersen wrote: Hi Rob, It works perfect here. Using Xymon 4.3.21 with both 2008 / 2008 R2 / 2012 / 2012 R2 with no issues at all. Thanks for the update, I'll deleted the RDPNLA witch was the approach I did to get it to work. I'll too backup on the protocols.cfg updates in the next release. Fra: Xymon [mailto:xymon-bounces at xymon.com] På vegne af Rob Steuer Sendt: 19. oktober 2015 01:20 Til: xymon at xymon.com Emne: [Xymon] Fix for RDP tests Hi, After trying to implement the RDP tests for monitored hosts I noticed that they were returning a yellow warning with the warning text "Unexpected service response". I tried this for older hosts running Windows 2003 and newer hosts running 2008/2012 with RDP using NLA. It gave the warning text for both. So I'm guessing the original rdp test was implemented many years ago (2010 per below) when things were handled differently. The specification currently in the protocols.cfg file for RDP as it stands today is as follows: # Microsoft Terminal Services / Remote Desktop Protocol # From Chris Wopat (http://www.xymon.com/archive/2010/01/msg00039.html) [rdp] port 3389 send "\x03\x00\x00\x1e\x19\xe0\x00\x00\x00\x00\x00Cookie: mstshash=\r\n" expect "\x03\x00\x00\x0b\x06\xd0" I couldn't find anyone who provided a true fix in the archives other than suggesting doing a network trace. So that's what I did. After a bit of testing I found the following to work: # Microsoft Terminal Services / Remote Desktop Protocol # From Chris Wopat (http://www.xymon.com/archive/2010/01/msg00039.html) # Updated By Rob Steuer 10-17-2015 with send and expect strings that work for current versions of RDP [rdp] port 3389 send "\x03\x00\x00\x13\x0e\xe0\x00\x00\x00\x00\x00\x01\x00\x08\x00\x0b\x00\x00\x00" expect "\x03\x00\x00\x13\x0e\xd0\x00\x00\x12\x34" I was tempted to rename the protocol test to [rdpnla] or something like that to keep the old one around, but really the old one just didn't work for anything, so IMHO I think it just needs to be replaced entirely. I'd like feedback from others to see if this works for them also and see the protocols.cfg updated in the next release of Xymon. Thanks! Rob Hi Rob, I can confirm it's working for me as well. Thanks for the submission! It's been committed at https://sourceforge.net/p/xymon/code/7700/ Regards, -jc _______________________________________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

2 1

Patch for xymonclient-darwin.sh to fix numerous bugs
by jdwhite＠menelos.com 19 Oct '15

19 Oct '15

Greetings, The following patch fixes these long-standing issues with xymonclient-darwin.sh: * Disk usage test erroneously uses inode usage values as Darwin combines disk usage and inode usage into the same 'df' output by default. * Mountpoints with spaces in them were not reported. The former issues is fixed by passing the '-P' flag to 'df' to restore legacy mode reporting. The latter issue replaces spaces with underscores in the mountpoint. In addition to checking mount options for 'nobrowse', this patch also exclude readonly volumes which I find are mostly transient DMG files. Regards, -Jason -- Jason White jdwhite at menelos.com

3 3

Fix for RDP tests
by steuer＠hotmail.com 19 Oct '15

19 Oct '15

Hi, After trying to implement the RDP tests for monitored hosts I noticed that they were returning a yellow warning with the warning text "Unexpected service response". I tried this for older hosts running Windows 2003 and newer hosts running 2008/2012 with RDP using NLA. It gave the warning text for both. So I'm guessing the original rdp test was implemented many years ago (2010 per below) when things were handled differently. The specification currently in the protocols.cfg file for RDP as it stands today is as follows: # Microsoft Terminal Services / Remote Desktop Protocol # From Chris Wopat (http://www.xymon.com/archive/2010/01/msg00039.html) [rdp] port 3389 send "\x03\x00\x00\x1e\x19\xe0\x00\x00\x00\x00\x00Cookie: mstshash=\r\n" expect "\x03\x00\x00\x0b\x06\xd0" I couldn't find anyone who provided a true fix in the archives other than suggesting doing a network trace. So that's what I did. After a bit of testing I found the following to work: # Microsoft Terminal Services / Remote Desktop Protocol # From Chris Wopat (http://www.xymon.com/archive/2010/01/msg00039.html) # Updated By Rob Steuer 10-17-2015 with send and expect strings that work for current versions of RDP [rdp] port 3389 send "\x03\x00\x00\x13\x0e\xe0\x00\x00\x00\x00\x00\x01\x00\x08\x00\x0b\x00\x00\x0 0" expect "\x03\x00\x00\x13\x0e\xd0\x00\x00\x12\x34" I was tempted to rename the protocol test to [rdpnla] or something like that to keep the old one around, but really the old one just didn't work for anything, so IMHO I think it just needs to be replaced entirely. I'd like feedback from others to see if this works for them also and see the protocols.cfg updated in the next release of Xymon. Thanks! Rob

4 3

"invalid data" shown for swap usage; swap goes Clear (NOT red) and Memory goes Green
by mvanderw＠nd.edu 18 Oct '15

18 Oct '15

Hello, We've noticed that when total Swap being used is greater than the total Swap on the machine in the memory column/page, Xymon reports back with 0% for Swap usage and alongside it, it says, " - invalid data". We've noticed this happening several times for us and I assume it's due to excessive swap usage that causes the memory/swap usage being reported by the machine going completely out of wack... Here's a recent example: Memory Used Total Percentage[image: green] Physical 10183M 11910M 85%[image: green] Actual 9945M 11910M 83%[image: clear] Swap 1759218M 3967M 0% - invalid data This is fine and all and it's certainly not Xymon's fault in any way, as it's just reporting what the machine is reporting (and the machine is also showing wacked out numbers for swap usage). What I don't care for is that when this happens, the color/state for Swap just goes Clear, which causes the memory page/column to just go Green for the machine in question. This makes it very hard to know when this kind of thing happens and needs to be addressed (usually with a reboot of the machine), as it just appears that everything is fine since memory is showing Green. Often times, we don't even get any warning of excessive swap usage with any Yellow or Red alerts prior to this happening as it happens so fast on the machine, too fast for Xymon to catch it. Is it possible to make it so that this kind of situation causes the color/state for Swap to go Red, as an indication that something is very wrong and needs to be addressed, instead of going Clear? Or at least makes it go Yellow? I'd greatly appreciate this being changed so it at least doesn't show Clear! Any other suggestions for how to change this behavior are more then welcome! Thanks for the help!! -- Matt Vander Werf

2 2

Getting "ATT0001.bin" attachments sometimes -- MAILC fix is already in place
by hobbit＠elyograg.org 16 Oct '15

16 Oct '15

On 8/13/2015 9:01 AM, Ribeiro, Glauber wrote: > MAILC="tr -d \"\\001\\004\\015\" | mail" > > I think you shouldn't escape the quotes: > > MAILC="tr -d "\\001\\004\\015" | mail" I suspect that without the escapes, the variable won't have the right definition, since quotes are used to contain the value ... although it's possible that *with* the escapes, it won't have the right definition either. It's starting to sound like I need to write a script so that no special characters are required. An ugly hack, but I think it will work ... so I will go ahead and do that. A better option might be to create a feature where we can define a list of characters that should be stripped out of email text before it is sent, and have Xymon itself handle that. Thanks, Shawn

1 1

Xymon Proxy + Xymon Server
by mailinglists＠websitemanagers.com.au 13 Oct '15

13 Oct '15

Hi all, I was previously running an old version of hobbit and recently upgraded to Xymon (finally). I'm struggling again with the configuration of what must be an unusual case. The setup: Xymon server running on the main monitoring server in the office, internal IP is 192.168.x.1 and external IP does NAT for port 1984 into this internal IP so remote xymon clients can report in. At one location, the network consists of a linux based firewall, plus a bunch of servers. The firewall doesn't do NAT or any sort of forwarding, so all connections between the Internet and this bunch of servers must transit the squid proxy on the firewall (or similar). I also run a local xymon server on the linux firewall, and this works well. However, I want to forward all the status of everything back to the main xymon server in the office above. So, the obvious solution is to use the xymon proxy to receive reports from the "bunch of servers" and then send the data to both the local xymon server as well as the office xymon server. To do this I've configured things like this: From tasks.cfg: # Listen on 127.0.0.1 only [xymond] ENVFILE /usr/lib/xymon/server/etc/xymonserver.cfg CMD xymond --pidfile=/var/run/xymon/xymond.pid \ --restart=$XYMONTMP/xymond.chk --checkpoint-file=$XYMONTMP/xymond.chk --checkpoint-interval=600 \ --log=$XYMONSERVERLOGS/xymond.log \ --admin-senders=127.0.0.1,$XYMONSERVERIP \ --store-clientlogs=!msgs \ --listen=127.0.0.1 # Listen on the internal LAN IP, and send data to both 127.0.0.1 and the office xymon server [xymonproxy] ENVFILE /usr/lib/xymon/server/etc/xymonserver.cfg CMD $XYMONHOME/bin/xymonproxy --server=X.23.7.2,127.0.0.1 --listen=10.0.0.1 --report=$MACHINE.xymonproxy --no-daemon --pidfile=/var/run/xymon/xymonproxy.pid LOGFILE $XYMONSERVERLOGS/xymonproxy.log All the other normal xymon server tasks are enabled as well, such as xymonnet etc... However, if I set XYMONSERVERS=127.0.0.1 everything works well, except that most status reports from xymonnet and xymonclient don't get sent to the remote xymon server (since they don't get to the proxy). If I set XYMONSERVERS to the LAN IP of the xymon proxy 10.0.0.1 then all the status reports are sent to both servers, but the web interface is broken. Clicking on a dot to see the current status gives a error message 403 Invalid host. So, is there something I'm missing with my config? Should the proxy allow the www pages to work by passing whatever query through? How can I override XYMONSERVERS value depending on where it is used, and how do I know which parts I need to override? Any suggestions? Thanks, Adam

2 1

combo.cfg: integer arithmetic and comparisons broken
by abs＠shadymint.com 12 Oct '15

12 Oct '15

All, It seems that since revision 7092, this construction mentioned in the man pages no longer works:- WebCluster.http = (Web1.http + Web2.http + Web3.http) >= 2 I think this patch solves the above issue and hasn't adversely affected any of our other combo tests :- diff -c xymond/combostatus.c.FCS xymond/combostatus.c *** xymond/combostatus.c.FCS 2015-05-13 10:16:32.000000000 -0400 --- xymond/combostatus.c 2015-10-11 07:38:59.000000000 -0400 *************** *** 287,293 **** done = 0; inp=symbolicexpr; outp=expr; symp = NULL; while (!done) { ! if (isalpha((int)*inp) || (isdigit((int)*inp) && *(inp+1) && (*(inp+1) > ' ') && *(inp+2) && (*(inp+2) > ' ')) ) { /* puke */ if (!insymbol) { insymbol = 1; symp = symbol; } *symp = *inp; symp++; } --- 287,293 ---- done = 0; inp=symbolicexpr; outp=expr; symp = NULL; while (!done) { ! if (isalpha((int)*inp) || (isdigit((int)*inp) && insymbol && *(inp+1) && (*(inp+1) > ' ') && *(inp+2) && (*(inp+2) > ' ')) ) { /* puke */ if (!insymbol) { insymbol = 1; symp = symbol; } *symp = *inp; symp++; } Thanks -- Andy

2 2

Error running make install
by Myoung＠ataonline.com 12 Oct '15

12 Oct '15

Sorry Guys. My OS info is listed below. Ubuntu 14.04 64bit Xymon.sourceforge.net is where I got the source files from. I am new to Linux so I apologize for any shortcomings that may occur. LOL Thanks Mark -----Original Message----- From: John Thurston [mailto:john.thurston at alaska.gov] Sent: Monday, October 12, 2015 10:42 AM To: Mark Young <Myoung at ataonline.com> Subject: off-list Re: [Xymon] Error running make install On 10/12/2015 5:20 AM, Mark Young wrote: > When I am running the make command to install Xymon 4.3.21 I get the > following error. > > Xmongrep.c:23:21: Fatal error: version.h: no such file or directory > > #include “version.h” > Some hints as to what OS you are using, on what architecture, and where you got your source would make suggestions more meaningful. Without those, we're just playing 20-questions. -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska ________________________________ ========= CONFIDENTIALITY NOTICE ========= This message and its attachments (if any) may contain confidential, proprietary or legally privileged information and is intended only for the use of the addressee named above. No confidentiality or privilege is waived or lost by any mistransmission. If you are not the intended recipient of this message you are hereby notified that you must not use, disseminate, copy it in any form or take any action in reliance on it. If you have received this message in error please delete it and any copies of it and kindly inform the sender of this e-mail by replying.

1 0

Very peculiar behaviour in Analysis.cfg
by neilsimmonds1808＠gmail.com 12 Oct '15

12 Oct '15

Hi all, I seem to be having problems with CLASS in analysis.cfg and I'm really not sure as to why. I hope I can explain this well enough. I have some servers picking up the rules from analysis.cfg and some not, I've selected 2 as samples to try and illustrate the issue. These are the entries from hosts.cfg for each server 172.01.01.01 server1 # http://server1:2801/utils/enterLogin.jsp NOPROPYELLOW:disk,cpu,mq delayyellow=cpu:15 delayred=cpu:15 CLASS:linux 172.01.01.02 server2 # NOPROPYELLOW:disk,cpu delayyellow=cpu:15 delayred=cpu:15 CLASS:linux As you can see, both force the CLASS:linux parameter. Each server has it's own config file in an analysis.d directory which is included near the bottom of the analysis.cfg file. server 1's file contains this, HOST=server1 GROUP=unixsupport PORT "LOCAL=%([.:]22)$" state=LISTEN TEXT=ssh PROC cybAgent.bin 1 PROC rmi_server1 1 -1 red PROC admin_server1 1 -1 red PROC eventprocessor_server1 1 -1 red PROC queuemanager_server1 1 -1 red PROC scheduler_server1 1 -1 red PROC workflowengine_server1 1 -1 red PROC "server1Cell01 server1Node01 pim01srv" 1 -1 red PROC init 1 -1 red PROC tlmagent.bin 1 PROC /opt/tivoli/tsm/client/ba/bin/dsmcad 1 PROC "/opt/tivoli/tsm/client/ba/bin/dsmc sched" 1 LOG %/opt/IBM/MDMPIM/logs/\w*server1/\w*.log "internal error" COLOR=yellow IGNORE="unregistered" LOG /opt/IBM/MDMPIM/logs/workflowengine_server1/db_manager.log "CWPCM0033W:An error occurred when registering thread: heartbeat_workflowengine" COLOR=red LOG /applogs/mdmpim/logs/appsvr_server1/default.log "/utils/custom_page.jsp] ERROR jsp.footer - CWPCM0002E:Generic error / Exception: Not an AustinException, Exception:Failure to acquire exclusive lock for AustinContext" COLOR=red MQ_QUEUE SYSTEM.DEAD.LETTER.QUEUE depth-warning=1 MQ_QUEUE "%([A-Z.]*BO)$" depth-warning=1 and server 2's contains this, HOST=server2 GROUP=unixsupport PORT "LOCAL=%([.:]22)$" state=LISTEN TEXT=ssh PROC /home/dasusr1/das/adm/db2dasrrm 1 PROC /opt/IBM/db2/V9.7/bin/db2fmcd 1 PROC /opt/IBM/db2/V9.7/das/bin/db2fmd 1 PROC db2sysc PROC tlmagent.bin 1 PROC /opt/tivoli/tsm/client/ba/bin/dsmcad 1 PROC "/opt/tivoli/tsm/client/ba/bin/dsmc sched" 1 Nothing unusual or out of the ordinary in either of those. in my analysis.cfg file I have the following, HOST=* DISK %^/mnt IGNORE DISK %^/nimdir 101 101 DISK %^/media IGNORE DISK %^/cdrom IGNORE CLASS=win32 # SVC CentennialIPTransferAgent startup=automatic status=started # SVC %McShield startup=automatic status=started # CLOCK 600 yellow CLASS=linux UP 10m PROC ntpd 1 PROC /usr/sbin/sshd 1 DISK /nmon 95 98 TIME=W:0800:1800 DISK /nmon 95 101 CLASS=aix # PROC /usr/sbin/syslogd 1 PROC /usr/sbin/xntpd 1 PROC /usr/sbin/cron 1 PROC /usr/lib/errdemon 1 PROC /usr/sbin/syncd 1 PROC sshd 1 DISK /nmon 95 98 TIME=W:0800:1800 DISK /nmon 95 101 TIME=W:1800:0800 DISK /perf 95 98 TIME=W:0800:1800 DISK /perf 95 101 TIME=W:1800:0800 DISK /temp IGNORE # include files directory /xymon/server/etc/analysis.d CLASS=linux MEMSWAP 10 30 DEFAULT # These are the built-in defaults. UP 10m LOAD 6.0 8.0 DISK * 95 98 MEMPHYS 100 101 MEMSWAP 50 80 MEMACT 90 97 Server 1 does not pick up the lines in the analysis.cfg file yet server 2 does. That is the confusing thing, as far as I can see, both should pick up these rules. Thanks, Neil.

1 0

possible xymon 4.3.21 holiday alerting bug?
by g.stone-tolcher＠its.uq.edu.au 12 Oct '15

12 Oct '15

Hi, We are seeing unusual alerting behaviour with Xymon 4.3.21 server using a "holidays.cfg" with HOLIDAYLIKEWEEKDAY=0. We have a network operations team (uqnoc-sms) that gets alerts during business hours (TIME=W:0800:1700) And a data networks team (dn-sms) that get out of business hours alerts in certain windows (TIME=W:0600:0759,W:1701:2200,60:0600:2200) Rules are like: PAGE=$UNSMSREGEX EXHOST=$UNEXCLUDE MAIL uqnoc-sms at xx.yy.edu.au SERVICE=$UNSMSSVCS DURATION>6m TIME=W:0800:1700 COLOR=red REPEAT=1w FORMAT=SMS RECOVERED MAIL dn-sms at xx.yy.edu.au SERVICE=$UNSMSSVCS DURATION>6m TIME=W:0600:0759,W:1701:2200,60:0600:2200 COLOR=red REPEAT=1w FORMAT=SMS RECOVERED For a "red" conn test covered by the rule on a weekday public holiday, it seems to correctly identify not to send an alert to "uqnoc-sms" (TIME=W:0800:1700 ) and instead correctly generates an alert to "dn-sms" (TIME=60:0600:2200 component), but then keeps sending the same alert approximately every minute (my xymonnet poll cycle). Ignores REPEAT=1w? Before I try and debug much further, I thought I would ask if anyone else has seen similar behaviour? I have tried turning on the "-trace=filename" option of xymond_alert channel, but with a 7000 line hosts.cfg and 130 odd alerting rules it is rather hard to see what is going on in the trace file. I think I would have to build an isolated test environment, unless someone has one they could test a similar config to above in. Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: g.stone-tolcher at its.uq.edu.au<mailto:g.stone-tolcher at its.uq.edu.au> W: www.its.uq.edu.au<http://www.its.uq.edu.au> ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B

2 3