[hobbit] Hobbit Communication Protocol

[Henrik Stoerner]

On Thu, Jan 26, 2006 at 11:26:27AM -0700, Charles Jones wrote:
> 
> I was thinking of writing a perl implementation of a mail-ack gateway 
> for Hobbit. I know bb-mailack.sh exists, but it has to be modified to 
> work with hobbit, and I would also like to have the ability to not only 
> ack an alert but to enable/disable hosts via email as well.

There *is* a "hobbit-mailack" tool included with Hobbit, which provides
the ability to acknowledge alerts. It doesn't do enable/disable, though.

> That being said, I also would like to have my script totally self 
> contained, and not rely on any external binaries or having to source 
> external shell environments.  So I was wondering if you had documented 
> anywhere the protocol hobbit uses to communicate - in other words, what 
> I need to do to emulate "./bb hobbitserver hobbitcommand".

The syntax of the commands you can send to Hobbit is documented in the
bb(1) man-page. Most of them, at least - looking over it, I see that the
acknowledge syntax is missing. I'll get that fixed, but beware - the
acknowledge syntax is undergoing some changes currently, since the
current protocol (which is compatible with the older Big Brother
protocol) has some deficiencies.

It's a fairly simple text-based TCP protocol. The hobbitd daemon listens
on TCP port 1984, so your Perl code must make a TCP connection to that
port. Once connected, you send text messages in the format described by
the bb(1) man-page. E.g. to disable the "conn" test for the host 
"router1.foo.com" for 60 minutes, you would send

disable router1,foo,com.conn 60 Hardware problem

> Speaking of this, I think it would be helpful if when a service is in 
> alert status, that there was an easy way to ack the alert from the web 
> page *without knowing what the alert ID is*. Something like an 
> "acknowledge *this* alert" (w/ same password protection as admin area) 
> button right smack next to the history button :-)  People that I am 
> teaching to use hobbit have commented that they find it inefficient to 
> have to go through their email to find the last alert ID for a service, 
> and cut and paste it into hobbit to ack an alert.

I tend to agree. The current implementation was made to be compatible
with the Big Brother way of acknowledging alerts (not quite, though,
because Hobbit ack ID's are not per-status/per-user, only per-status).

You *can* build the functionality you describe. You could easily write
a script that is invoked from the status view and passed the hostname
and columnname; then you could query hobbitd to get the ack ID and
generate an acknowledge without the user knowing about what the ID was.
To get the ack ID for host "foo.bar.com" column "ftp" send this to
hobbitd:
   "hobbitdlog foo.bar.com.ftp fields=cookie"
and you get the ack ID as a number on the first line of the response.
E.g. my current test system responds:

$ bb 127.0.0.1 "hobbitdlog voodoo.hswn.dk.ftp fields=cookie"
204493
red <!-- [flags:ordaStLe] --> Thu Jan 26 22:04:48 2006 ftp NOT ok

Service ftp on voodoo.hswn.dk is not OK : Service unavailable
(Connection refused)


Seconds: 0.00

The ack ID for this test is "204493".


But again, the acknowledgment function is currently being changed so
if you plan on implementing something now, contact me off-list and I'll
give you some more info about how the new system will be. 


Regards,
Henrik