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.

Veeam Backup & Replication – Error: VSSControl: Failed to prepare guest for freeze, wait timeout 900 sec

Bei einem Kunden funktionierte das Veeam Backup für eine VM nach der Installation eines Microsoft SQL Server 2016 Express nicht mehr. Fehlermeldung in Veeam:

Error: VSSControl: Failed to prepare guest for freeze, wait timeout 900 sec

Die von Veeam bereitgestelle KB1377 hat nicht geholfen. Bei der Überprüfung der Volumenschattenkopiedienste mit „vssadmin list writers“ wird der SQLWriter nicht aufgeführt. Die Anwendung von KB2095 von Veeam hilft allerdings auch nicht.

In den Ereignislogs des Servers findet sich folgende Fehlermeldung mit der Ereignis-ID 24583:

Sqllib-Fehler: OLE DB-Fehler beim Aufrufen von
                    IDBInitialize::Initialize. hr = 0x80004005.
                    SQLSTATE: HYT00, Native Error: 0
Source: Microsoft SQL Server Native Client 11.0
Error message: Anmeldungstimeout abgelaufen SQLSTATE: 08001, Native
               Error: -1
Source: Microsoft SQL Server Native Client 11.0
Error message: Netzwerkbezogener oder instanzspezifischer Fehler beim
               Herstellen einer Verbindung mit SQL Server. Der Server
               wurde nicht gefunden, oder auf ihn kann nicht
               zugegriffen werden. Überprüfen Sie, ob der Instanzname
               richtig ist und ob SQL Server Remoteverbindungen
               zulässt. Weitere Informationen erhalten Sie in der SQL
               Server-Onlinedokumentation.
SQLSTATE: 08001, Native Error: -1
Error state: 1, Severity: 16
Source: Microsoft SQL Server Native Client 11.0
Error message: SQL Server-Netzwerkschnittstellen: Fehler beim Suchen
               des angegebenen Servers/der angegebenen Instanz
               [xFFFFFFFF].
DBPROP_INIT_DATASOURCE: SRV003\SQLEXPRESS
DBPROP_INIT_CATALOG: master
DBPROP_AUTH_INTEGRATED: SSPI

Nachdem ich da nicht weiter wusste (diverse Dinge überprüft, wie bspw. die Zugriffsberechtigungen auf die Datenbank etc.), habe ich dann erstmal die SQL-Datenbanken in Veeam von der Sicherung ausgeschlossen. Ein Backup lief dann für den Server durch. Anschließend habe ich mir ein Script zur Datenbank-Sicherung erstellt, welches eigentlich als geplante Aufgabe täglich einmal durchlaufen sollte. Dazu habe ich die von Microsoft bereitgestellte Anleitung verwendet: https://support.microsoft.com/en-us/kb/2019698

Beim Testen des Scripts in der Testumgebung lief alles glatt. Auf dem Produktivserver erhielt ich dann aber die Fehlermeldung, dass die Instanz „.\SQLEXPRESS“ nicht gefunden wurde (obwohl sie lief). Das hat mir zu denken gegeben. Nachdem ich das Script so angepasst habe, dass die Instanz „SQLEXPRESS“ nicht mehr benannt wird (also nur „.\“), konnte ein Backup erstellt werden. Somit war mir klar, dass die Instanz quasi „unsichtbar“ ist. Nachdem ich mir dann die SQL-Server-Konfiguration im SQL Server Configuration Manager angeschaut habe, insbesondere bei den Server-Protokollen und dies mit der Konfiguration in der Testumgebung verglichen hatte, stellte ich fest, dass das Protokoll „Shared Memory“ nicht aktiviert war. Nachdem ich das Protokoll „Shared Memory“ sowie zur Sicherheit auch noch „Named Pipes“ aktiviert und den SQL-Server neu gestartet hatte, lief das Backup-Script auch mit der Benennung der Instanz. Eine Überprüfung der VSS-Writer mit „vsadmin list writers“ zeigte nun auch den SQL-Writer mit an.

