I have to build an icinga2 infraestructure following scheme master-satellite-client, but a different situation.
My master, which has icingaweb and director module installed it’s managed by me.
Satellite server, installed on client’s infraestructure, which has icingaweb, it will be managed by me at first instance and then my client will have all control of it, acting like its master.
Client nodes connected to satellite on same my client’s local network.
As that satellite is for one of my clients, i have to receive whatever is monitoring to my master, but i dont want that satellite accepts commands and config of my master.
So, the satellite server it will manage al checks to clients and have to report all elements (host and service) to my master.
I would rather define the permissions based on e.g. a hostgroup, and grant that on the master instance to your customer, to the monitoring and director modules. That way everything is managed on the master, and the satellite is just a checker with a hop into the customer’s DMZ.
The other way around is complicated and I am not sure if everything can be synced or would work as expected. Typically Icinga’s best practices isareto have the master zone as authoritative for everything.
Thank you for your reply. I thought that it can’t be posible to do it like i wanted…
So, new idea, this satellite for my client it will be reconfigure as master, could I send check results to another master with a way like OCSP for Nagios?
that new idea doesn’t follow best practice, and involves quite a few things. You can do it by using the REST API and write a sync script which does 1) create the host/services known on the satellite at the master 2) listen on event streams for check results and forward them to the master. Such a script doesn’t exist, but there’s programmatic examples throughout the documentation and on GitHub.
I would still prefer the permission model on the config master, this is where you’ll also get support and answers in here. A custom solution may introduce problems no-one ever had, or may become hard to debug.