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

07. 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.

"Entdecken"-Schaltfläche in der ownCloud/Nextcloud News-App ausblenden

29. Juni 2016 · Anwendungen · andreas · Kein Kommentar

news_app_entdecken Leider haben die Entwickler der ownClould/Nextcloud News-App keine Möglichkeit vorgesehen, den “Entdecken”-Button am Ende der Feed-Liste auszublenden.

Änderungen am Code sind zwar problemlos möglich, haben aber den Nachteil, daß sie nach jedem Update der App erneut eingepflegt werden müssen.

Ein einfachere Möglichkeit ergibt sich durch Nutzung eines Custom Themes:

Im “/themes”-Ordner einen Ordner mit beliebigem Namen (der Name dieses Ordners ist dann gleichzeitig der Name des Themas) anlegen und in diesem die Ordner-Hiearchie “apps/news/css” erzeugen.

In diesem CSS-Ordner dann eine Datei namens “custom.css” mit folgendem Inhalt erzeugen:

	#app-navigation > ul > li.explore-feed {
 display: none;
 }

Anschließend muß das Theme noch aktiviert werden:

In der Datei “config/config.php” die Zeile

config/config.php
'theme' => 'NameDesThemas',

einfügen und die Seite im Browser neu laden.

Reset der Synology Photo Station

23. Juni 2016 · Anwendungen · andreas · 8 Kommentare

Nachdem die Datenbank der Photo Station leider beschädigt war, musste sie zurückgesetzt werden.

Symptome waren u.a. Meldungen in der Form

	Jun 14 21:11:06 mynas synoindexplugind: Failed to run PQexec: ERROR: duplicate key value violates unique constraint "image_label_ukey"
Jun 14 21:11:06 mynas synoindexplugind: photo_database.cpp:3708 Failed to exec [INSERT INTO photo_image_label (image_id, label_id, info_new, status) VALUES(61877, 29, '', 't')] (ERROR: duplicate key value violates unique constraint "image_label_ukey"
Jun 14 21:11:06 mynas synoindexplugind: photo_database.cpp:1434 PhotoInfoDBImageLabelDataAdd failed for /volume1/photo/Dateiname, iPhotoId: 61877, iLabelId: 29

in der Datei “/var/log/messages”. Eine Neuinstallation der Photo Station brachte nicht die erhoffte Besserung, beim erneuten Indizieren trat der Fehler wieder auf, denn die Datenbank bleibt bei der Deinstallation des Paketes erhalten.

Also musste die Kommandozeile mit psql ran.

Die Anmeldung gelingt unter DSM 5.2 mit dem Benutzer “postgres” problemlos:

	mynas> psql -U postgres
psql (9.3.6)
Type "help" for help.

Anschließend kann über “\list” eine Liste der installierten Datenbanken aufgerufen werden:

	postgres=# \list
                               List of databases
    Name     |   Owner    | Encoding  | Collate | Ctype |   Access privileges
-------------+------------+-----------+---------+-------+-----------------------
 ........... | .......... | SQL_ASCII | C       | C     |
 photo       | postgres   | SQL_ASCII | C       | C     |
 ........... | .......... | SQL_ASCII | C       | C     |

in der auch die zur Photo Station gehörende Datenbank aufgelistet wird.

Diese kann dann mittels

	postgres=# drop database photo;
DROP DATABASE

gelöscht und der Kommandozeilen-Client mit

	postgres=# \quit
mynas>

verlassen werden. Bei der anschließenden Neuinstallation legt die Photo Station die Datenbank wieder an und fängt an, diese (hoffentlich fehlerfrei) zu befüllen.

MODIFY FILE failed. Size is greater than MAXSIZE. (Microsoft SQL Server, Error: 5040)

06. Juni 2016 · Anwendungen · andreas · Kein Kommentar

Sofern versucht wird, in den Datenbank-Eigenschaften die maximale Dateigröße des Transaktionslogs auf einen Wert kleiner als die tatsächliche Dateigröße zu setzen wird dies vom SQL-Server mit einem

MODIFY FILE failed. Size is greater than MAXSIZE.
(Microsoft SQL Server, Error: 5040)

quittiert. Erste Suchergebnisse führen in der Regel zu Lösungsvorschlägen unter Verwendung des Befehls “backup log [DATENBANKNAME] with truncate_only”, welche von neueren Versionen des Microsoft SQL-Servers (2008 und später) mit der Fehlermeldung “’truncate_only’ is not a recognized BACKUP option.” quittiert werden.

Stattdessen muss zur Anpassung der Dateigröße das Recovery-Modell geändert werden. Hierzu wird zuerst das aktuell verwendete Modell ermittelt

	SELECT name, recovery_model_desc FROM sys.databases
 GO

dann wird im nächsten Schritt das Modell auf “Simple” geändert:

	ALTER DATABASE [DATENBANKNAME]
 SET RECOVERY SIMPLE;
 GO

Nach Ermittlung der anzupassenden Datei

	SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
 FROM sys.database_files;

kann dann mittels

	DBCC SHRINKFILE ('LOGDATEINAME', GROESSEINMB);
 GO

die Datei auf den gewünschten Wert verkleinert werden.

Als letzter Schritt sollte dann das Recovery-Modell wieder auf den Ausgangswert (i.d.R ‘FULL’) zurückgesetzt werden :

	ALTER DATABASE [DATENBANKNAME]
 SET RECOVERY FULL;
 GO