Unable to schedule a check or run "check now"

Icinga Web
,
1

icingaweb2: 2.12.1
PHP: 7.3.33
monitoring: 2.12.1
icinga2: r2.14.2-1
selinux: disabled
firewall: none

Icinga2 feature list:
Disabled features: compatlog debuglog elasticsearch gelf graphite icingadb influxdb influxdb2 journald livestatus opentsdb perfdata syslog

Enabled features: api checker command ido-pgsql mainlog notification

Hi all,

The icingaweb2 UI is unable to schedule a check nor can it run “check now” on any host.

In Modules → Monitoring → Backends → Edit Command Transport, I fill out the information (transport type Icinga 2 API) and press “validate configuration”, which returns the following:

Failed to successfully validate the configuration: Couldn't connect to the Icinga 2 API:

The fields match exactly what is in /etc/icinga2/conf.d/api-users.conf.

I also replaced “Host” with: localhost, 0.0.0.0, [::1], 127.0.0.1, $FQDN

None of the above worked.

In the logs, I see the curl command ran by icingaweb2, followed by an error output from icingaweb2:

**Icinga\Module\Monitoring\Exception\CurlException in /usr/share/icingaweb2/modules/monitoring/library/Monitoring/Web/Rest/RestRequest.php:291 with message:**

Icinga\Module\Monitoring\Exception\CommandTransportException in /usr/share/icingaweb2/modules/monitoring/library/Monitoring/Command/Transport/CommandTransport.php:137 with message: icinga2: . #0 /usr/share/icingaweb2/modules/monitoring/application/forms/Command/Object/CheckNowCommandForm.php(77): Icinga\Module\Monitoring\Command\Transport\CommandTransport->send(Object(Icinga\Module\Monitoring\Command\Object\ScheduleHostCheckCommand)) #1 /usr/share/php/Icinga/Web/Form.php(1175): Icinga\Module\Monitoring\Forms\Command\Object\CheckNowCommandForm->onSuccess() #2 /usr/share/icingaweb2/modules/monitoring/library/Monitoring/Web/Controller/MonitoredObjectController.php(327): Icinga\Web\Form->handleRequest() #3 /usr/share/icingaweb2/modules/monitoring/library/Monitoring/Web/Controller/MonitoredObjectController.php(69): Icinga\Module\Monitoring\Web\Controller\MonitoredObjectController->setupQuickActionForms() #4 /usr/share/icingaweb2/modules/monitoring/application/controllers/HostController.php(63): Icinga\Module\Monitoring\Web\Controller\MonitoredObjectController->showAction() #5 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Controller/Action.php(516): Icinga\Module\Monitoring\Controllers\HostController->showAction() #6 /usr/share/php/Icinga/Web/Controller/Dispatcher.php(76): Zend_Controller_Action->dispatch(String) #7 /usr/share/icinga-php/vendor/vendor/shardj/zf1-future/library/Zend/Controller/Front.php(954): Icinga\Web\Controller\Dispatcher->dispatch(Object(Icinga\Web\Request), Object(Icinga\Web\Response)) #8 /usr/share/php/Icinga/Application/Web.php(294): Zend_Controller_Front->dispatch(Object(Icinga\Web\Request), Object(Icinga\Web\Response)) #9 /usr/share/php/Icinga/Application/webrouter.php(105): Icinga\Application\Web->dispatch() #10 /usr/share/icingaweb2/public/index.php(4): require_once(String) #11 {main}

I can run the curl command that icingaweb2 runs successfully. I can also run other api commands via curl/command line to run the checks for me (check now), and that runs succesfully. It is only the webui that is unable to schedule checks.

Is this a bug in icinga2? Or is there some workaround for this issue? It is surprisingly similar to: CurlException in RestRequest.php - API Timeout but curl from shell works fine · Issue #3725 · Icinga/icingaweb2 · GitHub

Thanks

2

did you restart icinga2 after you changed credentials in api-users.conf?

3

Hello, thanks for the reply. I have restarted icinga2 as well as nginx several times with no change, the webui still errors on scheduling.

4

what’s the content of your

  • /etc/icingaweb2/features-enabled/api.conf
  • /etc/icingaweb2/modules/monitoring/commandtransports.ini
  • /etc/icinga2/conf.d/api-users.conf
  • /etc/icinga2/icinga2.conf

?

5

(I think you mean /etc/icinga2/ instead of /etc/icingaweb2 for this:)
/etc/icinga2/features-enabled/api.conf

Is the commented out “accept_commands” the issue?

/**
 * The API listener is used for distributed monitoring setups.
 */

object ApiListener "api" {
  //accept_config = false
  //accept_commands = false

  ticket_salt = TicketSalt
}

/etc/icingaweb2/modules/monitoring/commandtransports.ini

[icinga2]
transport = "api"
host = "localhost"
port = "5665"
username = "redacted"
password = "redacted"
  • /etc/icinga2/conf.d/api-users.conf
/**
 * The ApiUser objects are used for authentication against the API.
 */
object ApiUser "redacted" {
  password = "redacted"
  permissions = [ "status/query", "actions/*", "objects/modify/*", "objects/query/*" ]
}
  • /etc/icinga2/icinga2.conf
    Just a bunch of includes, most relevant:
include "constants.conf"
include "zones.conf"
include "features-enabled/*.conf"
include_recursive "conf.d"
include <itl>
include <plugins>
include <plugins-contrib>
include <manubulon>
6

yes, uncommend it.
if you use icinga director, or want to create objects via api you need to set accept_config too.