[Nagios-users] RFC/RFP Service sets

[Andreas Ericsson]

On 05/17/2011 03:21 PM, Matt Simmons wrote:
> Hi,
> 
> On first glance, I liked the nested config example, but after thinking
> about it for a little while, I'm starting to lean toward specifying
> the service_sets per service. In cases where multiple groups
> contribute to the Nagios configuration of an entity, doing this will
> allow each group to "subscribe" their services, and file permissions
> on the individual cfg files can be maintained, whereas storing things
> in the nested service_set object requires everyone to be able to write
> to that (plus it adds some additional complexity).
> 

Not really. You can quite easily group service sets based on who is
supposed to edit them and give file permissions to db admins for all
files containing service-sets handling database stuff, and for windows
admins to handle the service-sets that take care of windows-checks and
so on. You're a bit too stuck to the "services.cfg" way of thinking,
where one type of object is only ever listed in one file. Nothing
prevents you from having one file per service set, and when you want
to share service sets with other users around the world, that's most
likely what will happen anyway.

> For what it's worth, I'm one of those people who are using host groups
> to assign services to machines because I like being able to minimize
> my work and maximize my results, and that's the shortest cut I've seen
> so far. This replaces that functionality nicely, I think.
> 

That's the general idea, so we can finally stop overloading hostgroups
or implement stuff to hide hostgroups that are only used to assign
services (which would be a patch to a patched thing, and therefore
quite ugly on a conceptual level).

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
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.

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay