ejabberd zu Prosody: Migration & Konfiguration

Endlich habe ich mein lange geplantes Projekt umgesetzt und meinen ejabberd-Server durch einen Prosody ersetzt. Hier eine kurze Übersicht für andere, die diesen Schritt auch planen.

Hintergründe – Warum der Wechsel?

Mein ejabberd hat mir in letzter Zeit immer öfter „consuming too much memory“-Fehlermeldungen gebracht, das hat mich ziemlich genervt (war aber vermutlich eine Konfigurations-Sache). Zudem hat der werte ejabberd immer wieder Einstellungen „vergessen“, was ziemlich ärgerlich war. Kurzum, er war schon immer ein wenig zickig und von der Konfiguration her stellenweise nicht sehr entgegenkommend (mag hier und da mein Fehler gewesen sein). Zudem ist ein Stream Management-Plugin nicht in absehbarer Zeit zu erwarten.

Warum Prosody?

Nun, Prosody ist relativ neu (2008) und sehr schlank, dafür umso einfacher zu erweitern. Da der/die Entwickler anderen gegenüber sehr offen sind, hat sich ein gesundes Ökosystem an Modulen gebildet. Eines davon hatte es mir besonders angetan – Überraschung – : Stream Management. Endlich ist es möglich, auch bei schlechter Verbindung verlässlich zu kommunizieren! 🙂

Was darüber hinaus wirklich spitze ist, ist der Support, den einem die Leute im MUC bieten – ich habe einige Stunden hier verbracht und eine Hand voll Leute haben sichwirklich viel Mühe gegeben (und sie waren Erfolgreich *g*), meine Fragen bestmöglich zu klären – danke nochmals!!

Installation Prosody – Mein Vorgehen

Während der ejabberd noch friedlich auf dem Server arbeitete, begann die Revolution. Es empfiehlt sich bei Debian-Systemen auf das Repository von prosody (Übersicht hier) zurück zu greifen, da hier immer die aktuellste Version zusammengeschnürt wird (0.6.1 in den ubuntu-Repos versus 0.8.2 in den Prosody-Repos).

Im Anschluss sollte man sich die Konfig-Datei  /etc/prosody/prosody.cfg.lua zu Gemüte ziehen. Sie ist glücklicher Weise recht schön dokumentiert. Hier muss man als erstes den Host auf die eigene Domain ändern. Bei der Verwendung von self-signed-certificates kann man zunächst einmal das aus der Konfiguration weiter oben kopieren und später ein neues erzeugen.

Ein weiteres Detail, das man beachten sollte ist, dass der Nutzer unter dem Prosody läuft auf /var/lib/prosody/* vollen Schreib- und Lesezugriff haben muss. Um herauszufinden, ob etwaige Probleme, z.B. mit den MUC-Bookmarks (nicht les- oder beschreibbar) daran liegen, kann man unter /var/log/prosody/prosody.log bzw. prosody.err nach Fehlermeldungen mit „Permission denied“ schauen. Bei mir ist das jedenfalls der Fall gewesen, lies sich durch die Rechtevergabe auf den Ordner aber  schnell beheben.

Migration ejabberd => Prosody IM

Nun, natürlich wollte ich die Nutzeraccounts samt allen Einstellungen und gespeicherten Daten erhalten. Glücklicherweise gibt es von den Prosody-Leuten hierfür ein Script, das sehr gut funktionierte: http://prosody.im/files/ejabberd2prosody (Update: Jens hat im Kommentar unten auf das Script bei Github verwiesen. Es ist rund 1.100 Zeilen kürzer und wohl einiges aktueller. Ich habe es selbst nicht getestet, bei ihm scheint es ja funktioniert zu haben – daher hier der nochmal sein Link: https://github.com/bjc/prosody/blob/master/tools/ejabberd2prosody.lua ). Auszuführen ist es in /var/lib/prosody/. Zunächst muss man jetzt auf der Konsole mittels
ejabberdctl dump filename.txt
die Daten aus der Datenbank von Ejabberd exportieren (sollte nicht die Standard-DB verwendet werden, weiß ich nicht, ob es geht -> an den Prosody MUC wenden). Das Migrations-Script führt man mittels
lua ejabberd2prosody pfadZurExportiertenEjabberdDatei
aus.
Zu beachten ist, dass der Pfad wo die Dateien hin sollen vom Skript nicht richtig erkannt werden kann und man ggf. noch den Ordner verschieben muss.
Das Skript hat bei mir alles übernommen, es hat sich nur an einer Stelle etwas verschluckt: meine hoch geschätzten Notizen (Storage-Notes) konnten nicht von Psi+ (hab es auch mit Miranda IM getestet) geladen werden. Hier knallte es irgendwie. Wer die Notizen wieder richten möchte, kann folgendermaßen vorgehen: Das private XML liegt unter /var/lib/prosody/<host>/private/<nutzername>.dat.
Das Problem (ich saß da echt ’ne Weile dran, bis ich endlich darauf kam) liegt darin, dass hier leere Attribute = {} gesetzt werden, was irgendwie nicht interpretierbar ist. Wenn man alle leeren geschweiften Klammern durch zwei Anführungszeichen („“) ersetzt, sollte es gehen. Darüber hinaus fügt Prosody bei neuen Notizen immer den Namespace hinzu, daher habe ich das auch gemacht:

["attr"] = {};

bzw.

["tags"] = {};

wurde somit zu

["attr"] = {
["xmlns"] = "http://miranda-im.org/storage#notes";
};

bzw.

["tags"] = "";

Dann ist alles wie gehabt vorhanden und man kann munter weiter damit arbeiten. Könnte man sich auch ein nettes kleines Script basteln, aber den Aufwand war es bei mir nicht wert (genau genommen war es auch den von mir betriebenen nicht wert, weil es nur um meine eigenen Notizen ging, aber egal *g*)

Module

Neue Module werden unter /usr/lib/prosody/modules abgelegt und in der oben bereits erwähnten Konfigurations-Datei aktiviert.

Wer Stream Compression nutzen will (bietet sich bei dem nicht gerade sparsamen XMPP-XML meines Erachtens an), muss unter Debian & Konsorten normal noch die Lua Erweiterung für zlib mittels sudo apt-get install lua-zlib herunterladen und installieren – sonst kann Prosody mit dem aktivierten Modul nichts anfangen. Danach kann man es in der Konfig-Datei aktivieren (und es läuft *g*).

Das Stream Management-Modul mod_smacks lies sich ohne weiteres einbinden und lief auf Anhieb. Jetzt braucht es nur noch bessere Client-Unterstützung, aber für Gajim ist diese in Arbeit und wird hoffentlich nicht so schändlich (bzw. einfach nicht) eingepflegt wie bei Psi. Und Swift bekommt hoffentlich bald Stream Resumption. Aber ich schweife vom Thema ab.

Was es sonst so an Modulen gibt, kann man hier (https://prosody-modules.googlecode.com/hg/) nachsehen und hier (https://code.google.com/p/prosody-modules/w/list) in den meisten Fällen eine kurze Beschreibung und Anleitung finden.

Was nicht mehr geht

Derzeit unterstützt Prosody offiziell kein Publish-Subscribe (es ist aber bereits ein Modul verfügbar), das wird sich aber vermutlich bald ändern. Ich muss zugeben, dass mir der genaue Zweck von PubSub noch nicht 100% erschlossen hat (Nachlesebedarf! *g*), aber ich habe dadurch noch keine Einschränkungen erkennen können.

Ein Webinterface ist standardmäßig nicht gegeben, als eingetragener Admin (entsprechende JIDs sind in der Konfig eingebbar) kann man aber so gut wie alles über Adhoc Kommandos einstellen, einschließlich dem Laden von Modulen). Es gibt aber auch ein Modul, welches auch via Webinterface diese Kommandos bietet, allerdings habe ich das noch nicht getestet. Einfach mal reinschnuppern.

Fazit

Ich bin sehr zufrieden! Die Migration lief mit Ausnahme der Notizen im private XML Storage erstaunlich glatt und problemlos. Dieses Problem wird aber ohnehin nur die Wenigstens tangieren. Die Module funktionieren wunderbar. Ich würde sagen, dass Prosody auf dem Besten Weg ist, State of the Art bei den offenen XMPP-Servern zu werden – wenn er das nicht schon ist. Ejabberd ist gewiss ein guter Server, der auch im großen Stile relativ gut skaliert und seit Jahren bewährt ist. Aber wenn man sich mit XMPP etwas austoben will, halte ich Prosody für die bessere Wahl. Ich hoffe, dass er mich weiterhin so begeistert und sich weiterentwickelt. Rein subjektiv habe ich übrigens das Gefühl, dass der Verbindungsaufbau jetzt schneller geht als zuvor – aber das kann auch euphorische Einbildung sein ;-D

So, vielleicht hilft das hier ja dem Einen oder der Anderen bei der Migration bzw. bei der Entscheidung zu eben dieser.

9 Kommentare

      1. Ich mf6chte nur kurz auf 2 Client Probleme mit neueren ejebbard Versionen hinweisen, wovon vielleicht ein paar Benutzer auf diesem Server betroffen sein werden.Mit ejebbard 2.0.3 gibt es ein Problem mit Kopete im Zusammenhang mit MUCs, wobei das ein Bug in Kopete ist. ejebbard fcberprfcft ab dieser Version den Absender, der in den XML Daten vom Client hinzugeffcgt werden kf6nnen und Kopete schreibt dort leider die jeweilige MUC JID von sich selber rein, wodurch ein Kopete Benutzer beispielsweise beim Abschicken einer Nachricht in einem MUC vom Jabber Server vf6llig getrennt wird. Ein Bug Report ffcr Kopete gibt es schon, aber da hat sich leider lange nichts getan (obwohl selbst alle Kopete Benutzer mit gmail betroffen sind): Und sonst werden noch teilweise e4ltere Pidgin Clients (<=2.4.X) Probleme mit der Authentifikation am Server haben (das Problem gab es frfcher auch schon mit Openfire und ist auch ein Bug in Pidgin). Abhilfe wfcrde hier die Benutzung von der e4lteren SSL Methode ffcr die Verbindung zum Server oder die Aktualisierung auf eine neue Pidgin Version schaffen.Vielleicht habe ich ja jemand mit diesen Hinweisen geholfen

  1. Super-Anleitung! Nach jahrelangem Warten auf XEP-0198 in ejabberd habe ich es aufgegeben, und bin innerhalb weniger Stunden auf Prosody umgestiegen. Bei IPv6 war zwar noch etwas Hilfe der Entwickler vonnöten, aber nun läuft die Bude!

    1. Hallo Georg, danke für das Feedback 🙂
      IPv6 steht bei mir auch noch auf der Liste… bislang haben meine Experimente da nicht so wirklich gut funktioniert (also Server allgemein, beim Prosody war ich noch nicht einmal).
      Dann mal viel Spaß mit Prosody – ich habe die Migration keine Sekunde lang bereut.
      Vielleicht besinnen sich die eJabberd-Devs auch mal auf Stream Management, wenn sie bemerken, dass ihnen immer mehr Nutzer durch die Finger rinnen – ich sähe aber keinerlei (!) Grund, wieder zurück zu migrieren.

    2. Jo, ich auch nich mehr, schon le4nger. Ist hier nur eine Person ffcr den Server zuste4ndig? Wenn ja, kann man das verzeihen am Wochenende, aber man sotlle das vllt mal auf 2-3 Leute verteilen, so dass schnelle Reaktionszeiten gewe4hrleistet sind (Wir wollen doch eine Alternative zu den Grodfen wie ICQ aufbauen, oder?)

    1. Hi Jens, danke für deinen Kommtentar! Freut mich, wenn es geklappt hat – hoffe, Du wirst mit Prosody so zufrieden sein wie ich.

      Zum Link: Also ich konnte ihn eben problemlos aufrufen, hatte vllt. prosody.im ein kleines Problem? Allerdings ist die von dir verlinkte Version wohl einiges neuer – daher habe ich den Artikel aktualisiert.

      Zu den SSL-Einstellungen: Ja, mit Cipher-Konfiguration kann man sich wirklich verkünsteln 😉 Ist aber natürlich immens wichtig. Falls noch nicht bekannt: unter http://xmpp.net/ kann man den eigenen Server S2S und C2S dahingehend testen lassen.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*