Syncing Plugins

This forum was archived to /woltlab and is now in read-only mode. Please register a new account on our new community platform.

You can create a thread on the new site and link to an archived thread. This archive is available as knowledge base, safe and secured.

More details here.
  • Hi,

    Why is a global config zone not able to sync plugins? I've tried it and I've found that the only thing stopping it from working is the default permissions of the files that are created don't allow execution. Once I change it to executable, the synced plugins work fine.

    According to this, "Plugin scripts and binaries cannot be synced, this is for Icinga 2 configuration files only. Use your preferred package repository and/or configuration management tool (Puppet, Ansible, Chef, etc.) for that.", but my system's architecture makes those tools suboptimal. Is there really no way to enable execution of synced files to allow for plugins to be managed by Icinga?

  • It is not supported, as Icinga aims to be a monitoring tool, not a package management or lifecycle tool.

    Abusing the cluster config sync for this is dangerous. It may just break your monitoring and then there's noone to help.

    Put your focus on tools which help you manage plugin binaries and its dependencies. Foreman, Katello, Pulp, Spacewalk, Aptly as well as Puppet, Ansible, Chef or Saltstack are awesome tools which not only help here but with general server management and deployments.

    If you can't do that because company's policy on tool adoption is slow and oldgrown, you'll at least have a central scm where clients can pull their configuration and scripts from.

  • The issue for me is that I won't necessarily have access to these clusters after deployment, which I am currently using Ansible for, so being able to handle all plugin management via Icinga from the master server would save a lot of hassle. I set up a cluster yesterday that I had syncing plugins via the global config zone, as well as running a cron job that made the plugins executable, and it's working fine but it obviously feels so wrong.

  • The issue for me is that I won't necessarily have access to these clusters after deployment

    Well - There might be a reason for that, then.

    I. e. that some plugins run sudo - which is a reason for some admins not to delegate the installation of these scripts.

  • Anyone looking into this thread - don't do it. I nor the devs won't help you with troubleshooting here. This is a matter of stable monitoring, and also security (i.e. an attacker could just inject an executable on the master, and clients will just execute it). That is why the executable bit is intentionally not set.

    If you need more details on why it is dangerous - try to sync without having any perl library installed on the client.

    That plugin relies on the Net::SNMP library to actually work. Just syncing the plugin will break the check. How would you manage these dependencies you cannot add beforehand?

    This gets worse with binary files which are linked against specific architectures, library versions, and so on. The plugin keeps crashing, although you tested it ok on the master. Turns out that the client uses an older openssl library where exported function addresses changed.

    Even if you would want to have that in Icinga, you cannot support such things with reliable ressources and time. Users do crazy things just to make things work in the first place. Not so many think of long term maintenance and safe deployments.

    You've mentioned Ansible, which should be easy to just unlock a firewall port for during upgrades and install new plugins. Or didn't you plan to upgrade Icinga 2 on the client itself? :-)