Hi list, we are using Icinga v2.4.10, on Ubuntu 14.04 LTS installed from the
formorer PPA.
We are using icinga2-classicui from the same ppa.
I’m seeing the /var/lib/icinga2/modified-attributes.conf file that gets new
data when we switch something in the classicui, for example if we turn off
notifications for a service. Then when we ‘revert’ the setting, the file gets
updated.
But the entry in that file is there forever, no matter what we do in the
classicui, and it will override any modification that we do in the service
configuration file.
I’ll try to overcome my non-native-english with an explicit example:
- you start with a pretty common scenario, a service with active checks and
nothing special
- from classicui you click “disable notifications for service”, the ui shows
notifications disabled and modified attributes “None”
- the modified-attributes.conf does not show anything, I don’t know if Icinga2
persisted the setting somewhere else or if it’s just in ram
- if we reload or restart Icinga2, the modified-attributes.conf gets an entry
added for that service which contains
"obj.modify_attribute("enable_notifications", false)”
So far so good.
Now, if in the classic ui we click “Reset Modified Attributes”, nothing at all
happens. Notifications stay disabled, the modified-attributes.conf file does
not change even on Icinga2 restart. I guess this could be intended behavior,
maybe disabling notifications is not a “modified attribute” ?
Let’s go on...
- in the classic ui we now click “Enable notifications for this service”
- notifications are correctly re-enabled and the ui does not show anymore the
“notification disabled” icon on that service
- modified-attributes.conf again does not get updated at runtime
- after reload or restart of icinga2, the entry in modified-attributes.conf is
still there but has been updated to read
"obj.modify_attribute("enable_notifications", true)”
So we end up with a pile of “enable_<stuff>”, true whenever we use the UI to
temporarily switch off notifications, or active checks, or whatever, and then
re-enable them later on. Annoying, but the real problem is if we change the
service configuration.
After that disable-and-enable dance imagine that we modify the .conf file where
the service is defined, and we set enable_notifications=false there.
We reload Icinga2… and notifications are still enabled! That’s because the
modified-attributes.conf file overrides our service config file and sets them
true.
As far as I can tell, there is no way from the ClassicUI to tell Icinga2
“remove any overriding setting and just use whatever is in the main
configuration”.
Clicking “enable X” or “disable X” will force that setting forever even if the
service configuration changes and using the “reset modified attributes” link
seems to do nothing.
The only way to be sure to get applied what we put in the service configuration
is to stop Icinga2 and manually “clean” the modified-attributes.conf file,
removing the settings that are not real exceptions to the configuration.
Are we doing something wrong? How could we tell Icinga2 to forget about any
“override” and just apply the service configuration as is?
thanks,
--
Luca Lesinigo
LM Networks Srl
_______________________________________________
icinga-users mailing list
[email protected]
https://lists.icinga.org/mailman/listinfo/icinga-users
