Nagios 4 unter Ubuntu 18.04 (Upgrade)

Nach dem Upgrade von Ubuntu 16.04 auf Ubuntu 18.04 hatte ich mit diversen Fehlern unter Nagios zu kämpfen. Die meisten waren im Zusammenhang mit SSL.

NRPE und NSClient++

Der NSClient++ bringt leider nur 512bit-DH-Schlüssel mit. Der aktuelle NRPE verlangt aber eine stärkere Verschlüsselung. Die Fehlermeldung die ich in Nagios erhalten habe war:

Error: Could not complete SSL handshake. <host> 1

Im nsclient.log war diese Fehlermeldung zu finden:

ssl alert handshake failure: 1040

Meine Lösung (nach einiger Recherchearbeit) ist:

Mit OpenSSL stärkere Diffie-Hellman-Schlüssel zu erzeugen und diese dann in die Clients zu verteilen (Fleißarbeit). Dazu folgenden Befehl ausführen:

openssh dhparam -C 2048

Es wird dadurch ein Schlüssel erzeugt (was einen Moment dauert), den man dann in eine Datei (bspw. nrpe_dh_2048.pem) speichert. Der Schlüssel beginnt mit -----BEGIN DH PARAMETERS----- und Endet mit -----END DH PARAMETERS----- . Die Datei wird dann im Zertifikatspfad vom NSClient++ abgelegt (bspw. C:\Program Files\NSClient++\security\)

Außerdem muss dann noch folgender Eintrag in den Abschnitt [/settings/NRPE/server] der nsclient.ini eingetragen werden:

; DH KEY -
dh = ${certificate-path}/nrpe_dh_2048.pem

Nach einem Neustart des NSClient++ Dienstes kann NRPE auch wieder abgerufen werden.

Hilfreichste Quelle: https://help.univention.com/t/problem-nagios-ssl-issues-with-nsclient/11620

SSH und alte Cipher

Manche Systeme, die mit Nagios überwacht werden, haben ältere SSH-Versionen, die entsprechend veraltete Cipher benutzen. Bei mir war es u.a. ein Fujitsu Eternus. Fehlermeldung in Nagios war folgende:

[ssh return code = 255]

Eine Überprüfung via direkter SSH-Verbindung ergab, dass mein System nicht die nötigen Cipher anbietet:

Unable to negotiate with 192.168.2.3 port 22: no matching cipher found. Their offer: aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast1 28-cbc,3des-cbc,des-cbc,des-cbc,arcfour128,arcfour

Als Lösung habe ich einen der genannten Cipher (aes256-cbc) in der /etc/ssh/ssh_config hinzugefügt:

Ciphers +aes256-cbc

Anschließend war eine SSH-Verbindung zu dem betroffenen System wieder möglich und Nagios hat wieder korrekte Werte geliefert.

NagiosQL unter Ubuntu 18.04 LTS (PHP7.2, MySQL)

In Anschluss an meinen Beitrag von vor ein paar Jahren (NagiosQL unter Ubuntu 16.04) habe ich hier einen Fix für NagiosQL unter der aktuellen Ubuntu 18.04. LTS. Ich sag nur soviel dazu: bei mir läuft es bisher problemlos, aber ich übernehme keine Haftung/Garantien.

Nagios Update 4.3.0 Probleme

Ups, nachdem ich mein Nagios 4.2.3 auf 4.3.0 aktualisiert hatte, war ich einigen kleinen Problemen ausgesetzt. Zunächst meldete Nagios, dass es den Prozess-Status nicht finden konnte:

Unable to get process status

Weiterhin konnte ich auf keinen Menüpunkt in Nagios zugreifen. Bspw. beim Aufruf von „Tactical Overview“ bekam ich die Meldung vom Apache Server

The requested URL /nagios/cgibin/tac.cgi was not found on this server.

Es stellte sich heraus, dass Nagios in der aktuellen Version nicht mehr unter /nagios/cgi-bin/ sondern unter /nagios/cgibin nach den CGIs sucht. Also habe ich in der Datei /etc/apache2/sites-enabled/nagios.cfg (kann abweichend sein) noch den zusätzlichen ScriptAlias /nagios/cgibin für/usr/local/nagios/sbin eingetragen. Nach einem Neustart des Apache Servers war zumindest das Problem schon mal gelöst.

Ein weiteres Problem waren die Map und die Trends. Im Legacy-Mode funktionierten sie, aber nicht mehr im „normalen“ Modus. Ich bekam hier lediglich die Meldung

Warning: Monitoring process may not be running! Click here for more info

