Hi, John:
El Martes, 3 de Junio de 2003 15:35, John Arley Burns escribi=F3:
> --- Jes=FAs 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=
=20
more than one rough corner, so that news are welcome.
I'd consider having more than one package: core engine, plugins, gui and=20
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=
=20
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=20
manage through a firewall). The conectivity issue is part one, and the=20
connection load is the other one: rigth now if I want ten remote probes at =
a=20
box I have to start ten encripted connections (and this is a clear overload=
). =20
Probably your two issues would be properly managed with a serialization=20
protocol (say XML) so the server can ask through any given port for all=20
remote probes at a box, and recieve them all on a single piece. Something=
=20
like...
(...)
(...)
This way one conection (and one connection negotiation) makes all, and you=
=20
immediately know if all data was transfer or not.
2/ Alarm handling is top offer for that kind of tool, but trends=20
presentation/analisis is second one: I'd want to see a tool like a merge=20
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 collecti=
ng=20
engine (daemon, scheduling queue, active/passive checks) and a clean=20
interface both to plugins and UI, so I could use it as a fundation for my=20
"Control Center" -alarms, trends, file integrity, remote intrusion probes..=
=2E=20
nagios+cacti+snort+samhain+...
Well... my two cents.
=2D-=20
SALUD,
Jes=FAs
***
[email protected]
***
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]