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
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
> > pr
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]