Das „here“ verwies auf einen ungültigen Pfad (nämlich auf /{{cgiurl}}extinfo.cgi?type=0). Nach einigem Suchen fiel mir auf, dass irgendwie unter /usr/local/nagios/share/js die Datei config.js fehlte. Diese beinhaltet die Variable für cgiurl. Nachdem ich die Datei config.js.in aus dem Source-File angepasst (ich habe @cgiurl@ durch cgibin ersetzt und die Dateiendung .in entfernt) und in das genannte Verzeichnis gelegt hatte, funktionierte Nagios bei mir wieder ohne Probleme.

config.js:

var nagcfg = {};
nagcfg.cgidir = "cgibin/";


NagiosQL unter Ubuntu 16.04 LTS (PHP7, MySQL)

Nachdem mir die Verwaltung von Nagios allein durch das Jonglieren mit Config-Files in Texteditoren zu aufwändig wurde (und ich meinen Kollegen keinen mehrtägigen Lehrgang geben wollte, wie sie selbst Hosts und Services hinzufügen können), habe ich mir NagiosQL 3.2.0 hinzuinstalliert. Das Projekt ist seit einiger Zeit in das kommerzielle Nagios XI integriert und wird nicht mehr frei verfügbar weiterentwickelt. Da hatte ich mit Nagios 4 unter Ubuntu 16.04 und PHP7 etwas ungünstige Voraussetzungen.

Letztendlich haben mir aber die für Nagios 4 und PHP7 angepassten Dateien eines Brasilianers geholfen, das Ding zum Laufen zu bringen. Muchas gracias Fabio Lucchiari!

Letztendlich waren von mir noch ein paar kleine Fixes nötig, da in den PHP-Scripts teilweise doch noch mysql_ statt mysqli_ Methoden verwendet wurden. Und ein ganz ärgerlicher Bug war schon im Original enthalten: in der Datei ./functions/prepend_content.php in Zeile 324 muss es am Ende wie folgt heißen:

GROUP BY `$preKeyField`, `id`";

Sonst erhält man beim Klick auf „Alle Konfigdateien schreiben“ im Punkt „Services“ den Fehler:

Einige Konfigurationsdateien wurden nicht geschrieben. Es wurde kein existierender bzw. kein aktiver Datensatz gefunden oder die Schreibrechte fehlen.
bzw.
Some configuration files were not written. Dataset not activated, not found or you do not have write permission!

Wer direkt eine funktionierende(?) Installation haben möchte, kann sich die von mir gefixte Version hier herunterladen: nsql320_Fix.tar

PS: Das Fragezeichen hinter „funktionierende“ steht da ganz bewusst, da ich viel rumgefrickelt habe und alles soweit mit den Dateien in dem Archiv bei mir funktioniert. Ich kann aber nicht versprechen, dass nicht noch irgendwo andere Probleme bestehen, die ich abseits der Dateien gelöst habe. Dazu auch ein
PPS: Ich hatte nach der initialen Installation ein paar Probleme mit der SQL-Datenbank beim Importieren von bestehenden Nagios Config Files. Hier half es, alle betroffenen Tabellen via phpMyAdmin zu prüfen und die Spalten, bei denen als Standardwert nichts eingetragen war (also „kein(e)“ bzw. „none“) den Standardwert auf „NULL“ zu setzen.

[Update 01.06.2017]
Ich hatte heute nach dem Einspielen von Updates (u.a. PHP7) Probleme, auf NagiosQL zuzugreifen. Der Server lieferte mir einen 500er aus und in den Error-Logs vom Apache habe ich gesehen, dass es dort zwei Fehler gibt:

PHP Warning:  mysqli_error() expects parameter 1 to be mysqli, boolean given in /usr/local/nagios/share/nagiosql/functions/mysql_class.php on line 283
PHP Fatal error:  Uncaught Error: Call to a member function query() on boolean in /usr/local/nagios/share/nagiosql/functions/mysql_class.php:174\nStack trace:\n#0 /usr/local/nagios/share/nagiosql/functions/prepend_adm.php(248): mysqldb->getDataArray('SELECT * FROM `...', '', 0)\n#1 /usr/local/nagios/share/nagiosql/index.php(41): require('/usr/local/nagi...')\n#2 {main}\n  thrown in /usr/local/nagios/share/nagiosql/functions/mysql_class.php on line 174

Letztendlich hat sich herausgestellt, dass diese Fehlermeldungen mit dem eigentlichen Problem nichts zu tun haben, sondern dass das nur Folgefehler des Problems sind. In Zeile 279 der mysql_class.php wird für die MySQLi-Connection noch der Server-Port übergeben. Aus irgendeinem Grund führt das dann dazu, dass die Connection auf localhost:3306:3306 geht. Ändert man die Zeile in

$this->strDBId = @mysqli_connect($dbserver,$dbuser,$dbpasswd);

läuft NagiosQL wieder.