August 2008 - Xymon - Xymon mailman web

Graph multiple unknown named RRD values in one graph
by michael.hobbs＠infusionsoft.com 18 Aug '08

18 Aug '08

Hi all, I have spent the last day reading documentation and searching the "tubes" for an answer without any luck. Here is my scenario. I have multiple hosts reporting JVM free memory numbers in the following format. Each line is a different JVM name with its current free memory number. mn17camp.web: 846 mn18camp.web: 669 mn19camp.web: 337 mn30camp.web: 938 mn31camp.web: 750 mn32camp.web: 812 mn33camp.web: 723 mn5camp.web: 785 mn63camp.web: 179 mn65camp.web: 518 mn6camp.web: 597 mp3camp.web: 673 tbo1camp.web: 461 tbo2camp.web: 1030 tbo3camp.web: 490 I have hobbit saving them to an rrd file using the data channel in the ncv format. Is there a way to graph these without explicitly defining each jvm name? i.e. Can I iterate through whatever names are in the file? Or can I have hobbit create different rrd files based on content of the ncv file? I'm guessing it could be similar to how the disk test does it. Thanks, -- Michael S. Hobbs sr. systems administrator Phone: 480.289.6832 | Fax: 480.807.0665 michael.hobbs at infusionsoft.com | www.infusionsoft.com [cid:3301557926_12416683]

3 3

issue with rrd files being generated
by forums＠triadbiz.rr.com 18 Aug '08

18 Aug '08

I am seeing this in my rrd-status.log 2008-08-18 10:33:02 RRD error updating /opt/hobbit/data/rrd/gsoncit-wns-2950-3/if_load.Fa0_24.rrd from 165.237.105.30: expected 1 data source readings (got 2) from 1219069982:93493833310:67142126420 And I am not getting any graphs created for the if_load column at all. Anyone have any ideas? -Josh

1 0

need help in monitoring edmz client
by santoshbabu_perumal＠platts.com 18 Aug '08

18 Aug '08

Hi, We have some servers in edmz.port 1984 is blocked by firewall.so client cannot able to communicate with hobbit server on port 1984.when I search around I read about msgcache,hobbitfetch utilities but I am not familiar with that. can anyone please give me the configuration steps that I need to make on both server side and edmz client site. Thanks in advance Thanks santhosh -------------------------------------------------------- The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. The McGraw-Hill Companies, Inc. reserves the right, subject to applicable local law, to monitor and review the content of any electronic message or information sent to or from McGraw-Hill employee e-mail addresses without informing the sender or recipient of the message. --------------------------------------------------------

5 15

Migration to SourceForge tracker?
by spa＠syntec.co.uk 18 Aug '08

18 Aug '08

Seeing as we are now using subversion (yay!), and moving to a more de-centralised development model, maybe it's time (or after the project namechange anyway) to start using the SourceForge bug and feature-request tracker? (Or another tracker.) This would enable all the developers and users to track the outstanding bugs instead of just Henrik. I've noticed in the past that Henrik is very quick at fixing the critical bugs and core dumps (thanks), but other less critical ones (in trunk) seem to be outstanding for many months. Having a public bug tracker would: (a) enable users to contribute to bugs via confirmation of the bug, narrowing down of the cause(s) / scenarios, testing of patches, etc. (b) ensure bugs (and feature requests) don't get forgotten about; (c) more easily allow other developers to create patches; (d) facilitate the release process by being able to see what might need fixing / doing / adding before the next release; (I believe 4.3.0 is about a year overdue, but unfortunately trunk still isn't stable ) (e) increase the acceptance of Hobbit by users / companies, as it would increase the signs of life of the project (if used properly), the signs of support (in terms of bug fixing), etc. (f) encourage people posting bugs that someone who might fix their bug might (eventually) see their bug post! ;) In terms of the stability of hobbit, if new features are going to be added, isn't it time we branched 4.3 off from trunk? (So we don't add new bugs to the 4.3 branch and further delay the release. Or has this already been done?) Personally, I would have liked this to have happened this time last year after Henrik announced 4.3.0 was nearly ready, instead of adding new features since then. What would have happened, I suppose, is the current trunk would have developped into 4.4.0. (If someone particularly wanted a specific new feature from trunk in 4.3, they could backport the patch. This would be facilitated if patches were uploaded to the bug tracker for these new features when, or preferably before (thereby increasing the stability of trunk by allowing testing of the patch first), checking in to trunk.) I expect nearly everyone knows an open-source project that works like this, but Asterisk is one that works well in this way, with hundreds of people submitting patches to their customised Mantis bug tracker. Kind regards, SebA

1 0

clear "msgs" column under CentOS 5.x and later versions of Fedora despite hobbitclient.sh hack
by tleavitt＠unameits.com 18 Aug '08

18 Aug '08

All, I just spent way too much time too late at night to be doing this, trying to figure out why my CentOS 5.1 VM had a "clear" under the "msgs" column, despite having implemented the standard modification to hobbitclient.sh and put the proper entry in /etc/sudoers. It was driving me nuts, because it would work when I ran hobbitclient.sh as the user hobbit, but not when it was executing as a service. It would just sliently fail to execute without giving any error message... eventually it occurred to me that I've been driven nuts this way by another paranoid security mechanism that "silently" changes the way everything works, SELinux, and decided to go grep for sudo in /var/log... where I saw hordes of messages like this: secure.2:Aug 3 03:46:43 dust-testlink-vm sudo: hobbit : sorry, you must have a tty to run sudo ; TTY=unknown ; PWD=/local/home/hobbit ; USER=root ; COMMAND=/local/home/hobbit/client/bin/logfetch /local/home/hobbit/client/tmp/logfetch.dust-testlink-vm.cfg /local/home/hobbit/client/tmp/logfetch.dust-testlink-vm.status Doh, I should've looked there sooner. Bleah. It turns out that in these versions of RHEL and Fedora, they've locked down sudo so that, by default, you can't run it unless you're attached to a real tty... you have to comment out this line in /etc/sudoers: "Defaults requiretty". Any comments on the security implications of turning this off? Is there an alternative solution? I figured I'd share this so the next person wouldn't go crazy the same way. Regards, Thomas Leavitt

2 1

bbd status on hobbit server turned purple.
by santoshbabu_perumal＠platts.com 15 Aug '08

15 Aug '08

HI, Bbd(column) status for hobbit server turned purple on the webpage. can you please let me know what would caused this problem and how can I resolve this issue. Thanks in advance. Thanks Santhosh.p -------------------------------------------------------- The information contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. The McGraw-Hill Companies, Inc. reserves the right, subject to applicable local law, to monitor and review the content of any electronic message or information sent to or from McGraw-Hill employee e-mail addresses without informing the sender or recipient of the message. --------------------------------------------------------

2 1

[hobbit] multiple hobbit servers with different bb-hosts files: BBDISPLAYS troubles
by stef.coene＠docum.org 15 Aug '08

15 Aug '08

On Thursday 14 August 2008, Sebastian wrote: > Well your situation / original message is not very clear then. What is the > big picture you are trying to achieve here? Have you checked your > http://xxx/hobbit-cgi/bb-hostsvc.sh?HOST=xxx&SERVICE=hobbitd > and > http://yyy/hobbit-cgi/bb-hostsvc.sh?HOST=yyy&SERVICE=hobbitd > pages? Are there are errors, warnings, ghosts or multi-source statuses? > Maybe you can post them? Nop, no error. And the problem is solved. It was just a remark that if you have multiple hobbit servers, the first hobbit server in BBDISPLAYS is checked to make sure it has an entry for the client. If it has no entry for the client, no information is send to the other BBDISPLAYS servers. Stef

2 1

Filesystem monitoring and group alerts
by Mike.Wood＠kci1.com 15 Aug '08

