nagios-devel — Developers List

Re: [Nagios-devel] Nagios Core 3.5.0rc1

[eponymous a. <epo...@ya...>]

This issue is presumably of no great consequence, but it ought
to be fixed along the way.  I found it today while looking for
something else.

Between Nagios 3.3.0 and 3.3.1, certain lines got dropped from
base/checks.c, that made calls to delete_check_result_file().
However, there was also an accompanying log message that claims
the check result file is deleted, and that log message was not
also removed.  That message is now line 205 in base/checks.c
in the 3.5.0rc1 release.  It should now be removed, as all
check result file deletion now appears be done only from within
base/utils.c code.  So if there is still a need for such a
message, it should be moved closer to where the file is
actually deleted.  If not, the message can simply go away.

--- On Thu, 2/28/13, Eric Stanley <est...@na...> wrote:

> From: Eric Stanley <est...@na...>
> Subject: [Nagios-devel] Nagios Core 3.5.0rc1
> To: "Nagios Developers List" <nag...@li...>
> Date: Thursday, February 28, 2013, 3:59 AM
> Sorry for multiple release
> candidates, but I fixed two more issues with the CGIs that
> are very closely related to issues fixed in the 3.4.5rc1
> tarball.
> 
> The release has also been bumped to 3.5.0 because of an ABI
> change. (It should have been bumped prior to 3.4.5rc1.) The
> downtime structure had a member added to help resolve the
> downtime notification problem. This means that modules will
> need to be recompiled to use this version.
> 
> You can download the 3.5.0rc1 tarball from http://sourceforge.net/projects/nagios/files/nagios-3.x/nagios-3.5.0/nagios-3.5.0rc1.tar.gz/download.
> 
> Feel free to compile it and try it (on a test system,
> please). The 3.4.5 candidate did not generate much feedback
> and I'm hoping no news is good news. The changes between
> 3.4.5rc1 and 3.5.0rc1 are relatively minor, so I don't plan
> to wait long until releasing 3.5.0.
> 
> The complete changelog since 3.4.4 is as follows:
> 
> * Fixed bug #403: The "configuration" page of the webui
> doesn't use entity encoding when displaying the "command
> expansion" item (Eric Stanley)
> * Fixed bug #424: Nagios Core 3.4.4 seg fault (core dump) on
> restart after removing config for running service (Eric
> Stanley)
> * Updated CGI utility functions to support UTF-8 characters
> (Eric Stanley)
> * Fixed bug where selecting Command Expansion from
> Configuration CGI page would display commands instead (Eric
> Stanley)
> * Fixed bug #369: status.cgi crashes with segfault when
> there are german ulauts (äöüß) in the hostname or the
> servicename (Eric Stanley)
> * Fixed bug #418: Scheduled Downtime Notifications Resent On
> Nagios Restart/reload (Eric Stanley)
>   
> 
> -- 
> Eric Stanley
> ___
> Developer
> Nagios Enterprises, LLC
> Email:  est...@na...
> Web:    www.nagios.com
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
> 

Re: [Nagios-devel] [Nagios-users] Questions about Nagios quick search

[Daniel W. <dan...@st...>]

I've been building/using CentOS/RHEL RPM's if you're interested in those let me know.

Dan


On Mar 1, 2013, at 5:25 PM, Andreas Ericsson wrote:

> On 03/01/2013 03:32 PM, Deborah Martin wrote:
>> Folks,
>> Is Nagios 4.0 available for download from somewhere for testing and if so where ?
>> 
> 
> svn trunk and at least two github repositories for now. I really
> should check if I can upload files to sourceforge and tick off a
> nagios-4-beta1 release tarball though. I've got a feeling it's
> about time.
> 
> -- 
> Andreas Ericsson                   and...@op...
> OP5 AB                             www.op5.se
> Tel: +46 8-230225                  Fax: +46 8-230231
> 
> Considering the successes of the wars on alcohol, poverty, drugs and
> terror, I think we should give some serious thought to declaring war
> on peace.
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel

Re: [Nagios-devel] Nagios Core 3.5.0rc1

[Paul D. <wo...@pa...>]

eponymous alias wrote:
> I have two simple requests for the 3.5.0 release.
>
...
> * I would much prefer that the tarball unroll into a directory
>    named with the release level, such as nagios-3.5.0rc1/ or
>    nagios-3.5.0/ (for the final release), instead of a plain
>    nagios/ directory.  This makes it a lot easier to deal with
>    multiple releases unrolled in parallel, which we often want
>    in order to compare versions.  This convention used to be
>    followed in older releases, at least through the nagios-3.2.3
>    release.  Yes, of course, I can rename the directory myself,
>    but this convention is a lot cleaner (and followed by many if
>    not most other projects).
>

FWIW, the dtrx tool can do this for you.
http://brettcsmith.org/2007/dtrx/

Re: [Nagios-devel] [Nagios-users] Questions about Nagios quick search

[Andreas E. <ae...@op...>]

On 03/01/2013 03:32 PM, Deborah Martin wrote:
> Folks,
> Is Nagios 4.0 available for download from somewhere for testing and if so where ?
> 

svn trunk and at least two github repositories for now. I really
should check if I can upload files to sourceforge and tick off a
nagios-4-beta1 release tarball though. I've got a feeling it's
about time.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] Nagios Core 3.5.0rc1

[Andreas E. <ae...@op...>]

On 02/28/2013 10:58 PM, Paul Dubuc wrote:
> Eric Stanley wrote:
>> Sorry for multiple release candidates, but I fixed two more issues with the
>> CGIs that are very closely related to issues fixed in the 3.4.5rc1
>> tarball.
>>
>> The release has also been bumped to 3.5.0 because of an ABI change. (It
>> should have been bumped prior to 3.4.5rc1.) The downtime structure had a
>> member added to help resolve the downtime notification problem. This means
>> that modules will need to be recompiled to use this version.
> 
> Does this mean that modules would have to be recompiled for 3.4.4?
> I've been using that with current versions of npcdmod (for PNP4Nagios 0.6.19)
> and livestatus 1.2.0p3.  They seem to be working fine with 3.4.4.
> 

Only if they add or remove downtime. npcdmod won't be affected.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] External Command Ideas

[Andreas E. <ae...@op...>]

On 02/28/2013 10:40 AM, Jochen Bern wrote:
> Hello everyone,
> 
> in a current project, I have a need to override Nagios' check scheduling
> on specific occasions (*). Hence, I'm looking at what I can or (relevant
> point here) cannot do with external commands, as documented for 3.x.
> Since there's a new major version upcoming, I thought I might toss a
> couple thoughts this list's way, just in case you're taking suggestions ...
> 
> -- I can CHANGE_NORMAL_SVC_CHECK_INTERVAL to have a service checked
>     as often as interval_length and/or the scheduler permits, but I
>     cannot tell Nagios to return to whatever the config files had set
>     initially.
> -- I can SCHEDULE_* (or SCHEDULE_FORCED_*) single services or all
>     services of a host, but not the members of a service group.
>     (I guess that filtering for services in a non-OK state only is
>     really a job for livestatus or the like, not Nagios.)
> -- I cannot touch a service's ATTEMPT counter ~= SOFT/HARD distinction,
>     to possibly have Nagios' scheduler go through the retry_interval
>     routine for me, unless I PROCESS_SERVICE_CHECK_RESULT an
>     all-out-fake OK state.
>     (I guess that incrementing via CHANGE_MAX_SVC_CHECK_ATTEMPTS *might*
>     have the side effect of returning the service to SOFT non-OK, but
>     again, there's no "return to config file value" available.)
> 
> (*) Basically, I want all SLA relevant services that are still non-OK at
> the end of the standard maintenance window to be rechecked so that the
> non-OK state doesn't check_interval into the SLA relevant time more than
> necessary. Note that I intend to use avail.cgi to produce reports on SLA
> fulfilment, so I'll have to define a matching service group, anyway.
> FWIW, it's a 3.4.4 installed from repos.
> 

Write an eventbroker module. It's not so hard, and since you're only
filling a very specific need with one or more very specific times you
shouldn't run into many problems. Object iteration is done more or
less the same in Nagios 4 as it's done in Nagios 3 btw, so you won't
run into huge issues if/when you decide to migrate.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] [Nagios-users] Questions about Nagios quick search

[Deborah M. <Deb...@ko...>]

Folks, 
Is Nagios 4.0 available for download from somewhere for testing and if so where ? 

Thanks,
Deborah 
-----Original Message-----
From: Andreas Ericsson [mailto:ae...@op...] 
Sent: 01 March 2013 08:05
To: Nagios Users List
Subject: Re: [Nagios-users] Questions about Nagios quick search

On 02/28/2013 10:49 PM, Jonas Meurer wrote:
> Am 20.02.2013 16:13, schrieb Jonas Meurer:
>> Hello,
> 
> Hey again,
> 
>> we're using Nagios as monitoring system for several hundred systems.
>> While navigating through hosts and services, recently two questions 
>> regarding the quick search (in navigation bar) raised:
>>
>> 1/ Why doesn't nagios search for host aliases as well? Is it possible 
>> to enable alias searching? We're using rather short values for 
>> host_name, and tend to add information like server position to the 
>> alias. Thus searching for host_name and alias would be awesome for us.
>>

Today it's not possible to enable alias searching. Patches welcome.
If you create one, please use some format that makes it possible to add searching on other fields as well, such as "alias~<regex>" or some such.

>> 2/ When searching for IP addresses, only the first match is returned.
>> In some cases (e.g. NRPE Port forwarding through firewall), several 
>> hosts have the same IP address. For these cases it's rather 
>> irritating, that only the first matching host is returned.
>>

Tru dat. Patches welcome. You'll want to find and remove the correct "break" statement, I guess. Other than that it shouldn't be much trouble.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Nagios-users mailing list
Nag...@li...
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null


This e-mail and any files transmitted with it are strictly confidential and intended solely for the use of the individual or entity to whom they are addressed.  If you are not the intended recipient, please delete this e-mail immediately.  Any unauthorised distribution or copying is strictly prohibited.

Whilst Kognitio endeavours to prevent the transmission of viruses via e-mail, we cannot guarantee that any e-mail or attachment is free from computer viruses and you are strongly advised to undertake your own anti-virus precautions. Kognitio grants no warranties regarding performance, use or quality of any e-mail or attachment and undertakes no liability for loss or damage, howsoever caused.

