Hi,
I’m facing a particular issue that has been somewhat brought up before. Here is a bit of background information before the question.
I tried to do some testing with modifying objects, in this case User objects that have been initially defined in configuration files, through the API. The modification only includes a specific custom variable that is not used anywhere else for now.
As you imagine, I faced some issues. Essentially, the API modifications will always override any current and future modifications done in config files, even after a complete stop/start of Icinga2.
I did some research here and on github. I found out that it is a really bad idea to mix both files and runtime config for the same object.
Let’s say I want to get back to the values specified in the configuration file initially. The solution provided in another topic is “Use the original_attributes API to restore the original value of the variable”. This is working as expected but the catch is that we are reverting the state of the variable using the API, still overriding any other configuration from files.
Now, what if I don’t want to use the API anymore for these objects and get back to config files only ?
I know that attributes modified by the API are stored in /var/lib/icinga2/modified-attributes.conf but I also read that it is strongly discouraged to edit this file.
So the question is, is there a safe way to go back to config files only, essentially removing any trace of runtime modifications in objects like Users ?
As a note, I already tried to stop Icinga2, delete the content of modified-attributes.conf, and restart the service. Everything seems fine for now, icinga2 object list and an API GET request on users are in sync but I want to make sure that nothing can break in the future because of this. This is not production and I have backups ready just in case.