Ejabberd: Unterschied zwischen den Versionen

← Zum vorherigen Versionsunterschied Zum nächsten Versionsunterschied →

Version vom 25. Juni 2009, 11:59 Uhr

Der richtige Titel für diesen Artikel lautet ejabberd. Dies ist aus technischen Gründen derzeit jedoch nicht möglich.

Dieser Artikel oder Artikelabschnitt ist noch nicht vollständig!

Achtung: Derzeit scheint es Probleme mit dem ejabberd-Paket bzw. dem Erlang-Paket zu geben. Dies betrifft auch die Transport-Funktionalität, die daher hier zwar beschrieben wird, aber nicht getestet werden konnte. Siehe dazu Bug-Eintrag #14483

Dieser Artikel ist anhand einer bereits installierten, nicht aktualisierten Version (ejabberd 2.0.4-1, erlang R12B-2) erstellt worden

ejabberd ist ein in Erlang geschriebener, erweiterbarer Jabber-Server. Jabber ist ein offenes, auf XMPP basierendes Instant-Messaging-Protokoll. XMPP ist ein von der IETF standardisiertes, auf XML basierendes Messaging- und Anwesenheits-Protokoll.

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

Jabber 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 (Jabber-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 -Sy ejabberd

Nach der Installation muss der Jabber-Daemon noch in das DAEMONS-Array in der rc.conf eingetragen 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 Jabber-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 Daemons.

Aufbau der Datei

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 Jabber-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 Jabber 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 Jabber-Server anmelden kann werden im Abschnitt „SERVED HOSTNAMES“ in der Konfigurationsdatei definiert.

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

In diesem Fall werden zwei Hostnamen, „jabber“, 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, ["jabber.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_type“ 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", "jabber.example.org"}}.

Der so definierte User mit der User-ID „root“ am Server „jabber.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 Jabber-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 Jabber-Server!",
                     "Immer schön artig bleiben!"}}
  {registration_watchers, ["regadmin@jabber.example.org",
                           "admin2@jabber.example.org"]},

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

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

Zusätzlich werden „regadmin@jabber.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 Tastel aufen 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 jabber.example.org
[…] 
PORT     STATE    SERVICE
[…] 
5222/tcp open     unknown
5280/tcp open     unknown

Port 5222/tcp wird von Jabber 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.

Nun kann entweder mittels „ejabberdctl start“, dem Ausführen von „/etc/rc.d/ejabberd start“, oder einem Neustart des Systems, wenn „ejabberd“ im DAEMONS-Array steht, der Jabber-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 jabber.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 jabber.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://jabber.example.org:5280/admin“ zu erreichen. Als Nutzername muss die Jabber-ID (JID) des Administrations-Users verwendet werden, das Passwort ist jenes, das beim Anlegen des User-Accounts verwendet wurde. Also beispielsweise

Username: root@jabber.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 Jabber-ID 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@jabber.example.org
anton@jabber.example.org
dirk@jabber.example.org
frank@jabber.example.org
michael@jabber.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@jabber.example.org
martina@jabber.example.org
susanne@jabber.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.

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@jabber.example.org
- ma2@jabber.example.org
- ma3@jabber.example.org

FA
- fa1@jabber.example.org
- fa2@jabber.example.org
- fa3@jabber.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@jabber.example.org“, obwohl er in der Männer-Gruppe ist, das Assistenz-System „FA2@jabber.example.org“ direkt sehen können, so ist unter „Benutzer“ auf „dirk@jabber.example.org“ zu klicken. Auf der User-Informationsseite ist dann unter „Kontaktliste“ die JID „fa2@jabber.example.org“ hinzuzufügen.

Zusätzlich sollte man diesen Vorgang für „fa2@jabber.example.org“ wiederholen, und dort „dirk@jabber.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

Mit ejabberd ist es möglich, auch andere Messaging-Dienste zu verwenden. Dies geschieht mit Hilfe von Transports. Transports sind Zusatzprogramme, mittels derer ein Jabber-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 -Sy pyicqt

pyicqt muss dann noch in das DAEMONS-Array in der „rc.conf“ eingetragen werden. 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 Jabber-Transport erreichbar sein soll. Dieser Host muss über das DNS auflösbar sein.

<jid>icq.jabber.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.jabber.example.org"],
     [{password, "key"}]
   }
]},

Starten

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

ejabberdctl start
/etc/rc.d/pyicqt start

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.

Todo

Ein Multi-Node-System muss ebenfalls noch getestet werden

Siehe auch

Weblinks

@@ Zeile 331: / Zeile 331: @@
 [[Kategorie:Netzwerk]]
 [[Kategorie:Jabber]]
+[[Kategorie:Server]]