<br><font size=2 face="sans-serif">The problem or tangible benefits are
to provide an easier way of handling hosts, laying them out in pages by
</font>
<br><font size=2 face="sans-serif">categories such as location, application
etc. This becomes a real issue when the number of hosts is large.</font>
<br>
<br><font size=2 face="sans-serif">The other benefit I see is that it makes
hobbit look a lot more professional and enterprise ready if multiple users</font>
<br><font size=2 face="sans-serif">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</font>
<br><font size=2 face="sans-serif">other locations such as an asset database,
it is usually easier to write a database to database interface. (I am now
ducking in order </font>
<br><font size=2 face="sans-serif">to avoid the incoming flames).</font>
<br>
<br><font size=2 face="sans-serif">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 </font>
<br><font size=2 face="sans-serif">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 </font>
<br><font size=2 face="sans-serif">on the bbhosts file and the other side
which require the hobbit admins to have to type everything.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">We never ever touch the bbhosts file
now.</font>
<br>
<br><font size=2 face="sans-serif">We do of course have the benefit of
a development hobbit system which allows for easy development of code etc.</font>
<br>
<br><font size=2 face="sans-serif">I think maybe a seperate project outside
of hobbit is the way to go here. Just create a db application and interface
to hobbit</font>
<br><font size=2 face="sans-serif">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</font>
<br><font size=2 face="sans-serif">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</font>
<br><font size=2 face="sans-serif">of the IT Director because he calls
it a toy cmpared to apps with db frontends.</font>
<br>
<br><tt><font size=2>"W.J.M. Nelis" <nelis@nlr.nl> wrote
on 10/06/2010 06:19:43 PM:<br>
<br>
> [image removed] </font></tt>
<br><tt><font size=2>> <br>
> Re: [hobbit] CPAN Modules</font></tt>
<br><tt><font size=2>> <br>
> W.J.M. Nelis </font></tt>
<br><tt><font size=2>> <br>
> to:</font></tt>
<br><tt><font size=2>> <br>
> hobbit@hswn.dk</font></tt>
<br><tt><font size=2>> <br>
> 10/06/2010 06:24 PM</font></tt>
<br><tt><font size=2>> <br>
> Please respond to hobbit</font></tt>
<br><tt><font size=2>> <br>
> Buchan Milne wrote:<br>
> > On Wednesday, 9 June 2010 00:24:27 david.peters@industry.nsw.gov.au
wrote:<br>
> >   <br>
> >> BTW we still use a database to store all information about
our servers and<br>
> >> routers and then use this to generate the bbhosts and include
files. This<br>
> >> includes<br>
> >> a screen under INFO for a host that provides this information
within<br>
> >> hobbit. <br>
> >>     <br>
> ><br>
> > Well, in devmon, I have some work in my local checkout which
populates some <br>
> > discover-related information into a database (e.g., cdp neighbours,
IPs, <br>
> > routes).<br>
> ><br>
> >   <br>
> >> Allows us to do advanced searching based on other parameters,<br>
> >> using an advanced search<br>
> >> web screen within hobbit.<br>
> >><br>
> >> Last time I spoke of the database there seemed to be very
little interest<br>
> >> in it so it has stayed where it is and hasn't been used anywhere
else.<br>
> >>     <br>
> ><br>
> > I think having a database is useful. I think there was resistance
to having <br>
> > all the monitoring depend on a database.<br>
> >   <br>
> I think that at quite a few sites a database is used to generate the
<br>
> xymon configuration files, thus using a database for monitoring purposes
<br>
> is perhaps not an such a big issue. In my case, the use of an additional
<br>
> database for monitoring only is not feasible.  There is a database,
used <br>
> by many applications, maintained by a lot of people, which I should
use <br>
> for the monitoring application as well. There must be some real benefits
<br>
> in order to justify the (partial)  duplication of information
and the <br>
> additional maintenance efforts.<br>
> <br>
> Regards,<br>
>   Wim Nelis.<br>
> <br>
> <br>
> <br>
> *******************************************************************************************************<br>
> The NLR disclaimer (</font></tt><a href=http://www.nlr.nl/emaildisclaimer><tt><font size=2>http://www.nlr.nl/emaildisclaimer</font></tt></a><tt><font size=2>)
is valid for <br>
> NLR e-mail messages.<br>
> *******************************************************************************************************<br>
> <br>
> <br>
> To unsubscribe from the hobbit list, send an e-mail to<br>
> hobbit-unsubscribe@hswn.dk<br>
> <br>
> <br>
</font></tt>
<p style="font-family:Arial;font-size:9px;font-style:normal;font-weight:normal;text-decoration:none;text-transform:none;color:000000;"><br><br>
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.<br><br>
</p>