XEP-0156 auf XMPP aktivieren

geralt / Pixabay

Die Erwartungen an einen XMPP-Server steigen ständig. Deshalb bin ich bemüht meinen auf Prosody basierenden XMPP-Server stets auf dem neueseten Stand der Technik zu halten.

Gestern fiel mir jedoch auf, dass mein XMPP-Server den Complience-Test von Daniel Gultsch, dem Entwickler von Conversations, nicht mehr komplett bestehen konnte. XEP-0398: User Avatar to vCard-Based Avatars Conversion und Contact Addresses for reporting abuse konnten recht schnell aktiv gesetzt werden. Bei der Gelegenheit habe ich auch die Möglichkeit geschaffen Avatare für Chaträume einzubinden.

Ein größeres Problem hatte ich hingegen mit der Aktivierung von XEP-0156: Discovering Alternative XMPP Connection Methods (HTTP). Hierzu musste eigentlich nur im Webroot das Verzeichnis .well-known erstellt und dort eine Datei host-meta mit folgendem Inhalt erzeugt werden.

Wer noch keinen Account hat, kann sich hier registrieren.

Viel Spaß!

Prosody inaktive User löschen

Im Artikel „Prosody – inaktive User ausfindig machen“ hatte ich beschrieben, wie man nach inaktiven XMPP-Accounts in Prosody suchen kann. Eine elegante Möglichkeit diese User wieder loszuwerden zeigt Thomas Leister auf seinem Blog. 

Ich habe mich für meinen XMPP-Server entschieden, Accounts welche drei Monate inaktiv waren zu löschen. Hierzu erstelle ich lt. Anleitung ein Script.

Dieses wird dann im Anschluss ausgeführt. 

Danach sind alle inaktiven User des zuvor erwähnten Zeitraums vom drei Monaten vom Server gelöscht.

XEP-0368 auf dem Prosody XMPP-Server

Letztes Wochenende hatte ich den ComplianceTester von Daniel Gultsch durchlaufen lassen und gesehen, dass enige XMPP-Erweiterungen (XEP) nicht aktiviert waren. Die größten Probleme hatte ich bei der Suche nach einer Lösung zur Aktivierung von XEP-0368. Schlußendlich half mir die Anleitung von Dominion auf adminforge.de.

Hier meine Änderungen am XMPP-Server intux.de:

Zuerst wurde sslh installiert.

An dieser Stelle wurde ein „eigenständiger Server“ ausgewählt.

Dann musste die Datei /etc/apache2/ports.conf (Apache2) mit

von 

in

geändert werden. Im Anschluss wurde in die /etc/prosody/prosody.cfg.lua (Prosody) mit 

die Zeile 

eingefügt. In der /etc/default/sslh musste via

der Eintrag

gesetzt werden. Die vorhandene DEAMON_OPTS kommentierte ich aus und fügte

darunter ein. Nun musste das Verzeichnis /etc/sslh/ erstellt werden.

Dann wurde eine /etc/sslh/sslh.cfg mit folgendem Inhalt via

erstellt. Die Dienste Prosody, Apache2 und sslh wurden im Anschluss neu gestartet.

Ob die IPs und Ports richtig konfiguriert sind, zeigte die Ausgabe von:

Die Records für den XMPP-Server wurden wie folgt gesetzt.

Records
Records des XMPP-Servers

Abschließend konnte ich via openssl erfolgreich die HTTPS-Vervindung testen.

Der Status zum XMPP-Server intux.de kann man hier abfragen.

Prosody – inaktive User ausfindig machen

Da Spam-Registrierungen unter XMPP an der Tagesordnung sind, wird es immer mal wieder notwendig inaktive Accounts wieder los zu werden.

Mit folgendem Befehl kann man entsprechende User innerhalb des letzten Jahres  auf seinem Prosody XMPP-Server ausfindig machen. Vorausgesetzt man hat die entsprechenden Community-Module mod_list_inactive sowie mod_lastlog installiert.

