Hello,
After upgrading a Nagios XI instance to version 2026R1.5 all the services that were configured with the ‘check_ncpa’ plugin are failing due to invalid credentials. The command used by these services is as follows: ‘$USER1$/check_ncpa.py -H $HOSTADDRESS$ -t $_HOSTTOKEN$ -M “$ARG1$” $ARG2$’. The authentication token configured either at the host template level or at the host level itself.
All the services are launching a CRITICAL with the message "CRITICAL: Incorrect credentials given."
Does anyone have this same issue after the upgrade? Is there any way to fix it?
Issues after 2026R1.5 upgrade
-
DoubleDoubleA
- Posts: 311
- Joined: Thu Feb 09, 2017 5:07 pm
Re: Issues after 2026R1.5 upgrade
Hi @IT_LAS,
Thanks for your post. At the moment we're looking at what might have changed in this release to cause that and it's not obvious what that might have been. We'll keep looking at it.
I suppose I have to ask, is there any chance credentials changed on your end?
Also, what version did you upgrade from?
Thanks,
Aaron
Thanks for your post. At the moment we're looking at what might have changed in this release to cause that and it's not obvious what that might have been. We'll keep looking at it.
I suppose I have to ask, is there any chance credentials changed on your end?
Also, what version did you upgrade from?
Thanks,
Aaron
Re: Issues after 2026R1.5 upgrade
Hi,
I've upgrade from 2026 SR1.4.
The Nagios XI instance is hosted on a Ubuntu Server 22 virtual machine.
I haven't changed the NCPA community_string on the hosts.
I've upgrade from 2026 SR1.4.
The Nagios XI instance is hosted on a Ubuntu Server 22 virtual machine.
I haven't changed the NCPA community_string on the hosts.
Re: Issues after 2026R1.5 upgrade
Hi IT_LAS
So this may be an issue that you'll have to take our support team; they may need some information about your system and environment that it wouldn't be safe to share here. But in the mean time let's see what we can do. It looks like you have your token defined in the macro $_HOSTTOKEN$ and one of the first things you'll probably want to look at is what that's expanding to. The easiest way to do that is to generate the run command. For one of the affected services you can generate a run command via the web interface:
Configure (top) -> Core Config Manager -> Services (left) ->
Find the service you've configured and click on the wrench on the right side.
Then Click on the "Run Check Command" button and the confirmation.
Take a look at the token value after -t and see if it reflects the correct value for the target system. Are any of the characters being escaped like this (note the leading \ ):
Is the token quote wrapped in single quotes ?
You should be able copy the run command and use it on the command line to experiment with the string a bit.
Good Luck and please let us know what you find.
Thanks and kind regards !!
So this may be an issue that you'll have to take our support team; they may need some information about your system and environment that it wouldn't be safe to share here. But in the mean time let's see what we can do. It looks like you have your token defined in the macro $_HOSTTOKEN$ and one of the first things you'll probably want to look at is what that's expanding to. The easiest way to do that is to generate the run command. For one of the affected services you can generate a run command via the web interface:
Configure (top) -> Core Config Manager -> Services (left) ->
Find the service you've configured and click on the wrench on the right side.
Then Click on the "Run Check Command" button and the confirmation.
Take a look at the token value after -t and see if it reflects the correct value for the target system. Are any of the characters being escaped like this (note the leading \ ):
Code: Select all
'\!@#$%^&*()_+' You should be able copy the run command and use it on the command line to experiment with the string a bit.
Good Luck and please let us know what you find.
Thanks and kind regards !!