Hi Peter,
thanks again for your advice.
I agree with you: Putting sensitive data into host variables is one of
the best ways. I would do so, however, in this specific project, it
won't be possible (please don't ask for the reasons).
Using the director is a very elegant approach, and indeed this is
happening in this project. But in this case, many definitions will
remain within the filesystem (again, please don't ask why).
At the end, I guess that in this specific case, I will not be able to
avoid redundant configuration. But your idea in terms of letting a
config mgmt system handle the duplicates is a good approach.
Thanks again,
Valentin
On 22.03.2017 18:41, Peter Eckel wrote:
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.
--
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