Re: [Nagios-devel] Nagios Core 3.5.0rc1

[Paul D. <wo...@pa...>]

Eric Stanley wrote:
> Sorry for multiple release candidates, but I fixed two more issues with the
> CGIs that are very closely related to issues fixed in the 3.4.5rc1
> tarball.
>
> The release has also been bumped to 3.5.0 because of an ABI change. (It
> should have been bumped prior to 3.4.5rc1.) The downtime structure had a
> member added to help resolve the downtime notification problem. This means
> that modules will need to be recompiled to use this version.

Does this mean that modules would have to be recompiled for 3.4.4?
I've been using that with current versions of npcdmod (for PNP4Nagios 0.6.19) 
and livestatus 1.2.0p3.  They seem to be working fine with 3.4.4.

Re: [Nagios-devel] Event handlers functionality reapplied to Nagios 4

[Andreas E. <ae...@op...>]

On 02/25/2013 04:31 PM, Ton Voon wrote:
> Andreas,
> 
> We've noticed that the event handlers do not currently work in Nagios
> 4 trunk. It seems that there is a FIXME message where the worker part
> was not implemented.
> 

I just tested this, and event handlers work properly here. Granted, my
test only involves running a command that writes a few lines to a file,
so it finishes quickly and never fails.

In what way do you consider them broken?

> We've now implemented this, so I think this is now working as
> expected.
> 
> Please find the patch below, nagios_4_support_event_handlers.patch.
> This applies on top of the envvar support we added for Nagios 4
> (subject "Fix default value for enable_environment_macros") which is
> reattached as nagios_macro_environents_in_command_definition.patch.
> 
> Are there any other things that are not implemented yet that you
> would like some assistance with?
> 

Downtime and comment handling needs a complete rewrite to avoid O(xn)
removal time. A doubly linked list would do the trick. We can add a
fan-out table later. Note that you'll have to do clever tricks with
a container_of() macro to get a doubly linked list without breaking
the ABI though. Using the fact that the first entry of a struct
always has the same address as the struct should do the trick.

The query-handler could use a macro-substitution service.

The existing nerd-channels should take a format-string to replace
macros and whatnot before shipping the data to its subscriber. It
should also print neater output by default.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

[Nagios-devel] External Command Ideas

[Jochen B. <Joc...@LI...>]

Hello everyone,

in a current project, I have a need to override Nagios' check scheduling
on specific occasions (*). Hence, I'm looking at what I can or (relevant
point here) cannot do with external commands, as documented for 3.x.
Since there's a new major version upcoming, I thought I might toss a
couple thoughts this list's way, just in case you're taking suggestions ...

-- I can CHANGE_NORMAL_SVC_CHECK_INTERVAL to have a service checked
   as often as interval_length and/or the scheduler permits, but I
   cannot tell Nagios to return to whatever the config files had set
   initially.
-- I can SCHEDULE_* (or SCHEDULE_FORCED_*) single services or all
   services of a host, but not the members of a service group.
   (I guess that filtering for services in a non-OK state only is
   really a job for livestatus or the like, not Nagios.)
