[hobbit] CPAN Modules

[david.peters at industry.nsw.gov.au]

The problem or tangible benefits are to provide an easier way of handling 
hosts, laying them out in pages by 
categories such as location, application etc. This becomes a real issue 
when the number of hosts is large.

The other benefit I see is that it makes hobbit look a lot more 
professional and enterprise ready if multiple users
can change / add / remove hosts without having to rely on an admin with vi 
to modify the files. Even if the data is coming from
other locations such as an asset database, it is usually easier to write a 
database to database interface. (I am now ducking in order 
to avoid the incoming flames).

We have 20 or more IT staff who add servers and it is all done through the 
database interface. Commits to hobbit from the database 
are made only when one of 3 people go into the database application and 
verify the changes. This is a trade off between many hands 
on the bbhosts file and the other side which require the hobbit admins to 
have to type everything.

I found that even when we had two or three people editing the bbhosts, 
that I couldn't trust that someone wouldn;t screw the file up.

We never ever touch the bbhosts file now.

We do of course have the benefit of a development hobbit system which 
allows for easy development of code etc.

I think maybe a seperate project outside of hobbit is the way to go here. 
Just create a db application and interface to hobbit
and then people can choose to use it or not. I just know that I am being 
continually harassed by the helpdesk manager because in his
view the helpdesk application can do all of this (which I know is not 
true). It is just easy for him at the moment to run down hobbit in front
of the IT Director because he calls it a toy cmpared to apps with db 
frontends.

"W.J.M. Nelis" <nelis at nlr.nl> wrote on 10/06/2010 06:19:43 PM:

> [image removed] 
> 
> Re: [hobbit] CPAN Modules
> 
> W.J.M. Nelis 
> 
> to:
> 
> hobbit at hswn.dk
> 
> 10/06/2010 06:24 PM
> 
> Please respond to hobbit
> 
> Buchan Milne wrote:
> > On Wednesday, 9 June 2010 00:24:27 david.peters at industry.nsw.gov.au 
wrote:
> > 
> >> BTW we still use a database to store all information about our 
servers and
> >> routers and then use this to generate the bbhosts and include files. 
This
> >> includes
> >> a screen under INFO for a host that provides this information within
> >> hobbit. 
> >> 
> >
> > Well, in devmon, I have some work in my local checkout which populates 
some 
> > discover-related information into a database (e.g., cdp neighbours, 
IPs, 
> > routes).
> >
> > 
> >> Allows us to do advanced searching based on other parameters,
> >> using an advanced search
> >> web screen within hobbit.
> >>
> >> Last time I spoke of the database there seemed to be very little 
interest
> >> in it so it has stayed where it is and hasn't been used anywhere 
else.
> >> 
> >
> > I think having a database is useful. I think there was resistance to 
having 
> > all the monitoring depend on a database.
> > 
> I think that at quite a few sites a database is used to generate the 
> xymon configuration files, thus using a database for monitoring purposes 

> is perhaps not an such a big issue. In my case, the use of an additional 

> database for monitoring only is not feasible.  There is a database, used 

> by many applications, maintained by a lot of people, which I should use 
> for the monitoring application as well. There must be some real benefits 

> in order to justify the (partial)  duplication of information and the 
> additional maintenance efforts.
> 
> Regards,
>   Wim Nelis.
> 
> 
> 
> 
*******************************************************************************************************
> The NLR disclaimer (http://www.nlr.nl/emaildisclaimer) is valid for 
> NLR e-mail messages.
> 
*******************************************************************************************************
> 
> 
> To unsubscribe from the hobbit list, send an e-mail to
> hobbit-unsubscribe at hswn.dk
> 
> 

This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of their organisation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20100611/bdac75a6/attachment.html>