Fryboyter

Über fehlgeschlagenen Service per XMPP informieren

Auf meinen Raspberry Pi’s laufen einige Dienste wie ein Q3A-Server. Diese zum Beispiel mit Zabbix zu überwachen ist mir dann doch etwas übertrieben, da diese Dienste entweder rein privat genutzt werden oder ich einfach keine Uptime garantiere.

Trotzdem wäre es dann doch interessant, wenn ich darüber informiert werde, wenn zum Beispiel ein Dienst nicht gestartet werden konnte. Vor allem, wenn man nicht daheim ist. Da ich auf meinem Smartphone auch einen XMPP-Client installiert habe, würde sich eine Lösung mittels XMPP und systemd anbieten.

Um die Nachrichten zu versenden habe ich mir sendxmpp installiert. Unter Arch findet man das Paket im AUR. Um zu testen, ob das Versenden überhaupt funktioniert, habe ich es gleich einmal ausprobiert.

echo 'Hallo Welt' | sendxmpp -t -u fryboyter -j jabjab.de -p 'strenggeheim' empfänger@deshalbfrei.org

Und schon knallt es und ich bekomme die Fehlermeldung “Invalid or unreadable path specified for ssl_ca_path. at /usr/share/perl5/vendor_perl/XML/Stream.pm line 641” vor den Latz geknallt. Dann schauen wir uns die Datei doch mal an. Zeile 641 verrät mir allerdings recht wenig. Allerdings gibt es in besagter Datei die Zeile $self->{SIDS}->{default}->{ssl_ca_path} = ‘’;. An deren Ende habe ich zwischen die beiden ’’ einfach mal /etc/ssl/certs eingetragen.

Nächster Versuch, nächste Fehlermeldung. Error ‘AuthSend’: error: bad-protocol[?]. Na das ist ja mal sehr aussagekräftig. Nach etwas Google-Fu konnte ich das Problem in der Datei /usr/share/perl5/vendor_perl/Net/XMPP/Protocol.pm ausfindig machen. In Zeile 2104 steht return $ self-> AuthSASL (% args);. Diese Zeile kommentieren wir einfach mal mit einem # am Anfang aus. Ich bin mir allerdings nicht sicher, ob das nicht irgendwelche Nebenwirkungen hat.

Und wieder ein neuer Anlauf. Und plötzlich informiert mich mein XMPP-Client, dass ich für empfänger@deshalbfrei.org eine Nachricht erhalten habe. Yeehaa!

Da nun die Benachrichtigungen per XMPP funktionieren, erstellen wir unter /usr/bin ein Shellscript (nennen wir es mal xmpp.sh) mit folgendem Inhalt.

#!/bin/bash

UNIT=$1

UNITSTATUS=$(systemctl status $UNIT)
ALERT=$(echo -e "\u26A0")

echo "$ALERT Unit failed $UNIT $ALERT Status: $UNITSTATUS" | /usr/bin/site_perl/sendxmpp -t  -u fryboyter -j jabjab.de -p 'strenggeheim' empfänger@deshalbfrei.org

Nun erstellen wir unter /etc/systemd/system die Service-Datei xmpp@.service mit folgendem Inhalt.

[Unit]
Description=Benachrichtigung mittels XMPP
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/xmpp.sh %I

Zum Schluss editieren wir noch die Service-Dateien der Dienste, die wir überwachen wollen und packen unter dem Bereich [Unit] die Zeile OnFailure=xmpp@%n.service.

Startet nun ein Service nicht erhält man automatisch eine Nachricht per XMPP, die beispielsweise so aussieht.

⚠ Unit failed monitorhell.service ⚠ Status: ● monitorhell.service - Tastaturbeleuchtung automatisch aktivieren
   Loaded: loaded (/etc/systemd/system/monitorhell.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2017-09-11 16:36:13 CEST; 1min 18s ago
  Process: 510 ExecStart=/bin/bashx -c echo 2219 > /sys/class/backlight/intel_backlight/brightness (code=exited, status=203/EXEC)
 Main PID: 510 (code=exited, status=203/EXEC)

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

Gajim - Nachricht beim Betreten und Verlassen eines MUC deaktivieren

Martin von mdosch.de hat gestern einen Multi-User-Chat für das OSBN erstellt. Der Idee an sich nicht abgeneigt, habe ich mich gestern und heute dort mit dem Client Gajim eingeloggt. An einer Stelle nervt das Teil aber.

Jedes Mal, wenn jemand den Chat betritt oder verlässt wird eine entsprechende Nachricht angezeigt. Das nervt. Also allgemein und nicht nur beim OSBN-MUC. Eine Möglichkeit dies über die normalen Einstellungen zu deaktivieren habe ich nicht gefunden. Daher habe ich ein paar Minuten einfach mal die Suchmaschine meiner Wahl gequält und bin fündig geworden…

Wenn man die Einstellungen von Gajim aufruft, findet man ganz rechts den Reiter “Erweitert”. Dort findet man dann ganz unten den “erweiterten Konfigurationseditor”. Dort muss man dann nach print_status_in_muc suchen und dort bei Wert none eintragen. Und schon hält Gajim die Klappe, wenn jemand den MUC verlässt oder betritt.

Prosody bei uberspace.de installieren

Jetzt habe ich es endlich mal in Angriff genommen, und versucht, den XMPP-Server Prosody auf meinem Uberspace zu installieren. Als Erstes habe ich mit per SSH eingeloggt. Das hat schon mal funktioniert… ;-) Als Nächstes habe ich mir den Source-Code heruntergeladen und diesen dann entpackt.

wget http://prosody.im/downloads/source/prosody-0.8.2.tar.gz

tar xzf prosody-0.8.2.tar.gz

Da mich Versionsnummern im Verzeichnisnamen nerven, habe ich noch schnell das Verzeichnis umbenannt und bin dann in das Verzeichnis gewechselt.

mv prosody-0.8.2 prosody

cd prosody

Laut Anleitung reicht ein ./configure aus. Hier habe ich mir überlegt, wann ich das zum letzten Mal gemacht habe. Ist auf jeden Fall lange her. Da ich aber vermutlich keinen Vollzugriff auf alle Verzeichnisse habe, habe ich daraus erst einmal ein ./configure –prefix=/home/benutzer/prosody gemacht, damit das Ganze im Homeverzeichnis installiert wird. Und schon bekam ich die erste Fehlermeldung um die Ohren.

./configure –prefix=/home/mathmos/prosody Lua interpreter found: /usr/bin/lua… Looking for Lua… Checking Lua includes… lua.h not found (looked in /usr/include/lua.h) You may want to use the flag –with-lua-include. See –help.

Er findet also die Datei lua.h nicht unter /urs/include/. Langsam habe ich mich wieder erinnert, wieso ich diese Installationsart schon ewig nicht mehr verwendet habe. Genau wegen solchen Sachen. Unter anderem. Also habe ich mir mal das Wiki von uberspace.de angesehen, was dort zum Thema LUA steht. Wenige Sekunden später hatte ich die Lösung. Das Zeug liegt hier unter /package/host/localhost/lua/. Dort gibt es dann ein Unterverzeichnis include in der die benötigte Datei liegt. Was sagt uns ./configure –help zu dem Thema? Eigentlich alles was man braucht. Also nächster Versuch…

./configure –prefix=/home/mathmos/prosody –with-lua-include=/package/host/localhost/lua/

Damit sollte lua.h nun zu finden sein. Und genau so war es dann auch. Das ganze lief ohne Probleme durch. Also gleich ein make hinterher. Auch das hat funktioniert. Jetzt wollte ich den Server zumindest einmal zum Testen starten. Also gleich mal das Teil mittels ./prosody aufgerufen. Und was soll ich sagen. Es funktioniert nicht, weil der Server einige LUA-Erweiterungen nicht findet. Da ich die vermissten Sachen auch nicht gefunden habe, habe ich gerade eine Anfrage an hallo@uberspace gestellt. Mit etwas Glück wird es nachgerüstet. Mit etwas Pech muss ich die Sachen selbst ins Homeverzeichnis installieren. Mit etwas mehr Pech funktioniert das nicht. Aber ich warte jetzt erst mal die Antwort ab.

Der XMPP-Server des FryBoyters

Ich verwende auf Benutzerseite schon seit geraumer Zeit XMPP / Jabber als Alternative zu ICQ, da dies unterm Strich meiner Meinung nach einfach besser ist. Mal von der Verbreitung abgesehen.

Gestern habe ich mich mal wieder im Wiki von Uberspace (meinem derzeitigen Webhoster) umgesehen und bin auf eine Anleitung gestoßen, wie man auf deren Webspace ejabberd (ein XMPP-Server) installiert. Und schon wieder hatte mein Spieltrieb die Kontrolle übernommen. Denn einen eigenen XMPP-Server wollte ich schon immer mal installieren. Nicht einmal um den bestehenden Servern Konkurrenz zu machen, sondern einfach um sich mit der technischen Seite auseinanderzusetzen. Da Uberspace auch Lua anbietet, werde ich es allerdings mit Prosody probieren. Sollte dies klappen werde ich wohl meine bisherigen Zugänge auf den eigenen Server umstellen. Wenn Interesse besteht und sich der Traffic und die Auslastung in Grenzen hält, könnte ich dann sogar für eine überschaubare Benutzerzahl Zugänge anbieten.

Ein neues Bastelprojekt ist also geboren.