-- I cannot touch a service's ATTEMPT counter ~= SOFT/HARD distinction,
   to possibly have Nagios' scheduler go through the retry_interval
   routine for me, unless I PROCESS_SERVICE_CHECK_RESULT an
   all-out-fake OK state.
   (I guess that incrementing via CHANGE_MAX_SVC_CHECK_ATTEMPTS *might*
   have the side effect of returning the service to SOFT non-OK, but
   again, there's no "return to config file value" available.)

(*) Basically, I want all SLA relevant services that are still non-OK at
the end of the standard maintenance window to be rechecked so that the
non-OK state doesn't check_interval into the SLA relevant time more than
necessary. Note that I intend to use avail.cgi to produce reports on SLA
fulfilment, so I'll have to define a matching service group, anyway.
FWIW, it's a 3.4.4 installed from repos.

Kind regards,
								J. Bern
-- 
*NEU* - NEC IT-Infrastruktur-Produkte im <http://www.linworks-shop.de/>:
Server--Storage--Virtualisierung--Management SW--Passion for Performance
Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel

Re: [Nagios-devel] Nagios Core 3.5.0rc1

[eponymous a. <epo...@ya...>]

I have two simple requests for the 3.5.0 release.

* Since the Nagios developers adopted some tool-enforced coding
  standards a few releases ago, those tools should be run before
  every new release, to bring all recent changes up to the
  claimed standards.  In the nagios-3.5.0rc1.tar.gz release,
  running the indent-all.sh script yields 77 files Unchanged
  (which is what we want), but 20 files Formatted (out of spec
  with regard to the coding standards).  Please run this before
  issuing the final 3.5.0 release.

* I would much prefer that the tarball unroll into a directory
  named with the release level, such as nagios-3.5.0rc1/ or
  nagios-3.5.0/ (for the final release), instead of a plain
  nagios/ directory.  This makes it a lot easier to deal with
  multiple releases unrolled in parallel, which we often want
  in order to compare versions.  This convention used to be
  followed in older releases, at least through the nagios-3.2.3
  release.  Yes, of course, I can rename the directory myself,
  but this convention is a lot cleaner (and followed by many if
  not most other projects).

--- On Thu, 2/28/13, Eric Stanley <est...@na...> wrote:

> From: Eric Stanley <est...@na...>
> Subject: [Nagios-devel] Nagios Core 3.5.0rc1
> To: "Nagios Developers List" <nag...@li...>
> Date: Thursday, February 28, 2013, 3:59 AM
> Sorry for multiple release
> candidates, but I fixed two more issues with the CGIs that
> are very closely related to issues fixed in the 3.4.5rc1
> tarball.
> 
> The release has also been bumped to 3.5.0 because of an ABI
> change. (It should have been bumped prior to 3.4.5rc1.) The
> downtime structure had a member added to help resolve the
> downtime notification problem. This means that modules will
> need to be recompiled to use this version.
> 
> You can download the 3.5.0rc1 tarball from http://sourceforge.net/projects/nagios/files/nagios-3.x/nagios-3.5.0/nagios-3.5.0rc1.tar.gz/download.
> 
> Feel free to compile it and try it (on a test system,
> please). The 3.4.5 candidate did not generate much feedback
> and I'm hoping no news is good news. The changes between
> 3.4.5rc1 and 3.5.0rc1 are relatively minor, so I don't plan
> to wait long until releasing 3.5.0.
> 
> The complete changelog since 3.4.4 is as follows:
> 
> * Fixed bug #403: The "configuration" page of the webui
> doesn't use entity encoding when displaying the "command
> expansion" item (Eric Stanley)
> * Fixed bug #424: Nagios Core 3.4.4 seg fault (core dump) on
> restart after removing config for running service (Eric
> Stanley)
> * Updated CGI utility functions to support UTF-8 characters
> (Eric Stanley)
> * Fixed bug where selecting Command Expansion from
> Configuration CGI page would display commands instead (Eric
> Stanley)
> * Fixed bug #369: status.cgi crashes with segfault when
> there are german ulauts (äöüß) in the hostname or the
> servicename (Eric Stanley)
> * Fixed bug #418: Scheduled Downtime Notifications Resent On
> Nagios Restart/reload (Eric Stanley)
>   
> 
> -- 
> Eric Stanley
> ___
> Developer
> Nagios Enterprises, LLC
> Email:  est...@na...
> Web:    www.nagios.com
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
> 

[Nagios-devel] Nagios Core 3.5.0rc1

[Eric S. <est...@na...>]

Sorry for multiple release candidates, but I fixed two more issues with the CGIs that are very closely related to issues fixed in the 3.4.5rc1 tarball.

The release has also been bumped to 3.5.0 because of an ABI change. (It should have been bumped prior to 3.4.5rc1.) The downtime structure had a member added to help resolve the downtime notification problem. This means that modules will need to be recompiled to use this version.

You can download the 3.5.0rc1 tarball from http://sourceforge.net/projects/nagios/files/nagios-3.x/nagios-3.5.0/nagios-3.5.0rc1.tar.gz/download.

Feel free to compile it and try it (on a test system, please). The 3.4.5 candidate did not generate much feedback and I'm hoping no news is good news. The changes between 3.4.5rc1 and 3.5.0rc1 are relatively minor, so I don't plan to wait long until releasing 3.5.0.

The complete changelog since 3.4.4 is as follows:

* Fixed bug #403: The "configuration" page of the webui doesn't use entity encoding when displaying the "command expansion" item (Eric Stanley)
* Fixed bug #424: Nagios Core 3.4.4 seg fault (core dump) on restart after removing config for running service (Eric Stanley)
* Updated CGI utility functions to support UTF-8 characters (Eric Stanley)
* Fixed bug where selecting Command Expansion from Configuration CGI page would display commands instead (Eric Stanley)
* Fixed bug #369: status.cgi crashes with segfault when there are german ulauts (äöüß) in the hostname or the servicename (Eric Stanley)
* Fixed bug #418: Scheduled Downtime Notifications Resent On Nagios Restart/reload (Eric Stanley)
  

-- 
Eric Stanley
___
Developer
Nagios Enterprises, LLC
Email:  est...@na...
Web:    www.nagios.com

Re: [Nagios-devel] Nagios Core 3.4.5rc1

[Randal, P. <phi...@ho...>]

Thanks Andreas,

I was sure it worked differently in the past, but heck, old age is creeping up on me.

Cheers,

Phil



-----Original Message-----
From: Andreas Ericsson [mailto:ae...@op...]
Sent: 28 February 2013 05:58
To: Nagios Developers List
Cc: Randal, Phil
Subject: Re: [Nagios-devel] Nagios Core 3.4.5rc1

On 02/27/2013 06:14 PM, Randal, Phil wrote:
> Scheduled downtimes don't work as expected for me in this build.
>
> Box goes down (someone forgot to inform us of maintenance).
>
> Schedule flexible downtime after it's down and nagios refuses to accept that it's in a scheduled downtime window.
>

Flexible downtime only triggers when the host *enters* the down state. I'm pretty sure that's both documented and intended. If you want downtime that happens no matter what, you should add fixed downtime instead.

--
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace.
“Any opinion expressed in this e-mail or any attached files are those of the individual and not necessarily those of Hoople Ltd. You should be aware that Hoople Ltd. monitors its email service. This e-mail and any attached files are confidential and intended solely for the use of the addressee. This communication may contain material protected by law from being passed on. If you are not the intended recipient and have received this e-mail in error, you are advised that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. If you have received this e-mail in error please contact the sender immediately and destroy all copies of it.

Re: [Nagios-devel] Arguments to check commands

[Andreas E. <ae...@op...>]

On 02/27/2013 02:59 PM, Ton Voon wrote:
> Hi,
> 
> It seems like Nagios 4 has changed the way that check_command arguments are parsed. Overall, this looks like a good thing as I think it looks easier to understand as it seems to be much more similar to how the shell would evaluate a command. However, I'm worried about the migration of existing Nagios configurations.
> 
> For instance, this worked in Nagios 3:
> 
> ----
> define service {
>    ...
>    check_command           check_nrpe!-H $HOSTADDRESS$ -c CheckEventLog -a file=Application \"filter=generated gt -2d AND severity NOT IN ('success', 'informational')\" MaxWarn=1 MaxCrit=10
>   }
> 

That looks slightly insane, tbh, and it's one of those commands that should
trigger a command anomaly (CMD_HAS_PAREN), which we shouldn't handle in the
runcmd library but instead paw off to the shell the same way we did in
Nagios 3.

> define command {
>          command_name    check_nrpe
>          command_line    /usr/local/nagios/libexec/check_nrpe $ARG1$
>          }
> ----
> 
> In Nagios 4, this fails. To get the same result, you need to configure it as:
> ----
> define service {
>    ...
>    check_command           check_nrpe!-H $HOSTADDRESS$ -c CheckEventLog -a file=Application "filter=generated gt -2d AND severity NOT IN ('success', 'informational')" MaxWarn=1 MaxCrit=10
>   }

And that looks much more sane, as shell (and runcmd) can properly parse
both escaped and quoted parentheses without problem.

> ----
> 
> I can't quite understand the Nagios 3 rules versus the Nagios 4 rules
> or what the conversion process should be.

runcmd strives to be shell-compatible, but Nagios 4 should pass a
string to its worker that makes it parse that string so the result is
the same as what Nagios 3 would have gotten.

I just added a lot of tests to make it a whole lot easier to see
how the runcmd library parses arguments, so if you find anything that
doesn't work as per Nagios 3, you can add tests for it and I'll see
what can be done.

You may have to enable debug-logging to get to see processed_command
as it gets gets passed to runcmd though. If that's different from the
one passed for Nagios 3, we have a very fixable problem. If it's the
same, we're in standoff mode and shell.

A pretty simple workaround is to use single-quotes around arguments
you want to pass unmolested to the script or program you're running
though. shell and Nagios 3 has always handled those two alike.


> Is there anything that is going to be provided for Nagios 4 to ease
> migrating existing configurations?
> 

Most likely not. We haven't noticed anything like this with any of our
about 1000 running configurations, so it's unlikely to be so big a
problem that it warrants tool-assistance to fix.

What I could do is add a "wproc runcmd" thing for the query handler,
which would let one issue commands as processed, and perhaps with
some different macro settings so one can test various commands while
Nagios is running. That would make it trivial to see exactly what
Nagios gets back from a worker when a check has been run, which could
be nice as a debug tool. That's really the only way I can think of to
make Nagios' entire chain of command execution testable from command
line.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] Nagios Core 3.4.5rc1