Also habe ich die Ausnahme aus Veeam wieder entfernt und das Backup gestartet, welches dann erfolgreich durchgelaufen ist.

Windows 10 Roaming Profile V5

Es gibt eine unschöne Erfahrung in Bezug auf Windows 10 zu teilen, die insbesondere für Admins von Windows-Netzwerken interessant sein dürfte. Und zwar habe ich festgestellt, dass es ein Problem mit servergespeicherten Profilen bei Windows 10 gibt: Statt nur den Roaming-Ordner auf dem Server zu speichern, wird der gesamte Profilordner kopiert.

Weiterlesen

Windows 10 RSAT

In meinem vorigen Beitrag hatte ich ja schon erzählt, dass ich Windows 10 nun auf meinem Arbeits-PC installiert habe. Eine grundlegende Funktion für meinen Job als Systemadministrator für Windows-Netzwerke fehlt allerdings. Na ja, „grundlegend“ ist möglicherweise übertrieben. Aber es ist schon sehr nützlich, die Remote Server Administration Tools (RSAT) auf dem eigenen Rechner zu haben. Sonst muss man sich immer per RDP auf einen der Server aufschalten, um von dort aus die quasi täglichen Aufgaben zu erledigen.

Weiterlesen

OS X möchte Änderungen vornehmen

Nachdem der Mail-Account bei einem Kollegen in Apple Mail neu eingerichtet wurde, erhielt er jedesmal beim Versuch, eine E-Mail zu versenden, den Hinweis „OS X möchte Änderungen vornehmen. Geben Sie Name und Passwort eines Administrators ein, um dies zu erlauben.“ mit dem weiteren Hinweis „OS X möchte den Schlüsselbund System verwenden.“. Die üblichen Schritte zur Fehlerbeseitigung, also Neustart des MacBooks, Prüfung/Reparatur des Schlüsselbundes, die Zugriffsrechte-Prüfung/Reparatur mit dem Festplattendienstprogramm sowie die Holzhammermethode, das Löschen des Anmeldeschlüssels unter ~/Library/Keychains, brachten nicht den gewünschten Erfolg. Ein Blick in die Kosole sagte zumindest, dass die Rules-Datei nicht geöffnet werden konnte und dass die Sandbox verhindert, dass Mail.app auf den Schlüsselbund zugreifen kann.

Mit Hilfe eines in Apple-Fragen versierteren Kollegen ließ sich dann feststellen, dass Apple Mail beim Versand von E-Mails diese mit dem Zertifikat, welches eigentlich für das VPN gedacht ist, verschlüsseln möchte. Nachdem wir den Haken für die S/MIME-Verschlüsselung in Apple Mail entfernt hatten, ging der Versand von E-Mails wieder Problemlos. Na ja, E-Mails werden jetzt mit dem Zertifikat signiert, aber das ist ja nicht weiter schlimm und verursacht keine Probleme. Apple Mail merkt sich zum Glück die zuletzt verwendete Einstellung und würde erst wieder verschlüsseln wollen, wenn man das Häkchen wieder aktiv setzt.

Wie konnte es nun dazu kommen? Initial wurde der Mac nur mit dem Mail-Konto eingerichtet. VPN kam erst einige Zeit später hinzu. Mail hat also die ganze Zeit sowieso nicht auf das Zertifikat zugegriffen. Erst nachdem es aufgrund eines Fehlers im Mail-Konto nötig war, das Mail-Konto neu einzurichten, hat Apple Mail nachgeschaut, ob es ein Zertifikat im System findet, welches die Identität des angemeldeten Nutzers nachweist, mit dem es E-Mails verschlüsseln kann. Da es fündig wurde, hat es also als Standardeinstellung dieses eigentlich für VPN gedachte Zertifikat genommen. Und da das Zertifikat im System-Speicher liegt, ist dafür ein administrativer Zugriff nötig.