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.

WSUS Datenbank umziehen

Wer einen Windows Server Update Services (WSUS) Server installiert, könnte aus Bequemlichkeit bei der Installation wählen, dass die interne Windows-Datenbank (WID) für den WSUS genutzt werden soll. Das hat meiner Erfahrung nach verschiedene Nachteile:

  • Der benötigte Speicherplatz für die WID könnte irgendwann recht groß werden. Standardmäßig ist diese unter C:\Windows\WID gespeichert.
  • Die WID ist leistungsmäßig unterirdisch und macht in verschiedenen Szenarien immer wieder Probleme (bspw. wenn die WID schon etwas größer geworden ist)

Deshalb sollte man sich, wenn man einen WSUS installieren möchte, zunächst einen SQL Server installieren. Standalone oder – in den meisten Fällen sinnvoller und auch ausreichend – SQL Express auf dem gleichen Server.

Ist das Kind schon in den Brunnen gefallen (wie bei meinem Szenario, wo eine mehr als 10 GB große WID für Probleme sorgte), lässt sich das aber zum Glück relativ einfach nachträglich ausbessern. Ich habe mich dabei an dem How-To von Microsoft orientiert, das allerdings etwas verwirrend ist: https://technet.microsoft.com/de-de/library/dd939918(v=ws.10).aspx

Zunächst installiert man einen SQL Express Server bzw. legt eine neue Instanz an. Ich nenne sie WSUS. Der Server hat „MGMT-SRV“ als Hostname, so dass die Instanz nun unter „MGMT-SRV\WSUS“ erreichbar ist. Beim Erstellen der Instanz habe ich Windows-Authentifizierung gewählt und dem Konto „NT-Autorität\Netzwerkdienst“ den Zugriff gestattet.

Weiterhin ist es nötig, das Microsoft SQL Server Management Studio zu installieren, um den Umzug zumindest komfortabler zu gestalten (grundsätzlich sollte das alles auch über die Kommandozeile gehen).

Im nächsten Schritt habe ich die Dienste „IIS-Verwaltungsdienst“ sowie „WSUS-Dienst“ beendet.

Danach habe ich in der klassischen Eingabeaufforderung folgende Befehle eingegeben:

sqlcmd -S np:\\.\pipe\MICROSOFT##WID\sql\query
use master
alter database SUSDB set single_user with rollback immediate
go
sp_detach_db SUSDB
go

Achtung: bei Server 2008 R2 und älter ist die interne Datenbank MSSQL$MICROSOFT##SSEE (statt MICROSOFT##WID).

Wenn man jetzt möchte, kann man die Datenbank an einen anderen Speicherplatz verschieben. Ich habe die Dateien SUSDB.mdf und SUSDB_log.ldf auf ein anderes Laufwerk verschoben, auf dem sich auch die übrigen WSUS-Daten befinden. Die Dateien befinden sich unter Windows Server 2012 (R2) im Verzeichnis C:\Windows\WID\Data.

Mit dem SQL Management Studio habe ich nun die neue Instanz MGMT-SRV\WSUS geöffnet und einen Rechtsklick auf „Datenbanken“ gemacht. Dort habe ich mit dem Punkt „Anfügen“ die Datenbankdatei SUSDB.mdf hinzugefügt.

Anschließend sollte man nochmal prüfen, ob alle Berechtigungen stimmen:

  1. Unter Sicherheit\Anmeldungen sollte das Konto „NT-Autorität\Netzwerkdienst“ aufgeführt werden.
  2. Unter Datenbanken Rechtsklick auf SUSDB und Eigenschaften wählen. Unter Berechtigungen sollte ein Eintrag für „NT-Autorität\Netzwerkdienst“ vorhanden sein.
  3. Unter Datenbanken\SUSDB\Sicherheit\Rollen\Datenbankrollen Rechtsklick auf webService und Eigenschaften wählen. Dort sollte bei „Mitgliedern dieser Rolle“ auch „NT-Autorität\Netzwerkdienst“ eingetragen sein.

Nun habe ich regedit.exe gestartet und im Schlüssel HKLM\SOFTWARE\Microsoft\UpdateServices\Server\Setup den Eintrag SqlServerName auf MGMT-SRV\WSUS geändert. Also: [Servername]\[Instanzname]

Danach habe ich die Dienste „IIS-Verwaltungsdienst“ und „WSUS-Dienst“ wieder gestartet und zur Sicherheit auch noch den WWW-Publishingdienst sowie den Dienst „Interne Windows-Datenbank“ neugestartet.

Zuletzt habe ich mit dem Start der WSUS Verwaltung erfolgreich geprüft, ob wieder alles läuft.

Shrew Soft VPN Client: negotiation timeout occurred

Heute hatte ich mit dem Problem zu kämpfen, dass der Shrew Soft VPN Client keine VPN-Verbindung zum Kundennetzwerk aufbauen konnte. Die immer wiederkehrende Meldung: negotiation timeout occurred

Setup: Windows 10 Client, WLAN-Verbindung

Zunächst dachte ich, dass es an der Windows-Firewall oder an der installierten Sicherheitssoftware (Virenscanner etc.) liegen könnte. Nachdem ich das alles deaktiviert hatte, war es trotzdem nicht möglich, das VPN aufzubauen. Letztendlich habe ich jedoch den Hinweis gefunden, dass da eine ganz andere Komponente, die in neueren Windows-Versionen enthalten ist, eine Rolle spielt: Der „Microsoft Wi-Fi Direct Virtual Adapter“

Offenbar hat der Shrew-Client Probleme damit, wenn dieser virtuelle Adapter vorhanden ist. Nachdem ich den „Microsoft Wi-Fi Direct Virtual Adapter“ dann im Gerätemanager deaktiviert hatte, konnte das VPN erfolgreich aufgebaut werden.

Hätte man versucht, das VPN aufzubauen, wenn der Rechner per Kabel verbunden gewesen wäre, hätte vermutlich alles anstandslos funktioniert. Das hilft nur dann nicht mehr, wenn der Mitarbeiter unterwegs und auf WiFi-Verbindungen angewiesen ist.

Ich kann nicht ausschließen, dass das Problem nur in wenigen Fällen auftritt. Soweit habe ich das noch nicht getestet. Aber wenn das Problem auftritt, dass die VPN-Verbindung mit dem Shrew-Client nicht aufgebaut werden kann, wenn der Client eine WLAN-Verbindung nutzt, dann sollte dies eine der ersten Ansatzpunkte für die Problemlösung sein.

 

 

Tech-Tipp: Windows 10 Update Fehler 0x80004005 bei KB3087040

Nur ganz kurz: Gestern hat Microsoft ein Update für Internet Explorer Flash Player (KB3087040) veröffentlicht. Bei manchen Systemen schlägt dieses Update jedoch fehl – auch ein Neustart und ein wiederholter Versuch bleibt erfolglos. Die Lösung ist, das Update manuell zu installieren (evtl. hat Microsoft inzwischen auch schon einen Fix veröffentlicht, der aber noch nicht bei allen Systemen in Windows Update verfügbar ist).

2015-09-22 10_31_25-Einstellungen

Download-Links: