[hobbit] big brother replacement
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
The biggest problem I have with going to Hobbit is there is no snmp trap sending support. We don't use BB as our main interface for showing all alerts, but it is required and we do send snmp traps from the BBPAGER to our main dashboard of alerts. Is this functionality in Hobbit yet?
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information. There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
On Fri, Nov 02, 2007 at 08:30:38AM -0400, PAUL WILLIAMSON wrote:
The biggest problem I have with going to Hobbit is there is no snmp trap sending support. We don't use BB as our main interface for showing all alerts, but it is required and we do send snmp traps from the BBPAGER to our main dashboard of alerts. Is this functionality in Hobbit yet?
BB really just calls the "snmptrap" utility to send the trap message to your SNMP based console. A script to do the same from hobbit-alerts.cfg is a very simple solution to this.
Henrik
I believe there is a workaround for it using something else. I know you can find it in the mailing list archives - it has been asked and discussed many times.
I read that Henrik has SNMP planned for a later release, too, though I don't believe that is confirmed.
Josh
On 11/2/07, PAUL WILLIAMSON <pwilliamson at mtb.com> wrote:
The biggest problem I have with going to Hobbit is there is no snmp trap sending support. We don't use BB as our main interface for showing all alerts, but it is required and we do send snmp traps from the BBPAGER to our main dashboard of alerts. Is this functionality in Hobbit yet?
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information. There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
-- 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
For posterity:
We use mrtg to do all our SNMP polling (I know devmon is the popular solution hear, but it's messy and so multi-filed so we have a bad taste for it) and for traps we have a script we stopped using recently, but it was setup much like Henrik stated. It was just added to hobbit-alerts.cfg and life was good.
Tod Hansmann
Network Engineer
<http://www.directpointe.com/>
From: Josh Luthman [mailto:josh at imaginenetworksllc.com] Sent: Friday, November 02, 2007 8:48 AM To: hobbit at hswn.dk Subject: Re: [hobbit] big brother replacement
I believe there is a workaround for it using something else. I know you can find it in the mailing list archives - it has been asked and discussed many times.
I read that Henrik has SNMP planned for a later release, too, though I don't believe that is confirmed.
Josh
On 11/2/07, PAUL WILLIAMSON <pwilliamson at mtb.com> wrote:
The biggest problem I have with going to Hobbit is there is no snmp trap sending support. We don't use BB as our main interface for showing all alerts, but it is required and we do send snmp traps from the BBPAGER to our main dashboard of alerts. Is this functionality in Hobbit yet?
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information. There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
-- 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
On Friday 02 November 2007 17:07:28 Tod Hansmann wrote:
For posterity:
We use mrtg to do all our SNMP polling (I know devmon is the popular solution hear, but it's messy and so multi-filed so we have a bad taste for it)
Would you like to expand on what's wrong with devmon? The problem I have with mrtg/cacti etc. is that they *only* do trends, which is half the job. I have got interface graphs (as well as temperature for Dell and HP servers) working, and there is very little that our cacti installation is doing that I still need to have available on devmon.
Regards, Buchan
Hello Tod,
Since you've stopped using the script, would you be willing to share it for posterity sake?
Joe
Tod Hansmann wrote:
For posterity:
We use mrtg to do all our SNMP polling (I know devmon is the popular solution hear, but it’s messy and so multi-filed so we have a bad taste for it) and for traps we have a script we stopped using recently, but it was setup much like Henrik stated. It was just added to hobbit-alerts.cfg and life was good.
*Tod Hansmann*
Network Engineer
[http://www.directpointe.com/] <http://www.directpointe.com/>
*From:* Josh Luthman [mailto:josh at imaginenetworksllc.com] *Sent:* Friday, November 02, 2007 8:48 AM *To:* hobbit at hswn.dk *Subject:* Re: [hobbit] big brother replacement
I believe there is a workaround for it using something else. I know you can find it in the mailing list archives - it has been asked and discussed many times.
I read that Henrik has SNMP planned for a later release, too, though I don't believe that is confirmed.
Josh
On 11/2/07, *PAUL WILLIAMSON* <pwilliamson at mtb.com <mailto:pwilliamson at mtb.com>> wrote:
The biggest problem I have with going to Hobbit is there is no snmp trap sending support. We don't use BB as our main interface for showing all alerts, but it is required and we do send snmp traps from the BBPAGER to our main dashboard of alerts. Is this functionality in Hobbit yet?
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information. There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission.
-- 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
Sorry, no can do. It's long gone. I didn't set it up but I'm pretty sure we just got it off of deadcat (though I just did a couple searches and found nothing like what we were using).
Probably wouldn't be hard to write a new one for someone who knows snmp "syntax" well enough. Just pass the hobbit message to the server receiving traps, and you're golden.
It wasn't exactly helpful for us when we use the emails and the display page as the key modes of contact for alarms in our environment.
Tod Hansmann Network Engineer
-----Original Message----- From: Sloan [mailto:joe at tmsusa.com] Sent: Friday, November 02, 2007 11:21 AM To: hobbit at hswn.dk Subject: Re: [hobbit] big brother replacement
Hello Tod,
Since you've stopped using the script, would you be willing to share it for posterity sake?
Joe
Tod Hansmann wrote:
For posterity:
We use mrtg to do all our SNMP polling (I know devmon is the popular solution hear, but it's messy and so multi-filed so we have a bad taste for it) and for traps we have a script we stopped using recently, but it was setup much like Henrik stated. It was just added to hobbit-alerts.cfg and life was good.
*Tod Hansmann*
Network Engineer
[http://www.directpointe.com/] <http://www.directpointe.com/>
*From:* Josh Luthman [mailto:josh at imaginenetworksllc.com] *Sent:* Friday, November 02, 2007 8:48 AM *To:* hobbit at hswn.dk *Subject:* Re: [hobbit] big brother replacement
I believe there is a workaround for it using something else. I know you can find it in the mailing list archives - it has been asked and discussed many times.
I read that Henrik has SNMP planned for a later release, too, though I don't believe that is confirmed.
Josh
On 11/2/07, *PAUL WILLIAMSON* <pwilliamson at mtb.com <mailto:pwilliamson at mtb.com>> wrote:
The biggest problem I have with going to Hobbit is there is no snmp trap sending support. We don't use BB as our main interface for showing all alerts, but it is required and we do send snmp traps from the BBPAGER to our main dashboard of alerts. Is this functionality in Hobbit yet?
This email may contain privileged and/or confidential information that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information. There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this
transmission.
-- 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
Paul,
Drop me a private email and I will tell you what I am doing for my "main dashboard of alerts."
GLH
From: PAUL WILLIAMSON [mailto:pwilliamson at mtb.com]
Sent: Friday, November 02, 2007 7:31 AM
To: hobbit at hswn.dk
Subject: RE: [hobbit] big brother replacement
The biggest problem I have with going to Hobbit is there is nosnmp trap sending support. We don't use BB as our main interface for showing all alerts, but it is required and we do send snmp traps from the BBPAGER to our main dashboard of alerts. Is this functionality in Hobbit yet?
************************************
This email may contain privileged and/or confidentialinformation that is intended solely for the use of the addressee. If you are not the intended recipient or entity, you are strictly prohibited from disclosing, copying, distributing or using any of the information contained in the transmission. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. This communication may contain nonpublic personal information about consumers subject to the restrictions of the Gramm-Leach-Bliley Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or disclose such information for any purpose other than to provide the services for which you are receiving the information. There are risks associated with the use of electronic transmission. The sender of this information does not control the method of transmittal or service providers and assumes no duty or obligation for the security, receipt, or third party interception of this transmission. ************************************
Deiss, Mark wrote:
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).
Interestingly enough, we've been running redundant bb servers for each lan, without any concern for race conditions and while that has it's own peculiar behavior in corner cases, we've never seen any sort of real, intractable problems with it. The general consensus here is that redundancy is good, except for the notifications - we don't want to be notified twice for every incident, thus the so-called bb "failover" capability saves us that annoyance with no extra hacks required.
I probably made it sound a lot more sophisticated than it really is - we really just have active/active BBNET/BBDISPLAY servers, with the delegation of BBPAGER decided by the failover status.
It looks like Henrik has a good roadmap to get there in 4.3 from what I read here, so hopefully we've got our bb replacement at last. The only other concern is that we copy all bb notifications as snmp traps to netcool, but it looks as though that should be with a hobbit plugin.
Joe
Joe,
Do you have any support to any extent with BB? The main reason I switched was that there was a mailing list to look to for support. Secondly, it wasn't BB.
Josh
On 11/2/07, Sloan <joe at tmsusa.com> wrote:
Deiss, Mark wrote:
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).
Interestingly enough, we've been running redundant bb servers for each lan, without any concern for race conditions and while that has it's own peculiar behavior in corner cases, we've never seen any sort of real, intractable problems with it. The general consensus here is that redundancy is good, except for the notifications - we don't want to be notified twice for every incident, thus the so-called bb "failover" capability saves us that annoyance with no extra hacks required.
I probably made it sound a lot more sophisticated than it really is - we really just have active/active BBNET/BBDISPLAY servers, with the delegation of BBPAGER decided by the failover status.
It looks like Henrik has a good roadmap to get there in 4.3 from what I read here, so hopefully we've got our bb replacement at last. The only other concern is that we copy all bb notifications as snmp traps to netcool, but it looks as though that should be with a hobbit plugin.
Joe
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- 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
We have no official bb support, just google, and the experience of local sys admins. But it's been here so long that infrastructure has grown up around it, which really drives the need for a drop-in replacement.
Joe
Josh Luthman wrote:
Joe,
Do you have any support to any extent with BB? The main reason I switched was that there was a mailing list to look to for support. Secondly, it wasn't BB.
Josh
On 11/2/07, *Sloan* <joe at tmsusa.com <mailto:joe at tmsusa.com>> wrote:
Deiss, Mark wrote: > > 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). > Interestingly enough, we've been running redundant bb servers for each lan, without any concern for race conditions and while that has it's own peculiar behavior in corner cases, we've never seen any sort of real, intractable problems with it. The general consensus here is that redundancy is good, except for the notifications - we don't want to be notified twice for every incident, thus the so-called bb "failover" capability saves us that annoyance with no extra hacks required. I probably made it sound a lot more sophisticated than it really is - we really just have active/active BBNET/BBDISPLAY servers, with the delegation of BBPAGER decided by the failover status. It looks like Henrik has a good roadmap to get there in 4.3 from what I read here, so hopefully we've got our bb replacement at last. The only other concern is that we copy all bb notifications as snmp traps to netcool, but it looks as though that should be with a hobbit plugin. Joe To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk <mailto:hobbit-unsubscribe at hswn.dk>-- 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
I really like this mailing list - you learn quite a bit even just by reading the questions of others. I'm the only system administrator around here so I need a shoulder to lean on every once and a while!
Are you saying you've used BB so much that you know it too well and need a replacement? Sounds kind of backwards to me =P
On 11/2/07, joe <joe at tmsusa.com> wrote:
We have no official bb support, just google, and the experience of local sys admins. But it's been here so long that infrastructure has grown up around it, which really drives the need for a drop-in replacement.
Joe
Josh Luthman wrote:
- we
Joe,
Do you have any support to any extent with BB? The main reason I switched was that there was a mailing list to look to for support. Secondly, it wasn't BB.
Josh
On 11/2/07, *Sloan* <joe at tmsusa.com <mailto:joe at tmsusa.com>> wrote:
Deiss, Mark wrote: > > For a vanilla BB environment, you can have multiple BBDISPLAYentities > 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). >
Interestingly enough, we've been running redundant bb servers foreach lan, without any concern for race conditions and while that has it's own peculiar behavior in corner cases, we've never seen any sort of real, intractable problems with it. The general consensus here is that redundancy is good, except for the notifications - we don't want to be notified twice for every incident, thus the so-called bb "failover" capability saves us that annoyance with no extra hacks required.
I probably made it sound a lot more sophisticated than it really isreally just have active/active BBNET/BBDISPLAY servers, with the delegation of BBPAGER decided by the failover status. It looks like Henrik has a good roadmap to get there in 4.3 fromwhat I
read here, so hopefully we've got our bb replacement at last. Theonly
other concern is that we copy all bb notifications as snmp traps to netcool, but it looks as though that should be with a hobbit plugin. Joe To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk <mailto:hobbit-unsubscribe at hswn.dk>-- 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
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- 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
Josh Luthman wrote:
I really like this mailing list - you learn quite a bit even just by reading the questions of others. I'm the only system administrator around here so I need a shoulder to lean on every once and a while!
Are you saying you've used BB so much that you know it too well and need a replacement? Sounds kind of backwards to me =P
Haha, what I mean is, big brother is showing it's age, and getting harder to support as time goes by, simply by virtue of the fact that the code is slowly rotting. But we can't just make a clean sweep - so much now depends on the way big brother behaves, that the replacement needs to be able to act identically to big brother.
Joe
Joe,
I see what you're saying now. In your case Hobbit is an absolute perfect match! Hopefully we can all enjoy seeing your questions and see you answering some of ours =)
Josh
On 11/5/07, Sloan <joe at tmsusa.com> wrote:
Josh Luthman wrote:
I really like this mailing list - you learn quite a bit even just by reading the questions of others. I'm the only system administrator around here so I need a shoulder to lean on every once and a while!
Are you saying you've used BB so much that you know it too well and need a replacement? Sounds kind of backwards to me =P
Haha, what I mean is, big brother is showing it's age, and getting harder to support as time goes by, simply by virtue of the fact that the code is slowly rotting. But we can't just make a clean sweep - so much now depends on the way big brother behaves, that the replacement needs to be able to act identically to big brother.
Joe
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
-- 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
On 11/5/07, Sloan <joe at tmsusa.com> wrote:
Haha, what I mean is, big brother is showing it's age, and getting harder to support as time goes by, simply by virtue of the fact that the code is slowly rotting. But we can't just make a clean sweep - so much now depends on the way big brother behaves, that the replacement needs to be able to act identically to big brother.
In your original email you said:
"only one of the bb servers does reporting, as determined by the failover state"
Does that mean only one of the two sends out notifications?? If so, why not just have two identical Hobbit servers, with all the clients sending reports to both, and disable the [bbpage] section in server/etc/hobbitlaunch.cfg on the backup system. Then your failover solution only has to detect "death of twin" and rewrite the hobbitlaunch.cfg with DISABLED removed from that section. I guess Hobbit might need to be reloaded or restarted for the change to take effect.
I haven't tried this - we don't use the paging system - I'm just wondering if something as simple as that might work.
Ralph Mitchell
Ralph Mitchell wrote:
In your original email you said:
"only one of the bb servers does reporting, as determined by the failover state"
Does that mean only one of the two sends out notifications?? If so, why not just have two identical Hobbit servers, with all the clients sending reports to both, and disable the [bbpage] section in server/etc/hobbitlaunch.cfg on the backup system. Then your failover solution only has to detect "death of twin" and rewrite the hobbitlaunch.cfg with DISABLED removed from that section. I guess Hobbit might need to be reloaded or restarted for the change to take effect.
I haven't tried this - we don't use the paging system - I'm just wondering if something as simple as that might work.
Yes, that approach has merit, it could work.
However I still need to give Henrik's quick solution from last week some testing - I'm currently building a hobbit infrastructure so I can see how his failover script behaves under pressure.
Joe
participants (9)
-
bgmilne＠staff.telkomsa.net
-
greg.hubbard＠eds.com
-
henrik＠hswn.dk
-
joe＠tmsusa.com
-
josh＠imaginenetworksllc.com
-
Mark.Deiss＠acs-inc.com
-
pwilliamson＠mtb.com
-
ralphmitchell＠gmail.com
-
thansmann＠directpointe.com