October 2005 - Xymon - Xymon mailman web

[hobbit] short vs. canonical name
by adam.scheblein＠marquette.edu 27 Oct '05

27 Oct '05

I have run into this in my administration of HP-UX and Tru64 where just like you, my HP-UX servers use the short names, and the Tru64 are fully qualified. What I have done is in the bb-hosts file put the entry like this: IP server.fqdn.com # CLIENT:shortname [tests] Ex: 1.2.3.4 foo.bar.com # CLIENT:foo !ftp ssh !telnet Because then when the servers send their messages to hobbit, Hobbit is able to translate the messages no matter what the name is... Hope this helps, Adam ________________________________ From: Christian, Ron [mailto:rchristian at columbia.com] Sent: Wednesday, October 26, 2005 1:11 PM To: hobbit at hswn.dk Subject: [hobbit] short vs. canonical name We're bringing up 4.1.2 on a QA machine, and have noticed an anomaly. Our environment is mostly Solaris 9 with a few machines running Red Hat Enterprise AS. We have Hobbit 4.0.4 running on our production administrative server and Hobbit 4.1.2 server running on our QA box. The intention was to qualify 4.1.2 and push it into the production environment if it seemed reasonable to do so. I've run into a problem with the QA instance on Red Hat machines. I can see a couple ways to fix it but want to find out what is considered "best practices" The Solaris node names are the short (non-canonical) form, but the node names of RHEE tend to be fully qualified. It looks like we will have more Red Hat and fewer Solaris machines in the near future, so this issue will become significant. It looks like different parts of 4.1.2 arrive at the machine name in different ways. The name of the server is set explicitly as BBSERVERHOSTNAME in hobbitserver.cfg. It appears that this is used both for the built-in tests and server extensions. The client, on the other hand, appears to get it's hostname in a different fashion depending on whether it's a built-in test or an extension. With the client short name in bbhosts, but the client uname defaulting to the fully qualified name, the built-in tests work but extensions do not. It appears that the built-in tests somehow figure out the client's short name, and the server recognizes it and displays the data. However, when extensions are invoked, the client name is set to the fully qualified name, the name is munged to hostname,my,domain (note commas) and the server doesn't recognize the client. I see a few ways around this. We could set the uname on all the Linux boxes to the short name, and remember that we have to do this for any new installs. (I'm not sure if this will break anything else.) Or, we could set up a hobbit alias for each Linux machine (ick...). Or, we could change runclient.sh to use "hostname -s" instead of "uname -n" (But only on Linux boxes.) or change the "MACHINE="`echo $MACHINEDOTS | sed [...]`" expression to dump the domain name instead of changing the dots to commas. Have others run into this, and is there an accepted solution? Ron - Silence is golden. Duct tape is silver.

1 0

disabled hosts, re-enabled on hobbitd restart
by rdeal＠tigr.ORG 26 Oct '05

26 Oct '05

Should hobbitd maintain disabled hosts when restarted? The files are still in the data/disabled directory but the hosts are listed as enabled after a restart.

3 2

[hobbit] Missed pages going from Yellow to Red
by Jason.Chambers＠geosoft.com 26 Oct '05

26 Oct '05

The only problem that I have had with yellow to red is that, using the big brother client for windows, I changed the disk capacity warning and critical to something really small. Like 5% and 10%. Theres like 58% used, and I got a yellow alert instead of a red alert for some strange reason. Jason Chambers IT Helpdesk Support Geosoft Inc. 85 Richmond St. West - 8th Floor Toronto, Ontario, Canada M5H 2C9 Tel: 416-369-0111 x344 Fax: 416-369-9599 www.geosoft.com -----Original Message----- From: Pat Vaughan [mailto:hobbit at pvaughan.us] Sent: Wednesday, October 26, 2005 3:28 PM To: hobbit at hswn.dk Subject: [hobbit] Missed pages going from Yellow to Red This morning I had a filesystem start to fill up and go to a yellow state. Hobbit sent the Email as expected. But then the alarm went to a red state. Once it goes to a red state, I should get a page. At first I thought it might be something to do with the long REPEAT time on this rule, but it looks like there is only a problem when the state is yellow and then switches to red. Has anyone else noticed similar behavior? To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

