a word against web interfaces

[local.coder]

<Me speaking as Ethan Again>

I hate speaking in Ethan's words but this is pretty clear cut and easy for me.

Ethan has committed that Nagios 2.+ is text based config files as far as nagios
goes. There will not be a nagios built in database back end.

In 1.2 he migrated some db code in for extinfo and other stuff and it started
turning into a code/support nightmare for him and took time away from the core
nagios.

As of later versions all DB related code is removed from nagios and will not be
there no matter how hard you look for it. All DB functions will have to be
completed through an External module that uses the nagios common API, or a
completely seperate process that exports happy nagios cfg files and hups the
process.

The DB functionality will only come from those who want it/need it and are
willing to write/contribute to it on it's own. The same as the nagios plugins
are today.

In my own view I need a DB backend but I agree it needs to be seperate. It
sounds like we may have the talent around to make that happen and I hope it
does. Frankly as long as Ethan doesn't turn the config files into some XML
based setup I think I will be happy.

Derrick

Quoting Ian Holsman <kryton at gmail.com>:

> I didn't think announcing a new GUI interface would have brought such
> polar views out.
>
> the reason I created a DB backend/GUI was:
>
> we have 5-10 people who want to add monitors to different things,
> without the gui, they would bug me about it.. now they don't. This is
> what I like the most.
>
> The gui has pages in there to do complex things. The trick is to make
> the things you do often into a web-page, and automate it.. (have a
> look at the application pages for examples of this)
> Cut & Paste is just asking for problems in a fast changing environment.
>
> We have batch jobs which integrate certain tables (like hosts &
> hostgroups) from other places in our environment. So when we add a new
> machine to the web server pool, or take a machine out of rotation I
> don't have to touch the config, again less work for me.. We have new
> machines being added every day. To do this with a text file would have
> been much harder.
>
> As for PHB's screwing things up.. let them, just make sure they know
> (politely) that they did. A simple bounce shell script, which does a
> config check before it restarts and bails if the config is invalid
> will stop most mischef..
> and if you hook that up with a CVS checkin/audit trail which points
> the finger squarely at them they'll stop and think after a couple of
> times, otherwise.. find a job where you can be appreciated!
>
> The only problem I have with a db-based config is the lack of version
> control, but that can be addressed easily.
>
> but again.. let me remind the people on the list, that a DB-based
> config is optional. while some people might not see the need, and will
> not use it, respect the wishes of the people who want it.
>
>
> ps.. given a choice between giving a PHB ssh access and a web-based
> form I choose web-based anyday!
>
> --Ian
>
>
> On Thu, 17 Jun 2004 09:33:11 -0500, jeff vier
> <jeff.vier at tradingtechnologies.com> wrote:
> >
> > On Thu, 2004-06-17 at 10:26 +0100, Ben Clewett wrote:
> > > > web configuration is obviously evil.
> > > Why 'obviously'?  Web configuration is ideally suited to alterations:
> > > - Easy to use.
> >
> > I beg to differ.  I found them to all be a major PITA if I tried to do
> > anything at all elaborate/complex.
> >
> > > - Can be used where ftp/telnet access is not possible.
> >
> > If you're letting web traffic in, why wouldn't you let SSH traffic in?
> > I, for one, would never let a critical box (like my Nagios servers) have
> > external incoming web access (and, for that matter, *direct* ssh
> > access).
> >
> > > - Does not require a restart to nagios.
> >
> > What?  Of course it does.  Slapping some random web interface on it
> > doesn't change its internal functionality.
> >
> > > - Does not require in depth training about format/layout.
> > > - On-screen help ensures a flatter learning curve.
> >
> > As much as Nagios isn't simple, it's not rocket science, either.  And
> > once you have a few hosts set up, it's quite easy to copy off of
> > existing entries.  If THAT is too rough for the person trying to make
> > changes/additions, perhaps you should reconsider allowing them to alter
> > a mission-critical service.
> >
> > > - Can make use of CGI controls like CHECKBOX and SELECT to ensure less
> > > chance of error.
> >
> > Not sure why you're labeling them as "CGI controls" when they're just
> > basic HTML elements, nonetheless I don't think I've ever run into this
> > where I felt like if I had a GUI on the front end of the configuration
> > process it would have been avoided.  If I skipped something, it's
> > because I didn't know the person requesting the addition had intended me
> > to watch the thing that I skipped.  I would have skipped it either way,
> > and they still would have looked at the Nagios screen and said "Hey,
> > could you turn on XXX, too?"
> >
> > > - A good security model using HTML authentication.
> >
> > More secure than...what?  FTP and telnet from the outside?  yes.  SSH,
> > no way.
> >
> > > I cannot see web configuration as 'obviously' evil, and I would be very
> > > interested to know why you feel this way.
> > >
> > > I believe this is a huge gain for nagios and will ensure greater
> > > acceptance and far less support requests, as well as a far more
> > > professional feel to the program.  These are my of course my personal
> > > views only. :)
> >
> > There are third-party packages that deal with this already, and *I*
> > appreciate that they're not included by default, else I might have the
> > PHBs a) forcing me to use them or b) trying to make changes themselves
> > (*shudder*).
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> > _______________________________________________
> > Nagios-devel mailing list
> > Nagios-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nagios-devel
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND