I have a specific use case.
I have a master configured with Director.
Under this master, I want to add a satellite to execute certain checks.
However, on this satellite, I would also like to have the ability to add checks that would not be propagated to the master. Ideally, this should be done with Director to allow everything to be managed via a graphical interface (the satellite is intended for end-users who are not comfortable with Linux).
Is that only possible ? and if by miracle the answer is yes, how can I do that ?
I think it might be technically feasible, but would NOT recommend to do that.
You are going to shoot yourself in the foot (or other body parts) in the forseeable future with that
You will end up with two conflicting sets of configuration.
The recommended way to allow some users to configure only a part of the whole
Icinga system is to use the permissions system to limit the scope available to those users to a defined subset.
If you would like to continue anyway with your idea, please report how it did (not) work, I would be interested.
Mainly you have to setup two Icinga instances with Icinga Web 2 + Director, where one Icinga 2 (the satellite) is subservient to the primary node. The documentation should tell you how to do this part.
humm interresting !
Is your checks works with agent ?
If yes (I hope the answer is yes because mine are :)) how do you configure your agent to talk with two different parent for the same check ?
You can always use filters in IcingaDB/Monitoring and just filter these checks out for any “non unrestricted” usergroup, for example assign a Service group and filter out these services
how do you configure your agent to talk with two different parent for the same check ?
I don’t. All checks on the secondary Icinga are exclusive to this instance and the python script only transports the host and service objects to my main master icinga instance and synchronizes the states via passive checks (API).
You could have the python script running on both icinga instances and use filters to only replicate the objects you want to show on the other instance but one caveat is, that the transported objects are read only in the director.
I’m on an Infrastructure team and I need to monitor OS on servers. On those server there are some process running that I don’t need to check.
The other team wich will use the satellite want to monitor those specific process AND want to see the OS check I do on the master.
My base idea was to create a satellite wich inheritate check from the master and with a local director instance for create it own specifics checks.
Apparently, it is not easily achievable.
So I could copy host and service object from my master to the other dedicated team master and synchronise the states to it ?
Sorry if it’s a noob question but how can I do this concretely?
Or you filter out the services by a customvar.
Anyway If you switch from an unrestrcited user to a restricted one, and you can still give the role all permissions which is almost identical to unrestricted you will not see these services on your master node
Yes, but you could just as well use the permissions in the roles in a singe Icinga cluster.
I follow the Linuxfabrik recommendation of using host.vars.teams and service.vars.teams data lists to manage notifications and permissions.
Multiple Icinga environments connected by a sync script has the advantage, that deployments don’t hamper the other system and a plugin of questionable quality can’t mess up the other system.
Giving permision on the master webui, even with filter, is not an option.
The webui is hosted on a network unaccessible by users for security purpose.
But I think the script could be an option for us.
I can give to the users a dedicated and standalone master, and use scripts on it to send to my master the hosts / services / state ?
Can you give me (or link me if it’s public) a copy of this script ?
