Add custom config

[lbetz]

as simple files to add to existing managed files like feature or monitoring config, see assemble.

[flybyray]

@lbetz Is that supposed to support the case from the documentary?
"to organize your own local object tree"

[mkayontour]

Hi, no this feature is just to add custom configuration files, which are not managed or generated over the icinga2_objects variable.

So when you have a really complicated checkcommand with lots of syntax then it's easier to work around the parser an provide a whole file at the given location.

[mkayontour]

The task will check if in a file in a files/ directory on the management node matches on the given name and deploys or copies it to the destination.

    icinga2_custom_config:
      - name: icinga2_command.conf
        path: zones.d/main/commands/custom_commands.conf

[mkayontour]

@flybyray to answer your question to add config to your own directory.

Just add your new directory in the variable: icinga2_confd: myownconfigdir.d

In addition if you want to manage the config over the collection then add the directory to the managed directories variable.

icinga2_config_directories:
  - zones.d/main/hosts/
  - zones.d/main/services/
  - myownconfigdir.d/commands/

https://github.com/Icinga/ansible-collection-icinga/blob/main/doc/role-icinga2.md#manage-configuration

Hope that answers your question ;)

[flybyray]

@mkayontour thanks for explanation. Is there any other feature request which will support a custom „local object tree“?
I just ask because on RHEL based machines rpm icinga package updates most of the time overwrite important configuration files like /etc/sysconfig/icinga , /etc/icinga2/icinga2.conf, /etc/icinga2/constants.conf and /etc/icinga2/zones.conf.
Even a custom systemd unit override should be part of this feature.

I think this is relevant, because package updates should be possible independent from an ansible icinga2 configuration run.
Currently I see, that package update could possible destroy configuration and configuration needs to be applied again via ansible after an update.

[mkayontour]

The RPM packages should never overwrite those given config files. Otherwise we would have massive problems on big "server" installations which would be erased after an update. If there's currently a problem with the packages which I'm not aware of, I guess this should be a problem for the Icinga 2 packages.
Icinga2 updates overwrite the source, but its located at /usr/share/icinga2/ there indeed, nothing should be changed.

But I have many users which are running thousands of hosts on RHEL and manage them by Ansible and mostly Ansible is only deployed once on these machines.

The goal of the collection is the configuration of Icinga2 and its features, therefore we only provide the functionality of Icinga 2. Everything besides Icinga should be managed by yourself, systemd unit files won't be part of it.

[flybyray]

Right: For normal operations with rpm packages there is no problem.

It is only for some edge cases like disfunction of reinstall - but remove+install works.
Then the rpm packages will create standard config because those default config files moved to *.rpmsave files.

...
  Erasing    : icinga2-2.12.9-1.el7.icinga.x86_64                                                                                                                                                                                                                         1/3
warning: /etc/sysconfig/icinga2 saved as /etc/sysconfig/icinga2.rpmsave
warning: /etc/icinga2/zones.conf saved as /etc/icinga2/zones.conf.rpmsave
warning: /etc/icinga2/icinga2.conf saved as /etc/icinga2/icinga2.conf.rpmsave
warning: /etc/icinga2/constants.conf saved as /etc/icinga2/constants.conf.rpmsave
...

I would like to manage - as you said - the systemd myself with an override to use a dedicated /etc/sysconfig/icinga2<-override> which specifies /etc/icinga2/icinga2<-override>.conf ... so that a local config tree is completely independent from icinga2 packages ( just to be safe ).

In my case there are additional considerations. Some checks for example check_http which have patches not merged upstreams. So custom RPMs are installed in /usr/local/... and some icinga config includes for custom plugin-contributions are used. It looks easier to mee to manage an own local config tree and just pick plugin changes which come with icinga updates.
I started to build a