[Nagios-users] regexp match problem

[Andreas Unterkircher]

Andreas Ericsson (ae at op5.se) schrieb:
>
> Andreas Unterkircher wrote:
> > Hello!
> >
> > I'm experiencing a problem with regular expression match in service check
> > definitions. Nagios version is 2.04b. In nagios.cfg I enabled regexp:
> >
> > use_regexp_matching=1
> > use_true_regexp_matching=0
> >
> > As far as I understand (documentation), because I disabled the true regexp
> > matching, regexp match would only occur if I use wildcard characters (*,?).
> >
> > Now I have two hosts with the names:
> > *) LNX_SRVAPPNET
> > *) LNX_SRVAPPNET02
> >
> > defined like the following:
> >
> > # 'LNX_SRVAPPNET'
> > define host{
> >         use                     generic-host
> >         host_name               LNX_SRVAPPNET
> >         address                 192.168.1.1
> >         alias                   Appnet Server
> > }
> >
> > # 'LNX_SRVAPPNET02'
> > define host{
> >         use                     generic-host
> >         host_name               LNX_SRVAPPNET02
> >         address                 192.168.1.2
> >         alias                   Appnet2 Server
> > }
> >
> > On LNX_SRVAPPNET process inetd should be monitored through nrpe & check_proc,
> > but not on  LNX_SRVAPPNET. So a service is defined like the following:
> >
> > define service {
> >         use                             generic-service
> >         service_description             PROC_inetd
> >         hosts                           LNX_SRVAPPNET
> >         check_command                   check_nrpe!check_procs!1: 1: inetd
> > }
> >
> > The problem is, that not only LNX_SRVAPPNET has the check PROC_inetd, it also
> > appears on LNX_SRVAPPNET02 too. This happens also to any other service check
> > defined for LNX_SRVAPPNET. They are all appear on LNX_SRVAPPNET02 too.
> >
> > I can reproduce this problem every time a hostname appears in a part of a
> > other hostname (LNX_SRVEBS, [LNX_SRVEBS]TEST,...).
> >
> > There is no other service check definition which could cause this.
> >
> > Some has the same phenomenon and probably a solution?
> >
>
> It seems that Nagios doesn't recognize that there are no regex chars in
> there. To mitigate the problem you can put a dollar-sign at the end of
> the variable value. This might break in the future (in case Nagios works
> around it by simply surrounding the variable value with ^$).

Hello Andreas,

Yes, this is currently the solution I'm using to get ride of the problem. But
the question is, if this is a wanted behaviour or a mistake somewhere in the
xodtemplate.c source.

Cheers,
Andreas

>
> --
> Andreas Ericsson                   andreas.ericsson at op5.se
> OP5 AB                             www.op5.se
> Lead Developer
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> 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
>



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
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