<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2658.34">
<TITLE>RE: [hobbit] big brother replacement</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=2>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).</FONT></P>
<P><FONT SIZE=2>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. </FONT></P>
<P><FONT SIZE=2>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.</FONT></P>
<P><FONT SIZE=2>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.....</FONT></P>
<P><FONT SIZE=2>Maybe Mr. Croteau and Mr. MacGuire will do a LBO and take BB private again.</FONT>
</P>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Sloan [<A HREF="mailto:joe@tmsusa.com">mailto:joe@tmsusa.com</A>] </FONT>
<BR><FONT SIZE=2>Sent: Thursday, November 01, 2007 8:05 PM</FONT>
<BR><FONT SIZE=2>To: hobbit@hswn.dk</FONT>
<BR><FONT SIZE=2>Subject: Re: [hobbit] big brother replacement</FONT>
</P>
<P><FONT SIZE=2>Josh Luthman wrote:</FONT>
<BR><FONT SIZE=2>> That would be relative to Hobbit's bbtest I believe - someone correct</FONT>
<BR><FONT SIZE=2>> me if I'm wrong, I'm just guessing here!</FONT>
<BR><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> I don't see any reason to think that script wouldn't work with some</FONT>
<BR><FONT SIZE=2>> variable changes like BBNET=`$GREP BBNET $BBHOSTS | $GREP "^[0-9]" |</FONT>
<BR><FONT SIZE=2>> $GREP -v "^\#"` but I am not an expert by any means!</FONT>
</P>
<BR>
<P><FONT SIZE=2>Well, depending on what I hear on this list in the next day or so,</FONT>
<BR><FONT SIZE=2>taking a crack at adapting the old bb failover script may be my best</FONT>
<BR><FONT SIZE=2>option.</FONT>
</P>
<P><FONT SIZE=2>></FONT>
<BR><FONT SIZE=2>> Getting back to the version 3.3 - after 1.9btf Quest starting selling</FONT>
<BR><FONT SIZE=2>> the product. I don't know the exact history behind it but 1.9btf is</FONT>
<BR><FONT SIZE=2>> what you get without paying for anything. I have worked with and</FONT>
<BR><FONT SIZE=2>> continue to monitor a network with 3.1 or 3.2 (they decided to revert</FONT>
<BR><FONT SIZE=2>> from 3.3 as it looks quite a bit different on the BBDISPLAY) and I</FONT>
<BR><FONT SIZE=2>> honestly don't see what they've changed between 1.9 and 3.2. Most of</FONT>
<BR><FONT SIZE=2>> the features of BB I heard of or read were not only already in Hobbit</FONT>
<BR><FONT SIZE=2>> but were even better then what I had heard. Not to mention the dozens</FONT>
<BR><FONT SIZE=2>> of BB scripts that can be relatively painless to migrate.</FONT>
</P>
<P><FONT SIZE=2>Ah, interesting - I always had the feeling that quest didn't do much of</FONT>
<BR><FONT SIZE=2>anything with the code except put in some verbiage and legal warnings,</FONT>
<BR><FONT SIZE=2>and tried to push their own proprietary and non linux-friendly stuff and</FONT>
<BR><FONT SIZE=2>left the bb code base to slowly decay.</FONT>
</P>
<P><FONT SIZE=2>Joe</FONT>
</P>
<P><FONT SIZE=2>To unsubscribe from the hobbit list, send an e-mail to</FONT>
<BR><FONT SIZE=2>hobbit-unsubscribe@hswn.dk</FONT>
</P>
</BODY>
</HTML>