Yes, CIDR-style notation is accepted.
On 09/22/2010 08:47 AM, Assaf Flatto wrote:
Hello
Has anyone tried placing a range ip entry in the allowedhosts directive
of NRPE ?
Will putting 10.1.0.0/24 work ?
If not ,does anyone know if is it something that is planned to future
versions of
Honestly, your best solution may actually be to install a new machine
that is running an OS new enough to run the latest version of Nagios.
Keeping old hardware and old OS'es running may be a requirement for
specific software systems, but there is no technical reason you have to
run Nagios on
You will have to write your script in a way that it is able to parse the
date fields in that output and calculate the difference between that
time and the current time..
Is it possible to have that program output UNIX timestamps instead? If
not, it will require you to get creative with awk,
Issues like this is just one of the reasons why we had to abstract out
all notifications from Nagios to an external script. We have servers in
a number of different locations, different platform groupings,
escalation tiers, etc., as well as notifications sent by Jabber. They
had to do to
Basic HTTP authentication is what you would use if you were password
protecting a web page using an .htaccess file. Since Facebook does not
use basic HTTP authentication, Facebook is ignoring the login and
password you are sending it and is just displaying the standard login
page (in this
Additionally, Nagios is really sensitive about how the Perl script is
written. It should be written well-enough to run with use strict
without any errors. (I see that it is commented out of both of your
scripts.) Additionally, the embedded Perl interpreter causes the scripts
to be run in what
I don't use localhost in any host or service configs. There is no use
for localhost, since it is such an ambiguous hostname. In a
distributed setup where there are multiple sources feeding data into a
single server, *every* host name must be unique, otherwise they clobber
each other's data (as
That would be considered a standard distributed Nagios setup. We do that
in our Nagios cluster.
We have a number of remote Nagios collectors in different locations.
They all forward their service check results back to a central
monitoring server. That server doesn't actually run any host or
On 08/05/2010 04:16 PM, Linus Gasser wrote:
Le 05.08.10 18:38, Herb J. a écrit :
That would be considered a standard distributed Nagios setup. We do that
in our Nagios cluster.
We have a number of remote Nagios collectors in different locations.
They all forward their service check
Nagios won't do that. If I recall correctly, when the host check fails,
it refuses to generate any further service notifications for that host
until the host check succeeds again. It also won't generate service
recovery notifications when those services actually come back online either.
Our
Unless you wish to somehow modify the source code to ignore certain
hosts (a very risky proposition unless you are good at C), I'd recommend
against trying to limit the number of hosts that NDO puts in the
database. Also, having that many services in NDO shouldn't be an issue
with the hardware
For that size of a deployment you will definitely want to use dedicated
hardware.
Also, with 300,000 services the standard nagios web interface could end
up being quite slow. Our deployment has just over 21,000 services
(multiple remote collectors feeding data back into a primary collector,
You may wish to periodically off-load the historical data to a second
database and clean up the primary one periodically. Having a smaller
database would help immensely when NDO periodically truncates old data.
Also, make sure that you have the proper database table indexes created.
Also
13 matches
Mail list logo
