Xymon Mailing List Archive search

Some configuration questions

list Greg L Hubbard
Wed, 31 May 2006 11:40:21 -0500
Message-Id: <user-6c07a49086b9@xymon.invalid>

Regarding topology --

The fully-fleshed out route statement almost mirrors a "traceroute"
function.  The topology is really a multiway tree, rooted in the Hobbit
server itself (or rooted in each network test server, anyway).  To me,
multi-way means more than two branches from a node.  I believe multiway
trees can be described as a list of parent-child relationships.  The
challenges are many, especially if there are gaps in the path.  This has
always been part of the network management tool challenge.  And purists,
of course, will say that just because things are wired in a certain path
doesn't mean that traffic goes that way...

So I guess it depends on how much work you want to do in the software
versus in bb-hosts.

My hierarchy is pretty simple, so I can go through and make the changes
by hand to provide the explicit end-to-end path from the Hobbit server
to each host.

But down the road, it would be cool if the Hobbit server could process
the bb-hosts file and either a) automatically discover the path to each
host with traceroute, and use this to build the dependency tree, or b)
let the admin specify the parent for each host, and build up the levels
internally.  Each approach has warts and programming challenges.

But thanks for the clarification, and all the hard work.  It is hard for
one programmer to keep hundreds of people happy -- but you are doing a
great job!

GLH

-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] 
Sent: Tuesday, May 30, 2006 11:34 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Some configuration questions

On Tue, May 30, 2006 at 11:16:59AM -0500, Hubbard, Greg L wrote:
Hobbits:

Some general questions, based on 4.1...

A) Do you know if the keywords in bb-hosts are case sensitive?  I 
noticed that the documentation is very careful to match case in 
examples as well as the definitions -- but some keywords are in ALL 
CAPS and others are lower case.  One wonders why this is so...unless 
they are case-insensitive, and it is just a curiosity in
Hobbit-lore...

It's mostly historical, based on the Big Brother ancestry.

I don't have the full picture in my head, but in most cases it is not
case-sensitive. The "bbgen" and "bbtest-net" are slightly more picky,
for historical reasons - they still do some parsing of the bb-hosts file
by themselves. Specifically, I know the "depends" and "route"
tags are case-sensitive.

B) Regarding the "route" keyword?  Can these be chained, or does the 
whole path have to be specified for each item in the file?

Example:  hobbit server -- firewall -- router a -- router b -- host --
app

Can it be coded this way?

Firewall 	no route statement
Router A	route:firewall
Router B	route:router A
Host		route:router B

Or do I have to say this:

Router B	route:firewall,router A
Host		route:firewall,router A,router B
The latter one will definitely work. I am not sure if the first one
will; a quick glance at the code appears not to support these tree-like
dependencies.

It would be nice to feed a map of your network topology into Hobbit so
when some router breaks, it will automatically know what tests will go
red as a result. It's just a little difficult to implement, I think.
Especially how you would describe your network topology.

C) I have some custom tests that are run by the client on "Host" -- 
these messages (which go purple) don't seem to get suppressed if a 
node is unreachable because of something else.  Is there some way to 
code this to take advantage of the downstream suppression?
If you have a "conn" test for that host, they shouldn't go purple.
<checking the code> wait, that only works if the "conn" test is
red,yellow or blue - not clear, which is what the dependency checks make
it. Will fix.

BTW -- Henrik -- I have seen the downstream suppression stuff work -- 
awesome!  It is a lot more difficult to achieve this in my commercial 
tools.

Thanks,
Henrik