Service definition host_name parameter logic?

[smiller at co.slo.ca.us]

I'm not having much luck with negative lookahead assertions using regexp 
with my service object definitions... could you provide an example?

I am trying something like:

host_name ^(?!(HOST1|HOST2)).*$

Thanks =)

---
Steve Miller <smiller at co.slo.ca.us>
Network Engineer
Information Technology Department
County of San Luis Obispo
805-781-5097




"Morris, Patrick" <patrick.morris at hp.com> 
08/10/2006 09:47 AM

To
<smiller at co.slo.ca.us>, <nagios-users at lists.sourceforge.net>
cc

Subject
RE: [Nagios-users] Service definition host_name parameter logic?






> I thought I'd drop a line to the list and inquire about if 
> there was any plan to extend the logic in the host_name 
> parameter of a service definition to be able to exclude 
> individual hosts or host groups. 
> 
> I've stumbled across a situation where that would be useful. 
> (e.g. host_name *,not SERVER1, not SERVER2) 
> 
> What I've done in the meantime is just disabled active 
> service checks for that service on that particular host. 

You can do this currently if you enable regexp matching in your Nagios
config.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/users/attachments/20060810/6abdaf88/attachment.html>
-------------- next part --------------
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
-------------- next part --------------
_______________________________________________
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