> On 3 May 2017, at 22:17, Denny Fuchs <linuxm...@4lin.net> wrote: > > Hi, > > >> Am 01.05.2017 um 22:21 schrieb Antony Stone >> <antony.st...@icinga.open.source.it>: >> >> In what way is that a "problem"? > > sorry, was a long day ... :-) > >>> The question is now: what is the best way, to add both zones with >>> satellites, while all zones not using the PuppetDB server, like the >>> master. >> >> I don't really understand the question. > > it is more a plain icinga2-Puppet problem. > > I learned a lot of new things about Puppet, an have a setup running, which > has its idea from here: > https://github.com/Icinga/puppet-icinga2/tree/master/examples/example3 > > So if I add a new node in Puppet and include the right profile (called > profile::Icinga::agent in my example), I can run the Puppet agent on the > Icinga master and the new Icinga host is added for monitoring. So far so > great. All magic things are working, because all nodes uses the same Puppet > server and the same PuppetDB in our office. > > Here comes the problem: > > We using also Puppet servers on our other infrastructures, for example on one > private dedicated datacenter (DC1) and one in a shared datacenter (Linode > DC2). Both have its own Puppet SSL certificates and they have also no > PuppetDB servers. So I expecting here the first problem, because the Icinga > master uses the PuppetCA certificates. Maybe it is possible to sign the > PuppetCA from DC1 and DC2 with the CA from the PuppetCA used by Icinga Master > at office, for a trusted chain.
I’d then recommend not to use the Puppet-CA, but a different method to create and sign certificates for the Icinga2 cluster. https://github.com/icinga/puppet-icinga2#ca-and-certificates Opinions on that differ of course. > Otherwise I think, is is not possible that the Icinga satellite at DC1 and > DC2 can connect to the master. > For the moment, I created for my first satellite (DC1) a certificate which is > signed by Icinga2 Master PuppetCA and do not use the CA from the PuppetCA at > DC1. > > The next thing is, that we don't have PuppetDB on DC1 and DC2 running, until > we can make sure, that no passwords or other secrets are stored in plaintext > for example in PuppetDB itself. It makes hiera-eyaml useless. I think, > without PuppetDB I have to add just more lines to the manifests and/or hiera > for creating the the correct agent -> satellite Icinga configs for DC1 and > DC2. On the Icinga master side, I hope to find the right lines, to add the > zones for the DC1 and DC2. The example4 > (https://github.com/Icinga/puppet-icinga2/tree/master/examples/example4) have > some Puppet examples for have external zones. I'm not sure, how to integrate > them in my setup, without breaking anything ;-) > So to speak, the example uses exported resources and those require the PuppetDB (just as explanation for others who can’t follow why it’s about PuppetDB here). Are those Puppet servers in DC1 and DC2 standalone Puppet masters, or how do they relate to your central Puppet-Master? That will be hard to maintain if the Puppet agent would need to 2 different parent locations (I doubt this works and is safe). From that point of view, all of these instances are isolated on their own, and likely should be treated as such. How does one manage these Puppet environments without Icinga 2 currently? Kind regards, Michael > The lines starting here from the example 3, which I using now: > > https://github.com/Icinga/puppet-icinga2/blob/master/examples/example3/site/profile/manifests/icinga/server.pp#L18 > > The next lines are from example4, which collects the zone slightly different: > > https://github.com/Icinga/puppet-icinga2/blob/master/examples/example4/profile/manifests/master.pp#L37 > > To add the first zone from DC1, I added some lines to my Puppet at office, > where my Icinga2 master runs: > > class profile::icinga2::external_hosts (){ > > ############ DC1 ######### > > # Create virtual resources for this agent node > ::icinga2::object::endpoint { "satellite-dc1.example.com": > host => "192.168.10.1", > } > > ::icinga2::object::zone { "satellite-dc1.example.com": > endpoints => [ "satellite-dc1.example.com", ], > parent => 'master', > } > > } > > After executing Puppet agent on the Icinga master host, the zone and endpoint > is created. On the DC1 side I installed the Icinga2 agent by hand without > Puppet, just to get the basics running. So I have at the moment the > "satellite" successful connected to my master. > So, I need help to get the right Puppet lines for the office Puppet master, > so that I have in the end > /etc/icinga2/zone.d/satellite-dc1.example.com/{satellite-dc1.example.com.conf|host-1-dc1.example.com.conf|host2-dc1.example.com.conf...} > ... > > For the Puppet on DC1 and DC2 I think I need stripped Puppet profiles, which > doesn't use the exported resources via PuppetDB. Maybe just plain icinga2 > config files with some templates .... with installing the Icinga2 agent. But > I have no real ideas ... > > I hope, that the few more words helps to understand ... what the "problem" is > :-) In the end, its more a puppet-icinga2 thing, than just Icinga2. ;-) > > > cu denny > _______________________________________________ > icinga-users mailing list > icinga-users@lists.icinga.org > https://lists.icinga.org/mailman/listinfo/icinga-users _______________________________________________ icinga-users mailing list icinga-users@lists.icinga.org https://lists.icinga.org/mailman/listinfo/icinga-users
