On 6 Feb 2006, at 20:48, Steve Shipway wrote:
Ton Voon wrote:
On 3 Feb 2006, at 19:24, Tedman Eng wrote
Read/Write access to cmd.cgi can already be disabled using .htaccess
I tried that (setting a group in .htaccess and only certain
users into that group), and it worked, but I didn't like t
Ton Voon wrote:
> On 3 Feb 2006, at 19:24, Tedman Eng wrote
> > Read/Write access to cmd.cgi can already be disabled using .htaccess
>
> I tried that (setting a group in .htaccess and only certain
> users into that group), and it worked, but I didn't like the
> user experience
This is the same
Stanley Hopcroft wrote:
> Mr Shipways approach is too process the Nag logs periodically
> with private/in-house (AFAIK) code to extract the entries of
> interest and insert them as rows in a table(s).
>
> (Incidentally, this sounds very enterprising since the
> extraction code has to deal with
Dear Folks,
Firstly thanks to all that answered either on the list or privately.
I will now attempt to emulate a journalling file system by summarising
the responses.
1 Having Nagios availability in a DB is a good thing.
Doing so reduces the cost of reporting since there is are data
representat
PROTECTED]
Sent: Friday, February 03, 2006 6:19 AM
To: [EMAIL PROTECTED]
Cc: nagios-users@lists.sourceforge.net
Subject: Re: [Nagios-users] RE: Reporting and misc rave.
On 3 Feb 2006, at 00:59, Jim Pye wrote:
My wishlist for Nagios?
0) Two levels of access - readonly and manage - on a per co
Read/Write access to cmd.cgi can already be disabled using .htaccess
-Original Message-
From: Ton Voon [mailto:[EMAIL PROTECTED]
Sent: Friday, February 03, 2006 6:19 AM
To: [EMAIL PROTECTED]
Cc: nagios-users@lists.sourceforge.net
Subject: Re: [Nagios-users] RE: Reporting and misc rave
On 3 Feb 2006, at 00:59, Jim Pye wrote:My wishlist for Nagios? 0) Two levels of access - readonly and manage - on a per contact, per service level. Dont just give 'manage' access to everyone listed as a contact for that service. True. I did work on a customers site where the management wanted acce
All,
I have only been using Nagios for a week or two. Have a system
configured to monitor a five server network. I therefore have not used
all the features comprehensively but I do see some of the points Steve
mentions below as things I see missing - see my notes.
Note I am using v2.0rc2.
On Fri
In message <[EMAIL PROTECTED]>,
Stanley.Hopcroft writes:
>I am writing with mainly a rant about Graphing and Reporting.
>
>
OT -> on topic in this case IMHO 8-).
>1 About graphing with Nagios
>Why would one bother when
> 1.1 Cacti does such a good job
Well cacti does a good job but I hate the
> Main problem: Both systems have their own host/service
> configuration systems, so you'll end up duplicating all the
> data entry.
We get around this with a home-grown configuration system, which outputs not
just the Nagios configuration files, but also files for MRTG, updates a
mysql database
> I am writing with mainly a rant about Graphing and Reporting.
Oh yes, I have problems with these, also. Please feel free to rant away at
length.
> 1 About graphing with Nagios
> Why would one bother when
> 1.1 Cacti does such a good job
> 1.2 Nagios could check the Cacti RRDs with either
> From: [EMAIL PROTECTED]
>
> 1 About graphing with Nagios
>
> Why would one bother when
>
> 1.1 Cacti does such a good job
>
> 1.2 Nagios could check the Cacti RRDs with either
> check_rrd, or by an
> outboard (Cron scheduled) RRD poller that submits passive service
> check results
>
Dear Folks,
I am writing with mainly a rant about Graphing and Reporting.
1 About graphing with Nagios
Why would one bother when
1.1 Cacti does such a good job
1.2 Nagios could check the Cacti RRDs with either check_rrd, or by an
outboard (Cron scheduled) RRD poller that submits pass
13 matches
Mail list logo
