- Xymon - Xymon mailman web

[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

Installing Hobbit on OS/X
by evan＠espphotography.com 03 Nov '07

03 Nov '07

Read throgh the documentation.. If I'm missing something obvious, let me know. But I can't even do a configure on my OS/X 10.4 box: (Fat fingers). This was a fresh download of 4.2.0 from today, source tar. Running as root. # ./configure.server Configuration script for Hobbit This script asks a few questions and builds a Makefile to compile Hobbit Checking your make-utility Unknown option: n Usage: head [-options] <url>... -m <method> use method for the request (default is 'HEAD') -f make request even if head believes method is illegal -b <base> Use the specified URL as base -t <timeout> Set timeout value -i <time> Set the If-Modified-Since header on the request -c <conttype> use this content-type for POST, PUT, CHECKIN -a Use text mode for content I/O -p <proxyurl> use this as a proxy -P don't load proxy settings from environment -H <header> send this HTTP header (you can specify several) -u Display method and URL before any response -U Display request headers (implies -u) -s Display response status code -S Display response status chain -e Display response headers -d Do not display content -o <format> Process HTML content in various ways -v Show program version -h Print this message -x Extra debugging output GNU make is required to build Hobbit. If it is available as "gmake", run configure as: 'MAKE=gmake ./configure.server' Any suggestions? Thanks. Evan

5 5

[hobbit] Installing Hobbit on OS/X
by evan＠espphotography.com 02 Nov '07

02 Nov '07

This is installing the server. :) I don't have the install CD - this is a second hand computer to me :( From what it looks like, whatever command the configure is passing to head isn't liked. but that's my guess... At 12:56 PM 11/2/2007, David Gilmore wrote: >Evan, > >I ran into this problem when we configured the client on several OS >X servers. You need to get the second install CD for OS X and >install the BSD utilities. I do not recall what they are as I do >not have a system CD in front of me, but it should be fairly clear >when you mount the CD. > >David

1 1

Installing Hobbit on OS/X
by evan＠espphotography.com 02 Nov '07

02 Nov '07

Read throgh the documentation.. If I'm missing something obvious, let me know. But I can't even do a configure on my OS/X 10.4 box: # ./configure.server Configuration script for Hobbit This script asks a few questions and builds a Makefile to compile Hobbit Checking your make-utility Unknown option: n Usage: head [-options] <url>... -m <method> use method for the request (default is 'HEAD') -f make request even if head believes method is illegal -b <base> Use the specified URL as base -t <timeout> Set timeout value -i <time> Set the If-Modified-Since header on the request -c <conttype> use this content-type for POST, PUT, CHECKIN -a Use text mode for content I/O -p <proxyurl> use this as a proxy -P don't load proxy settings from environment -H <header> send this HTTP header (you can specify several) -u Display method and URL before any response -U Display request headers (implies -u) -s Display response status code -S Display response status chain -e Display response headers -d Do not display content -o <format> Process HTML content in various ways -v Show program version -h Print this message -x Extra debugging output GNU make is required to build Hobbit. If it is available as "gmake", run configure as: 'MAKE=gmake ./configure.server' Any suggestions? Thanks. Evan

2 1