Anwendungen

Exchange 2010 Update Rollups hängt beim Schritt "Stopping Services"

3. März 2017 · Anwendungen · andreas · Kein Kommentar

Bei der Aktualisierung eines Exchange 2010 Service Pack 3-Servers lief die Installaton des Update Rollups an, blieb dann aber im Schritt “Stopping Services” hängen: weder wurde die Anzahl an Systemprozessen geringer noch konnte in der Dienste-Verwaltung ein Fortschritt beobachtet werden - alle Dienste liefen ungestört weiter. Auch der Versuch, vor der Installation des Update Rollups die Dienste manuell zu stoppen wurde vom Installationsprogramm zuverlässig ignoriert.

Nachdem die eigenen guten Ideen aufgebraucht waren, führte die Google-Suche nach vielen sinnlosen Forentreffern schließlich zum Artikel “Installing Exchange Server 2007/2010 Update Rollups”, der zwar mit “Have you ever tried to install an Exchange Server Update Rollup which ended with an error message?” auf den ersten Blick ebenfalls nicht zum Problem passend aussah, aber mit dem Stichwort “PowerShell execution polices” genau den zielführenden Hinweis lieferte:

Das Installationsprogramm des Update Rollups scheint im Hintergrund einige PowerShell-Skripte zu starten (u.a. zum Stoppen der Dienste), überprüft aber vorher weder, ob die Ausführungsvoraussetzungen gegeben sind noch wird offentlichlich eine Auswertung der erfolgreichen bzw. erfolglosen Skriptausführung vorgenommen - mit dem Resultat, daß die GUI des Installers mitsamt Progressbar artig bis in alle Ewigkeit auf ein Skript wartet, das seine Aufgaben gar nicht beginnen konnte.

Nachdem die Berechtigungen mittels

Get-ExecutionPolicy –List

zunächst überprüft und dann vom ursprünglichen “Nur signierte Skripts” auf “Lokale und remote signierte Skripts zulassen” geändert wurde, lief die Installation des Update Rollups innerhalb weniger Minuten durch.


Der Dienst "SQL Server (SQLEXPRESS)" konnte nicht gestartet werden

19. Februar 2017 · Anwendungen · andreas · 2 Kommentare

Wenn Windows nach dem Systemstart plötzlich mit einem “Fehler 1069: Der Dienst konnte wegen einer fehlerhaften Anmeldung nicht gestartet werden.” vermeldet, daß ein Start des “SQL Server (SQLEXPRESS)” nicht möglich ist, so blickt man im ersten Moment ratlos auf den Bildschirm, denn in der Regel wurden dem Dienst keine expliziten Anmeldedaten zugewiesen.

Die Lösung des Problems ist einfach, wenn auch auf den ersten Blick nicht unbedingt intuituv:

  • Übersicht der Dienste öffnen

  • Den SQL Server Dienst mit der rechten Maustaste anklicken und “Eigenschaften” wählen

  • Zur Registerkarte “Anmelden” wechseln

  • Die Punkte in den Kennwort-Feldern löschen

  • Mit “OK” bestätigen

Dies sollte zur Meldung führen, daß Windows die benötigten Berechtigungen erneut zugewiesen hat und der Dienst sollte sich wieder starten lassen.

Sofern das Problem nach einiger Zeit erneut auftritt, sollte ein Blick in die Gruppenrichtlinien erfolgen, ob hier eine benötigte Einstellung fälschlicherweise überschrieben wird.


Microsoft SQL-Server mit Icinga2 überwachen

7. Januar 2017 · Anwendungen · andreas · Kein Kommentar

Soll ein Microsoft SQL Server (an der Stelle egal, ob Express- oder Vollversion) mit Icinga2 überwacht werden, so stellt der Name des Dienstes eine kleine Hürde dar:

Wird der Name mit “MSSQL$SQLEXPRESS” in der entsprechenden Argumentliste angegeben, so beschwert sich Icinga2 beim Überprüfen der Konfiguration mit

critical/config: Error: Validation failed for object '...' of type 'Service'; 
Attribute 'vars' -> 'nrpe_remote_arguments': 
Closing $ not found in macro format string '...!MSSQL$SQLEXPRESS'.

Ein im ersten Reflex eingefügtes Backslash-Zeichen vor dem Dollar-Zeichen löst das Problem nicht, führt aber zu einer neuen Fehlermeldung:

critical/config: Error: Bad escape sequence found: \$

Des Rätsels Lösung bietet - wie so oft RTFM - oder hier RTFAQ, denn dort steht:

How do I properly escape $ in strings
Dollar signs are “strange” in Nagios and has to be escaped using double $$s. Thus in Nagios config you need to put $$.


Icinga2 startet nicht mehr nach Debian-Systemupdate

23. September 2016 · Anwendungen · andreas · Kein Kommentar

Nach einem Systemupdate wird Icinga2 nicht mehr ausgeführt und apt-get meldet eine Reihe von Fehlern:

icinga2-common (2.5.4-1~debmon70+3) wird eingerichtet ...
Neue Version der Konfigurationsdatei /etc/icinga2/icinga2.conf wird installiert ...
Neue Version der Konfigurationsdatei /etc/icinga2/features-available/gelf.conf wird installiert ...
Job for icinga2.service failed. See 'systemctl status icinga2.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript icinga2, action "start" failed.
dpkg: Fehler beim Bearbeiten des Paketes icinga2-common (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
libicinga2 (2.5.4-1~debmon70+3) wird eingerichtet ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von icinga2-bin:
icinga2-bin hängt ab von icinga2-common (= 2.5.4-1~debmon70+3); aber:
Paket icinga2-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes icinga2-bin (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von icinga2-ido-mysql:
icinga2-ido-mysql hängt ab von icinga2-bin (= 2.5.4-1~debmon70+3); aber:
Paket icinga2-bin ist noch nicht konfiguriert.
icinga2-ido-mysql hängt ab von icinga2-common (= 2.5.4-1~debmon70+3); aber:
Paket icinga2-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes icinga2-ido-mysql (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von icinga2:
icinga2 hängt ab von icinga2-bin (= 2.5.4-1~debmon70+3); aber:
Paket icinga2-bin ist noch nicht konfiguriert.
icinga2 hängt ab von icinga2-common (= 2.5.4-1~debmon70+3); aber:
Paket icinga2-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes icinga2 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
..........
Fehler traten auf beim Bearbeiten von:
icinga2-common
icinga2-bin
icinga2-ido-mysql
icinga2
E: Sub-process /usr/bin/dpkg returned an error code (1)

Ausschlaggebend ist der Fehler in dem Paket “icinga2-common”, die Fehler in den restlichen Pakten sind Folgefehler.

Freundlicherweise gibt dpkg auch gleich einige Tips zur Fehlersuche aus

root@monitoring:~# systemctl status icinga2.service
 ● icinga2.service - LSB: icinga2 host/service/network monitoring and management system
 Loaded: loaded (/etc/init.d/icinga2)
 Active: failed (Result: exit-code) since Do 2016-09-22 09:17:37 CEST; 8min ago
 Process: 6270 ExecStart=/etc/init.d/icinga2 start (code=exited, status=1/FAILURE)
Sep 22 09:17:37 vm-00017 icinga2[6270]: checking Icinga2 configuration
 Sep 22 09:17:37 vm-00017 icinga2[6270]: checking Icinga2 configuration. Check '/var/log/icinga2/startup.log' for details. ... failed!
 Sep 22 09:17:37 vm-00017 systemd[1]: icinga2.service: control process exited, code=exited status=1
 Sep 22 09:17:37 vm-00017 systemd[1]: Failed to start LSB: icinga2 host/service/network monitoring and management system.
 Sep 22 09:17:37 vm-00017 systemd[1]: Unit icinga2.service entered failed state.

Systemctl liefert den Hinweis, daß beim Check der Konfiguration wohl etwas nicht passt, und verweist auf die Logdatei “/var/log/icinga2/startup.log”

root@monitoring:~# cat /var/log/icinga2/startup.log
 information/cli: Icinga application loader (version: r2.5.4-1)
 information/cli: Loading configuration file(s).
 information/ConfigItem: Committing config item(s).
 critical/config: Error: Error while evaluating expression: Tried to access undefined script variable 'PluginContribDir'

die dann auch mehrfach den kitischen Fehler “Tried to access undefined script variable ‘PluginContribDir’” anmerkt.

Ein Blick in die Datei “/etc/icinga2/constants.conf” zeigt dann auch, daß die Variable tatsächlich weder gesetzt noch vorhanden ist. Im Verzeichnis “/etc/icinga2/” liegt aber noch eine “constants.conf.dpkg-dist” mit neuerem Datum als die “constants.conf”, in der die Zeile

/* The directory which you use to store additional plugins which ITL provides user contributed command definitions for.
 * Check the documentation, chapter "Plugins Contribution", for details.
 */
 const PluginContribDir = "/usr/lib/nagios/plugins"

vorhanden ist. Nach Hinzufügen der Definition in die “constants.conf” kann dpkg das Paket “icinga2-common” erfolgreich konfigurieren:

root@monitoring:~# dpkg --configure icinga2-common
 icinga2-common (2.5.4-1~debmon70+3) wird eingerichtet ...

Ein “apt-get update” läuft anschließend für die abhängigen Pakete problemlos durch.


"Operation not permitted" beim Zugriff von Kodi auf ein Synology NAS

7. August 2016 · Anwendungen · andreas · 5 Kommentare

Schlagen Verbindungsversuche bei der Ersteinrichtung über das SMB-Protokoll von Kodi auf ein Synology-NAS mit “Operation not permitted” fehl, so können entweder die Zugangsdaten manuell im Ordner “.kodi/userdata/” in den Konfigurationsdateien “sources.xml” und “mediasources.xml” eingetragen oder alternativ für die Herstellung der initialen Verbindung das Guest-Account des NAS (re)aktiviert werden. Kodi versucht - sofern noch keine Zugangsdaten hinterlegt sind - zuerst eine Verbindung als “Guest”, bevor es überhaupt nach möglichen Zugangsdaten fragt.