February 2016 - Xymon - Xymon mailman web

4.3.24 tests not clearing once disable expiration is reached
by larry＠fni-stl.com 12 Feb '16

12 Feb '16

I would like to officially retract this email. JC pointed out that the color doesn't change from blue on an expired disable until an update is provided on the test. In this case my ext script was skipping over any tests that were reporting as blue. So I've had this problem for quite a while and just didn't realize it until recently. So I've adjusted my script and all is humming along as usual. Thanks JC. From: Larry Bonham Sent: Wednesday, February 10, 2016 4:44 PM To: xymon at xymon.com Subject: 4.3.24 tests not clearing once disable expiration is reached I just noticed in 4.3.24 (RHEL 6.7) that a few monitors are not getting enabled once the disable expiration time is reached. All the "normal" tests seem to work fine. This is an environmental sensor device that is accessed with snmptraps and snmpgets for data retrieval. That is all functioning as it should. But when any of these particular tests are disabled (e.g. DC_Door_Alarm.ups) for a set time, they are now not getting enabled when the expiration time has been reached. They just remain blue. I did verify that the expiration time stamps are correct. So I'm assuming the problem is triggered due to the way the hosts.cfg entries are set up. Previous version used was 4.3.21 and disable expiration was working with it. Example from hosts.cfg # Data center facilities sensor 10.10.10.10 Sensor9 0.0.0.0 DC_Door_Alarm # noconn main side ups 0.0.0.0 DC_VESDA # noconn fault prealarm fire 0.0.0.0 DC_Fans # noconn fans ========================================================= Larry D. Bonham ========================================================= ________________________________ CONFIDENTIALITY NOTICE: This electronic mail message is intended exclusively for recipient to which it is addressed. The contents of this message and any attachments may contain confidential and privileged information. Any unauthorized review, use, print, storage, copy, disclosure or distribution is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to the message's sender and delete all copies of this message and its attachments without disclosing the contents to anyone, or using the contents for any purpose.

2 2

Phantom red statuses (Fwd: Xymon [750466] mgmtconsole:msgs CRITICAL (RED))
by earle＠isolar.DynDNS.ORG 11 Feb '16

11 Feb '16

I'm running Xymon 4.3.12-2 server (yeah, I know ...) on my management system. (RHEL 6.5 currently) A couple of days ago I migrated our central syslog server over to the Xymon server, so now "/var/log/messages" is getting a ton of stuff in it that it never had before since all my systems are now reporting in to it. Ever since then I've seen something weird - every hour (for about 17+ hours) I was getting RED alerts for the management console's own "msgs" status, but the actual e-mail notifications don't show anything marked red in them! It's either yellow or, as in the forwarded message below, green. I have no idea why I was getting RED alerts for this file if it thinks it's yellow or green - any ideas? The only other thing I can add is that when I go to the Web page for mgmtconsole:msgs, it says "WARNING: Flapping status" at the top. Is that a clue? (Update: interestingly, it looks like the status has finally changed to green a few minutes ago - after having been red for nearly 17 1/2 hours. Still seeing "WARNING: Flapping status" on the svcstatus Web page, though.) Thanks, - Greg > Begin forwarded message: > > From: xymon Monitor <xymon at mgmtconsole.my.do.ma.in> > Subject: Xymon [750466] mgmtconsole:msgs CRITICAL (RED) > Date: February 11, 2016 at 11:57:25 AM PST > To: sysadmins at mgmtconsole.my.do.ma.in > > green Thu Feb 11 11:57:24 PST 2016 - Log files ok > <pre> > </pre> > > No entries in <a href="/xymon-cgi/svcstatus.sh?CLIENT=mgmtconsole&SECTION=msgs:/var/log/messages">/var/log/messages</a> > > > Full log <a href="/xymon-cgi/svcstatus.sh?CLIENT=mgmtconsole&SECTION=msgs:/var/log/messages">/var/log/messages</a> > <...SKIPPED...> > Feb 11 11:57:17 host7 nrpe[20194]: [ID 927837 daemon.info] connect from mtfuji > > [... rest elided ... ] > > See http://mgmtconsole/xymon-cgi/svcstatus.sh?HOST=mgmtconsole&SERVICE=msgs

3 2

4.3.25 - ouch (reverting to 4.3.22)
by john.thurston＠alaska.gov 11 Feb '16

11 Feb '16