15 Aug '08

Hi All, Is there anyway to do the following for a specific filesystem on a specific host? At 80% full (yellow), page and E-mail group A, and E-mail group B. At 90% full (red), page and E-mail group A, and page group B. I don't see that the GROUP= parameter in hobbit_clients.cfg is sophisticated enough. I've searched the archives. It appears the question was asked in 2006, but never answered. Thanks! Mike Wood UNIX System Administrator Kinetic Concepts Inc. 5751 NW Parkway San Antonio, TX, 78249 E-mail: mike.wood at kci1.com Office: (210) 255-6382 Mobile: (210) 825-5134 ***************************************************************************** "CONFIDENTIALITY NOTICE: This transmission (including any accompanying attachments) is confidential, is intended only for the individual or entity named above, and is likely to contain privileged, proprietary and confidential information that is exempt from disclosure requests under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, use of or reliance upon any of the information contained in this transmission is strictly prohibited. Any inadvertent or unauthorized disclosure shall not compromise or waive the confidentiality of this transmission or any applicable attorney-client privilege. If you have received this transmission in error, please immediately notify us at postmaster at kci1.com." Kinetic Concepts, Inc. ******************************************************************************

1 0

AIX Client
by skjoldar＠gmail.com 15 Aug '08

15 Aug '08

Hi everyone. I've looked through the archives, and i see the AIX issue has come up quite a lot. I need to run the client on AIX boxes, but i can't get it compiled, nor do i know if I'm missing something. The runclient.sh is all wrong on the razorsedge compiled version, plus it needs chkconfig for aix which i have no idea where to get. Installed it with rpm 0Uvh --nodeps, and it installed, although i think it might have done only half way. It does run, but it doesn't open the 1984 port, and the config/log file variables are wrong, or the installation location is wrong. I can't get this version working Compiling the source of the client, I get the following (bottom of email) I'm stuck, I have no idea what is wrong here... Can anyone perhaps help me? I'm running AIX 5.3 make-3.81-1.aix5.2 pcre-3.7-3.aix5.1 pcre-devel-3.7-3.aix5.1 gcc-4.2.0-3.aix5.3 bash-3.00# gmake CC="gcc" CFLAGS="-g -O3 -qstrict -qcpluscmt -D_REENTRANT -DAIX -I. -I`pwd`/include -DCLIENTONLY=1 -DLOCALCLIENT=1 -I/usr/include" LDFLAGS="" OSDEF="-DAIX" RPATHOPT="" PCREINCDIR="-I/usr/include" SSLFLAGS="" SSLINCDIR="" SSLLIBS="" NETLIBS="" BBTOPDIR="/home/hobbit" BBLOGDIR="" BBHOSTNAME="" BBHOSTIP="172.24.44.34" BBHOSTOS="" LOCALCLIENT="yes" gmake -C lib client gmake[1]: Entering directory `/tmp/hobbit-4.2.0/lib' gcc -g -O3 -qstrict -qcpluscmt -D_REENTRANT -DAIX -I. -I/tmp/hobbit-4.2.0/include -DCLIENTONLY=1 -DLOCALCLIENT=1 -I/usr/include -I. -I../include -c -o cgiurls.o cgiurls.c gcc: unrecognized option '-qstrict' gcc: unrecognized option '-qcpluscmt' In file included from /tmp/hobbit-4.2.0/include/../lib/ipaccess.h:15, from /tmp/hobbit-4.2.0/include/libbbgen.h:58, from cgiurls.c:24: /usr/include/sys/socket.h:87: error: conflicting types for 'socklen_t' /tmp/hobbit-4.2.0/include/../lib/osdefs.h:21: error: previous declaration of 'socklen_t' was here gmake[1]: *** [cgiurls.o] Error 1 gmake[1]: Leaving directory `/tmp/hobbit-4.2.0/lib' gmake: *** [lib-client] Error 2 bash-3.00#

3 2

[hobbit] AIX Client - SOLVED
by skjoldar＠gmail.com 15 Aug '08

15 Aug '08

Thanks so much, that did the trick.. 2008/8/15 Brian O'Mahony <brian.omahony at curamsoftware.com>: > I came across this and found a solution on the web somewhere. > > However don't have the link. Have the solution though: > > /usr/include/sys/socket.h:87: error: conflicting types for 'socklen_t' > Solution is to change the osdefs.h file in lib. > Change the two lines to: > typedef int hobbit_socklen_t; > extern int hobbit_snprintf > (snprintf may not be needed but i saw it happen once or twice) > > > > -----Original Message----- > From: Stefan [mailto:skjoldar at gmail.com] > Sent: 15 August 2008 14:28 > To: hobbit at hswn.dk > Subject: [hobbit] AIX Client > > Hi everyone. > > I've looked through the archives, and i see the AIX issue has come up > quite a lot. > I need to run the client on AIX boxes, but i can't get it compiled, > nor do i know if I'm missing something. > > The runclient.sh is all wrong on the razorsedge compiled version, plus > it needs chkconfig for aix which i have no idea where to get. > Installed it with rpm 0Uvh --nodeps, and it installed, although i > think it might have done only half way. > It does run, but it doesn't open the 1984 port, and the config/log > file variables are wrong, or the installation location is wrong. I > can't get this version working > > Compiling the source of the client, I get the following (bottom of email) > > I'm stuck, I have no idea what is wrong here... > Can anyone perhaps help me? > > I'm running AIX 5.3 > make-3.81-1.aix5.2 > pcre-3.7-3.aix5.1 > pcre-devel-3.7-3.aix5.1 > gcc-4.2.0-3.aix5.3 > > > bash-3.00# gmake > CC="gcc" CFLAGS="-g -O3 -qstrict -qcpluscmt -D_REENTRANT -DAIX -I. > -I`pwd`/include -DCLIENTONLY=1 -DLOCALCLIENT=1 -I/usr/include" > LDFLAGS="" OSDEF="-DAIX" RPATHOPT="" PCREINCDIR="-I/usr/include" > SSLFLAGS="" SSLINCDIR="" SSLLIBS="" NETLIBS="" BBTOPDIR="/home/hobbit" > BBLOGDIR="" BBHOSTNAME="" BBHOSTIP="172.24.44.34" BBHOSTOS="" > LOCALCLIENT="yes" gmake -C lib client > gmake[1]: Entering directory `/tmp/hobbit-4.2.0/lib' > gcc -g -O3 -qstrict -qcpluscmt -D_REENTRANT -DAIX -I. > -I/tmp/hobbit-4.2.0/include -DCLIENTONLY=1 -DLOCALCLIENT=1 > -I/usr/include -I. -I../include -c -o cgiurls.o cgiurls.c > gcc: unrecognized option '-qstrict' > gcc: unrecognized option '-qcpluscmt' > In file included from /tmp/hobbit-4.2.0/include/../lib/ipaccess.h:15, > from /tmp/hobbit-4.2.0/include/libbbgen.h:58, > from cgiurls.c:24: > /usr/include/sys/socket.h:87: error: conflicting types for 'socklen_t' > /tmp/hobbit-4.2.0/include/../lib/osdefs.h:21: error: previous > declaration of 'socklen_t' was here > gmake[1]: *** [cgiurls.o] Error 1 > gmake[1]: Leaving directory `/tmp/hobbit-4.2.0/lib' > gmake: *** [lib-client] Error 2 > bash-3.00# > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > > > > The information in this email is confidential and may be legally privileged. > It is intended solely for the addressee. Access to this email by anyone else > is unauthorized. If you are not the intended recipient, any disclosure, > copying, distribution or any action taken or omitted to be taken in reliance > on it, is prohibited and may be unlawful. If you are not the intended > addressee please contact the sender and dispose of this e-mail. Thank you. > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > >

1 0