[Andreas E. <ae...@op...>]

On 02/27/2013 06:14 PM, Randal, Phil wrote:
> Scheduled downtimes don't work as expected for me in this build.
> 
> Box goes down (someone forgot to inform us of maintenance).
> 
> Schedule flexible downtime after it's down and nagios refuses to accept that it's in a scheduled downtime window.
> 

Flexible downtime only triggers when the host *enters* the down
state. I'm pretty sure that's both documented and intended. If
you want downtime that happens no matter what, you should add
fixed downtime instead.

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] Nagios Core 3.4.5rc1

[Randal, P. <phi...@ho...>]

Scheduled downtimes don't work as expected for me in this build.

Box goes down (someone forgot to inform us of maintenance).

Schedule flexible downtime after it's down and nagios refuses to accept that it's in a scheduled downtime window.

Cheers,

Phil

-----Original Message-----
From: Eric Stanley [mailto:est...@na...]
Sent: 22 February 2013 21:42
To: Nagios Developers List
Subject: [Nagios-devel] Nagios Core 3.4.5rc1

I've created a tarball with a release candidate for Nagios Core 3.4.5.
The tarball can be downloaded from
http://sourceforge.net/projects/nagios/files/nagios-3.x/nagios-3.4.5/nagios-3.4.5rc1.tar.gz/download.

Feel free to compile it and try it (on a test system, please). If I don't hear of any serious issues by the middle of next week, I'll release it.

The change log is as follows:

* Fixed bug #424: Nagios Core 3.4.4 seg fault (core dump) on restart after removing config for running service (Eric Stanley)
* Updated CGI utility functions to support UTF-8 characters (Eric Stanley)
* Fixed bug where selecting Command Expansion from Configuration CGI page would display commands instead (Eric Stanley)
* Fixed bug #369: status.cgi crashes with segfault when there are german ulauts (äöüß) in the hostname or the servicename (Eric Stanley)
* Fixed bug #418: Scheduled Downtime Notifications Resent On Nagios Restart/reload (Eric Stanley)

