RE: [hobbit] Xymon hosts database.

["David Peters" <davidp (at) electronf.com>]

What I have is a database front end, database and extraction script to
hobbit. The database was written from the viewpoint of storing data about
all the hosts that would end up in hobbit. It was always written to be our
hobbit data source and as such has that in mind.

The model is solid in terms of operations managing the data but provides
auditing and control.

The downside is that it is written in access because that is what the
manager wanted and I am but a lowly contractor. 

I am just a bit wary of trying to put too much into a configuration tool.

What I hate about hobbit and trying to sell it is that its host
configuration is pretty ordinary.

-----Original Message-----
From: Buchan Milne [mailto:bgmilne (at) staff.telkomsa.net] 
Sent: Wednesday, 1 July 2009 6:34 PM
To: hobbit (at) hswn.dk
Cc: T.J. Yang
Subject: Re: [hobbit] Xymon hosts database.

On Wednesday 01 July 2009 07:01:07 T.J. Yang wrote:
> ________________________________
>
> > To: hobbit (at) hswn.dk
> > From: david.peters (at) dpi.nsw.gov.au
> > Date: Wed, 1 Jul 2009 10:18:56 +1000
> > Subject: [hobbit] Xymon hosts database.
> >
> >
> >
> > I think I have posted this quite a while
> > ago but it is still on my mind.
>
> Not only in my mind. I got to deliver it in next few months.
>
> >We currently configure the hosts, pages
> > etc using a windows database and windows front end that I wrote quite
> > some time ago. I keep getting the urge to convert it to a linux database
> > and a web frontend. However I would not do this if there is no interest
> > in using it.
>
> My interest about Xymon and relational DB is mainly from asset inventory
> perspective. Xymon doing a decent jobs collecting system
> information(io/cpu/memory/disk). But what about a system's asset
> information ? where is rack position of this machine ? what is the serial
> number, owner, function ? and is it a owned orleased machnine ? Asset
> information like this are most likely kept in Excel files. Won't it be
> nature to tight these information together ? Xymon should be able to do
> both system and inventory monitoring.(ie, you got a red yellow alert if a
> machine's lease is expiring in 1 month).
>
>
> To achieve this goal, I plan to introduce a relational DB into my Xymon
> server system.
>
> Please see the details here,
>
http://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Developer_Guide#U
>sing_relational_DBs_with_Xymon_Server
>
> > The point is that you never touch the
> > bb-hosts file and all configuration of hosts and layouts is done via a
> > user interface.
> >
> >
> >
> > Is there any interest in this?
>
> Yes.
>
> > Is there anyone willing to help?
>
> Count me in.
> I am decent at perl programming and currently learning
> php/extjs/qWikiOffice.

IMHO you shouldn't be choosing solutions before you have requirements ....

While qwikioffice looks snazzy, one of my requirements is that a view must
be 
customised (possibly per-user), and a user *must* be able to get their
correct 
view without any interaction (no mouse clicking etc.), so that this display 
can be used e.g. on a video wall, where no one is able to click the mouse.
Any 
cycling of views etc. should be automated.

I have done some simple frame+js pages to do this with current hobbit (e.g.
to 
cycle one frame between weathermap view and main view).

>
> > If so I was going to convert to mysql
> > and either php or perl cgi. Any comments on this?
>
> perl cgi script works but it is really not eye-catching.
> I like to stay with perl but php community is so strong.
> Catalyst is perl's MVC solution but it is weak on "View" part.
> As long as your requirement doesn't need EXTJS then Catalyst a very good
> solution.

There are a number of AJAX libraries that people use with Catalyst, e.g. 
Prototype, Dojo, with some plugins allowing perl-ish calls in templates that

result in the correct javascript. In conjunction with View::JSON, everything

required is available ...

Maybe it's time to start collecting requirements and prototyping some stuff.
I 
think the first thing we need is a Model::Xymon .

Regards,
Buchan

To unsubscribe from the hobbit list, send an e-mail to
hobbit-unsubscribe (at) hswn.dk