Hi Peter,
you are referring to one of two scenarios in my e-mail:
Placing configuration which affects multiple agents in all zones.
While I realize that global zones are perfect places to put such
configuration in, doing so comes with several disadvantages:
- All agents/clients could/will receive this information due to config
synchronization,
no matter if they need these definitions or not.
(This is something one would not want in every case, e.g. when the
service template or definition
contains information which could be used by intruders, e.g. LDAP OUs
or high ports of SSH servers etc.)
(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)
- Due to avoiding configuration inconsistencies, one would have to place
all configuration object in global zones
which are needed by agents/clients when they validate their
configuration (this applies to other config scenarios aswell)
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.
> checks for hosts in a satellite zone are still executed by the
satellites,
> not the master, if that's your concern.
I know, and it is not my concern. My concern is "spamming" the clients
and giving them too much information in some cases.
Best regards
Valentin
On 22.03.2017 07:44, Peter Eckel wrote:
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
--
Valentin Höbel
Senior Consultant IT Infrastructure
mobil 0711-95337077
Linux Information Systems
LIS Stuttgart GmbH
Talstraße 41 70188 Stuttgart Germany
Geschäftsführer Tilo Mey
Amtsgericht Stuttgart, HRB 729287, Ust-IdNr DE264295269
Volksbank Stuttgart EG, BIC VOBADESS, IBAN DE75600901000340001003
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.icinga.org/mailman/listinfo/icinga-users
