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/";

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

Kerio Connect und fail2ban

Wer einen Mailserver betreibt, kennt das Problem, dass man neben den normalen E-Mails auch irgendwann höhere Mengen an Spam erhält. Bei dem von mir verwalteten Webserver mit Kerio Connect sind es so ungefähr 98% aller SMTP-Anfragen, die mit Spam zu tun haben.

Natürlich bietet Kerio Connect hier schon eine Auswahl an Antispam-Mechanismen an. So greift ein Spamassassin ein sowie verschiedene individuell zu gestaltende Spamfilter und Blacklist-Abfragen. Diese Möglichkeiten sollte man auf jeden Fall auch nutzen.

Das ändert aber nichts daran, dass der Mailserver immer wieder die gleichen Anfragen von den denselben Spam-Servern annehmen und verarbeiten muss. Hinzu kommen noch Script-Kiddies, die irgendwann auf den Webmailer aufmerksam werden und dort mit Exploit-Scripts versuchen, irgendwie Zugriff zu erlangen.

An dieser Stelle kommt dann das Tool fail2ban ins Spiel. Jedenfalls wenn man den Kerio Connect Server nicht unter Windows, sondern unter einem Linux laufen lässt.

Weiterlesen