November 2007 - Xymon - Xymon mailman web

Differences between bb and hobbit -
by joe＠tmsusa.com 06 Nov '07

06 Nov '07

Hello list, I've gotten a pair of hobbit servers set up, one in each data center, in a specific lan. I'm noticing that, due to the many transient network glitches in wan connectivity, that the hobbit history shows a lot of red/green/red/green. This appears to be different behavior from bb, which gives us some knobs to turn, mitigating the effects of the transient glitches and preventing the alternating red/green connectivity status. (We've got people watching bbdisplay pages, who panic when they see red.) If a bb-net test fails, bb waits "n" seconds and tries again, and if it still fails, it waits "m" seconds and tries a third time, and if that fails as well, the connectivity goes red. The delays between try 1 and try 2, and the delay between try 2 and try 3, are configurable in bb, but I don't see any such option in hobbit, nor is it obvious whether there is more than 1 attempt made to perform a network test. Can anyone confirm or deny that this is the case, and if not, point me to the correct configuration option? Thanks & Regards, Joe

3 4

Extend Hobbit server from external Company sites
by johan.boye＠latecoere.fr 06 Nov '07

06 Nov '07

Hello, I'm running a Hobbit server on a place A. There, it monitors a couple of servers, databases, filers... I would like to run another Hobbit server on a place B to monitor machines on the B place. Is there a way to give feedback to the A-Hobbit server if there are red errors on the B-Hobbit server ? Thanks, Johan "Les informations contenues dans ce message electronique peuvent etre de nature confidentielles et soumises a une obligation de secret. Elles sont destinees a l'usage exclusif du reel destinataire. Si vous n'etes pas le reel destinataire, ou si vous recevez ce message par erreur, merci de le detruire immediatement et de le notifier a son emetteur." "The information contained in this e-mail may be privileged and confidential. It is intended for the exclusive use of the designated recipients named above. If you are not the intended recipient or if you receive this e-mail in error, please delete it and immediately notify the sender."

4 3

[hobbit] Creating a fake, or combination, client
by Martin.Ward＠colt.net 06 Nov '07

06 Nov '07

Thanks Gary, I think the thing I am missing in your example (and in general to be honest) is: What is the link between fake-host in the bb-hosts file and [custom-postfix] in the hobbitgraph.cfg file? |\/|artin -----Original Message----- From: Gary Baluha [mailto:gumby3203 at gmail.com] Sent: 06 November 2007 15:34 To: hobbit at hswn.dk Subject: Re: [hobbit] Creating a fake, or combination, client On 11/6/07, Ward, Martin <Martin.Ward at colt.net> wrote: Hi all, I am a newbie to Hobbit and have inherited a working system. I have a good idea of how it all hangs together but now I want to produce certain graphs and cannot figure out how. I have a cluster of mail servers that run Postfix; each of these clients is monitored within Hobbit. In the Trends link for each client I have graphs showing the various mail queues (incoming, deferred etc) and this data is stored in RRD files on the Hobbit server. Is there a way within Hobbit of creating a false or meta- client that can have a graph with data from all of these RRD files? Particularly I would like a graph that has all the incoming mail queue sizes on it with one line per server. I already have this information in lots of different RRD files but would like to have them all in one graph. I can create a graph outside of Hobbit to do this, but within the monitoring system it restricts the RRD files it will display data from to those in the data directory of the selected client (in the Trends link). Hmm. You could probably create a host and set up a noconn test to some random IP like 10.0.0.1 (i.e. in bb-hosts: 10.0.0.1 fake-host # noconn). Regardless of what host (or fake host, if you do that), you will need to create a new RRD trend to that host. You can create an RRD graph (by modifying hobbit-graph.cfg) that gets its data from multiple RRD files. These files are usually created in a directory for each host, and I don't know if you can just create a symlink to those or not. But assuming that works, you should be all set in creating a single graph that plots all the other data using a single scale. I think you would want to add the following to hobbitserver.cfg: GRAPHS="<whatever is already there>,custom-postfix" And then hobbit-graph.cfg would look something like this: [custom-postfix] . . . DEF:hosta:HostA.rrd:AVERAGE DEF:hostb:HostB.rrd:AVERAGE . . . I have tried creating a new client in the data files ans symbolically linking the other RRD files into its data directory, but cannot persude the graphs to appear in the trends web page. Thanks for your time, |\/|artin ************************************************************************************* The message is intended for the named addressee only and may not be disclosed to or used by anyone else, nor may it be copied in any way. The contents of this message and its attachments are confidential and may also be subject to legal privilege. If you are not the named addressee and/or have received this message in error, please advise us by e-mailing security at colt.net and delete the message and any attachments without retaining any copies. Internet communications are not secure and COLT does not accept responsibility for this message, its contents nor responsibility for any viruses. No contracts can be created or varied on behalf of COLT Telecommunications, its subsidiaries or affiliates ("COLT") and any other party by email Communications unless expressly agreed in writing with such other party. Please note that incoming emails will be automatically scanned to eliminate potential viruses and unsolicited promotional emails. For more information refer to www.colt.net or contact us on +44(0)20 7390 3900.

1 0

[hobbit] Soon-to-be 4.3.0
by gumby3203＠gmail.com 06 Nov '07

06 Nov '07

Henrik, It's been a while since we've heard any news about 4.3.0, as far as features go. From the various threads around here, it sounds like it's going to be pretty feature-packed, and if that's the case, I can see why this release is taking a while to come out. I was just wondering if you could provide some info on some of the more important / major changes and additions that can be confirmed in the 4.3.0 release? There is one or two features I'd like to see, but perhaps some of the other features you have planned will be enough for what I need.

1 0

[hobbit] Hobbit CONN questions
by Chris.Morris＠RWEsystemsUK.com 06 Nov '07

06 Nov '07

Well it depends whether you are using fping or hobbitping - try reading the man pages, which can be accessed from the Help menu of the web page. This tells you how many pings, what happens when the first ping fails, the timeout etc etc and yes it is configurable. > -----Original Message----- > From: johan.boye at latecoere.fr [SMTP:johan.boye at latecoere.fr] > Sent: Tuesday, November 06, 2007 2:43 PM > To: hobbit at hswn.dk > Subject: [hobbit] Hobbit CONN questions > > Hello again, > > I'm polished a Hobbit installation. I would like to know how the Hobbit > server handle the "conn" step. I guess it's a couple of ping, isn't it ? > How it works when a first ping doesn't not respond? How many packet are > sent each time? What is the time-out? Can we configure it? > > Thanks by advance for any informations related to this ;) > > Johan > > _____ > > "Les informations contenues dans ce message electronique peuvent etre de > nature confidentielles et soumises a une obligation de secret. Elles sont > destinees a l'usage exclusif du reel destinataire. Si vous n'etes pas le > reel destinataire, ou si vous recevez ce message par erreur, merci de le > detruire immediatement et de le notifier a son emetteur." > > "The information contained in this e-mail may be privileged and > confidential. It is intended for the exclusive use of the designated > recipients named above. If you are not the intended recipient or if you > receive this e-mail in error, please delete it and immediately notify the > sender." > > _____ > ********************************************************************** This e-mail including any attachments is provided for general information purposes only and does not constitute advice except to the addressee if expressly stated in this email. For the avoidance of doubt the contents of this email and any attachments are subject to contract and are not intended to and will not constitute a legally binding contract or any part of a legally binding contract. The information contained in this email and any attachments is confidential. It is intended only for the use of the intended recipient at the email address to which it has been addressed. If the reader of this message is not an intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution or copying of the message or associated attachments is strictly prohibited. If you have received this e-mail in error, please notify postmaster at RWEsystemsUK.com and permanently delete the email and any attachments immediately from your system. You should not retain, copy or use this email or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you for your co-operation. Neither RWE Systems UK Ltd nor any of the other companies in the RWE Group from whom this e-mail originates accept any responsibility for losses or damage as a result of any viruses and it is your responsibility to check attachments (if any) for viruses. RWE Systems UK Ltd Registered office: Mistral, Westlea Campus, Chelmsford Road, Swindon, Wiltshire, SN5 7EZ. Registered in England and Wales: company number 6052966. *******************************************

1 0

Hobbit CONN questions
by johan.boye＠latecoere.fr 06 Nov '07

06 Nov '07

Hello again, I'm polished a Hobbit installation. I would like to know how the Hobbit server handle the "conn" step. I guess it's a couple of ping, isn't it ? How it works when a first ping doesn't not respond? How many packet are sent each time? What is the time-out? Can we configure it? Thanks by advance for any informations related to this ;) Johan "Les informations contenues dans ce message electronique peuvent etre de nature confidentielles et soumises a une obligation de secret. Elles sont destinees a l'usage exclusif du reel destinataire. Si vous n'etes pas le reel destinataire, ou si vous recevez ce message par erreur, merci de le detruire immediatement et de le notifier a son emetteur." "The information contained in this e-mail may be privileged and confidential. It is intended for the exclusive use of the designated recipients named above. If you are not the intended recipient or if you receive this e-mail in error, please delete it and immediately notify the sender."

1 0

Two BBDisplays, one collaboration
by josh＠imaginenetworksllc.com 05 Nov '07

05 Nov '07

What I am trying to do is have two BBDisplay servers. The first one being our main one - monitors our network equipment and things - and a second one that lives on the customer's network and pings APs, Switches, etc. I have setup this in bb-hosts on the main one: page HIXX Holiday Inn X X group-compress <H3><I>Access Points</I></H3> 1.2.3.4 host.com # noconn group-compress <H3><I>HIDM Hardware</I></H3> 2.3.4.5 host2.com # noconn Reason for the noconn is that these are all private IPs, accessible only by the customer's LAN. These configuration match those of the customer's bb-hosts (with the exception of noconn, of course =) I then went into the customer's server/etc/hobbitserver.cfg and changed it as such: BBDISP="0.0.0.0" BBDISPLAYS=" 10.59.1.119,MAINSERVERPUBLIC" I have also tried it without quotes When I set this neither BBDisplay has anything on the www pages, they're completely blank! Once I switch it to BBDISP="$BBSERVERIP" # IP of a single hobbit/bbd server BBDISPLAYS="" It works perfectly fine on the customer's server, but the main one is display blank (obviously =) Please let me know where I went wrong. Thanks in advance! Josh -- Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 Those who don't understand UNIX are condemned to reinvent it, poorly. --- Henry Spencer

4 14

[hobbit] big brother replacement
by Mark.Deiss＠acs-inc.com 05 Nov '07

05 Nov '07

For a vanilla BB environment, you can have multiple BBDISPLAY entities but the recommendation is that there is only one BBNET entity. A BBNET server that is generating the pings out to the clients will be sending the ping results to all of the BBDISPLAY entities (as defined on the BBNET host). If you have multiple BBNET entities that ping the same servers, you will be sending duplicated results as far as the individual BBDISPLAY servers are concerned (the connection messages will be renamed to the host being pinged). To support multiple BBNETs in a non-race environment requires additional coding to carefully direct the BBNET results to not trip over each other. The default behavior is to pump them out to whatever BBDISPLAY is listed - you get the race conditions when you want all the BBDISPLAY servers to monitor all of the BBNET hosts (i.e. want BBNET to send their client-side tests to the BBDISPLAY entities - this will result in the BBNET poll messages going out to all the BBDISPLAY entities also). It's doable, hacked the heck out of the BB code base years ago to support three separate BBDISPLAY/BBNET servers that provided redundant monitoring over a client base and over each other. The goal in this case is the BBNET directs its status messages to only a defined group of BBDISPLAY servers - that will only have the one source of BBNET message traffic. The rest of the BBNET's tests would be allowed to go to a wider distribution of BBDISPLAY servers. These other tests would be keyed to the BBNET's server name so there would not be a race or conflict conditions occurring on the BBDISPLAY servers. The BBNET race condition may seem minor - but then think about what is going on with any RRD database entries - you would be updating if from all the BBNET entities in a given time window. Resulting trends can get really bizarre if the BBNET polls are originating from different network segments with different response times. Bad times from one segment getting masked in the trends due to updates occurring from another segment etc. Main difference in the commercial version of BB over the BTF version is that they added support for encrypting the communications from the clients to the servers. I would place some value on that as some sites are running external tests that are sending sensitive client information to the BBDISPLAY boxes. There may be a difference in the level of included documentation - but who reads the documentation anyways..... Maybe Mr. Croteau and Mr. MacGuire will do a LBO and take BB private again. -----Original Message----- From: Sloan [mailto:joe at tmsusa.com] Sent: Thursday, November 01, 2007 8:05 PM To: hobbit at hswn.dk Subject: Re: [hobbit] big brother replacement Josh Luthman wrote: > That would be relative to Hobbit's bbtest I believe - someone correct > me if I'm wrong, I'm just guessing here! > > I don't see any reason to think that script wouldn't work with some > variable changes like BBNET=`$GREP BBNET $BBHOSTS | $GREP "^[0-9]" | > $GREP -v "^\#"` but I am not an expert by any means! Well, depending on what I hear on this list in the next day or so, taking a crack at adapting the old bb failover script may be my best option. > > Getting back to the version 3.3 - after 1.9btf Quest starting selling > the product. I don't know the exact history behind it but 1.9btf is > what you get without paying for anything. I have worked with and > continue to monitor a network with 3.1 or 3.2 (they decided to revert > from 3.3 as it looks quite a bit different on the BBDISPLAY) and I > honestly don't see what they've changed between 1.9 and 3.2. Most of > the features of BB I heard of or read were not only already in Hobbit > but were even better then what I had heard. Not to mention the dozens > of BB scripts that can be relatively painless to migrate. Ah, interesting - I always had the feeling that quest didn't do much of anything with the code except put in some verbiage and legal warnings, and tried to push their own proprietary and non linux-friendly stuff and left the bb code base to slowly decay. Joe To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk

9 16

strange result in fping by hobbit and fping by yours truly
by dortsen＠gmail.com 05 Nov '07

05 Nov '07

Hi everyone, I've got a somewhat strange issue with fping in hobbit. I've got a list of about 122 terminals that are used for a chipcard payment system. Each one of them has an ip-address and connects to a server to process the payments. Every now and then the terminals loose the connection or whatever, they need to be reset before they can process the payments again on the server. I thought I might use Hobbit to ping all the terminals to see if they still respond to a ping. If they don't reply anymore, they need a reset. I only do a conn test on an ip-address. I use the full path to fping in hobbitserver.cfg, without any extra parameters. When hobbit starts testing the connection, only 14 terminals respond to a ping, but when I execute a fping myself (as the hobbit user) in a shell to the same amount of terminals, I get a totally different result, instead of 14 responding terminals, I get 95 responding terminals with fping! It's not just a lucky shot, I can keep on trying these terminals, the huge difference remains whether I fping them myself or when hobbit fpings them. I'm running hobbit 4.2.0. According to bbtest I have 806 hosts that are pinged, that takes about 26 seconds to complete. To complete all tests (954), it takes about 47 seconds. Does anyone have a clue why specifically these terminals have such a difference in hobbit ping and a ping performed by myself? I can't explain it, and it doesn't seem like a timeout (latency) issue to me either. Thanks in advance, Br. Dennis

5 7

Removing interfaces from trends graph
by Vernon.Everett＠woodside.com.au 05 Nov '07

05 Nov '07

Hi all I haven't found it in the docs, but how do you limit the interfaces being monitored/graphed in the trends column? I have a server, with many interfaces, most of them virtual, that I do not care about, and that change from time to time. Graphing them, is cluttering the graphs of the interfaces I do care about. So, how do I limit the trends to specific interfaces only? (Alternatively, how do I exclude specific interfaces?) Regards Vernon NOTICE: This email and any attachments are confidential. They may contain legally privileged information or copyright material. You must not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages and all attachments.

1 0