Hi Valentin, > Now, let's say I want to define a service which affects multiple clients in > all zones. Those services need to be executed by the satellites. > Where would you define this apply rule? In the global zone on the master? > This would be "bad practice" IMHO, but I don't know any other way when I want > to avoid placing configuration multiple times.
*why* would you regard placing the service apply rules in the global zone a bad practice (serious question)? You are mentioning the best argument for doing it yourself: Avoiding duplicating configuration. What I'm missing are your arguments against it. I am currently setting up a distributed schema as well, and the general rule I am following is to put everything that isn't specific to a particular zone (which is, at least for the time being, everything apart from host definitions, which contain variables controlling group membership, which in turn then controls which services apply) in the global zone. That way I don't have any duplicate configuration files and get a clean setup. This has no influence on where the services actually execute - I am using two basic service templates, one of which contains a command_endpoint setting (causing the checks to run locally on the agent, e.g. disk and process checks) and one which doesn't (causing the checks to run on the satellite for the zone or the master for the master zone, e.g. TCP port and ping checks). Having the service apply rules in the global zone does not affect where the checks are actually run, checks for hosts in a satellite zone are still executed by the satellites, not the master, if that's your concern. Cheers, Peter. _______________________________________________ icinga-users mailing list [email protected] https://lists.icinga.org/mailman/listinfo/icinga-users
