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