Der Zeitraum lässt sich mit day, week oder month natürlich auch kürzer fassen.

Das Ganze funktioniert natürlich auch umgekehrt. Hierfür ist das Modul mod_list_active nötig.

Prosody Admin Web

Das Neuaufsetzen von Prosody auf einen Server mit Debian 9 lief bei mir mal wieder nicht ganz ohne Probleme. So hatte ich erst am Wochenende festgestellt, dass es nicht möglich war einzelne Usern zu löschen. Die letzten Spam-User-Registrierungen, wollte ich aber schnell wieder los werden. Der Lösch-Befehl

brachte in /var/log/prosody/prosody.err eine Fehlermeldung mit dem Hinweis auf ein Upgrade der neuen Datenbank. Dies war notwendig, da Prosody zuvor auf MySQL lief. Debian 9 hingegen nutzt MariaDB. Dieser Fehler konnte nun recht einfach mit

behoben werden.

Nun fiel mir aber noch ein weiteres Problem ins Auge. Seit einiger Zeit nutze ich das Modul mod_admin_web. Auch hier konnte ich mich nicht mehr im Webinterface einwählen.

Prosody – Admin Web

Die Ursache bestand darin, dass ich das Modul wie in der offiziellen Beschreibung

zwar in die prosody.cfg.lua eingebunden hatte, jedoch die Installation im Nachgang nicht ausgeführt hatte.

Da meine Community-Module in /usr/lib/prosody/prosody-modules liegen, sah die Lösung dann wie folgt aus:

Der Systemstatus sah danach nun wieder unauffällig aus:

Und immer wieder Servercow

Mein Umstieg auf Debian 9

Aus IT-technischer Sicht sollte man Web- und Mailserver auf getrennten Systemen laufen lassen. Da ich aber meinen Server privat betreibe und das Ganze mehr ein Hobby ist, laufen bei mir Web- und Mailserver auf einem Host. 

vServer, Servercow
Übersicht der laufenden Prozesse mit htop

Angefangen hatte ich mit Debian 8 auf dem bisher meine Seite intux.de lief. Parallel dazu hatte ich einen Mailserver mit Mailcow 0.14 aufgesetzt. Beides arbeitete bisher ohne Probleme und es gab eigentlich keinerlei Bedarf hieran irgendetwas zu ändern, da Debian 8 als LTS noch bis Ende April 2020 unterstützt wird.

Da ich aber mein System auf die aktuelle Version Debian 9 Stretch anheben wollte, musste ich mir Gedanken machen, wie das am besten zu realisieren ist. Da es momentan kein Upgrade für Mailcow 0.14 gibt und diese Version nicht auf dem aktuellen Debian Stretch läuft, kam für mich nur die Container-Variante Mailcow Dockerized in Frage.

Ein Upgrade auf Debian 9 wäre natürlich möglich gewesen, jedoch habe ich mich dazu entschlossen Stretch auf einem separaten Server zu installieren und alle Dienste nacheinander rüber zu holen. Dieses Vorhaben konnte ich ohne Zeitdruck auf Servercow realisieren. Der grandiose Support von André Peters war hierbei mehr als hilfreich. Bei einigen Problemen hatte ich so einen kompetenten Ansprechpartner, der sehr schnell auf Anfragen reagierte.

Da Mailcow Dockerized autonom und aus dem System herausgelöst in einer eigenen Virtualisierung arbeitet, wär mein Apache 2 mit dem Webserver Nginx in Dockerized kollidiert. Hierzu war es notwendig einen Reverse Proxy auf dem Apache, wo mein Blog läuft, einzurichten. Des Weiteren konnten von meinem frischen System keine Mails über PHP abgesetzt werden. Auch hier musste ich mich in eine für mich neue Thematik, einen Local MTA, einarbeiten, welcher dann u.a. Systemnachrichten an Mailcow Dockerized zum Versenden übergibt. 

