October 2005 - Xymon - Xymon mailman web

[hobbit] Hobbit and SQUID
by rdeal＠tigr.ORG 04 Oct '05

04 Oct '05

If you want to check that the service is actually functional use something like: 0.0.0.0 firewall.uscourts.gov # 0.0.0.0 router.uscourts.gov # route:firewall.uscourts.gov 0.0.0.0 router.ISP.gov # route:firewall.uscourts.gov,router.uscourts.gov 0.0.0.0 squid.uscourts.gov # http://squid.uscourts.gov:8080/http://www.google.com/ route:firewall.uscourts.gov depends(http:router.ISP.gov/conn, router.uscourts.gov/conn) plug in your own IP addresses and host names of course but you get the idea. -----Original Message----- From: patrick_healy at nywd.uscourts.gov [mailto:patrick_healy at nywd.uscourts.gov] Sent: Tuesday, October 04, 2005 9:29 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Hobbit and SQUID Since the system is a Fedora machine, I'd be looking for the output of: # service squid status Which should return something like: squid (pid 13626 13624) is running... If nothing came back, or if the word 'running' wasn't present then it should go red... Thanks Adam! Pat ==================================================== Patrick Healy U.S. District Court, NYWD patrick_healy at nywd.uscourts.gov 304 U.S. Courthouse Voice: 716-332-1770 68 Court Street FAX: 716-551-4850 Buffalo, NY 14202 Adam Scheblein <adam.scheblein at marquette.edu> 10/03/2005 05:41 PM Please respond to hobbit at hswn.dk To hobbit at hswn.dk cc Subject Re: [hobbit] Hobbit and SQUID You could configure the proc check to make sure that the specific processes that you are looking for exist. What are you looking for exactly? it may be a quick write since i just got done writing up a script to check who is on the system. Adam patrick_healy at nywd.uscourts.gov wrote: Hi, Has anyone developed a good 'Services test' for checking the squid process? I can plug in the port number and make sure it's being answered, but does anyone have something better? Thanks! Pat ==================================================== Patrick Healy U.S. District Court, NYWD patrick_healy at nywd.uscourts.gov <mailto:patrick_healy at nywd.uscourts.gov> 304 U.S. Courthouse Voice: 716-332-1770 68 Court Street FAX: 716-551-4850 Buffalo, NY 14202

1 0

[hobbit] Channel processing problem with 4.11
by Mark.Deiss＠acs-inc.com 04 Oct '05

04 Oct '05

Thanks, was not aware of the beta release site. -----Original Message----- From: Dan Vande More [mailto:bigdan at gmail.com] Sent: Monday, October 03, 2005 8:44 AM To: hobbit at hswn.dk Subject: Re: [hobbit] Channel processing problem with 4.11 Find the latest snapshot here: http://hswn.dk/beta/hobbit-snapshot.tar.gz (In the future, you can browse the http://hswn.dk/beta/ directory) Then I usually just copy the Makefile over from the directory I compiled the last one out of. Then what I do is edit <snapshot dir>/build/Makefile.rules and take "demo-build" off the end of line 18. It looks like this: BUILDTARGETS = lib-build common-build bbdisplay-build bbnet-build bbproxy-build docs-build build-build hobbitd-build client demo-build After that, I'd try applying the patches he sent you. Good luck Dan On 10/3/05, Deiss, Mark <Mark.Deiss at acs-inc.com> wrote: > > > Confused even more now. Back to Sourceforge, from what I can tell, am using > the current (?) release of hobbitserver 4.1.1. Not seeing anything in any of > the Soureforge headings about a more current snapshot - under CVS or patch > groupings. > > For your supplied patch, patch failed to apply - inspecting the patch, there > are the following reference to old and patched lines in the > hobbitd_client.c: > > - add_disk_count(fsname); > + if (fsname) add_disk_count(fsname); > > Did a global search in the entire hobbit code tree and there is no > add_disk_count function defined. Noticed the old code of: > > if (fsname && (usage != -1)) { > > Where in the 4.1.1 code base it is: > > if (usage != -1)) { > > Figured a check for valid fsname is what you are after before proceeding > with the add_disk_count call above so made this change in the branch to work > on disk threshold checking. Recompiled, retested, same error. Oh well. > > For the second patch in client_config.c, the line counts do not add up in > the patch - closest code appears to be in the add_process_count function. > Would not expect add_process_count to be part of processing df messages. > Guess the add_disk_count is defined in this module in another version. > > > > RCS string for hobbitd_client.c and client_config.c module in the 4.1.1 > release are: > static char rcsid[] = "$Id: hobbitd_client.c,v 1.21 2005/07/25 13:57:56 > henrik Exp $"; > static char rcsid[] = "$Id: client_config.c,v 1.5 2005/07/24 07:50:13 henrik > Exp $"; > > In the patch file, noticed string IDs for the patch targets of: > --- hobbitd/hobbitd_client.c 2005/09/28 21:21:56 1.34 > +++ hobbitd/hobbitd_client.c 2005/09/30 15:53:55 > --- hobbitd/client_config.c 2005/09/21 11:37:05 1.9 > +++ hobbitd/client_config.c 2005/09/30 15:54:57 > > So looks like am working with an older release set. Using the CVS web > browser agent on Sourceforge, not turning up any more recent code trees for > other then the hobbit client package. > > > -----Original Message----- > From: henrik at hswn.dk [mailto:henrik at hswn.dk] > Sent: Friday, September 30, 2005 12:02 PM > To: hobbit at hswn.dk > Subject: Re: [hobbit] Channel processing problem with 4.11 > > > > On Fri, Sep 30, 2005 at 10:47:39AM -0500, Deiss, Mark wrote: > > > > I have narrowed down the fault in the client message to the first line in > > the df output (how strange). Below is the client side code where only > > reporting the initial client line and then the [df] block header and the > df > > output. If the HPUX df header line is removed before sending out message, > no > > error on channel. > I just had another report about hobbitd_client crashing, also with the "df" > reports. In that case I was able to track it down and the attached patch > should fix it (the patch is on top of the current snapshot). Could you > try if this fixes it ? It might be the same problem. > Regards, > Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

