I am very new to this group and pretty new to icinga as well.
I need some help with simplifying how the email notifications are send out in my current environment.
Currently it i being send to all the users.
I was expecting the contactgroups/conatct to be defined in host definition or service definition but I can not find how actually is it configured. The person who configured never documented these things and here I am now.
Is there a way I can leave the existing system as it is and create create separate contactgroup and contacts and route the emails?
I am happy to share my screen if someone can guide me through this.
that’s an old Icinga 1.x setup where you are looking at. Icinga 2.x is the new Icinga where notifications differ.
Icinga 1.x is EOL already, but the docs archive is still online.
In terms of the problem, I’d suggest looking into the host and service objects and their contact* attributes. Modifying the list should solve the requirement to add more of the defined contact* objects.
Screen sharing is something where I would suggest getting professional support from an Icinga partner.
Thanks Michael, I have used the documentation earlier but will use it again to make sure I am not missing on anything.
The real confusion I have is that if I create a user in AD the user gets the access to login to the icinga1 but if I check for the user in contacts in LDAP-Users or a previous folder the user does not exists.
I am thinking to just create 3 contactgroups and assign users accordingly. I then plan to add these groups to individual hosts and service checks cfg files. This is definitely a longer route but can simplify some of the things.
Honestly I’ve stopped working with 1.x after dropping support for it a while ago, and have focussed on Icinga 2.x being around since 2014. There’s some things I just have forgotten in the years.
IIRC the contact names must match the REMOTE_USER served from Apache/AD as otherwise you don’t get permission to see anything inside the Classic UI. That limitation was btw an inspiration to create Icinga Web 2 where you can just assign permissions based on host groups or custom variables.
So, the contacts are not only used for notifications, but also UI permissions. AFAIK the common best practice was to define many dummy contacts, like sms-mf, sms-mf-auth, sms-mf-real, etc.
I strongly suggest that you plan a migration to 2.x soon enough, also in regard of security and maintenance upgrades.
