0

I believe that I have succesfully configured Icinga 2 on Debian 9 (Stretch) using the stock Debian packages with the "Top Down Config Sync" mode as described in the Icinga documentation.

I have installed icinga2 and monitoring-plugins-basic on the clients and I am able to add remote checks using check_apt etc. I've even managed to add my own CheckCommands via the "global-templates" mechanism that are sent to the clients automatically and end up in /var/lib/icinga2/api/zones/global-templates/_etc/

I have a number of my own check scripts (written in shell and Python) that I'd also like to run. I've put them in /etc/icinga2/zones.d/global-templates too and they also get sent to the clients. However, they lose their execute bit on the way so I'm forced to provide the interpreter explicitly when I run them. This works, but it's a bit ugly.

Is there a better way to send my check scripts from the master to clients? If not, is there a way to keep the execute bit with this method?

Mike Crowe
  • 105
  • 4

1 Answers1

0

Don't do that. The cluster config sync is for plain configuration files only.

While a script might just need an executable bit, binaries with different architecture and library dependencies are a whole more of a problem.

The path to the synced configuration might change too, there is no reliable way to depend on it.

Deployment of such scripts can be helped with (lifecycle) management tools such as Puppet, Ansible, etc. Resolving script dependencies can be helped by fully creating a package from your scripts available in a software repository.

In my previous job I had a central plugin repository which was checked out on the clients on a regular basis.

dnsmichi
  • 845
  • 5
  • 12
  • Thank you for your answer. For me the scripts are absolutely fine and can deal with any architecture-specific issues themselves, but I can see how that isn't necessarily true in general. I shall investigate disseminating them by other means. – Mike Crowe Aug 25 '17 at 13:36