Fazit

Den Server parallel einzurichten und alle Dienste nach und nach umzuziehen stellte sich aus der Situation als die richtige Entscheidung heraus. Ich war so nicht gezwungen alles am Stück wieder zum Laufen zu bringen. Mailcow Dockerized ist leicht zu installieren und ohne ewige Konfiguration sofort einsatzbereit. Trotz zwei nun nebeneinander arbeitender Webserver läuft das gesamte System performanter als vorher. 

Ich habe mich zur Verwirklichung meiner kleinen Projekte vor fast 10 Monaten bewusst und aufgrund guter Kritiken für Servercow entschieden. Bei Problemen am Server und speziell mit Mailcow steht ein kompetenter Ansprechpartner zur Seite. Diesen Schritt habe ich zu keinem Zeitpunkt bereut. Sicher hat man mit einem eigenen Server einiges an Arbeit und Verantwortung auf dem Schirm, aber man ist dafür wesentlich flexibler. Dafür bietet Servercow ein gutes Zuhause.

http-upload in Prosody aktivieren

Um nun auch Bilder in den XMPP-Chaträumen versenden zu können, habe ich den http-upload in Prosody aktiviert. Dazu wurde zuerst ein A-Record für die Subdomain upload.intux.de angelegt. Danach musste mein Let’s Encrypt Zertifikat, welches für intux.de und www.intux.de gültig war, noch erweitert werden.

Im Anschluss wurden die Zertifikate noch in das entsprechende Verzeichnis /etc/prosody/certs kopiert.

Ich habe die Config von Prosody geöffnet.

Diese wurde um die Einträge

und 

erweitert. Danach wurde Prosody neu gestartet und http-upload aktiviert.

Tipp

In Gajim muss das Plugin HttpUpload nachinstalliert werden.

Unerwünschte Anmeldungen in Prosody

Seit einiger Zeit kommt es auf meinem XMPP-Server immer wieder verstärkt zu Registrierungen von Spam-Accounts. Die neuen User sehen dann in etwa so aus:

l0v382l0stdust348@domain.tld

Das Schlimme dabei ist, dass solche Anmeldungen fast im Minutentakt erfolgen und sich so plötzlich dutzende neue unerwünschte Accounts in die Datenbank eintragen. Als erste Reaktion sperrte ich früher i.d.R. für eine gewisse Zeit die öffentliche Anmeldung. Da die Angriffe jedoch meist von ein und derselben IP kommen, kann man diese mit folgendem Eintrag in der /etc/prosody/prosody.cfg.lua recht erfolgreich abwehren.

Dazu setzt man dies entsprechende IP auf die Blacklist zur Registrierung. Hier ein Beispiel:

Dabei werden Registrierungen zwar erlaubt, jedoch nur alle 300 Sekunden. Die IP von der die Spam-Registrierungen ausging wird gesperrt.

Prosody kann auch nerven

Es hat einige Zeit gedauert bis ich den HTTP Server unter Prosody vernünftig einbinden konnte. Eigentlich wollte ich ja nur das Webinterface mod_admin_web nutzen. Egal wie ich es anstellte, ich bekam keinen Zugang, trotz Befolgung der Installationshinweise. 

Prosody Webadmin

Das Problem kam eigentlich nur zustande, da ich die Config aus meinem Artikel zur Installation des XMPP-Servers auf Uberspace übernommen hatte. Hierbei wurde der VirtualHost vor den SSL-Pfaden gesetzt. Dies macht aber den Zugang zum HTTP-Server unmöglich. 

Nachdem ich den VirtualHost, wie in meiner aktuellen Config nach den SSL-Pfaden eingetragen hatte, konnte ich endlich auch mein Webadmin wie gewünscht erreichen.

Auszug aus meiner alten Konfiguration bei Uberspace

Hier nun meine aktuelle prosody.cfg.lua: