[hobbit] Current development plans
I would really like to have the option of a client on the unix world.
Having a central machine poll all of the clients constantly a far less
distributed system than running remote clients. I prefer a locally run
client from an NFS mounted area were I can centrally control each with
the config files.
I agree, on the snmp situation, BB/Hobbits strengths are in scripts and ext's snmp should be an ext to Hobbit.
My only concern about changing the BB protocols would be to make it optional and not to make adding EXT scripts more difficult.
-----Original Message----- From: Daniel J McDonald [mailto:dan.mcdonald at austinenergy.com] Sent: Thursday, June 09, 2005 8:18 AM To: Hobbit List Subject: Re: [hobbit] Current development plans
On Thu, 2005-06-09 at 15:58 +1000, Adam Goryachev wrote:
On Thu, 2005-06-09 at 07:41 +0200, Henrik Stoerner wrote:
Personally, I'd most like to see a 'free' client (ie, GPL, without the BB license issue),
Ditto, but I'd really like the bb-central approach. Most of the status information can be grabbed from non-privileged accounts on all unix-like platforms. I concede that a client is necessary in the windows world.
and I'd also like to see *much* better SNMP support. ie, point it at a router, and it will automatically (or some tool) setup the various values to monitor (interfaces, byte counter thresholds, cpu, temperature, etc) or a switch, or firewall, or UPS, or whatever thingamabob you have lying around.
Although I'd love to see a "better mrtg", I'd hate to re-invent the wheel on that one. It would be nice if the mrtg folks would add snmp-v3, but that's not in the offing today.
But I have a set of cfgmaker templates that I use to do pretty much what you are asking. It's got a few complex scripts wrapped around it. By policy every device has a unique snmp string, so I have a huge database with hostnames, community strings, and device-types that allows me to generate my mrtg and hobbit configurations on the fly.
Finally, what about some sort of compression/encryption protocol,
If we are building an extended protocol, we should support authentication as well. That's been a serious hole in bb for a long time - any hacker who sees that you are trusting bb for monitoring can simply send spoofed status messages to either distract you from the real mischief or hide it from obvious view.
-- Daniel J McDonald, CCIE # 2495, CNX Austin Energy
dan.mcdonald at austinenergy.com
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Thu, 2005-06-09 at 08:26 -0400, Deal, Richard wrote:
I would really like to have the option of a client on the unix world.
Having a central machine poll all of the clients constantly a far less distributed system than running remote clients. I prefer a locally run client from an NFS mounted area were I can centrally control each with the config files.
This can work if all your machines are the same architecture and library versions etc, but it soon falls apart. Also you are relying on your network + NFS for the monitoring system to actually work, which isn't a good presumtion.
For little extra work, you can simply push out the config files/etc via some ssh/scripting....
I agree, on the snmp situation, BB/Hobbits strengths are in scripts and ext's snmp should be an ext to Hobbit.
Well, why couldn't this be core to hobbit, just as http network tests, or fping etc... You need a fairly complex/flexible config file to be able to specify enough SNMP values to monitor, and which values are good/ok/bad, etc, but I wouldn't see the need for writing multiple scripts for each and every snmp device you want to monitor like we have at the moment (apc UPS/cisco routers/etc...)
My only concern about changing the BB protocols would be to make it optional and not to make adding EXT scripts more difficult.
Actually, thinking about this for a few seconds, it should only require changes to the bb (client exe file) and bbd (server exe file) and all other scripts would stay the same. bbd would have some config variable which says either ignore un-encrypted msgs, accept both, or accept only un-encrypted. Then the client would be configured for either send encrypted/send plain. Finally, the server would 'detect' wether the client is sending encrypted message or plain text, and if encrypted, would decrypt it, and pass it to itself as per normal for processing (or discard it if it is invalid/not permitted).
One drawback I see in the BB protocol is that there is no client/server method to see any 'version' of each other, so they can't negotiate these things very well.
Just my 0.02c worth
Regards, Adam
participants (2)
-
adam＠websitemanagers.com.au
-
rdeal＠tigr.org