February 2017 - Xymon - Xymon mailman web

update: New 4.3.28 build collecting no data to RRD
by losburn＠thepinnaclegroup.com 22 Feb '17

22 Feb '17

Thanks to several of you who made Linux-specific recommendations. While this is an HP-UX install, I did check to ensure that rrdtools had the necessary libraries to compile and link, for example. The output of the configure command includes the following lines Checking for RRDtool ... Not RRDtool 1.0.x, checking for 1.2.x Compiling with RRDtool works OK Linking with RRDtool works OK I think the key symptom is that nothing is being written into the /opt/xymon/data/rrd directory. Not even the creation of the subdirectory for each target in hosts.cfg. I added the "--debug" option to both the rrd-data and rrd-status channels in tasks.cfg, in hopes of finding something more useful in the /var/log/rrd-status.log but all I'm getting there is still endless repeats of "Peer not up, flushing message queue" Client data is being received. I can see it by clicking the xymon server, then in the svcstatus page I can click on "Client data" and see the raw inputs. This tells me there is no trouble binding the port, and that the client is communicating with the server. What part of the code detects a new host in the hosts.cfg file and sets up the necessary directories in /opt/xymon/data/hist, /opt/xymon/data/histlogs, /opt/xymon/data/hostdata and /opt/xymon/data/rrd ??

2 1

Fun with xymonlaunch and MAXTIME
by ralphmitchell＠gmail.com 22 Feb '17

22 Feb '17

Apparently the tasks.cfg MAXTIME option is not very tolerant of spacing: MAXTIME 10m - with two spaces, is interpreted as 10 seconds MAXTIME 10m - with one space, is interpreted as 600 seconds I think the problem lies at line 276 in xymon-4.3.28/common/xymonlaunch.c: tspec = p + strspn(p, "0123456789"); switch (*tspec) { case 'm': curtask->maxruntime *= 60; break; /* Minutes */ case 'h': curtask->maxruntime *= 3600; break; /* Hours */ case 'd': curtask->maxruntime *= 86400; break; /* Days */ } The pointer p is pointing to the first character after "MAXTIME ". That's fine as long as it points to a numeric string. If it doesn't point to a string of digits, tspec doesn't end up pointing to the multiplier, so MAXTIME is handled as seconds. Adding a space to the strspn string should fix it: tspec = p + strspn(p, " 0123456789"); Similarly, at line 254, for the INTERVAL option. Ralph Mitchell

2 2

New 4.3.28 build collecting no data to RRD
by erik＠schminke.us 22 Feb '17

22 Feb '17

OK. Also, httpd is what will attempt to read those files. The user httpd runs as (probably apache) is going to need read access to the directories where you write your data. On Wed, Feb 22, 2017 at 10:00 AM Lynn Osburn <losburn at thepinnaclegroup.com> wrote: > Hi Erik – this is an HP-UX install, rather than any of the Linux family, > so SEL isn’t hurting me but will pursue the permissions angle to see if I > find anything useful and update the list if so. > > -Lynn > > > > *From:* Erik [mailto:erik at schminke.us] > *Sent:* Wednesday, February 22, 2017 7:47 AM > *To:* xymon at xymon.com; Lynn Osburn <losburn at thepinnaclegroup.com> > *Subject:* Re: [Xymon] New 4.3.28 build collecting no data to RRD > > > > I don't think those messages you're seeing are related to your problem. I > have plenty of those same log entries and mine is working fine. > > > > My first question would be permissions. I see your listing of permissions > for the directory, but not the permissions on /opt/xymon/data, /opt/xymon, > and /opt... what are those. If eXecute permissions aren't set on all > parent directories, I don't think other users can read from there. > > > > Also.. is SELinux getting in your way? SELinux used to bite me a lot when > I first stopped disabling it and actually working with it. > > > > Check SELinux Status: > > #> getenforce > > > > If it returns "Enforcing".. you'll have some additional work to do: > > > > Set SELinux to "Permissive" mode.. but do NOT leave it like this: > > #> setenforce 0 > > > > There are better tools for this in RHEL/Centos 7, but this is what I do to > get by in previous versions.. > > > > Make note of NUM_OF_LINES in the log file > > #> LINES=$(wc -l /var/log/audit/audit.log | awk '{ print $1 }') > > > > Next, run the Xymon GUI through it's paces.. Look at graphs, > enable/disable monitoring, acknowledge alerts, edit critical systems, > everything you can think of.. > > > > Then, generate a custom SELinux policy module using the log entries you > generated by running Xymon in permissive mode: > > #> sed -n "$(($LINES + 1)),$ p" /var/log/audit/audit.log | audit2allow -M > xymon > > > > Install the new policy module: > > #> semodule -i xymon.pp > > > > Restore SELinux to "Enforcing" mode: > > #> setenforce 1 >