safeguards
by bigdan＠gmail.com 04 Oct '05

04 Oct '05

I just had an issue where one of servers was having a php issue. This filled up /var/log/messages really fast (/var/log on separate partition) - think gigs of logs in a few minutes. Naturally, (bb) client is going to see this difference and want to store that in its diff file located in BBHOME/tmp. This, of course, filled up my root partition (Which we can blame on the shortsightedness of the person who partitioned this in the first place), exacerbating the problem. In this particular situation, it was mostly the setup that caused this issue, but is it worth considering putting some sanity checks into the hobbit client to prevent this? Are they already there and I'm not aware of them? Thanks Dan

2 1

[hobbit] Hobbit client reporting question
by adam.scheblein＠marquette.edu 03 Oct '05

03 Oct '05

Henrik, I have a working prototype, and have tested it against tru64 and hpux and linux. Unfortunately my c programming skills are not up to snuff, so i currently have it done as a shell script. Where do you want me to send it -- to the list? and also, would you prefer me to do it in C rather than shell? thanks, Adam Henrik Stoerner wrote: >On Thu, Sep 29, 2005 at 01:14:25PM -0500, Scheblein, Adam wrote: > > >>Basically I want to fold in bb-who into hobbit where you can >>say if root is logged in then panic, if foo is logged in then >>warn, and then display that on the main page as well as just >>a general "who". We wouldn't really need any graphing, just >>a server tweak -- but if I wanted it to happen at the same >>frequency as all the other tests where would it be put? >> >> > >OK - I've never used that extension, so I hadn't thought about >using those data like that. > >I had a look at bb-who, and it seems to generate a separate >status column "who" with the output from "who". The color of >this status then varies, depending on who is logged in. > >The way I would implement this for Hobbit would be as a >server module that is fed the client data and acts on it. > >Try logging in as the hobbit user on your Hobbit server, >then run "bbcmd hobbitd_channel --channel=client cat". >Whenever a client sends in an update message about itself, >you'll have it dumped to stdout (actually, it is read by the >"cat" utility, which then dumps it to stdout). It looks like this: > >hobbit at osiris:~$ bbcmd hobbitd_channel --channel=client cat >@@client#1201|1128023857.793392|172.16.10.2|osiris.hswn.dk|linux >client osiris,hswn,dk.linux >[date] >Thu Sep 29 21:57:26 CEST 2005 >[uname] >Linux osiris.hswn.dk 2.6.7 #2 Wed Jun 16 22:25:25 CEST 2004 i686 >GNU/Linux >[uptime] > 21:57:26 up 247 days, 23:10, 0 users, load average: 0.00, 0.14, 0.21 >[who] >henrik :0 Sep 25 07:54 >henrik :0 Sep 25 07:54 >... lots more lines ... >@@ > >So the client messages go from the "@@client..." line until the >"@@" line, and inside that is the section beginning with "[who]". > >What you need to do is write a program that receives these messages, >picks out the hostname from the fourth field in the "@@client..." >line, and then grabs the data from the "[who]" section of the client >message. You can then use these to build a status message, and send >it off to Hobbit as a new status column. For debugging you can run it >by hand; when it works, you just add a new section in hobbitlaunch.cfg >for this new module. > >I don't know what your favourite programming language is - IF you want >to implement this as a C program, there's a skeleton module included >with Hobbit in the hobbitd/hobbitd_sample.c file, which has all of the >necessary stuff to pick up a message, split up the "@@client..." line >into fields, and generally lets you concentrate on what you want to >do with the data. > >If you'd rather implement this in Perl, Python or some other language - >fine, then you'll just have to write that bit of code to fetch a single >message from stdin and process it. > > >Regards, >Henrik > > >To unsubscribe from the hobbit list, send an e-mail to >hobbit-unsubscribe at hswn.dk > > > >

2 1

Clientdata messed up
by lars.ebeling＠leopg9.no-ip.org 03 Oct '05

03 Oct '05

Hi, Some problems wit the clientdata. After [top] no data, then [vmstat] with data including top data, then again [vmstat] with data Are the commands not performed after each other? See attached file Regards Lars Ebeling http://leopg9.no-ip.org Hobbithobbyist "Never run after your own hat. Others will be delighted to do it; why spoil their fun?" -- Mark Twain

1 0

[hobbit] noprop tag suppresses too much
by KauffmanT＠nibco.com 03 Oct '05

03 Oct '05

I'm trying to avoid doing alerts on test environments AND keep the management staff from freaking out when a test system has an issue. Putting it on the "all non-green" page would be enough, I think. They actually do show up (indirectly) on the "all non-green", but only in the detailed event list, and only if they've transitioned in the last four hours. I'm just about to leave on a 4-day D/R phun & phrolic, followed by two weeks of much-needed R&R -- when I get back, I get to re-build my hobbit server on a 'new' system. I'll be going with the most current release at that point. It is ever so much easier to document the 'hobbit on SuSE' install as compared to the 'BB + RRD + LARRD + BBGEN on SuSE' install; for this alone you have my thanks! Tom Kauffman NIBCO, Inc -----Original Message----- From: Henrik Storner [mailto:henrik at hswn.dk] Sent: Sunday, October 02, 2005 10:03 AM To: hobbit at hswn.dk Subject: Re: [hobbit] noprop tag suppresses too much In <5B3853EEF769544ABD6EEC79788A063904DA3AF9 at EXVS2.nibco.com> "Kauffman, Tom" <KauffmanT at nibco.com> writes: >page test-nt-systems <H3><A HREF="notes/TestNTSys.html"><I>Test NT >Systems </I></H3> >group-compress <H3><I>NT Systems (Testing)</I></H3> >10.8.60.1 whq-sapxisbx # NOPROPRED:* !ftp !ssh !telnet >It also prevents this sub-page from being red, which may also be nice. >BUT -- there is NO indication on the summary display page (all >non-green), and the 'Test NT Systems' dot on the main page is also >green. >What I need from the 'noprop' tags is to keep the background from >changing based on the host flagged, but I still need to see that there >is a problem down in the sub page; I'd like the main page to still be >green, but the dot should show red for the 'Test NT Systems'. Not doable, I'm afraid. You *might* be able to convince me that it should show up on the "all non-green" page, but currently the idea is that when put a "noprop" on a status, it doesn't show up anywhere except on the page where it's hosted. Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

[hobbit] Hobbit 4.1.2 Release Candidate now available.
by Craig_Whilding＠mentor.com 03 Oct '05

03 Oct '05

I downloaded it about 1200 GMT today. Craig -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: 03 October 2005 15:57 To: hobbit at hswn.dk Subject: Re: [hobbit] Hobbit 4.1.2 Release Candidate now available. On Mon, Oct 03, 2005 at 07:46:08AM -0700, Whilding, Craig wrote: > When I installed the client earlier on a redhat ES3 system I set the > install dir as /usr/local/hobbit. Running the client produced errors > cannot find /bin/bb and cannot find /bin/hobbitclient-linux.sh as it had > set hobbit home as /usr/local/hobbit and hobbitclient.sh was looking for > the above files here instead of the client subdirectory. Have you tried it with the current version ? The client should now be completely relocatable, adjusting paths according to the location of the runclient.sh script. Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

[hobbit] Hobbit 4.1.2 Release Candidate now available.
by Craig_Whilding＠mentor.com 03 Oct '05

03 Oct '05

When I installed the client earlier on a redhat ES3 system I set the install dir as /usr/local/hobbit. Running the client produced errors cannot find /bin/bb and cannot find /bin/hobbitclient-linux.sh as it had set hobbit home as /usr/local/hobbit and hobbitclient.sh was looking for the above files here instead of the client subdirectory. Craig -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: 03 October 2005 15:15 To: hobbit at hswn.dk Subject: [hobbit] Hobbit 4.1.2 Release Candidate now available. The first release candidate for Hobbit 4.1.2 is now available at http://www.hswn.dk/beta/ It will also be uploaded to hobbitmon.sourceforge.net shortly. Loads of bugfixes and minor improvements, especially in the new Hobbit client code. See the attached Changes logfile. Please test this if you can, and report any bugs to hobbit at hswn.dk. If no major disasters show up, I expect to release the final 4.1.2 early next week. Regards, Henrik

2 1

[hobbit] Hostname Hobbit Client sends as
by Craig_Whilding＠mentor.com 03 Oct '05

03 Oct '05

I was running 4.1.1, upgrading to 4.1.2 and doing the suggested has solved the problem and client data is now appearing thanks :). Craig -----Original Message----- From: Werner (Ext Lists) [mailto:wmlist_ext at terra.com.br] Sent: 03 October 2005 13:30 To: hobbit at hswn.dk Subject: Re: [hobbit] Hostname Hobbit Client sends as Hi, If you're using a current snapshot, you can run ~client/runclient.sh with "--hostname=machine.name.com" option, or edit the runclient.sh itself and change the MACHINEDOTS variable to reflect your hostname. One way to see what hostname you're client is sending is take a look at the ~client/tmp/mst.txt 's firt line. Regards -wm On Mon, 3 Oct 2005 04:30:14 -0700 "Whilding, Craig" <Craig_Whilding at mentor.com> wrote: > Hi, is it possible to manually set the hostname thatthe Hobbit client sends as in the way the bb windows client does? I ask this asI have hobbit using FQDN’s but I don’t think my host are sendinginformation as such. > > Thanks, > > Craig To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

[hobbit] Channel processing problem with 4.11
by Mark.Deiss＠acs-inc.com 03 Oct '05

03 Oct '05

Confused even more now. Back to Sourceforge, from what I can tell, am using the current (?) release of hobbitserver 4.1.1. Not seeing anything in any of the Soureforge headings about a more current snapshot - under CVS or patch groupings. For your supplied patch, patch failed to apply - inspecting the patch, there are the following reference to old and patched lines in the hobbitd_client.c: - add_disk_count(fsname); + if (fsname) add_disk_count(fsname); Did a global search in the entire hobbit code tree and there is no add_disk_count function defined. Noticed the old code of: if (fsname && (usage != -1)) { Where in the 4.1.1 code base it is: if (usage != -1)) { Figured a check for valid fsname is what you are after before proceeding with the add_disk_count call above so made this change in the branch to work on disk threshold checking. Recompiled, retested, same error. Oh well. For the second patch in client_config.c, the line counts do not add up in the patch - closest code appears to be in the add_process_count function. Would not expect add_process_count to be part of processing df messages. Guess the add_disk_count is defined in this module in another version. RCS string for hobbitd_client.c and client_config.c module in the 4.1.1 release are: static char rcsid[] = "$Id: hobbitd_client.c,v 1.21 2005/07/25 13:57:56 henrik Exp $"; static char rcsid[] = "$Id: client_config.c,v 1.5 2005/07/24 07:50:13 henrik Exp $"; In the patch file, noticed string IDs for the patch targets of: --- hobbitd/hobbitd_client.c 2005/09/28 21:21:56 1.34 +++ hobbitd/hobbitd_client.c 2005/09/30 15:53:55 --- hobbitd/client_config.c 2005/09/21 11:37:05 1.9 +++ hobbitd/client_config.c 2005/09/30 15:54:57 So looks like am working with an older release set. Using the CVS web browser agent on Sourceforge, not turning up any more recent code trees for other then the hobbit client package. -----Original Message----- From: henrik at hswn.dk [mailto:henrik at hswn.dk] Sent: Friday, September 30, 2005 12:02 PM To: hobbit at hswn.dk Subject: Re: [hobbit] Channel processing problem with 4.11 On Fri, Sep 30, 2005 at 10:47:39AM -0500, Deiss, Mark wrote: > > I have narrowed down the fault in the client message to the first line in > the df output (how strange). Below is the client side code where only > reporting the initial client line and then the [df] block header and the df > output. If the HPUX df header line is removed before sending out message, no > error on channel. I just had another report about hobbitd_client crashing, also with the "df" reports. In that case I was able to track it down and the attached patch should fix it (the patch is on top of the current snapshot). Could you try if this fixes it ? It might be the same problem. Regards, Henrik

2 1