I'm the.. erm.. 'maintainer' of Nagat
I have found some time to again work on it and currently I'm completely
rewriting it. I'm sticking to the interface though.
Just for you knowledge:
- Nagat is not using any web interface like the Nagios CGI one
- I'm importing data and save it to another file (currently as
serialized data, but plugins should be made for mysql and stuff)
- Making the config actual means exporting (overwriting) the current
Nagios config
- restarting and stopping Nagios goes via the command stuff of nagios
- yup, Nagat needs to run on the Nagios machine for now
Don't know about merging and stuff, but I think it's good to have two
WebInterfaces. People have then a choice and it will only make our
beasts stronger
Best regards,
Geert
On Tue, 2003-06-03 at 16:30, Jesús M. NAVARRO wrote:
> Hi, John:
>
> El Martes, 3 de Junio de 2003 15:35, John Arley Burns escribió:
> > --- Jesús M. NAVARRO wrote:
> > > Hi, John:
>
> [...]
>
> > >
> > > The "view config" option is merely a wrapper around the config.cgi
> > > CGI, since
> > > that was my very first idea: if I can just drop in a few PHP classes
> > > so I
> > > have the same functionality current Nagios ui has, then I can go at
> > > my own
> > > pace adding functionality or rewriting CGIs as I feel I can, and
> > > still using
> > > the byproduct on a day by day basis.
> >
> > There is a PHP program that allows editing of config files named
> > "NAGAT", available on the "Extras" download page off the main Nagios
> > site. Perhaps you could merge this into your own.
> >
>
> I'll take a look at it.
>
> > I'm currently working on getting debian packaging working for Nagios,
> > the current debian package has some problems. I'll release it to
> > debian when it's ready.
> >
>
> I'm a Debian user, and I know Debian packages todate are outdated and with
> more than one rough corner, so that news are welcome.
> I'd consider having more than one package: core engine, plugins, gui and
> extras should be different packages, if you want my opinion.
>
> > The main piece I'll eventually contribute is probably in the monitoring
> > area. NSCA is a good start for a basic system but I need something
> > that's far more secure and works over HTTPS. I'm currently not sure if
> > extending NSCA is better or developing an entirely new add-on agent.
> > That's probably going to be my major contribution to Nagios.
> >
>
> Well, I see two things I think Nagios can do better than now (I'm trying to
> make a positive criticism here, so plase take it that way):
> 1/ The NCSA issue: it can go through ssh or https (I see this can be easier to
> manage through a firewall). The conectivity issue is part one, and the
> connection load is the other one: rigth now if I want ten remote probes at a
> box I have to start ten encripted connections (and this is a clear overload).
> Probably your two issues would be properly managed with a serialization
> protocol (say XML) so the server can ask through any given port for all
> remote probes at a box, and recieve them all on a single piece. Something
> like...
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> (...)
>
> (...)
>
>
>
> This way one conection (and one connection negotiation) makes all, and you
> immediately know if all data was transfer or not.
>
> 2/ Alarm handling is top offer for that kind of tool, but trends
> presentation/analisis is second one: I'd want to see a tool like a merge
> between Nagios and Cacti (going to the "paradigms", I'd say BigBrother+MRTG).
>
> 3/ (Ok, I lied) I'd want to see Nagios more concentrated about the collecting
> engine (daemon, scheduling queue, active/passive checks) and a clean
> interface both to plugins and UI, so I could use it as a fundation for my
> "Control Center" -alarms, trends
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]