[hobbit] CPAN Modules

[W.J.M. Nelis]

david.peters at industry.nsw.gov.au wrote:
>
> 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.
Indeed, and that is what we are doing too. The nett result is that the 
configuration is as complete and as correct as the database is and that 
the configuration stays consistent.

> 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).
True. As our database does not contain all the required information to 
regenerate bb-hosts completely, I consider bb-hosts to be a database too 
(see http://xymonton.trantor.org/doku.php/addons:xymonconfigsync). This 
means that changes in the tests of a host (yes, using vi) will survive 
if a new version of bb-hosts is generated.

> 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.
It is almost the same here. I do edit bb-hosts occasionally, but it has 
been changed this year about 700 times by a script. A benefit can be 
described as "power to the administrator": if an administrator modifies 
information about the equipment or services, it will be reflected in 
xymon within half an hour.

Given this situation, the benefits you mention are already realized, at 
least for a major part. That makes it a bit difficult to make a sort of 
business case for yet another database and yet another GUI to maintain.

> 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.
Ahh, an application is not sexy enough if there is no Db frontend...

>
> "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.
*******************************************************************************************************