a word against web interfaces

[Ian Holsman]

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