s mixed
arch configuration so have no idea how stable it ultimately is.
Duncs
--
Duncan Ferguson
Senior Developer
-- next part --
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 749 bytes
Desc: not available
Url :
http://lists.opsview.org/lur
Hi all,
We recently upgraded to Opsview 3.1.0, which was seamless. Everything
worked fine following the upgrade.
For some reason, I am now unable to access anything under
http://server/admin so I am unable to administer the system. I have 3
contacts that are ³admin² and each one is showing th
I'd be happy to contribute anonymous audit data of this sort if it would be
useful.
Craig
On 6/23/09 5:44 AM, "James Peel" wrote:
>
>
> Thanks for your comments James.
>
>> Why not set up a facility to anonymously audit the configuration and
>> scale of Opsview installations and (electively
Hello,
I unchedked "Resend Notifications" for some of our passive services,
then caused a passive service not to get results for one of our hosts.
After 4 hours, we didn't see an unknown status or get an alert for that
service (which is what we are looking for).
What am I missing about
Thanks for your comments James.
> Why not set up a facility to anonymously audit the configuration and
> scale of Opsview installations and (electively, opt-in) upload this
> information to you to load in a database somewhere so that you can
> see what facilities are being used, what monit
Hi,
thanks for the reaction. I 've checked the php module. It is loaded.
When i want to select a map, i cannot select automap and overview.
Automap generate the index.php error.
Overview show just following ï>>
I can access the url nagvis/nagvis/index.php?map=opsview
Erwin
Op vrijdag 19
On 23 Jun 2009, at 09:47, Quintin Vorster wrote: Nope, this is actually the master server that I'm checking.Amending the nrpe.cfg on the master will only affect the agent on the master - you need to amend the nrpe.cfg on the server you are trying to monitor and restart the daemon there. Duncs --
On 23 Jun 2009, at 09:06, Karsten Müller wrote:
So I decided to install the opsview-perl-3.1.0.180-1.ct5.x86_64.rpm
and for now everything seems to be fine;)
Glad to hear it - you should note that the perl libraries are sent
down the the slaves too - primarily for access to Nagios::Plugin -
ris CPU Menu
> CRITICAL
> 19h 12m 43s
> 2009-06-23 08:03:423/3NRPE: Command 'check_cpu_solaris' not defined
Can you post the nrpe.cfg file from the agent? Just blank out any
passwords or other config changes (if you made any)
Duncs
--
Duncan Ferguson
Senior Developer
-
On 23 Jun 2009, at 07:10, Quintin Vorster wrote:
Ok, I have added the 2 checks in nrpe.cfg and restarted the agent,
but I'm still getting the same errors:
this is the nrpe.cfg file on the server being monitored, not the
master server? Just checking...
Solaris CPU
Hi Duncs,
> perl -e 'print join " ",@INC'
I got /usr/local/nagios/perl/lib/x86_64-linux-thread-multi, which
seems to be a relict from an earlier install of 64bit packages. I
deleted it and reinstalled the opsview-perl 32bit package. Its i386-
linux-thread-multi directory is not used by /usr/
Hi,
after an upgrade from 3.0.5 to 3.1.0 everything seems to be running
except the webinterface. We have this funny situation where we use
32bit packages on a 64 bit OS to support
# service opsview-web start
Starting opsview-web: Goto undefined subroutine &Moose::import at usr
local/nagios/p
12 matches
Mail list logo
