Nach einigen Monaten gibt es nun endlich wieder eine neue Version des freien Messengers Pidgin. Die Änderungen der Version sind dabei eher unter der Oberfläche zu finden. So wurden viele Probleme mit den unterstützten Messengerdiensten behoben. Auch Sicherheitsprobleme bei SSL/TLS gesicherten Verbindungen wurden behoben. Die eingebauten Pythonskripte sind nun zu Python 3 kompatibel. Unter anderem wurde ein nerviger Fehler behoben.
Pidgin unter Windows
Das komplette Changelog kann sich dabei im Entwicklerbereich angeschaut werden. Bezogen werden kann Pidgin unter anderem auf der offiziellen Seite.
Das schöne an einem XMPP-Server ist die Tatsache das man ihn relativ einfach aufsetzen kann. Wenn er dann funktionstüchtig ist, stellt man sich nicht selten die Frage, wie sicher das ganze konfiguriert ist. Hier hilft das IM Observatorymit seiner Webseite.
Eine Auswertung des IM Observatory
Dort gibt man die URL zum XMPP-Server ein und anschließend wird dieser einigen Tests unterzogen. Nach Ablauf des Tests bekommt man eine Note von A bis F zugewiesen, wobei F das schlechteste Ergebnis darstellt. Daneben bekommt man detailliert aufgelistet welche sicherheitsrelevanten Features aktiv sind.
Wenn man einen XMPP Server mittels „ejabberd“ eingerichtet hat und für diesen SRV Einträge in der DNS eingerichtet hat, kann es passieren, das die Windowsversion von Pidgin sich nicht mit diesem Server verbinden kann. Pidgin meldet sich dabei nur mit dem Fehler „Nicht autorisiert“. Der Grund dafür ist ein Bug, welcher sich in die Version 2.10.7 eingeschlichen hat.
Der gemeldete Bug im Ticketsystem
Mittlerweile ist dieser behoben, so das der Login im nächsten Release (2.10.8) wieder funktioniert. Solange sollte man die Vorgängerversion (2.10.6) nutzen, welche bei SourceForge heruntergeladen werden kann.
Wenn man einen XMPP-Server unter einer Subdomain wie „xmpp.example.org“ betreibt, so sehen die Kontakte dementsprechend aus – in diesem Fall „“. Möchte man Kontakte nach dem Schema „“ anlegen, so muss der DNS Eintrag der Hauptdomain auf den XMPP-Server zeigen. Dies ist aber nicht immer möglich. So kann es vorkommen das der Webserver auf der Hauptdomain seinen Dienst verichtet, während der XMPP-Server auf einem anderen Server läuft. In einem solchen Fall kann man sich das ganze mit „SRV“ Einträgen im DNS zurechtzubiegen.
_jabber._tcp IN SRV 0 0 5269 xmpp.example.org.
_xmpp-client._tcp IN SRV 0 0 5222 xmpp.example.org.
_xmpp-server._tcp IN SRV 0 0 5269 xmpp.example.org.
Mit diesen Einträgen ist es dann möglich den XMPP Server unter „example.org“ zu betreiben, obwohl der A-Record auf einen anderen Server zeigt, da der anfragende Client umgeleitet wird.
Möchte man Instant Messaging mittels XMPP (früher unter dem Namen Jabber bekannt) nutzen, so kann man natürlich zu einem der vielen Dienste wie GMail, GMX und ähnliches gehen. Damit bekommt man dann neben den Vorteilen auch den Nachteil, das man sich nicht sicher sein kann was mit den eigenen Daten passiert. Eine andere Lösung ist es hier den XMPP Server selbst aufzusetzen. Dazu bietet sich „ejabberd“ an. Mittels:
sudo apt-get install ejabberd
wird das passende Paket installiert. Der Server „ejabberd“ unterstützt dabei die Verwaltung mehrerer Domains, so das eine Serverinstanz die Adressen und bereitstellen kann. Um dies umzusetzen, geht es im ersten Schritt an die Konfiguration. Dazu wird die Datei „/etc/ejabberd/ejabberd.cfg“ mittels „nano“ geöffnet:
nano /etc/ejabberd/ejabberd.cfg
Die Syntax der Datei ist dabei im Gegensatz zu anderen Konfigurationsdateien etwas gewöhnungsbedürftig, da sie auf der Programmiersprache Erlang basiert. Kommentare z.B. werden in dieser Datei mit einem Prozentzeichen eingeleitet. Im ersten Schritt werden die Domain respektive Hostnamen definiert, welche „ejabberd“ verwalten soll. Dazu wird der Punkt „hosts“ gesucht und mit den entsprechenden Domains gefüllt.
Die Serversprache kann man für einen deutschsprachigen Server geändert werden:
{language, "de"}.
Damit werden Nachrichten vom Server in Deutsch anstatt in Englisch ausgegeben. Standardmäßig ist der Server so eingestellt, das niemand außer dem Administrator Nutzer anlegen kann. Natürlich wäre es auch denkbar, einen Server zu betreiben, bei welchem sich jeder registrieren kann. Damit man Nutzer anlegen kann, muss ein Nutzer mit den entsprechenden Rechten definiert werden:
