Ejabberd

XMPP ist eine von der IETF standardisierte Sammlung diverser XML-basierender Netzwerkprotokolle, die ein erweiterbares Messaging- und Anwesenheitsprotokoll darstellen.

Anders als die meisten anderen Messaging-Dienste ist XMPP dezentral aufgebaut. Die nötige Server-Software sowie das Protokoll um einen XMPP-Server zu betreiben sind ebenfalls frei verfügbar. So steht jedem Anwender die Möglichkeit offen, selbst einen XMPP-Server aufzusetzen.

XMPP eignet sich daher nicht nur, um großen, öffentlichen Nutzergruppen eine Möglichkeit der Kommunikation zu bieten, sondern auch, um im kleinen Rahmen schnell und einfach, und ohne große Hürden (XMPP-Clients sind für alle gängigen Architekturen und Systeme verfügbar) eine Kommunikationsmöglichkeit bereitzustellen.

Installation

ejabberd ist im community-Repository verfügbar, und kann aus diesem mittels Pacman installiert werden.

pacman -S ejabberd

Nach der Installation sollte der Service noch mittels systemctl enable ejabberd für den automatischen Start markiert werden. Allerdings sollte man vor dem ersten Start noch einiges anpassen und konfigurieren, und das System ein mal in einem Live-Modus testen.

Erster Start

Vor der Inbetriebnahme des XMPP-Servers sollte dieser konfiguriert werden. Alle Einstellungen werden in der Datei /etc/ejabberd/ejabberd.cfg vorgenommen. Änderungen an dieser Datei bedürfen eines Neustarts des Services.

Aufbau der Datei

vi zeigt die Konfigurationsdatei an, Abschnitt MODULES

Die Datei hat eine für viele User vielleicht etwas ungewöhnliche Syntax.

% Dies ist ein Kommentar
{definition, "wert"}.
{anderedefinition, ["gruppe", "von", "werten"]}.
{weiteres, [{wert, "mit"}, {gruppe, "die"}, {weitere, "definitionen"}, {setzen, "kann"}]}.

Der besseren Lesbarkeit halber können diese Definitionen auch umgebrochen und zudem innerhalb der Definitionen auch mit weiteren Kommentaren versehen werden.

{weiteres, [
  % Setzt „wert“ und „gruppe“
  {wert, "mit"},
  {gruppe, "die"},

  % Hier werden weitere Werte gesetzt
  {weitere, "definitionen"},
  {setzen, "kann"},

  % Verschachtelungen gehen auch noch
  {untergruppe, [
    {optiona, "werta"},
    {optionb, "wertb"},
    {optionc, "wertc"}
  ]}
]}.

In der ejabberd-Konfigurationsdatei ist vor allem die letzte Form stark vertreten. In der Konfigurationsdatei werden Kommentare mit %% oder %%% versehen, was hier aber ignoriert werden kann.

Die Datei ist intern durch ausführliche Kommentierung in verschiedene Abschnitte unterteilt und gut dokumentiert.

Konfiguration

Vor dem ersten Start von ejabberd müssen noch einige Dinge angepasst werden. Zum Beispiel wurde noch kein Administrations-User angelegt, und der Hostname wurde zudem auch noch nicht definiert. Es wird hier nur die Grundkonfiguration mit nur einem einzigen Server (in der XMPP-Terminologie Node) beschrieben. Dinge, auf die nicht eingegangen wird, können so belassen werden.

Hostname

ejabberd ist in der Lage, mehrere Hostnamen anzubieten. Allerdings muss der Rechner, auf dem ejabberd läuft, per DNS über den Hostnamen erreichbar sein, damit man diesen auch zum Anmelden nutzen kann.

In kleineren Umgebungen, die XMPP ausschließlich im LAN anbieten, ist es ausreichend, den LAN-Hostnamen zu verwenden. Sobald der Server aber auch von außen erreichbar sein soll, ist es ratsam, einen vollständigen Domain-Namen zu verwenden.

Die Hostnamen, mittels derer man sich am XMPP-Server anmelden kann werden im Abschnitt SERVED HOSTNAMES in der Konfigurationsdatei definiert.

{hosts, ["xmpp", "xmpp.example.org"]}.

In diesem Fall werden zwei Hostnamen, xmpp, und jabber.example.org definiert. Es können am Server mit beiden Hostnamen Accounts registriert werden. Mit jabber-Accounts kann man sich allerdings nicht an jabber.example.org-Accounts anmelden, und umgekehrt.

Der Einfachkeit halber ist es also sinnvoller, ejabberd nur einen Hostnamen anbieten zu lassen, allerdings muss dieser auch als Liste deklariert übergeben werden.

{hosts, ["xmpp.example.org"]}.

So wird von ejabberd nur der FQDN angeboten. Verwirrungen durch verschiedene Hostnamen sind dadurch nicht mehr möglich. Zudem vereinfacht dies die Konfiguration.

Nutzer-Registrierung

Über diese Option auth_method im Abschnitt AUTHENTIFICATION wird definiert, ob das interne Datenbanksystem (Mnesia), oder ein anderes verwendet werden soll. Zur Wahl stehen hier ein externes Script, eine beliebige Datenbank (ODBC), MySQL, PostreSQL, PAM oder LDAP.

PAM oder LDAP können direkt in diesem Abschnitt konfiguriert werden, ODBC benötigt die Konfiguration der Datenbank im darauffolgenden Abschnitt. Es können voreingestellt MySQL oder PostgreSQL verwendet werden. Allerdings unterstützt ejabberd jede ODBC-Kompatible Datenbank.

{auth_method, internal}.

Wenn nichts elementar Wichtiges dagegenspricht, sollte der ejabberd-internen Nutzerverwaltung der Vorzug gegeben werden. Hier können mehrere hundert User verwaltet werden, und die Datenbank arbeitet dennoch performant.

Einschränkung der Registrierung

Wenn man einen festen Benutzerkreis hat, möchte man eventuell nicht, dass sich jeder beliebige Nutzer am Server registrieren kann, auch wenn der Server im Internet verfügbar sein sollte.

Im Abschnitt ACCESS RULES kann definiert werden, dass die externe Nutzer-Registrierung nicht möglich ist. So kann nur der Administrator einen Nutzer anlegen.

{access, register, [{deny, all}]}.

Im selben Abschnitt können auch weitere Regeln definiert werden. Für den normalen Betrieb sind alle Regeln bereits mit sinnvollen Voreinstellungen belegt, so dass es hier keiner weiteren Änderung bedarf.

Administrator

Der erste Administrations-User ist der einzige User, der händisch in der Konfigurationsdatei angelegt wird. Dieser User besitzt alle Rechte, vergleichbar mit root. Es können allerdings beliebig viele „root“-User angelegt werden. Konfiguriert wird der Administrations-Account im Abschnitt ACCESS CONTROL LISTS.

{acl, admin, {user, "root", "xmpp.example.org"}}.

Der so definierte User mit der User-ID root am Server xmpp.example.org verfügt somit über alle Rechte. Allerdings wurde der User noch nicht angelegt und verfügt noch über kein Passwort.

Darauf, wie ein User angelegt wird, wird später in diesem Artikel eingegangen.

Serversprache

Wenn man einen internationalen Server betreibt, ist englisch natürlich die erste Wahl, was die Statusmeldungen des Servers betrifft, wenn man hingegen einen rein von deutschsprachigen Nutzern verwendeten Server betreibt, kann man die Sprache natürlich auf deutsch stellen. Dies geschieht im Abschnitt DEFAULT LANGUAGE

{language "de"}.

Wenn man einen Server mit mehreren Hostnamen betreibt, kann man die Sprache auch je Hostname definieren.

Module

Über Module kann der XMPP-Server um Funktionen erweitert werden. Module werden im Abschnitt MODULES geladen und konfiguriert.

Mehrbenutzer-Chat

Das standardmäßig aktivierte Modul mod_muc erlaubt Mehrbenutzer-Chaträume auf dem Server. Standardmäßig ist der Hostname hierfür conference.HOST, wobei HOST der Hostname ist. Wem dies nicht zusagt, kann das angepasst werden.

{mod_muc, [
  {host, "chat.@HOST@"},
  {access, muc},
  {access_create, muc},
  {access_persistent, muc},
  {access_admin, muc_admin}
 ]},

Hier wird der Mehrbenutzer-Chat-Host auf chat.@HOST@ gesetzt, @HOST@ wird durch ejabberd selbständig durch jabber.example.org ersetzt. Diese Angabe bedarf keiner weiteren Konfiguration, da ejabberd sich selbständig um die Auflösung der Second-(bzw. Third-)Level-Domain kümmert.

Willkommens-Nachricht

Wenn man die User-Registrierung nicht deaktiviert hat, und sich ein neuer Benutzer am Server anmeldet, ist es möglich, diesem Nutzer per Server-Nachricht eine Meldung zukommen zu lassen, und jemanden darüber zu informieren, dass ein User-Account registriert wurde. Dies wird über das Modul mod_register konfiguriert.

{mod_register, [
  {welcome_message, {"Hallo!",
                     "Willkommen auf diesem XMPP-Server!",
                     "Immer schön artig bleiben!"}}
  {registration_watchers, ["regadmin@xmpp.example.org",
                           "admin2@xmpp.example.org"]},

Über diese Konfiguration wird jedem neu registrierten User bei erster Anmeldung eine Nachricht geschickt.

Hallo!
Willkommen auf diesem XMPP-Server
Immer schön artig bleiben!

Zusätzlich werden regadmin@xmpp.example.org und admin2@jabber.example.org per Nachricht darüber informiert, dass ein neuer User-Account registriert wurde. Diese User müssen dafür natürlich existieren

Verteilte Kontaktliste

Damit man sich in Netzwerken nicht selbst darum kümmern muss, ob und wie alle Nutzer die weiteren User-Accounts auf dem Server in ihre Kontaktliste eintragen, gibt es eine Funktion, die sich „Shared Roster“ oder „Autoroster“ nennt. („Roster“, engl.: Mitgliedsverzeichnis). Diese Funktion wird über das Modul mod_shared_roster verfügbar gemacht.

Wenn dieses Modul aktiviert (sprich: nicht auskommentiert) ist, ist es möglich, zu definieren, dass die Kontaktliste allen angemeldeten Mitgliedern automatisch zur Verfügung gestellt wird. So haben Nutzer, die sich erstmalig anmelden, sofort alle weiteren registrierten User-Accounts in ihrer Kontaktliste, ohne, dass sie diese manuell hinzufügen müssen.

Die Konfiguration der verteilten Kontaktliste kann später über das Web-Interface einfach konfiguriert werden. Dort können dann auch Nutzergruppen und deren gegenseitige Sichtbarkeit definiert werden.

Test-Start

Nach der Konfiguration in der ejabberd-Konfigurationsdatei sollte man den Server nicht gleich als Daemon starten, sondern vorerst einen Live-Test vornehmen. Dass dabei noch kein User existiert ist nebensächlich, es geht lediglich um die Funktion des Servers.

ejabberdctl live

Hiermit wird ein Live-Start ausgeführt. Alle Meldungen des Servers werden direkt auf der Konsole ausgegeben. Es wird vorerst allerdings ein Warntext ausgegeben, an den man sich halten sollte. Wenn man sich komplett „verrant“ haben sollte, oder den Test beenden will, einfach zweimal Strg+C drücken.

Nach dem Druck einer beliebigen Taste laufen viele Statusmeldungen durch das Terminal. Wenn am Ende der Statusmeldungen …

=PROGRESS REPORT==== 29-Apr-2009::12:04:39 ===
        application: ejabberd
         started_at: ejabberd@localhost

… steht (Datum variiert natürlich), wurde der Server erfolgreich gestartet. Dies kann zudem auch mittels nmap auf den Host überprüft werden.

nmap xmpp.example.org

[…] 
PORT     STATE    SERVICE
[…] 
5222/tcp open     unknown
5280/tcp open     unknown

Port 5222/tcp wird von XMPP für die Kommunikation verwendet. Port 5280/tcp wird vom Administrations-Webinterface verwendet. Sollten die beiden Ports nicht in der Portliste von nmap erscheinen, so muss die Firewall so konfiguriert werden, dass diese Ports weitergeleitet werden.

Der Live-Test auf dem Server kann dann mittels zweimal Strg+C beendet werden.

Man kann den Server nun leider nicht mehr über Systemd starten, da dieser Probelauf bereits wichtige Dateien als der User angelegt hat, der diesen Test ausgeführt hat. Der User, als der der ejabberd jedoch normalerweise läuft, hat dann leider keine Rechte mehr auf diese Dateien zuzugreifen. Nachdem dieser Test erfolgreich durchgeführt wurde, sollte man die Rechte in /var/log/ejabberd und /var/lib/ejabberd überprüfen; der User ejabberd benötigt hier lese- und schreibrechte.

Nun kann entweder mittels ejabberdctl start, dem Ausführen von systemctl start ejabberd, oder einem Neustart des Systems, wenn zuvor systemctl enable ejabberd eingegeben wurde, der XMPP-Server gestartet werden.

User anlegen

Zuerst sollte nun über ejabberdctl der Administrations-Nutzer angelegt werden. Diese ist nötig, um auf das Web-Interface zugreifen zu können.

Da die Passwörter mit dieser Methode in Plaintext in der Bash-History angezeigt werden, sollte man diese entweder vorher deaktivieren, hinterher löschen, oder das Passwort auf etwas unkritisches stellen und die Nutzer zum Ändern des Passwortes auffordern.

ejabberdctl register root xmpp.example.org adminpasswort

Weitere User werden im selben Stil angelegt, man kann sich das Anlegen mehrerer User-Accounts allerdings vereinfachen.

for USER in frank dirk anton susanne michael andreas jana martina
do
  ejabberdctl register $USER xmpp.example.org changeme
done

Mittels dieses Scripts werden mehrere User gleichzeitig angelegt. Allen Usern wird das Passwort changeme zugewiesen. Geändert werden kann das Passwort wahlweise durch den Administrator im Webinterface, oder von den jeweiligen Benutzern selbst über die Funktionen des von ihnen verwendeten Clients.

Sollte man die externe Registrierung nicht deaktiviert haben, ist es nicht nötig, weitere User über das Administrationstool anzulegen. Zudem kann in einem solchen Fall der administrative Account ebenfalls direkt über einen Client angelegt werden.

Wenn man bei deaktivierter externer Anmeldung lieber grafisch arbeitet, kann man die User auch über die Weboberfläche anlegen, nachdem der administrative User angelegt wurde.

Weboberfläche

Die Weboberfläche ist unter der Adresse http://xmpp.example.org:5280/admin zu erreichen. Als Nutzername muss der Jabber Identifier (JID) des Administrations-Users verwendet werden, das Passwort ist jenes, das beim Anlegen des User-Accounts verwendet wurde. Also beispielsweise

• Username: root@xmpp.example.org
• Passwort: adminpasswort

Die Verwaltung des Servers erfolgt an zwei Stellen. Zum Einen gibt es die generelle Verwaltung, diese umfasst alle direkt erreichbaren Menüpunkte. Zum Anderen gibt es die spezielle Server-Verwaltung. Diese Befindet sich unter „Virtuelle Hosts“. Dort wählt man Namen des Hosts aus, dessen Einstellungen man bearbeiten möchte.

Das Administrations-Webinterface von ejabberd direkt nach dem Einloggen

Man befindet sich durch die Auswahl des Hostnamens in einem Unter-Konfigurationsinterface. Hier können alle hostbezogenen Einstellungen vorgenommen werden. Mit einem Klick auf den Hostnamen über dem Menü gelangt man wieder zur Startseite der Host-Konfiguration, mit einem Klick auf den Header des Administrationsinterfaces gelangt man zurück zum Gesamt-Konfigurationsinterface.

Es wird nachfolgend immer vom Unter-Konfigurationsinterface ausgegangen. Änderungen, die über die Web-Oberfläche vorgenommen werden, bedürfen keines Neustarts des Daemons.

Userverwaltung

Über den Punkt „Benutzer“ gelangt man in die User-Verwaltung. Hier werden alle registrierten User-Accounts inklusive letztem Anmeldedatum des Nutzers angezeigt, zudem können hier weitere Accounts angelegt werden.

Durch einen Klick auf die JID eines Nutzers kann man weitere Einstellungen vornehmen und man bekommt zudem detailierte Informationen über den Account. So kann man hier das Passwort ändern, sieht die Offline-Nachrichten-Informationen des Users, und kann sich zudem die Kontaktliste anzeigen lassen, und diese auch bearbeiten.

Der Menüpunkt „Angemeldete Benutzer“ zeigt alle derzeit aktiven Benutzer auf dem Server. Ein Klick auf die JID führt zur selben User-Informations-Seite, wie unter „Benutzer“.

Automatische Kontaktliste

Die automatische Verteilung der Kontaktliste wird über den Menüpunkt „Gruppen der gemeinsamen Kontaktliste“ verwaltet. Zuerst sollte man eine Gruppe Alle anlegen. In diese Gruppe werden per Alias alle Benutzer eingefügt.

Mit einem Klick auf Alle wird diese Gruppe geöffnet. Hier können nun weitere Einstellungen vorgenommen werden. „Name“ und „Beschreibung“ sind frei wählbar. In das Feld „Mitglieder“ muss nun der Alias @all@ für alle User eingefügt werden. Damit gehören alle User dieser Gruppe an.

Nun hat man zwei Möglichkeiten. Im Abschnitt „Angezeigte Gruppen“ kann man nun entweder „Alle“ reinschreiben, oder man definiert hier weitere Gruppen, und lässt „Alle“ weg.

Autoroster-Beispiel

Der Aufteilung in Gruppen sind keine Grenzen gesetzt. So könnte man zum Beispiel in einem Unternehmen Gruppen je Abteilung anlegen. Für das Beispiel werden zwei Zusatz-Gruppen angelegt, um die Kontaktliste in Männer und Frauen zu trennen.

Es wird zunächst eine Gruppe „Alle“ angelegt. In das „Mitglieder“-Feld wird der Alias @all@ geschrieben. „Angezeigte Gruppen“ wird mit Männer und Frauen gefüllt.

Es wird nun eine Gruppe Männer angelegt. „Mitglieder“ enthält hier nun keinen Alias mehr, sondern eine Liste der Benutzer, die dieser Gruppe angehören sollen.

andreas@xmpp.example.org
anton@xmpp.example.org
dirk@xmpp.example.org
frank@xmpp.example.org
michael@xmpp.example.org

Das Feld „Angezeigte Gruppen“ bleibt vorerst leer.

Der selbe Vorgang wird nun auch für die Gruppe „Frauen“ ausgeführt, diesmal werden in das „Mitglieder“-Feld nur die Useraccounts der weiblichen Nutzer eingefügt.

jana@xmpp.example.org
martina@xmpp.example.org
susanne@xmpp.example.org

Nun bestehen drei Gruppen. In der Gruppe „Alle“ sind durch den Alias @all@ alle User Mitglied. In der Gruppe „Frauen“ sind nur die User-Accounts der weiblichen Nutzer Mitglied, und in der Gruppe „Männer“ nur die User-Accounts der männlichen Nutzer. Dadurch, dass in der Gruppe „Alle“ als „Angezeigte Gruppen“, die Gruppen „Männer“ und „Frauen“ definiert wurden, werden allen Usern, die in der Gruppe „Alle“ sind, diese beiden Gruppen angezeigt.

Änderungen an der Shared-Roster-Funktion werden automatisch an die Clients weitergeleitet und sind in den Clients nahezu in Echtzeit nachvollziehbar.

Nun sei es so, dass für männliche Nutzer und für weibliche Nutzer getrennt Assistenz-Systeme eingerichtet werden sollen, die könnten zum Beispiel User-Accounts für Bots sein. Da die Kontaktliste aber kompakt gehalten werden soll, sollen die jeweiligen Assistenz-Systeme nur der entsprechenden Gruppe sichtbar sein.

Gruppen-Anzeige des Users dirk@xmpp.example.org in Pidgin

Man legt nun für die Assistenz-Systeme jeweils eigene Gruppen an, und fügt die User diesen Gruppen hinzu. Sei die Assistenz-Gruppe für Männer MA und für Frauen FA. Die User seien ma1 bis ma3, bzw. fa1 bis fa3. So werden zwei Gruppen erzeugt, und diesen die jeweiligen Mitglieder hinzugefügt.

• MA
  • ma1@xmpp.example.org
  • ma2@xmpp.example.org
  • ma3@xmpp.example.org

• FA
  • fa1@xmpp.example.org
  • fa2@xmpp.example.org
  • fa3@xmpp.example.org

Nun wird die Gruppe „Männer“ geöffnet. In das noch leere Feld „Angezeigte Gruppen“ wird nun der Name der Männer-Assistenz-Gruppe MA hineingeschrieben, und das Ganze bestätigt. In der Gruppe „Frauen“ wird analog dazu FA in das Feld geschrieben.

So sehen Mitglieder der Gruppe „Männer“ nur die Gruppe MA. Mitglieder der Gruppe „Frauen“ sehen hingegen nur die Gruppe FA. Würde man die Gruppen MA und FA als angezeigte Gruppe in der „Alle“-Gruppe hinzufügen, würden alle User diese Gruppen sehen können.

User-Zuordnung

Soll im obigen Beispiel der User dirk@xmpp.example.org, obwohl er in der Männer-Gruppe ist, das Assistenz-System FA2@xmpp.example.org direkt sehen können, so ist unter „Benutzer“ auf dirk@xmpp.example.org zu klicken. Auf der User-Informationsseite ist dann unter „Kontaktliste“ die JID fa2@xmpp.example.org hinzuzufügen.

Zusätzlich sollte man diesen Vorgang für fa2@xmpp.example.org wiederholen, und dort dirk@xmpp.example.org zur Kontaktliste hinzufügen. Allerdings sollte ein Assistenz-System wie ein Bot die Authorisierung selbständig durchführen, so dass dies im Normalfall nicht nötig ist.

Der so hinzugefügte User erscheint im Client dann unter keiner Gruppe, bzw. in Pidgin unter der generischen Gruppe „Buddys“.

Transports

ICQ im Diensteverzeichnis, angezeigt in Psis „Service Discovery“-Fenster

Mit ejabberd ist es möglich, auch andere Messaging-Dienste zu verwenden. Dies geschieht mit Hilfe von Transports. Transports sind Zusatzprogramme, mittels derer ein XMPP-Server fähig ist, auch als Server für andere Messaging-Dienste benutzt werden zu können. Es gibt für alle gängigen Dienste Transports. Für dieses Beispiel wird der Transport für ICQ installiert und konfiguriert.

Installation

Der Transport für ICQ heißt pyicqt und muss aus dem community-Repository installiert werden.

pacman -S pyicqt

pyicqt muss dann noch aktiviert und gestartet werden.

systemctl enable pyicqt
systemctl start pyicqt

Ob der Transport schon läuft, oder nicht, wenn ejabberd gestartet wird, ist nicht von Bedeutung.

Konfiguration pyicqt

Nach der Installation sollte aus Sicherheitsgründen ein Schlüsselwort gesetzt werden. Dies wird in der Datei /etc/ejabberd/pyicq.xml konfiguriert. In diesem Fall wird key als Schlüsselwort verwendet.

<secret>key</secret>

Zusätzlich muss in dieser Datei noch der Host eingestellt werden, unter dem der XMPP-Transport erreichbar sein soll. Dieser Host muss über das DNS auflösbar sein.

<jid>icq.xmpp.example.org</jid>

Es können noch weitere Einstellungen vorgenommen werden: So kann in der Zeile port zum Beispiel der Verbindungs-Port angegeben werden, über den der Transport erreichbar ist. Auch können unter icqPort und icqServer die Konfiguration der ICQ-Seitigen Einstellungen vorgenommen werden. Für alle Einstellungen wurden sinnvolle Standardwerte gesetzt.

Konfiguration ejabberd

Der ICQ-Transport muss ejabberd noch in der Datei /etc/ejabberd/ejabberd.cfg hinzugefügt werden, so dass dieser den ICQ-Dienst anbieten kann. Im Abschnitt LISTENING PORTS wird ein neuer Eintrag erstellt.

{5347, ejabberd_service, [
   {access, all},
   {hosts,
     ["icq.xmpp.example.org"],
     [{password, "key"}]
   }
]},

Starten

Danach muss ejabberd (neu) gestartet werden. Ebenfalls muss pyicqt gestartet werden.

ejabberdctl start
systemctl start pyicqt

Wenn man will, kann man auch erst pyicqt starten, und danach ejabberd mittels ejabberdctl live in den Live-Modus versetzen, um eventuell auftretende Fehler direkt sehen zu können.

Siehe auch

• iptables
• XMPP
• Liste von XMPP-Software

Weblinks

• Community-Site des ejabberd
• Kommerzieller Support vom Anbieter
• Website der XMPP-Standards-Founddation
• XMPP-Server des CCC