Hi Valentin, > - All agents/clients could/will receive this information due to config > synchronization, no matter if they need these definitions or not.
correct. One might consider that an issue, depending on how many configurations are affected. My personal approach is to put as much of the configuration as I can into apply rules, not in explicit service objects, and have the configuration (e.g. passwords, LDAP DNs etc.) in variables with the hosts objects - which are local to their specific zone. Your mileage may vary, though, and this approach might not work for everyone. > (Furthermore it can't be healthy to "spam" too much configuration to all > clients/agents; just think of a setup > with hundreds or even thousands of nodes) A matter of taste ... I prefer sending a hundred apply rules to a couple of hundred nodes to having to deal with tons of identical or - worse - *almost* identical config files. You might be able to alleviate your issue with Icinga Director, which AFAIK (I haven't come around to have a closer look) uses the database and the Icinga API instead of sprinkling files all over the master's zones, thereby avoiding the file duplication issue. In addition you'll get a proper audit trail of changes, and versioning as well. A different approach is to maintain the configurations in a version control system (I'm using an internal git repository for that), and to distribute them to the master configuration using a deployment tool (I currently prefer Ansible for that purpose). The main advantage is that the files aren't really duplicates but copies of the same, mandatorily identical, master. In that case you'd still have duplicates on the master, but no spreading of all files to all zones. The disadvantage is clealy that it requires strong discipline on all sides, as manual changes to the config will inevitably get lost in the next deployment cycle. > On the other hand, there is the other scenario where I would like to apply > service rules to members of 2 of 3 zones (just a simple example). In this > case, putting these definitions into the global zones might be too much. I still tend to stick to my original approach, but I see your point and will reconsider when I approach the point you are trying to avoid. Best regards, Peter. _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
