Facebook hat den RSS-Feed für öffentliche Seiten am 28. Januar 2015 wie angekündigt eingestellt und ähnelt damit einer modernen, auf Sicherheitsgefühl getrimmten Siedlung: man baut einen großen Zaun ums komplette Areal und achtet peinlich genau darauf, daß man unter sich bleibt.

Das alles wäre kein Problem, wenn nicht - wie vor Jahren schonmal bei Myspace - einige Bands dazu übergehen würden, ihre Neuigkeiten nur noch im “sozialen Netzwerk” zu veröffentlichen und die Pflege einer eigenen Internetpräsenz weitestgehend einzustellen.

Möchte man weiter mitlesen, so ist als Nicht-Facebook-Nutzer Bastelarbeit angesagt:

Zum einen benötigt man einen Facebook-Account, der über die Facebook-Entwicker-Seite als Entwickler registriert werden muss - zwingende Voraussetzung für diese kostenlose Registrierung ist entweder die Angabe einer gültigen Mobiltelefon-Nummer oder einer gültigen Kreditkarte.

Als Entwickler legt man dann eine App an - Name, Sinn und Zweck sind beliebig, letztendlich benötigt man nur die App-ID sowie den App-Geheimcode, mit deren Hilfe man sich später automatisiert bei Facebook anmelden kann. Solange eine Seite öffentlich ist, reicht ein x-beliebiger Benutzer, um auf die öffentlichen Daten zugreifen zu können.

Das Zauberwort für den Zugriff lautet dann “Graph API”, für die Facebook neben dem kompletten SDK auch eine Online-Hilfe zur Verfügung stellt.

Glücklicherweise muss man das Rad allerdings nicht neu erfinden:

Nachdem die Lieblingssuchmaschine mit den richtigen Begriffen gefüttert wurde, landet man z.B. auf GitHub bei “facebook-json-to-rss”, einem kleinen Skript, das Login sowie die mühevolle Aufgabe der Konvertierung von JSON nach RSS bereits erledigt.

Nach dem Eintragen der App-Daten in die entsprechenden Stellen im Skript kann der Aufruf über das Anhängen des gewünschten Seitennamens

/index.php?page=PageNameHere

erfolgen und liefert die XML-Daten für den RSS-Feed zurück.

In der ursprünglichen Variante benötigt das nur 3.72 KB Skript noch das SDK, das zwar ebenfalls nicht allzu groß ist, aber lediglich zur Anmeldung verwendet wird.

Im Zugriffsschlüssel-Hilfsprogramm kann man sich das App Token der zuvor angelegten App anzeigen lassen und dieses direkt als “$access_token” im Skript verwenden. Nach Auskommentieren (oder löschen) des SDK-Includes sowie des Token-Abrufs funktioniert “facebook-json-to-rss” dann auch ohne SDK.

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.

Eigentlich sollte man bei einem renomierten Hersteller wie Marantz davon ausgehen, daß Software nicht einfach irgendwie zusammengestrickt und auf die Geräte losgelassen wird, sondern ein Teil des Gerätepreises dafür verwendet wird, Prozesse zu durchdenken und sinnvoll zu gestalten.

Wer allerdings einmal erlebt hat, was passiert, wenn ein Firmware-Update auf einem Marantz Netzwerkplayer in ein Problem läuft, dem kommen unweigerlich Zweifel an dieser These:

Das Gerät meldet die Verfügbarkeit einer neuen Firmware-Version und bietet deren Installation an. Wer hier “Installieren” wählt, wählt eine Einbahnstraße, an deren Ende entweder eine aktuelle(re) Firmware installiert ist oder das Gerät dem technischen Kundendienst einen unfreiwilligen Besuch abstatten darf.

Ab dem Punkt, an dem die Installation einmal gestartet wurde, gibt es nur noch eine Schleife “Try - Error - Repeat”, die sich nicht mehr unterbrechen lässt. Die Möglichkeit, wie bei den Amps im Notfall einen Reset durchzuführen, funktioniert nicht und auch nach dem Ziehen des Netzsteckers, das nach 10 Stunden Endlosschleife und der wenig erbaulichen Fehlermeldung

ConnectionFail: A4
18min
NET(IMG)

als gar nicht so schlechte Option erscheint, führt lediglich dazu, daß auf dem Display wieder

Update Retry
Bitte warten …

steht und die Schleife wieder von vorne beginnt.

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.

Während sowohl Zugriffe des Hosts als auch der virtuellen Maschine auf beliebige Netzwerk-Ressourcen ohne Problem verlaufen, kam es beim Kopieren von Dateien zwischen Host und dem Windows Virtual PC immer wieder zu Geschwindigkeitseinbrüchen, die mit Transferraten um 25kb/sec an die guten alten Modem-Zeiten erinnerten.

Zwar ist Nostalgie in ruhigen Momenten ab und an willkommen, im Alltagsgeschäft aber in der Regel unerwünscht, weshalb eine Lösung für die Performance-Einbrüche gesucht und im Microsoft Knowledge Base-Artikel KB888750 “Slow performance when you try to access resources on your Virtual Server 2005 host computer from a guest virtual machine” auch gefunden wurde.

Zwar ist der Mircosoft Virtual PC in der Liste der “Applies to” nicht enhalten, das Setzen des in Methode 2 beschriebenen Registrierschlüssels

DisableTaskOffload

als DWORD mit Wert 1 im Pfad

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

löst das Problem aber trotzdem.