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 [email protected] 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 _______________________________________________ Nagios-users mailing list [email protected] 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
