Benzinpreis-Monitoring mit Icinga 2

Was brauchen Autos neben Öl? Richtig: Sprit. Und dieser sollte natürlich möglichst günstig sein. Das Bundeskartellamt hat 2013 die Markttransparenzstelle für Kraftstoffe (MTS-K) ins Leben gerufen. Viele Tankstellen müssen die Preise für Super E5, Super E10 und Diesel an die MTS-K melden. Diese gibt dann die gesammelten Daten an Verbraucher-Informationsdienste weiter. Ein solcher Verbraucher-Informationsdienst ist Tankerkönig.de. Dieser Dienst ist besonders hervorzuheben, da er neben dem Webinterface auch eine API für all die bereitstellt, die selbst mit den Daten arbeiten wollen. Leider sammelt die MTS-K keine Daten über die weiteren Kraft- und Hilfsstoffe wie Super Plus, Truckdiesel, Autogas, AdBlue usw. Deswegen findet man diese Preise auch nicht in der API von Tankerkönig wieder.

Ein weiterer bekannter Verbraucher-Informationsdienst ist http://www.clever-tanken.de. Die haben eine so hohe Nutzerzahl, dass sie neben den MTS-K Daten auch andere Kraft- und Hilfsstoffe aufführt. Diese werden durch User-Input zeitnah aktualisiert. Besser als nichts sind diese Daten auf jeden Fall.
Mit meinem Plugin check_clever_tanken kann man nun ganz einfach die aktuellen Preise in sein Icinga/Nagios-basierendes Monitoringsystem integrieren und eine Alarmierung bei niedrigen Preisen durchführen. Alle angebotenen Kraft- und Hilfsstoffe werden aus der Seite ausgelesen und dem Nutzer in Schön präsentiert. Für die maschinelle Verarbeitung (zum Beispiel Graphen malen) werden die gesammelten Daten zusätzlich als Performance Daten ausgegeben. Das Plugin ist dabei nach den Nagios Plugin Developer Guidelines entwickelt.

Die Installations- und Integrationsanleitung mit Beispielimplementierung befindet sich in der README des git-Repository. Fragen, Kritik und Verbesserungsvorschläge sind willkommen. Bitte denkt ein bisschen an die Betreiber der Webseite und holt die Preise nicht minütlich ab. Ich hole mir aktuell alle 30 Minuten die Infos und das reicht vollkommen aus.

Ein Screenshot aus meinem Icinga Web 2:

Die Ausgabe für den Benutzer und die daraus erhaltenen Performancedaten

Apemen Wildkamera H65 Review

Meine Oma wollte wissen welche Viecher täglich die Terrasse und andere Orte rund ums Haus besuchen. Eine Wildtierkamera musste also her. Ich habe mich für eine relativ günstige von Apeman entschieden und durch einen Amazon Prime Deal nur 75 € bezahlt. Regulär kostet die Kamera ca. 90 €. Die Preisspanne geht bei solchen Produkten von 60 € bis 600 €.

Ich habe die Kamera nun ca. einen Monat im Einsatz und an diversen Orten ausprobiert und möchte euch meine subjektive Meinung zum Produkt mitteilen.

Gehäuse

Das Gehäuse ist IP 54 genormt und somit Spritzwassergeschützt. Starker Regen gefährdet somit nicht die Elektronik. Stellt man die Kamera falsch auf, dann kann es zu Wasseransammlungen vor der Linse kommen, da sich dieses bedingt durch die Oberlächenspannung in der Aussparung sammelt. Das Ergebnis sind dann unscharfe (wegen falscher fokusierung) oder verwaschene Bilder. Über die korrekte Positionierung kommt aber noch ein eigenes Segment weiter unten.
Die Rückseite ist in schwarz gehalten. Die Vorderseite hat eine Tarnmuster.

An der Vorderseite ist die Kameralinse, ein Blitz aus 42 schwarzen LEDs, eine rote LED, eine blaue LED und drei PIR Bewegungssensoren. Der Blitz wird in der Nacht verwendet und soll weder für Mensch noch für Tier sichtbar sein. Die rote LED und die blaue LED werden nur im Test-Modus verwendet, aber dazu später mehr.
Mit Hilfe der Bewegungssensoren wird beim erkennen einer Bewegung das Foto oder Video ausgelöst. Read More „Apemen Wildkamera H65 Review“

Das Programm „Spotify“ kann nicht geöffnet werden

Seit dem letzten Spotify Update (Aktuelle Version: 1.0.50.41368.gbd68dbef) kann ich Spotify nicht mehr mit zwei unterschiedlichen Accounts öffnen. Die Fehlermeldung im Titel ist das Resultat. Es gibt zwei Möglichkeiten das Problem zu lösen: Spotify neu installieren unter dem aktuellen Benutzer (zum Beispiel via brew) oder die Rechte richtig setzen. Die Neuinstallation von Spotify ist nur eine temporäre Lösung. Das setzen der Rechte ist eine dauerhaftere Lösung.

Eine Gruppe, die es auf jedem Mac gibt heißt „everyone“ und jeder Account ist in dieser Gruppe. Ziel ist es Spotify von jedem Account, der in der Gruppe „everyone“ ist startbar zu machen. Das geht mit zwei Befehlen im Terminal:

:~$ sudo chown -R $USER:everyone /Applications/Spotify.app
:~$ sudo chmod -R 775 /Applications/Spotify.app

Beim ersten Befehl wird man nach seinem sudo-Passwort gefragt. Das sollte das selbe sein, das man auch zum login benutzt. Falls es nicht klappt, dann ist man kein Admin auf dem Mac. Dann hilft nur der Gang zum Admin und höfliches Bitten.

Die Befehle kurz erklärt: Mit dem chown-Befehl ändert man die User- und Gruppenzugehörigkeit des Spotify-Verzeichnisses ab. Es wird als User der aktuell eingeloggte User und als Gruppe „everyone“ gesetzt. Mit dem chmod-Befehl erteilt man nun dem User und der Gruppe Lese-, Schreib- und Ausführungsrechte. Damit können nun alle Benutzer Spotify öffnen.

Eventuell muss nach dem nächsten Update der Vorgang wiederholt werden. Leider muss das nach jedem Update neu ausgeführt werden. Ist aber noch verkraftbar und schneller als jedes mal eine Neuinstallation zu starten.

Application „Spotify“ can’t be opened

Since the last Spotify update (Current version: 1.0.50.41368.gbd68dbef) you are not able to launch Spotify with different user accounts on your mac. The error message in the title is the result. There are two different solutions for this problem: You can reinstall Spotify every time you switch user (for example via brew) or you set the right rights in the filesystem. Reinstalling spotify every time is not the right way and can be pretty annoying. Setting the right rights is a better approach.

On every Mac there is a group called „everyone“. Every user account is in there so it would be nice when Spotify would be started if the user is in that group. You can easily achieve this with two commands in the terminal:

 

:~$ sudo chown -R $USER:everyone /Applications/Spotify.app
:~$ sudo chmod -R 775 /Applications/Spotify.app

You are asked for your sudo-password at the first command. This should be the same password as your login password. If that’s not going to work out for you then you are not an admin on that Mac. Please ask your admin for help.

The commands explained: With the chown command you change the user  and group membership of the Spotify directory in the filesystem. The currently logged in user will be set in the user part and „everyone“ as group. With the chmod-command the read, write and execute rights are changed so the current user and the group „everyone“ are allowed to do everything. Now every user can open Spotify again.

 

Maybe these steps have to be done again when the next Spotify update is released.

Insurgency Dedicated Server – crash_handler Prozess blockiert Port

Der Insurgency Dedicated Server für Linux hat seit einiger Zeit ein Stabilitäts-Problem. Wenn der Server crashed – was ja durchaus häufiger vorkommt – wird ein Crash-Dump für die Entwickler geschrieben. In diesem Fall wird der crash_handler-Prozess gestartet, der diesen dann an die Entwickler sendet. In der Prozessliste tauchen dann diese Prozesse auf:

