Nagios Support Forum

We are in a process of upgrading the NCPA agent to 2.1.6 from 1.8.1. On most servers we are using an ITMS product to do the upgrade - it saves the plugins dir, then uninstalls 1.8.1, install 2.1.6 in a diff location and then copies plugins back. This process works fine. We also have several Asure servers and used the Azure runbook to perform the same procedure. After the upgrade was performed I could not list the plugins using the api:
[c601018@vhlgnngxi001 ~]$ /usr/local/nagios/libexec/check_ncpa.py -H BASTION1001.OCP-A.ZU2.PROD.travelport.io -t wspwebfarm -M plugins --list
{
"plugins": []
}

After changing the plugins dir permission from 755 to 777 it started to work:
[c601018@vhlgnngxi001 ~]$ /usr/local/nagios/libexec/check_ncpa.py -H BASTION1001.OCP-A.ZU2.PROD.travelport.io -t wspwebfarm -M plugins --list
{
"plugins": [
"LICENSE",
"Makefile",
"README.md",
"check_hawkular_machine_timestamp",
"check_openshift_cert_expiry_report",
"check_openshift_es_stats",
"check_openshift_node",
"check_openshift_node_fluentd",
"check_openshift_node_list",
"check_openshift_node_log_heartbeat",
"check_openshift_node_resources",
"check_openshift_pod_count",
"check_openshift_pod_cpu_usage",
"check_openshift_pod_memory",
"check_openshift_pod_node_alloc",
"check_openshift_pod_status_count",
"check_openshift_project_phase",
"check_openshift_project_pod_phase",
"check_openshift_pv_avail",
"check_openshift_pvc_phase",
"new-app-and-wait",
"openshift-dns.conf",
"openshift.conf",
"setup.py",
"utils",
"write-config"
]
}
[c601018@vhlgnngxi001

On checked other servers and permission 755 was sufficient. I cannot explain the discrepancy.
The server above is RHEL7

I haven't been able to recreate the issue in house. Having said that, the "old" NCPA used to run as root. The new one runs as nagios. What are the permissions of the plugins that you are using? Can you su (login as) nagios user, and try to run these plugins?

i have a mixture of ownership for those plugins--some owned by root and some by nagios. In order to troubleshoot the issue we did chmod 777 on all plugins and still could not list the plugins. On the servers where it did work and plugins dir had 755 permissions there was the same mixture of plugins ownership -- root and nagios. So the individual plugins ownership was not the issue.
Yes, i was able to run the plugins directly on a server as nagios: those that were owned by nagios and those that were owned by root after permission was changed to 777 on individual plugins.
Again, I've seen the problem only on servers that had 2.1.6 installed in a different way (Azure runbook automation) but cannot explain the difference and the need to change plugins dir ownership to 777.
If it is not a known issue, there is nothing obvious and you cannot reproduce it then I don't want to spend much time on this. My access to servers is very limited, only through a different support parson and since the number of servers affected is small i can live with this circumvention. It is just that it is a very strange problem.

Yes, i was able to run the plugins directly on a server as nagios: those that were owned by nagios and those that were owned by root after permission was changed to 777 on individual plugins.

Nagios just needs read permissions, so 755 would be sufficient for running the plugins (even owned by root). This is a very strange issue indeed.

Again, I've seen the problem only on servers that had 2.1.6 installed in a different way (Azure runbook automation) but cannot explain the difference and the need to change plugins dir ownership to 777.

NCPA was installed on the RHEL 7 system simply by running: Installing NCPA via Azure runbook hasn't been tested by us, and I am pretty sure it's not supported. I also cannot find any reasonable explanation why you would need to change permissions to 777 in order for NCPA to work. I can leave the topic open for the time being in case some users (who faced the same issue) would like to chime in.

This sounds good, thank you.

You are welcome!