--
Eric Stanley
___
Developer
Nagios Enterprises, LLC
Email:  est...@na...
Web:    www.nagios.com


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Nagios-devel mailing list
Nag...@li...
https://lists.sourceforge.net/lists/listinfo/nagios-devel
“Any opinion expressed in this e-mail or any attached files are those of the individual and not necessarily those of Hoople Ltd. You should be aware that Hoople Ltd. monitors its email service. This e-mail and any attached files are confidential and intended solely for the use of the addressee. This communication may contain material protected by law from being passed on. If you are not the intended recipient and have received this e-mail in error, you are advised that any use, dissemination, forwarding, printing or copying of this e-mail is strictly prohibited. If you have received this e-mail in error please contact the sender immediately and destroy all copies of it.

Re: [Nagios-devel] Arguments to check commands (including macros)

[<rou...@cs...>]

In message <512...@pa...>,
Paul Dubuc writes:
>William Leibzon wrote:
>> Don't use macros as arguments to commands at service definition. I
>> don't think this was ever documented in nagios 3 as being ok either
>> even if it worked....
>
>I sure hope this continues to work.  I think it allows us to write much 
>simpler command objects that can more easily be reused by different
>services. 
>
>Command definitions are often kept in a separate file.  It makes the
>service definition much more readable and maintainable if all the
>service specific args (including user defined macros which are
>defined in the service definition or a template used by it) are
>passed to the command in the service definition.

I have to agree. I have many commands defined with parameters that are
required for every service and I use macros to supply the value.

Specifying them in the command definition makes much more sense and is
less error prone IMO.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

Re: [Nagios-devel] Arguments to check commands (including macros)

[Paul D. <wo...@pa...>]

William Leibzon wrote:
> Don't use macros as arguments to commands at service definition. I
> don't think this was ever documented in nagios 3 as being ok either
> even if it worked....

I sure hope this continues to work.  I think it allows us to write much 
simpler command objects that can more easily be reused by different services. 
  Command definitions are often kept in a separate file.  It makes the service 
definition much more readable and maintainable if all the service specific 
args (including user defined macros which are defined in the service 
definition or a template used by it) are passed to the command in the service 
definition.

Re: [Nagios-devel] Arguments to check commands

[William L. <wi...@le...>]

Don't use macros as arguments to commands at service definition. I
don't think this was ever documented in nagios 3 as beinf ok either
even if it worked. So try to see if this works:

define command {
        command_name    check_nrpe
        command_line    /usr/local/nagios/libexec/check_nrpe -H
$HOSTADDRESS$ $ARG1$
        }

define service {
      ...
       check_command    check_nrpe!-c CheckEventLog -a
file=Application \"filter=generated gt -2d AND severity NOT IN
('success', 'informational')\" MaxWarn=1 MaxCrit=10
}

On Wed, Feb 27, 2013 at 5:59 AM, Ton Voon <ton...@op...> wrote:
> Hi,
>
> It seems like Nagios 4 has changed the way that check_command arguments are parsed. Overall, this looks like a good thing as I think it looks easier to understand as it seems to be much more similar to how the shell would evaluate a command. However, I'm worried about the migration of existing Nagios configurations.
>
> For instance, this worked in Nagios 3:
>
> ----
> define service {
>   ...
>   check_command           check_nrpe!-H $HOSTADDRESS$ -c CheckEventLog -a file=Application \"filter=generated gt -2d AND severity NOT IN ('success', 'informational')\" MaxWarn=1 MaxCrit=10
>  }
>
> define command {
>         command_name    check_nrpe
>         command_line    /usr/local/nagios/libexec/check_nrpe $ARG1$
>         }
> ----
>
> In Nagios 4, this fails. To get the same result, you need to configure it as:
> ----
> define service {
>   ...
>   check_command           check_nrpe!-H $HOSTADDRESS$ -c CheckEventLog -a file=Application "filter=generated gt -2d AND severity NOT IN ('success', 'informational')" MaxWarn=1 MaxCrit=10
>  }
> ----
>
> I can't quite understand the Nagios 3 rules versus the Nagios 4 rules or what the conversion process should be. Is there anything that is going to be provided for Nagios 4 to ease migrating existing configurations?
>
> Ton
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Nagios-devel mailing list
> Nag...@li...
> https://lists.sourceforge.net/lists/listinfo/nagios-devel

[Nagios-devel] [PATCH] for nagios 3.x to speed up send_nsca (in parallel)

[Sielski, W. <wsi...@te...>]

Hi there

We have one main Nagios server that receive plenty passive checks
from many satellites Nagios serveres - in each datacenter one.
We had a lot of Nagios performance issues in our very big environment
(more than 900 hosts, more than 13000 services).

Performance was connected with (forwarding) sending
passive check from satellite to master Nagios.
Script which is responsible for that is executed
 for each send passive check
./contrib/eventhandlers/distributed-monitoring/submit_check_result_via_nsca
and makes that other checks are queued till script finished.
-> overall it causes Nagios scheduled queue
was more than 30 minutes behind.