My testing of the release candidate was obviously inadequate. My phone rang off the hook after shipping 4.3.25 to my production server. I've reverted it to 4.3.22 while I try to get a handle on the changes. :: svcstatus refresh :: I didn't see any mention of this in the release notes, but the page is now being delivered with a 30-second _header_ refresh in place of a 60-second _meta_ refresh. I assume the change in method is related to XSS protection changes, but I don't know for sure. The shortening of the interval concerns me much more than the change in method. I'd prefer the darned page didn't refresh at all, but hard coding it to every half minute? Ouch. Ick. What's the business case here? Anyone who his visually monitoring a single info page can hit F5 when they want a refresh, can't they? :: XSS protections :: It looks like the XSS protection bits inserted into http headers > content-security-policy: script-src 'self'; connect-src 'self'; form-action 'self'; sandbox allow-forms; > X-Content-Security-Policy: script-src 'self'; connect-src 'self'; form-action 'self'; sandbox allow-forms; > X-Webkit-CSP: script-src 'self'; connect-src 'self'; form-action 'self'; sandbox allow-forms; has broken several functions for me. The most important things are the notes our operators use to figure out who to call. We insert some html into the DESCR tag of hosts.cfg. This appears on the "info" page as a link. The links are to static content served by the same Apache web server. The tags are of the form: > DESCR:"Important Server:<a href=/xymon/CNotes/ImportantServer target=Notes>Reference notes</a>" With Firefox, the links work. With InternetExploder and Chrome, the links quietly fail to work. The Chrome console returns the error message: Blocked script execution in 'https://foo.bar.com/xymon- cgi/svcstatus.sh?HOST=bb.bar.com&SERVICE=info' because the document's frame is sandboxed and the 'allow-scripts' permission is not set. Removing the "target" property from the A tag allows it to work. It overwrites the info page, but at least it works :p It feels like a step back to the 90's be forced into a single page that keeps getting replaced. I don't know enough about the "content security policy". What are my options to retain the named-window/tab capabilities? :: svcstatus disable function :: We are unable to enable/disable test from a host's "info" page. We can do so from enadis.sh, but this is a lot harder for many of our users. In Chrome, attempts to disable tests from the "info" page is generating the same "frame is sandboxed" messages. In Firefox, the attempts just don't do anything. There are messages in the console Content Security Policy: The page's settings blocked the loading of a resource at self ("script-src https://x.foo.com"). so maybe the information necessary to build the form isn't even being loaded. -- 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

3 9

Patch: AIX memory actual
by stef.coene＠docum.org 11 Feb '16

11 Feb '16

On Thursday 11 February 2016 09:57:06 you wrote: > Stef, is there a way to adjust the memory so it can't exceed 100%? Does it > make sense for actual memory usage to be more than 100%? The graph.cfg > definition for [mem], [memory] and [ram] have "-u100" defined, which means > xymon will likely not graph data points greater than 100. Also, I suspect > the code that creates the RRD file will have set the upper value to 100, > and will cause xymon to drop data points greater than 100. No, Actual memory on AIX is the amount of memory in use. And this can be more then 100% of the physical memory. If it does, swap will be used as memory. This is of course if you use the physical memory as the max for actual memory. If you take swap + physical as the max for actual, It can never exceed 100%. But that's normally not done. You want to know if the memory that's needed can fit in the physical memory. For linux, bbwin, freebsd and irix the actual memory is processed. And I don't see why this can't exceed 100% on theses OS'es if you allocate too much memory. But I never had a case, except for AIX. And for the code that generated the rrd, that's also changed in my patch. And for the graph, indeed, that definition also needs to be updated. PS: I CC'ed the mailing list. Stef

1 0

Patch: filelist option for graph page
by stef.coene＠docum.org 11 Feb '16

11 Feb '16

Hi, This patch enhances the graph creation pages and add a filelist option. This option can be used to limit what will be graphed. When the graph has FXPATTERN it will limit the matched files to what's specified in the filelist option. This is handy if you want to generate custom graphs. Example: this will create a network graph of only device eth0 showgraph.sh?host=host01service=ifstat&filelist=eth0&action=menu Stef

1 0

Patch: AIX memory actual
by stef.coene＠docum.org 11 Feb '16

11 Feb '16

Hi, On AIX, the actual memory is reported. And it can also be bigger then 100% . This patch will get the actual memory for AIX and allows for memact > 100%. Stef

1 0

Patch: 2 extra counters CPU counter for AIX
by stef.coene＠docum.org 11 Feb '16

11 Feb '16

