June 2013 - Xymon - Xymon mailman web

cannot update RRD using "data $MACHINE.trends"
by p3yeung＠gmail.com 06 Jun '13

06 Jun '13

I am using xymon 4.3.11. I sent data to multiple RRD files in one data message from the xymon client, but these data are not updated in the RRD files in the xymon server. Any suggestion how to update multiple RRD files in one data message? In the client side, I sent 2 values to each of the 2 RRD files. > cat /tmp/test.data [Test1.rrd] DS:value1:GAUGE:3600:0:U 101 DS:value2:GAUGE:3600:0:U 102 [Test2.rrd] DS:count1:GAUGE:3600:0:U 201 DS:count2:GAUGE:3600:0:U 202 > xymoncmd xymon $XMON_IP "data ct6-metrics.localdomain.trends `cat /tmp/test.data`" In the server side, /var/log/xymon/rrd-data.log shows the RRD files are created. But all the values in both RRD files are 0. Subsequent data message sent using different data does not change anything in the RRD files. 7176 2013-06-05 17:17:12 Creating rrd /var/lib/xymon/rrd/ct6-metrics.localdomain/Test1.rrd 7176 2013-06-05 17:17:12 RRD create param 00: 'rrdcreate' 7176 2013-06-05 17:17:12 RRD create param 01: '/var/lib/xymon/rrd/ct6-metrics.localdomain/Test1.rrd' 7176 2013-06-05 17:17:12 RRD create param 02: '-s' 7176 2013-06-05 17:17:12 RRD create param 03: '300' 7176 2013-06-05 17:17:12 RRD create param 04: 'DS:value1:GAUGE:3600:0:U' 7176 2013-06-05 17:17:12 RRD create param 05: 'DS:value2:GAUGE:3600:0:U' 7176 2013-06-05 17:17:12 RRD create param 06: 'RRA:AVERAGE:0.5:1:576' 7176 2013-06-05 17:17:12 RRD create param 07: 'RRA:AVERAGE:0.5:6:576' 7176 2013-06-05 17:17:12 RRD create param 08: 'RRA:AVERAGE:0.5:24:576' 7176 2013-06-05 17:17:12 RRD create param 09: 'RRA:AVERAGE:0.5:288:576' 7176 2013-06-05 17:17:12 Creating rrd /var/lib/xymon/rrd/ct6-metrics.localdomain/Test2.rrd 7176 2013-06-05 17:17:12 RRD create param 00: 'rrdcreate' 7176 2013-06-05 17:17:12 RRD create param 01: '/var/lib/xymon/rrd/ct6-metrics.localdomain/Test2.rrd' 7176 2013-06-05 17:17:12 RRD create param 02: '-s' 7176 2013-06-05 17:17:12 RRD create param 03: '300' 7176 2013-06-05 17:17:12 RRD create param 04: 'DS:count1:GAUGE:3600:0:U' 7176 2013-06-05 17:17:12 RRD create param 05: 'DS:count2:GAUGE:3600:0:U' 7176 2013-06-05 17:17:12 RRD create param 06: 'RRA:AVERAGE:0.5:1:576' 7176 2013-06-05 17:17:12 RRD create param 07: 'RRA:AVERAGE:0.5:6:576' 7176 2013-06-05 17:17:12 RRD create param 08: 'RRA:AVERAGE:0.5:24:576' 7176 2013-06-05 17:17:12 RRD create param 09: 'RRA:AVERAGE:0.5:288:576' 7176 2013-06-05 17:17:12 Want msg 219, startpos 233160, fillpos 233160, endpos -1, usedbytes=0, bufleft=295223 P Yeung

1 0

Monitoring HP ILO via Ssh
by betsy.schwartz＠gmail.com 05 Jun '13

05 Jun '13

I'm looking at monitoring hp ilo via ssh, as our existing script only runs on the linux boxes. Looking at this, it isn't hard, so I'm thinking someone *MUST* have done this already In the spirit of never writing from scratch what you can steal ^H^H^H^H find an existing collaborative project on, does anyone have anything like this already? thanks Betsy

2 2

flapping DNS error
by dboldt＠usgs.gov 05 Jun '13

05 Jun '13

I have recently downloaded xymon version 4.3.11 to experiment with as a replacement for the last publicly available version of Big Brother. It is running on Solaris 10 x86. The http test on the Display server, for itself, has a flapping status for http with DNS errors. I've experimented with the following, restarting the xymon server application each time server/etc/tasks.cfg CMD xymonnet --report --ping --checkresponse --concurrency=64 CMD xymonnet --report --ping --checkresponse --no-ares server/etc/tasks.cfg/hosts.cfg 130.11.50.48 owipm1.er.usgs.gov # bbd http://owipm1.er.usgs.gov =130.11.50.48 I am only monitoring the server itself and one remote host. xymond.log shows 2013-06-05 00:49:40 Flapping detected for owipm1.er.usgs.gov:cron - 5 changes in 1507 seconds xymonlaunch.log shows many of these 2013-06-05 10:35:04 Task xymongen terminated by signal 6 2013-06-05 10:36:04 Task xymongen terminated by signal 6 2013-06-05 10:37:06 Task xymongen terminated by signal 6 I've run a script which uses dig on the FQDN for the server once every second, and have never seen even a significant delay, let alone a failure. -- -- David Boldt <dboldt at usgs.gov> "Your manuscript is both good and original, but the part that is good is not original and the part that is original is not good." --Samuel Johnson [1709 - 1784], (attributed)

1 0

Has anyone played around with a Nagios wrapper for xymon?
by betsy.schwartz＠gmail.com 05 Jun '13

05 Jun '13

Just to follow up - I took another look at xynagios and it actually does what we want on the server side. I took xynagios and Hobbit.pm file from the Debian distro and had to compile nagios, installed Nagios::Plugins from cpan, and I had to grab nagios-plugins-perl , nagios-plugins-1.4.16.tar , and build it to get the missing utils.pm All that, and the nagios plugins for HP monitoring aren't really that great. check_ilo2_health.pl only checks temperature. check_snmp_HP_Bladesystem.pl was useful but super terse. I am reminded that one reason we like xymon so much is that xymon lets you send long informative text !

1 0

way to tell what version of the client is running
by jlaidman＠rebel-it.com.au 05 Jun '13

05 Jun '13

On 31 May 2013 03:48, Root, Paul T <Paul.Root at centurylink.com> wrote: > Is there a way from the server, to find out what version the client is > running? You could add this into client-local.cfg on the server: file:`( echo "client/xymonversion $MACHINE.$OSTYPE"; echo "[clientversion]"; $XYMON --version ) | $XYMON $XYMSRV @ >/dev/null` Assign to each device you want to know about. This causes each client to run "xymon --version" and send the result back as a supplementary "client" message. Then on the server you can retrieve it with the "clientlog" type message that Japheth showed. If you upgrade clients, they will automatically report new version strings. J

3 2

what does "O" mean in the [bind] section in graphs.cfg
by jlaidman＠rebel-it.com.au 05 Jun '13

05 Jun '13

Guys The graphs.cfg file has a [bind] section, obviously for graphing BIND DNS query counts for different resource record types (A, SOA, MX, etc). The DS names match the resource record types. One of those types RR types is called "O". As far as I know there's no such record type. So I'm guessing this means "Other", or all other record types. Can anyone confirm that "O" means "Other"? I haven't found anything in doco about this, but it's probably there for compatibility with Hobbit or BigBrother graphs. I could just make a new [bind] section, but I'd like to maintain backwards compatibility. Cheers Jeremy

2 2

IGNORE ignored
by Phil.Crooker＠orix.com.au 04 Jun '13

04 Jun '13

I've found the quotes to be problematic. Try escaping each space, or truncating the string: LOG=/var/adm/messages IGNORE=terminal-device\ not\ specifiedby\ login or LOG=/var/adm/messages IGNORE=terminal-device.*login These are a pain.... >>> On 1/06/2013 at 2:04 AM, in message <CAA9hN5MoP-+=BOS7wnjrD06bk7cK7W5fFmbHzG3d_etk_hD4iQ at mail.gmail.com>, Nick Pettefar <Nick at Pettefar.com> wrote: In the server/etc/analysis.cfg file I have the following: HOST=ourserver1 LOG=/var/adm/messages IGNORE="%terminal-device not specifiedby login%" # LOG=/var/adm/messages IGNORE="terminal-device not specifiedby login" I want to ignore messages containing the string "terminal-device not specifiedby login" May 31 17:22:53 ourserver1 bpjava-msvc[7112]: [ID 427199 user.error] pam_dial_auth: terminal-device not specifiedby login, returning Error in underlying service module. Unfortunately it doesn't work. From: system user for Xymon Subject: Xymon [214797] ourserver1-ge1:msgs CRITICAL (RED) red Wed May 29 12:52:59 IST 2013 - System logs NOT ok &red Critical entries in <a href="/xymon-cgi/svcstatus.sh? CLIENT=ourserver1&SECTION=msgs:/var/adm/messages">/var/adm/messages</a> &red May 29 12:51:56 ourserver1 bpjava-msvc[12541]: [ID 427199 user.error] pam_dial_auth: terminal-device not specifiedby login, returning Error in underlying service module. &red May 29 12:51:56 ourserver1 bpjava-msvc[12541]: [ID 427199 user.error] pam_dial_auth: terminal-device not specifiedby login, returning Error in underlying service module. <pre> </pre> <pre> </pre> <pre> </pre> What am I doing wrong? Regards, Nick Pettefar