Trick is to use '&' and STDOUT to /dev/null
I know this is a workaround / proof of concept
(ideal solution would be to have 'send_nsca ­-b'
- run in background as an option)
but this workaround will help also for any previous Nagios version.


Here is a patch to make sending more parallel and makes Nagios realtime
again. I hope you like it:

---
./contrib/eventhandlers/distributed-monitoring/submit_check_result_via_nsca
    2008-11-30 18:22:59.000000000 +0100
+++ fix/submit_check_result_via_nsca    2013-02-20 16:28:48.497742097 +0100
@@ -32,8 +32,11 @@
NscaCfg="/usr/local/nagios/etc/send_nsca.cfg"
NagiosHost="nagioshost"
+Debug="/var/log/nagios3/send_via_naca.log"
+#Debug="/dev/null"
+
# Fire the data off to the NSCA daemon using the send_nsca script
-$printfcmd "%s\t%s\t%s\t%s\n" "$1" "$2" "$3" "$4" | $NscaBin -H
$NagiosHost -c $NscaCfg
+$printfcmd "%s\t%s\t%s\t%s\n" "$1" "$2" "$3" "$4" | $NscaBin -H
$NagiosHost -c $NscaCfg >> $Debug &
# EOF

----------------
Wojciech Sielski
Site Ops Engineer
mobile.international GmbH
www.mobile.de

[Nagios-devel] Arguments to check commands

[Ton V. <ton...@op...>]

Hi,

It seems like Nagios 4 has changed the way that check_command arguments are parsed. Overall, this looks like a good thing as I think it looks easier to understand as it seems to be much more similar to how the shell would evaluate a command. However, I'm worried about the migration of existing Nagios configurations.

For instance, this worked in Nagios 3:

----
define service {
  ...
  check_command           check_nrpe!-H $HOSTADDRESS$ -c CheckEventLog -a file=Application \"filter=generated gt -2d AND severity NOT IN ('success', 'informational')\" MaxWarn=1 MaxCrit=10
 }

define command {
        command_name    check_nrpe
        command_line    /usr/local/nagios/libexec/check_nrpe $ARG1$
        }
----

In Nagios 4, this fails. To get the same result, you need to configure it as:
----
define service {
  ...
  check_command           check_nrpe!-H $HOSTADDRESS$ -c CheckEventLog -a file=Application "filter=generated gt -2d AND severity NOT IN ('success', 'informational')" MaxWarn=1 MaxCrit=10
 }
----

I can't quite understand the Nagios 3 rules versus the Nagios 4 rules or what the conversion process should be. Is there anything that is going to be provided for Nagios 4 to ease migrating existing configurations?

Ton

Re: [Nagios-devel] Object structure change

[Andreas E. <ae...@op...>]

On 02/27/2013 03:14 AM, Eric Stanley wrote:
> On 2/26/13 5:05 AM, Andreas Ericsson wrote:
>> On 02/25/2013 07:11 PM, Ton Voon wrote:
>>> Hi,
>>>
>>> Looking through recent commits, I came across 2601, which is a port
>>> of 2600, to fix a downtime issue.
>>>
>>> There is a change to downtime.h to add a new attribute to the
>>> downtime object.
>>>
>>> Am I right in saying that this is a object structure change and thus
>>> will affect the binary compatibility of all broker modules? If so,
>>> this is a problem for Nagios 4 which is in a structure freeze before
>>> release, but more seriously it is a problem in the Nagios 3.4 branch
>>> which will silently break lots of broker modules.
>>>
>> It's an ABI incompatibility, so it requires a recompile of affected
>> modules. No modules use the modified function calls, so for that part
>> it doesn't matter in practical terms, although it's academically
>> horribly (which is to say; It only matters if you're interested in
>> intellectual masturbation). Nagios 3 with the patch should really be
>> released as 3.5 though. For Nagios 4 it's ok to make this change
>> (although I'm not very happy about it).
>>
>> On a side-note, the downtime handling needs to be rewritten more or
>> less completely. I've started it, but the old code has to remain in
>> place (as a shim, preferrably) until 5.0 to retain api compatibility.
>>
>> To clarify, here are the "rules" which we try to adhere to:
>> API change (requires major release):
>>    * remove things from structs
>>    * remove or modify existing functions
>>    * remove existing types
>>    * rename existing types without backwards compatibility hacks
>>     ("#define comment nagios_comment" is the compat hack)
>>
>> ABI change (requires minor release and module recompilation):
>>    * add stuff to structs
>>    * reorder structs
>>
>> API addendum (requires API minor-version extension marker):
>>    * add new types
>>    * add new API's
>>    * add functions to API's
>>
>> Shimming (requires nothing at all):
>>    * Add new API
>>    * Rewrite old API in ABI-compatible way to front the new API
>>    * Use new API in core code
>>
>> Normally, ABI change and API addendum go hand in hand when doing
>> optimizations, and sometimes when doing bugfixes.
>>
> My apologies. I did not realize the trunk was in a code freeze.

Well, it is and it isn't. 4.0 hasn't gone stable yet, so we could
still break everything if it's really necessary. It would be terribly
bad form to do so though, as the amount of testing required is pretty
huge with all the modules and things.

> I've
> been going through the bug list on tracker and fixing things in the core
> 3 code, most of which apply to the core 4 code as well. I will be
> careful until core 4 is released.
> 
> Thanks, too, for the "rules" reminder. I will be happy to make the next
> release 3.5.0 and will include an ABI change notice with the release notes.
> 

That would be great. Thanks :)

-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: [Nagios-devel] Object structure change

[Eric S. <est...@na...>]

On 2/26/13 5:05 AM, Andreas Ericsson wrote:
> On 02/25/2013 07:11 PM, Ton Voon wrote:
>> Hi,
>>
>> Looking through recent commits, I came across 2601, which is a port
>> of 2600, to fix a downtime issue.
>>
>> There is a change to downtime.h to add a new attribute to the
>> downtime object.
>>
>> Am I right in saying that this is a object structure change and thus
>> will affect the binary compatibility of all broker modules? If so,
>> this is a problem for Nagios 4 which is in a structure freeze before
>> release, but more seriously it is a problem in the Nagios 3.4 branch
>> which will silently break lots of broker modules.
>>
> It's an ABI incompatibility, so it requires a recompile of affected
> modules. No modules use the modified function calls, so for that part
> it doesn't matter in practical terms, although it's academically
> horribly (which is to say; It only matters if you're interested in
> intellectual masturbation). Nagios 3 with the patch should really be
> released as 3.5 though. For Nagios 4 it's ok to make this change
> (although I'm not very happy about it).
>
> On a side-note, the downtime handling needs to be rewritten more or
> less completely. I've started it, but the old code has to remain in
> place (as a shim, preferrably) until 5.0 to retain api compatibility.
>
> To clarify, here are the "rules" which we try to adhere to:
> API change (requires major release):
>   * remove things from structs
>   * remove or modify existing functions
>   * remove existing types
>   * rename existing types without backwards compatibility hacks
>    ("#define comment nagios_comment" is the compat hack)
>
> ABI change (requires minor release and module recompilation):
>   * add stuff to structs
>   * reorder structs
>
> API addendum (requires API minor-version extension marker):
>   * add new types
>   * add new API's
>   * add functions to API's
>
> Shimming (requires nothing at all):
>   * Add new API
>   * Rewrite old API in ABI-compatible way to front the new API
>   * Use new API in core code
>
> Normally, ABI change and API addendum go hand in hand when doing
> optimizations, and sometimes when doing bugfixes.
>
My apologies. I did not realize the trunk was in a code freeze. I've 
been going through the bug list on tracker and fixing things in the core 
3 code, most of which apply to the core 4 code as well. I will be 
careful until core 4 is released.

Thanks, too, for the "rules" reminder. I will be happy to make the next 
release 3.5.0 and will include an ABI change notice with the release notes.

-- 
Eric Stanley
___
Developer
Nagios Enterprises, LLC
Email:  est...@na...
Web:    www.nagios.com

Re: [Nagios-devel] Event handlers functionality reapplied to Nagios 4

[Ton V. <ton...@op...>]

On 26 Feb 2013, at 11:06, Andreas Ericsson wrote:

> On 02/25/2013 04:31 PM, Ton Voon wrote:
>> Andreas,
>> 
>> We've noticed that the event handlers do not currently work in Nagios
>> 4 trunk. It seems that there is a FIXME message where the worker part
>> was not implemented.
>> 
>> We've now implemented this, so I think this is now working as
>> expected.
>> 
> 
> The patch is incomplete. There will be no warnings if the eventhandler
> times out, which is what the FIXME comments refer to.

I think this is already implemented. In base/workers.c, there are error messages like: "Warning: Service event handler command '%s' timed out after %.2f seconds", which is how we knew there were errors initially.

Also, the wproc_run_service_job() calls in base/sehandlers.c:obsessive_compulsive_service_check_processor doesn't include any timeout code at that function level, so the pattern seems to be to implement warnings in base/workers.c.

However, I can see removal of the early_timeout would be valid as this is dead code. I will do that if that is the only thing stopping the patch from being accepted.

Ton

Re: [Nagios-devel] Event handlers functionality reapplied to Nagios 4

[Andreas E. <ae...@op...>]

On 02/25/2013 04:31 PM, Ton Voon wrote:
> Andreas,
> 
> We've noticed that the event handlers do not currently work in Nagios
> 4 trunk. It seems that there is a FIXME message where the worker part
> was not implemented.
> 
> We've now implemented this, so I think this is now working as
> expected.
> 

The patch is incomplete. There will be no warnings if the eventhandler
times out, which is what the FIXME comments refer to.

> Please find the patch below, nagios_4_support_event_handlers.patch.
> This applies on top of the envvar support we added for Nagios 4
> (subject "Fix default value for enable_environment_macros") which is
> reattached as nagios_macro_environents_in_command_definition.patch.
> 
> Are there any other things that are not implemented yet that you
> would like some assistance with?
> 
> Ton
> 
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics Download AppDynamics Lite
> for free today: http://p.sf.net/sfu/appdyn_d2d_feb
> 
> 
> 
> _______________________________________________ Nagios-devel mailing
> list Nag...@li... 
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
> 


-- 
Andreas Ericsson                   and...@op...
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.