short vs. canonical name
by rchristian＠columbia.com 26 Oct '05

26 Oct '05

We're bringing up 4.1.2 on a QA machine, and have noticed an anomaly. Our environment is mostly Solaris 9 with a few machines running Red Hat Enterprise AS. We have Hobbit 4.0.4 running on our production administrative server and Hobbit 4.1.2 server running on our QA box. The intention was to qualify 4.1.2 and push it into the production environment if it seemed reasonable to do so. I've run into a problem with the QA instance on Red Hat machines. I can see a couple ways to fix it but want to find out what is considered "best practices" The Solaris node names are the short (non-canonical) form, but the node names of RHEE tend to be fully qualified. It looks like we will have more Red Hat and fewer Solaris machines in the near future, so this issue will become significant. It looks like different parts of 4.1.2 arrive at the machine name in different ways. The name of the server is set explicitly as BBSERVERHOSTNAME in hobbitserver.cfg. It appears that this is used both for the built-in tests and server extensions. The client, on the other hand, appears to get it's hostname in a different fashion depending on whether it's a built-in test or an extension. With the client short name in bbhosts, but the client uname defaulting to the fully qualified name, the built-in tests work but extensions do not. It appears that the built-in tests somehow figure out the client's short name, and the server recognizes it and displays the data. However, when extensions are invoked, the client name is set to the fully qualified name, the name is munged to hostname,my,domain (note commas) and the server doesn't recognize the client. I see a few ways around this. We could set the uname on all the Linux boxes to the short name, and remember that we have to do this for any new installs. (I'm not sure if this will break anything else.) Or, we could set up a hobbit alias for each Linux machine (ick...). Or, we could change runclient.sh to use "hostname -s" instead of "uname -n" (But only on Linux boxes.) or change the "MACHINE="`echo $MACHINEDOTS | sed [...]`" expression to dump the domain name instead of changing the dots to commas. Have others run into this, and is there an accepted solution? Ron - Silence is golden. Duct tape is silver.

1 0

[hobbit] EXHOST usage
by adam.scheblein＠marquette.edu 26 Oct '05

26 Oct '05

Greetings, Is there a way to make the apache graphs show up in the http page? Thanks, Adam

2 1

[hobbit] Error compiling todays snapshot 051026
by Stewart_Larsen＠doh.state.fl.us 26 Oct '05

26 Oct '05

Yeah. I get bbhostgrep.o(.text+0x192): In function `downok': ./snapshot/common/bbhostgrep.c:76: undefined reference to `parse_color' bbhostgrep.o(.text+0x23a):/home/slarsen/snapshot/common/bbhostgrep.c:90: undefined reference to `parse_color' collect2: ld returned 1 exit status parse_color is in ./lib/color.c Stewart ________________________________ From: lars ebeling [mailto:lars.ebeling at leopg9.no-ip.org] Sent: Wednesday, October 26, 2005 12:53 AM To: hobbit Subject: [hobbit] Error compiling todays snapshot 051026 cc -g -O -D_REENTRANT -DHPUX -I. -I/home/hobbit/snapshot/include -I/usr/local/in clude -o ../client/bbhostgrep bbhostgrep.o ../lib/hobbitclient.a /usr/ccs/bin/ld: Unsatisfied symbols: parse_color (code) collect2: ld returned 1 exit status makeÄ1Å: *** Ä../client/bbhostgrepÅ Error 1 makeÄ1Å: Leaving directory é/home/hobbit/snapshot/common' make: *** Äcommon-clientÅ Error 2 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 ________________________________ Spam <https://dohsmsi01.doh.state.fl.us/canit/b.php?c=s&i=49453825&m=c2be4eee05b3> Not spam <https://dohsmsi01.doh.state.fl.us/canit/b.php?c=n&i=49453825&m=c2be4eee05b3> Forget previous vote <https://dohsmsi01.doh.state.fl.us/canit/b.php?c=f&i=49453825&m=c2be4eee05b3>

1 0

[hobbit] hobbit_rrd core dumping
by rdeal＠tigr.ORG 26 Oct '05

26 Oct '05

(gdb) bt #0 0x7f8a01a0 in _libc_kill () from /usr/lib/libc.so.1 #1 0x7f836ce0 in abort () from /usr/lib/libc.so.1 #2 0x1e6d4 in setup_signalhandler ( programname=0xa <Address 0xa out of bounds>) at sig.c:57 -----Original Message----- From: Henrik Stoerner [mailto:henrik at hswn.dk] Sent: Tuesday, October 25, 2005 6:04 PM To: hobbit at hswn.dk Subject: Re: [hobbit] hobbit_rrd core dumping On Tue, Oct 25, 2005 at 05:49:36PM -0400, Deal, Richard wrote: > I cleaned up some old log data and hobbitd_rrd started to core dump. > I even tried removing the entire data/rrd/* but it is still dumping > core. Could you run the core-dump through gdb, as described in http://www.hswn.dk/hobbit/help/known-issues.html#bugreport Regards, Henrik To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

1 0

[hobbit] SMTP diamond shaped trend?
by Jason.Chambers＠geosoft.com 26 Oct '05

26 Oct '05

That's the one! I would too, except it makes no sense for our network. Why would all 4 of our monitored SMTP servers look the same? It's kinda strange if you ask me. Jason Chambers IT Helpdesk Support Geosoft Inc. 85 Richmond St. West - 8th Floor Toronto, Ontario, Canada M5H 2C9 Tel: 416-369-0111 x344 Fax: 416-369-9599 www.geosoft.com -----Original Message----- From: Geoff Steer [mailto:gsteer at firstwave.com.au] Sent: Wednesday, October 26, 2005 3:16 AM To: hobbit at hswn.dk Subject: RE: [hobbit] SMTP diamond shaped trend? Is this what you mean? (see attached jpg file) I was curious about this too but put it down to changing network load. Regards Geoff On Tue, 2005-10-25 at 16:22 -0400, Jason Chambers wrote: > No, I'm talking about the trends reporting, the RRDTOOL stuff I guess. > It forms diamond like responses on the 48 hour graph. I get like 4 and > 1/2 of them in one page sometimes. > > Jason Chambers > IT Helpdesk Support > Geosoft Inc. > 85 Richmond St. West - 8th Floor > Toronto, Ontario, Canada > M5H 2C9 > Tel: 416-369-0111 x344 > Fax: 416-369-9599 > www.geosoft.com > > > > -----Original Message----- > From: Rich Smrcina [mailto:rsmrcina at wi.rr.com] > Sent: Tuesday, October 25, 2005 4:10 PM > To: hobbit at hswn.dk > Subject: Re: [hobbit] SMTP diamond shaped trend? > > Are you referring to the icon that comes up on the web display? That is > > normal for tests that have been green for more than one day. They > change from the three-eyed-smiley to a diamond. > > Jason Chambers wrote: > > Hey guys, > > > > > > > > I'm noticing that a lot of my external SMTP tests seems to be forming > a > > diamond like pattern when tests are being done. This isn't just for > one > > server, but for pretty much all of my SMTP tests that are being done > on > > different servers, including local LAN servers. Anyone know why this > is > > happening? > > > > > > > > > > > > Jason Chambers > > > > **IT Helpdesk Support** > > > > Geosoft Inc. > > > > 85 Richmond St. West - 8th Floor > > > > Toronto, Ontario, Canada > > > > M5H 2C9 > > > > Tel: 416-369-0111 x344 > > > > Fax: 416-369-9599 > > > > www.geosoft.com <http://www.geosoft.com> > > > > > > > > > > > > > > > > -- > Rich Smrcina > VM Assist, Inc. > Main: (262)392-2026 > Cell: (414)491-6001 > Ans Service: (360)715-2467 > rich.smrcina at vmassist.com > > Catch the WAVV! http://www.wavv.org > WAVV 2006 - Chattanooga, TN - April 7-11, 2006 > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > > > To unsubscribe from the hobbit list, send an e-mail to > hobbit-unsubscribe at hswn.dk > > > > -------------------------------Safe Stamp----------------------------------- > Your Anti-virus Service scanned this email. It is safe from known viruses. > For more information regarding this service, please contact your service provider. -------------------------------Safe Stamp----------------------------------- The sender's Anti-virus Service scanned this email. It is safe from known viruses.

1 0

[hobbit] RE : [hobbit] SMTP diamond shaped trend?
by Jason.Chambers＠geosoft.com 26 Oct '05

26 Oct '05

Not that, the trends graph. Your 48 hour picture trends graph. Jason Chambers IT Helpdesk Support eosoft Inc. 85 Richmond St. West - 8th Floor Toronto, Ontario, Canada M5H 2C9 Tel: 416-369-0111 x344 Fax: 416-369-9599 www.geosoft.com ________________________________ From: FIGARO Nicolas [mailto:nfigaro at effigie.fr] Sent: Wednesday, October 26, 2005 2:14 AM To: hobbit at hswn.dk Subject: [hobbit] RE : [hobbit] SMTP diamond shaped trend? Hi, there are two sorts of icons in hobbit. check hobbit-tips (#icons) for the detail : What do the little red/yellow/green icons mean ? Color Recently changed Last change > 24 hours Green: Status is OK Green - recently changed<http://prdnpx23.mgen.fij/hobbit/gifs/green-recent.gif> Green<http://prdnpx23.mgen.fij/hobbit/gifs/green.gif> Yellow: Warning Yellow - recently changed<http://prdnpx23.mgen.fij/hobbit/gifs/yellow-recent.gif> Yellow<http://prdnpx23.mgen.fij/hobbit/gifs/yellow.gif> Red: Critical Red - recently changed<http://prdnpx23.mgen.fij/hobbit/gifs/red-recent.gif> Red<http://prdnpx23.mgen.fij/hobbit/gifs/red.gif> Clear: No data Clear - recently changed<http://prdnpx23.mgen.fij/hobbit/gifs/clear-recent.gif> Clear<http://prdnpx23.mgen.fij/hobbit/gifs/clear.gif> Purple: No report Purple - recently changed<http://prdnpx23.mgen.fij/hobbit/gifs/purple-recent.gif> Purple<http://prdnpx23.mgen.fij/hobbit/gifs/purple.gif> Blue: Disabled Blue - recently changed<http://prdnpx23.mgen.fij/hobbit/gifs/blue-recent.gif> Blue<http://prdnpx23.mgen.fij/hobbit/gifs/blue.gif> NF -----Message d'origine----- De : Jason Chambers [mailto:Jason.Chambers at geosoft.com] Envoyé : mardi 25 octobre 2005 22:07 À : hobbit at hswn.dk Objet : [hobbit] SMTP diamond shaped trend? Hey guys, I'm noticing that a lot of my external SMTP tests seems to be forming a diamond like pattern when tests are being done. This isn't just for one server, but for pretty much all of my SMTP tests that are being done on different servers, including local LAN servers. Anyone know why this is happening? Jason Chambers IT Helpdesk Support eosoft Inc. 85 Richmond St. West - 8th Floor Toronto, Ontario, Canada M5H 2C9 Tel: 416-369-0111 x344 Fax: 416-369-9599 www.geosoft.com

1 0

External scripts not working the same?
by Stewart_Larsen＠doh.state.fl.us 26 Oct '05

26 Oct '05

Greetings, We are looking at migrating from BB to Hobbit. One major stumbling block right now is that we have over 400 devices on the network right now that we monitor via SNMP. Firewalls, Routers, proxies, etc. Our basic script in BB was under the ext folder on the server and was run every 5 minutes when bbtest-net ran. An instance of this script was called for each device we needed checked. It pulled the IP address of the device from the environment variables and called the bb executable with it's result when the test was completed. This doesn't seem to be possible in hobbit. Every reference I've seen in the archives has told people to use hobbitlaunch. Unless I'm misunderstanding things (which is possible...), I can tell hobbitlaunch to fire off my external script every 5 minutes, but the script will only run that one time, meaning I'd have to modify my script to run a loop through all of the devices that I want the test run for. This is not really the way we want to go, because then it ignores the hosts that are planned down for maintenance and such. What I'd like to do is add a service tag in the bbhost file called router_test. Then, when the network tests are run, hobbit should be smart enough to know that there is an external script defined in hobbitlaunch.cfg that matches that tag and run it for that machine. Is this possible? Little help for a newbie to Hobbit? Stewart

3 4