[root@mineralwasser ~]# ps auxw | grep newworld
insurge+ 16353 100 0.0 21428 4612 pts/2 Rl+ 2016 4339:54 ./crash_handler 16350 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 31057 100 0.0 21428 4540 pts/2 Rl+ 14:59 10:39 ./crash_handler 31054 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 32614 100 0.0 21428 4776 pts/2 Rl+ 2016 3838:20 ./crash_handler 32611 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1

Es ist zwar cool, dass es so etwas gibt, jedoch hat dieser Prozess drei große Probleme. Der Prozess

  1. läuft endlos
  2. belegt permanent einen CPU Kern zu 100%
  3. verhindert das der Port des Gameservers freigegeben wird. Wenn der Server dann neu starten will, dann kann er auf diesen nicht binden. Daraufhin wird so lange hochgezählt, bis ein freier Port gefunden wurde. Das Resultat für die Spieler: Der Server verschwindet aus der Favoritenleiste, da der Server auf Port 27016 und nicht auf 27015 läuft.

Ich habe dazu ein Ticket bei New World Interactive eröffnet. Dort wurde mir sehr schnell gesagt, dass das Problem bekannt ist. Nun ja ich warte nun schon etwas länger darauf, deswegen habe ich einen Workaround gefunden. In die Crontab des UNIX-Gameserveraccounts einfach folgenden Eintrag hinzufügen:

# Kill the insurgency crash_handler process
*/1 * * * * /usr/bin/pkill crash_handler

Das funktioniert, da der Server dem crash_handler Prozess ein bisschen Zeit gibt, bevor der Server neustartet. Gerade genug, damit der Cronjob aktiv werden kann.

Insurgency Dedicated Server – crash_handler process blocks port

The insurgency dedicated server for linux currently has some problemes with its stability. If the server crashes – which happens quite often – a crash dump file is written and sent to the developers for further review. There’s a special binary named crash_handler which sends the dump file. When starte the process list looks like this:

 

[root@mineralwasser ~]# ps auxw | grep newworld
insurge+ 16353 100 0.0 21428 4612 pts/2 Rl+ 2016 4339:54 ./crash_handler 16350 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 31057 100 0.0 21428 4540 pts/2 Rl+ 14:59 10:39 ./crash_handler 31054 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 32614 100 0.0 21428 4776 pts/2 Rl+ 2016 3838:20 ./crash_handler 32611 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1

It’s okay that such a mechanism exists if it wouldn’t have three problems. The process:

  1. never finishes
  2. blocks 100% of a CPU core
  3. prevents the release of the gameserver port. For me that’s the main problem. If the new server is started after a crash the port is still blocked. The gameserver then seeks for the next free port. It won’t show up in you favourite list anymore because it binds then for example on port 27016 and not on 27015.

I’ve opened a ticket at New World Interactive. They told me pretty quick that the problem is known. For now I’m already waiting a bit long for a fix. I’ve found a workaround. Place the following command snippet in the gameservers‘ UNIX user:

# Kill the insurgency crash_handler process
*/1 * * * * /usr/bin/pkill crash_handler

This will kill the crash_handler-process every minute. The gameserver gladly gives the crash_handler-process enough time bevore the server finally restarts. Just enough that the cronjob can kick in and force the „release“ of the port.

UniFi Controller: TLS Zertifikat tauschen

Ich habe sehr lange die D-Link DAP-1665 für mein WLAN an meinen Wohnorten benutzt. Leider bin ich vom Handling und von der Performance her nicht wirklich überzeugt gewesen und habe deswegen auf Access Points von Ubiquity Networks geupgraded. Genauer gesagt auf die UniFi AP AC Lite.
Hersteller: https://www.ubnt.com/unifi/unifi-ap-ac-lite/
Amazon: http://amzn.to/2hMw3Fi

Die Besonderheit bei diesen Geräten ist, dass die Access Points von einem Controller gesteuert werden. Die WLAN Einstellungen und viele weitere Optionen werden zentral über dieses Managment Tool gesteuert. Im professionellem Umfeld  ist ein arbeiten ohne Controller überhaupt nicht denkbar. Im privatem Umfeld sind solche Systeme nicht üblich, da sie normalerweise sehr teuer und umständlich sind. Ubiquity hat mit seinen 100 € Access Points und kostenloser Controller Software aber ein tolles Produkt für dein Heimanwender geschaffen. Ein ganzes Haus zum Beispiel mit 4-8 Access Points effizient abzudecken sind somit kein Problem mehr.

Die Controller Software ist in Java implementiert und hat als Benutzerschnittstelle eine Weboberfläche. Diese ist standardmäßig mit TLS abgesichert, jedoch muss dazu ein valides Zertifikat erstellt werden, damit der Browser nicht permanent vor einer unsicheren Verbindung warnt.
Um die Weboberfläche mit einem eigenen SSL/TLS Zertifikat auszustatten, muss man ein bisschen basteln, da diese keine Möglichkeit zum Austausch bietet. Read More „UniFi Controller: TLS Zertifikat tauschen“

Sinusbot auf Debian 8

Der einzig gute TeamSpeak 3 Musikbot ist Sinusbot. Zumindest habe ich bis jetzt keine anständige Alternative gefunden. Das Problem mit TeamSpeak 3 ist, dass es eine GUI braucht. Auf Headless Servern kann man mit einem falschen X11 Server GUI Anwendungen laufen lassen. Leider ist die Codebase von Sinusbot nicht öffentlich verfügbar. Hinzu kommt, dass Sinusbot aktuell nur in einer Beta Version verfügbar ist.

Voraussetzung ist eine Debian 8 Headless Linux Server in der 64 bit Variante. 32 bit Installationen sind nicht kompatibel mit dem Sinusbot.

Am Anfang eine kleine Vorgeschichte

Auf der Entwicklerseite wird Sinusbot in der Version 0.9.8 angeboten. Dieser läuft aber auf keinen meiner getesteten Linux Versionen. In der Installationsanleitung wird nicht die normale Version verwendet, sondern Sinusbot in der Version 0.9.11-ee30ef7. Diese läuft aber auch nicht. Erst wenn man die Seite genauer ansieht, dann findet man sozusagen eine Beta Version von der Beta Version 0.9.12.2-58b509d und diese funktioniert auch.

Das Projekt hat eine schöne Homepage, aber wenn der Quellcode öffentlich wäre, dann könnte man selbst Versionen aus dem Git bauen. Vor jedem Systemupdate sollte man ein Backup von der kompletten Festplatte machen.

Vorbereitung

Abhängigkeiten und anlegen eines User Accounts

Read More „Sinusbot auf Debian 8“

Ubuntu und OpenVPN: Gepushte DNS Server Systemweit bekannt machen

Um mich mit meinem Heimnetzwerk zu verbinden benutze ich OpenVPN. Der Endpoint liegt auf meiner pfSense Firewall. Dort kann ich eine fertige OpenVPN Konfigurationsdatei erzeugen, in der alle benötigten Zertifikate und Verbindungsdetails hinterlegt sind.
In Ubuntu kann man diese Konfiguration in den Network Manager importieren. Leider funktioniert das nicht so wirklich. Selbst wenn man manuell diese Einstellungen ändert und manuell DNS Server setzt, werden diese nicht Systemweit bekannt gemacht. Das Resultat ist eine stehende Verbindung, jedoch ohne Namensauflösung. Surfen an sich macht dann nicht viel.

Auf den Network Manager werde ich also erstmal wieder verzichten, da ich bei einer VPN Verbindung nicht an drei verschiedenen Programmen rumdoktern will. Ich benutze als Fallback also das Terminal.
Mein OpenVPN Server pushed die IP Adressen des DNS Servers. Damit diese nun Systemweit bekannt ist hat man ein paar Möglichkeiten.

Unelegante Lösung: /etc/resolv.conf anpassen

Diese Lösung ist nicht elegant, da ich hier wieder manuell am System rumschrauben muss. Bei Linux konfiguriert man in dieser Datei alle DNS Server, die zur Namensauflösung verwendet werden sollen. Read More „Ubuntu und OpenVPN: Gepushte DNS Server Systemweit bekannt machen“