2 1

Xymon application is not working
by jlaidman＠rebel-it.com.au 03 Jun '13

03 Jun '13

On 1 June 2013 05:04, Siddesha Dodderi Hanumantharayappa < Siddesha.Hanumantharayappa at ness.com> wrote: > 2013-05-31 11:59:01 Loading tasklist configuration from > /home/xymon/server/etc/tasks.cfg > > 2013-05-31 11:59:01 Cannot open directory /home/xymon/server/etc/tasks.d > This might be important. Make sure that the user ID under which xymond process is running has permission to access the tasks.d directory. For example, login as or switch to the xymon user and run 'grep -c ^ /home/xymon/server/etc/tasks.d/*'. Although I don't think it would cause the problems you're seeing. It seems like xymond is not running, and is causing the statusboard request to time-out. Perhaps you can check that the IP address of 161.230.144.78 is your Xymon server. The fping error relates to the fact that accessing a socket to send a low-level packet type (ICMP=ping) requires root privileges, and the xymon user is not permitted to do so. It's the same for regular ping and regular users. But most UNIX systems work around this by giving the ping binary a special permission flag called "set-UID" or "set user-ID". Sometimes "set-GID" (set-group-ID) is set instead or as well as. This flag tells the kernel to switch to the user and/or group that owns the file being executed, and as it is owned by the root user, it switches to root's user ID for the life of the process, so that it can do low-level packet stuff. So if you run "ls -l /bin/ping" you should find that the set-UID bit is set, indicated by an "s" in place of the "x" in the "user" permissions. Here's mine: -rwsr-xr-x 1 root root 38112 2011-02-18 06:48 /bin/ping* So this "s" means it's executable AND set-UID for the "root" user. If you do the same thing for fping, you'll find it has an "x" instead of an "s", meaning it's executable, but without any special switch-user magic capability. You can add the setuid flag with this command (run as root or under sudo): chmod u+s /usr/local/sbin/fping Before you do this, you should make sure that the fping binary is not writeable by non-root users. If it is, then a non-root user can replace the contents of the file with their own, and they get to run it as root and then take over your machine. Perhaps you could do something like (as root/sudo): "chmod ugo-w /usr/local/sbin/fping". This will ensure that nobody has "write" permissions on the file. Then check with "ls -l" and then, set the setuid flag. If you're not sure about these permissions, check with your local security-aware sysadmin. J

3 12

way to tell what version of the client is running
by sean.clark＠twcable.com 03 Jun '13

03 Jun '13

On 5/30/13 6:20 PM, "cleaver at terabithia.org" <cleaver at terabithia.org> wrote: >> Hi, >> Is there a way from the server, to find out what version >> the client is running? >> >> I looked in the xymon command man page, but didn't find >> anything. >> >> Paul. > > >See http://www.xymon.com/xymon/help/manpages/man1/clientupdate.1.html > > >By default, no ... not unless you've created a file at >$XYMONHOME/etc/clientversion.cfg, which gets included in the >[clientversion] section by xymonclient.sh. > >The Terabithia RPMs report their RPM version there automatically. >(Presumably if you're installing by RPM you probably wouldn't be running >the clientupdate binary to deploy tarballs.) You could have the base rpm on a kickstart server, so that all machines get kickstarted with a standard image And then later on in the process, the update client based on their machine type once deployed, that is how ours runs >Either way, you'd query like so: > >/]$ xymon localhost "clientlog rhel6-x86-64.build section=clientversion" >[clientversion] >Xymon version 4.3.11-8.1.el6 > >/]$ > > > > >HTH, > >-jc > > >_______________________________________________ >Xymon mailing list >Xymon at xymon.com >http://lists.xymon.com/mailman/listinfo/xymon This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

1 0