1 0

New 4.3.28 build collecting no data to RRD
by erik＠schminke.us 22 Feb '17

22 Feb '17

I don't think those messages you're seeing are related to your problem. I have plenty of those same log entries and mine is working fine. My first question would be permissions. I see your listing of permissions for the directory, but not the permissions on /opt/xymon/data, /opt/xymon, and /opt... what are those. If eXecute permissions aren't set on all parent directories, I don't think other users can read from there. Also.. is SELinux getting in your way? SELinux used to bite me a lot when I first stopped disabling it and actually working with it. Check SELinux Status: #> getenforce If it returns "Enforcing".. you'll have some additional work to do: Set SELinux to "Permissive" mode.. but do NOT leave it like this: #> setenforce 0 There are better tools for this in RHEL/Centos 7, but this is what I do to get by in previous versions.. Make note of NUM_OF_LINES in the log file #> LINES=$(wc -l /var/log/audit/audit.log | awk '{ print $1 }') Next, run the Xymon GUI through it's paces.. Look at graphs, enable/disable monitoring, acknowledge alerts, edit critical systems, everything you can think of.. Then, generate a custom SELinux policy module using the log entries you generated by running Xymon in permissive mode: #> sed -n "$(($LINES + 1)),$ p" /var/log/audit/audit.log | audit2allow -M xymon Install the new policy module: #> semodule -i xymon.pp Restore SELinux to "Enforcing" mode: #> setenforce 1

1 0

New 4.3.28 build collecting no data to RRD
by losburn＠thepinnaclegroup.com 21 Feb '17

21 Feb '17

Env: HP-UX 11.31, xymon 4.3.28, gmake 4.2.1, gcc 4.2.3, rrdtool 1.6.0 New install, compiled cleanly, installed cleanly. xymon starts ok, status page shows the xymon server as expected. Selecting one of the attributes/tests from the server, e.g. "conn" produces the expected output, except that there is no graph. Clicking the magnifying glass icon produces the error message "Cannot access RRD directory" /var/log/xymon shows alert.log, clientdata.log, history.log, hostdata.log, rrd-status.log all being appended repeatedly with message similar to "2017-02-21 11:43:26.646604 Peer not up, flushing message queue" (where the timestamp increases with each entry of course) ps listing of running processes follows ========= $ ps -ef|grep xymon xymon 5580 5578 0 11:44:31 ? 0:00 vmstat 300 2 xymon 5091 5083 252 11:29:22 ? 18:51 xymond_channel --channel=status --log=/var/log/xymon/rrd-status.log xymond_rrd --rrddir=/opt/xymon/data/rrd xymon 5083 1 0 11:29:17 ? 0:00 /opt/xymon/server/bin/xymonlaunch --config=/opt/xymon/server/etc/tasks.cfg --env=/opt/xymon/server/etc/xymonserver.cfg --log=/v xymon 5090 5083 254 11:29:22 ? 18:45 xymond_channel --channel=client --log=/var/log/xymon/clientdata.log xymond_client xymon 5092 5083 0 11:29:22 ? 0:00 xymond_channel --channel=data --log=/var/log/xymon/rrd-data.log xymond_rrd --rrddir=/opt/xymon/data/rrd xymon 5089 5083 253 11:29:22 ? 16:56 xymond_channel --channel=page --log=/var/log/xymon/alert.log xymond_alert --checkpoint-file=/opt/xymon/server/tmp/alert.chk --c xymon 5084 5083 0 11:29:17 ? 0:00 xymond --pidfile=/var/log/xymon/xymond.pid --restart=/opt/xymon/server/tmp/xymond.chk --checkpoint-file=/opt/xymon/server/tmp/x xymon 5578 1 0 11:44:31 ? 0:00 sh -c vmstat 300 2 1>/opt/xymon/client/tmp/xymon_vmstat.usmkahpxbld004.5531 2>&1; mv /opt/xymon/client/tmp/xymon_vmstat.usmkahp xymon 5093 5083 255 11:29:22 ? 14:00 xymond_channel --channel=clichg --log=/var/log/xymon/hostdata.log xymond_hostdata xymon 5088 5083 254 11:29:22 ? 18:55 xymond_channel --channel=stachg --log=/var/log/xymon/history.log xymond_history --pidfile=/var/log/xymon/xymond_history.pid listing of /opt/xymon/data directory. Each of the listed subdirectories is empty. ========= $ ls -l /opt/xymon/data drwxr-xr-x 2 xymon xymon 96 Feb 17 11:32 acks drwxr-xr-x 2 xymon xymon 96 Feb 17 11:32 data drwxr-xr-x 2 xymon xymon 96 Feb 17 11:32 disabled drwxr-xr-x 2 xymon xymon 96 Feb 17 11:32 hist drwxr-xr-x 2 xymon xymon 96 Feb 17 11:32 histlogs drwxr-xr-x 2 xymon xymon 96 Feb 17 11:32 hostdata drwxr-xr-x 2 xymon xymon 96 Feb 17 11:32 logs drwxr-xr-x 2 xymon xymon 96 Feb 17 11:32 rrd