Hi, I have some patches that I apply when a new xymon version comes out. Maybe some of them are handy and can be included by default. All new IBM Power CPU's has 2 extra counters for CPU: Physical CPU used and entitled capacity used (in %). This patch will add them to the vmstat.rrd. BUT this will change the rrd and add 2 data sources. So this means that rrdtool tune must be used to manually add the 2 new data sources to the rrd! Relevant graph definitions: [vmstat-ec] TITLE Used Entitled CPU Capacity YAXIS ec % -b 1000 DEF:ect=vmstat.rrd:cpu_ec:AVERAGE CDEF:ec=ect,10,/ LINE2:ec#00CC00 GPRINT:ec:LAST:ec \: %5.1lf%s%% (cur) GPRINT:ec:MAX: \: %5.1lf%s%% (max) GPRINT:ec:MIN: \: %5.1lf%s%% (min) GPRINT:ec:AVERAGE: \: %5.1lf%s%% (avg)\n [vmstat-ec-multi] FNPATTERN vmstat.rrd TITLE Used Entitled CPU Capacity YAXIS ec % -b 1000 DEF:ect at RRDIDX@=@RRDFN@:cpu_ec:AVERAGE CDEF:ec at RRDIDX@=ect at RRDIDX@,10,/ LINE1:ec at RRDIDX@#@COLOR@:@RRDPARAM@ GPRINT:ec at RRDIDX@:LAST:ec \: %5.1lf%s (cur) GPRINT:ec at RRDIDX@:MAX: \: %5.1lf%s (max) GPRINT:ec at RRDIDX@:MIN: \: %5.1lf%s (min) GPRINT:ec at RRDIDX@:AVERAGE: \: %5.1lf%s (avg)\n [vmstat-pc] TITLE Used Physical CPU YAXIS pc (100 = 1 CPU) -b 1000 DEF:pc=vmstat.rrd:cpu_pc:AVERAGE LINE2:pc#00CC00 GPRINT:pc:LAST:pc \: %5.1lf%s (cur) GPRINT:pc:MAX: \: %5.1lf%s (max) GPRINT:pc:MIN: \: %5.1lf%s (min) GPRINT:pc:AVERAGE: \: %5.1lf%s (avg)\n [vmstat-pc-multi] FNPATTERN vmstat.rrd TITLE Used Physical CPU (Stacked) YAXIS pc (100 = 1 CPU) -b 1000 DEF:pc at RRDIDX@=@RRDFN@:cpu_pc:AVERAGE LINE1:pc at RRDIDX@#@COLOR@:@RRDPARAM@:STACK GPRINT:pc at RRDIDX@:LAST:pc \: %5.1lf%s (cur) GPRINT:pc at RRDIDX@:MAX: \: %5.1lf%s (max) GPRINT:pc at RRDIDX@:MIN: \: %5.1lf%s (min) GPRINT:pc at RRDIDX@:AVERAGE: \: %5.1lf%s (avg)\n Stef

1 0

4.3.24 tests not clearing once disable expiration is reached
by larry＠fni-stl.com 11 Feb '16

11 Feb '16

I just noticed in 4.3.24 (RHEL 6.7) that a few monitors are not getting enabled once the disable expiration time is reached. All the "normal" tests seem to work fine. This is an environmental sensor device that is accessed with snmptraps and snmpgets for data retrieval. That is all functioning as it should. But when any of these particular tests are disabled (e.g. DC_Door_Alarm.ups) for a set time, they are now not getting enabled when the expiration time has been reached. They just remain blue. I did verify that the expiration time stamps are correct. So I'm assuming the problem is triggered due to the way the hosts.cfg entries are set up. Previous version used was 4.3.21 and disable expiration was working with it. Example from hosts.cfg # Data center facilities sensor 10.10.10.10 Sensor9 0.0.0.0 DC_Door_Alarm # noconn main side ups 0.0.0.0 DC_VESDA # noconn fault prealarm fire 0.0.0.0 DC_Fans # noconn fans ========================================================= Larry D. Bonham ========================================================= ________________________________ CONFIDENTIALITY NOTICE: This electronic mail message is intended exclusively for recipient to which it is addressed. The contents of this message and any attachments may contain confidential and privileged information. Any unauthorized review, use, print, storage, copy, disclosure or distribution is strictly prohibited. If you have received this message in error, please advise the sender immediately by replying to the message's sender and delete all copies of this message and its attachments without disclosing the contents to anyone, or using the contents for any purpose.

2 1

disable not always working in 4.3.25
by john.thurston＠alaska.gov 10 Feb '16

10 Feb '16

I can disable tests when I use https://x.foo.com/xymon-seccgi/enadis.sh but when I try to disable tests from a host's "info" page, it quietly fails. https://x.foo.com/xymon-cgi/svcstatus.sh?HOST=y.foo.com&SERVICE=info I suspect this is related to the cgi_refererok function added to lib/cgi.c I can see there may be a chance at some logging, but I can't figure out which module on which to enable --debug. Can someone tell me where I will find the output from cgi_refererok > errprintf("Disallowed request due to missing HTTP_HOST variable\n"); or from enadis.c > dbgprintf("Not coming from self or svcstatus; abort\n"); -- 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

2 1

selinux messages during package update
by jlaidman＠rebel-it.com.au 10 Feb '16

10 Feb '16

Hi I have a couple of Xymon servers running RHELv6.7. I use the terabithia.org repo for the Xymon package, and it's been working just fine. However, recently I did a "yum update" and saw a message that was of concern to me. There were quite a few packages to update because it had been a while since I applied the last round of updates. Amidst the stream of updates was a bunch of errors related to xymon and selinux: Updating : xymon-4.3.24-3.el6.x86_64 178/481 SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.24, searching for an older version. SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.24: No such file or directory libsemanage.semanage_reload_policy: load_policy returned error code 2. SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.24, searching for an older version. SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.24: No such file or directory (repeated about 20 times) I'm inexperienced with selinux troubleshooting, and apart from knowing the concepts behind how it all works, I'm really in the dark about what goes on behind the scenes. Are these messages cause for concern? Is there something I need to do in order to complete the selinux policy update? Or something I can do next time to avoid the error messages? Cheers Jeremy

3 2