Send Notification with Jira module via icingacli

I have a problem sending notifications to Jira via icingacli. Our setup is special, so I don’t think it’s a problem with the module itself, but with how we set I up. Therefore, I didn’t create an issue on GitHub for it.
First: Our checker host is not our icingaweb2 host. As the Jira module assumes this is the case, we at least have to have the complete icingaweb2 installation (ipl lib, Jira mod) and parts of it’s config (some resources and the jira module config) as a copy on the checker host.

Since 2 weeks (approx.) we now can’t send any notifications anymore from the checker host with this error:

[2022-08-25 08:55:40 +0000] warning/PluginNotificationTask: Notification command for object 'checked-host1.fqdn!apt' (PID: 35079, arguments: '/usr/bin/icingacli' 'jira' 'send' 'problem' '--description' 'APT CRITICAL: 6 packages available for upgrade (4 critical updates). ' '--host' 'checked-host1.fqdn' '--issuetype' 'Service Request' '--project' 'JIPR' '--service' 'apt' '--state' 'CRITICAL' '--summary' 'apt on checked-host1.fqdn is CRITICAL' '--template' 'my-jira-tmpl') terminated with exit code 1, output: ERROR: PDOException in /usr/share/icinga-php/ipl/vendor/ipl/sql/src/Connection.php:401 with message: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'service.checkcommand_name' in 'field list'

We are running Debian bullseye on this and included the repository on packages.icinga.com, our current version is r2.13.5-1. icingaweb2 (as well as icingacli) have version 2.11.1-1.bullseye, icinga-php-library (which contains ipl) is on 0.9.1-1.bullseye. According to “apt update” these are the most recent versions.

My web frontend is running the current docker image with icingaweb2:

| Icinga Web 2 Version | 2.11.1 |
| Git commit | eecf8d9934cbf30ec063cea4a525b26bfd2bf99a |
| PHP Version | 7.4.30 |

Any hint on what could be wrong here? Do I have wrong versions somewhere?

OK, solved it by myself: As the error message says: the DB scheme didn’t include the latest updates, as there was a problem applying those (no full admin privileges on Azure MySQL services).

2 Likes