1 1

Debian hobbit-plugins misc test
by Johan.Sjoberg＠dgc.se 21 Feb '17

21 Feb '17

Hi, This is regarding the hobbit-plugins (xymon-plugins) Debian package. I've been setting up the "misc" test to monitor for read-only filesystems. It's working flawlessly on Debian Jessie, but on Wheezy it doesn't report to the Xymon server. There are no errors, and the output is exactly the same if I execute it manually on both dists. Has anyone used this script and got it to work on Wheezy? Regards, Johan

1 0

protocols.cfg - configuring yellow alarm - and combo.cfg -
by gonzalorodrigo.alvarez＠telefonica.com 20 Feb '17

20 Feb '17

Hola Sebastian, me pasaba lo mismo que a vos: Para lograr que el yellow sea interpretado como una alarma debes especificarlo en el comando de combosatus: --error-colors=COLOR[,COLOR] Specify which colors trigger an error status. By default only a "red" status counts as an error color - all other colors, including yellow, will count as "green" when evaluating the combined status. COLOR is "red", "yellow", "blue", "purple" or "clear". A simple test - e.g. "Web1.http" - results in the value "1" if the "http" test for server "Web1" is green, yellow or clear. It yields the value "0" if it is red, purple or blue. Si lo corres a mano: ~/server/bin/xymoncmd ~/server/bin/combostatus --error-colors=red,yellow,purple,clear Y para que quede permanente en el task.cfg: [combostatus] ENVFILE /home/xymon/server/etc/xymonserver.cfg NEEDS xymond CMD $XYMONHOME/bin/combostatus --error-colors=red,yellow,purple,clear LOGFILE $XYMONSERVERLOGS/combostatus.log INTERVAL 5m Por default los únicos que son considerados alarma son red, purple y blue. Saludos. [Firma TGT_GonzaloAlvarez_PNG]

1 0

don;t show "msgs" column
by EDSchminke＠Hormel.com 20 Feb '17

20 Feb '17

Have you tried using the tag "nomsgs"? You have to do a "drop hostname msgs" as a final step to get rid of the msgs column if it previously recorded data.Erik Schminke | Associate Systems ProgrammerHormel Foods Corporation | ITS Tech Servicesedschminke at hormel.com | www.hormelfoods.com(V) 507-434-6817 | (C) 507-473-5083Please excuse my brevity.. Sent from IBM Verse on Android

1 0

xymonnet timeouts?
by rlhamil2＠gmail.com 18 Feb '17

18 Feb '17

I noticed I was getting these when a host (marked dialup) was down; turns out it's because there was an RPC test, and rpcinfo has no option to choose a reasonable timeout; trying to run it against a host that's down or unreachable takes nearly ten minutes to time out! What I don't understand, is why, given the conn test was enabled and not green or yellow, it was trying to do other network tests on that host. Here's the host line: 192.168.0.56 lapple-sierra # dialup CLIENT:lapple-sierra.pri noflap=location ssh ntp rpc=mountd,nlockmgr,nfs,rpcbind,rquotad,status NOCOLUMNS:files multihomed NOPROPPURPLE:+location NOPROPYELLOW:+cpu,+location (location is an client extension script, not relevant to the problem at hand)

2 3

don;t show "msgs" column
by didds3＠yahoo.co.uk 17 Feb '17

17 Feb '17

xymon 4.2.3 serverclient is windows How do i suppress the msgs column/alert/status for a single host? Ive tried A.B.C.D HOSTNAME # MAINTNC:win NOCOLUMNS:msgs but that doesn't seem to work? ian

1 0