|
|
| (45 dazwischenliegende Versionen von 8 Benutzern werden nicht angezeigt) |
| Zeile 2: |
Zeile 2: |
| | | | |
| | = Registrierung = | | = Registrierung = |
| | + | Der Freifunk 3Ländereck betreibt für alle Freifunker in der Region einen Jabber-Dienst unter der Domain ''jabber.ff3l.net''. Die Registrierung ist offen und kann anonym unter der Adresse https://jabber.ff3l.net/register/ erfolgen. Alternativ lassen sich Benutzerkonten auch direkt aus den meisten Klienten heraus erstellen ("In-Band-Registrierung"). Dies ist jedoch aus technischen Gründen lediglich innerhalb des Freifunknetzes möglich. Registriere dich noch heute und werde Teil des weltweiten Jabber-Netzwerks! |
| | | | |
| − | Der Freifunk 3Ländereck betreibt für alle Freifunker in der Region einen Jabber-Dienst unter der Domain ''jabber.ff3l.net''. Die '''Registrierung''' ist offen und kann anonym unter der Adresse https://jabber.ff3l.net erfolgen. Alternativ lassen sich Benutzerkonten auch direkt aus den meisten Klienten heraus erstellen ("In-Band-Registrierung"). Dies ist jedoch aus technischen Gründen lediglich innerhalb des Freifunknetzes möglich. Registriere dich noch heute und werde Teil des weltweiten Jabber-Netzwerks! Geeignete Klienten für dein Betriebssystem findest Du im nächsten Abschnitt.
| + | Wähle hierzu auf der Registrierugsseite den Link "Register a Jabber account". Im Anschluss erscheint das unten dargestellte Formular. Trage den Benutzernamen ("Username") deiner Wahl ein. Im Jabber-Netzwerk bist du später unter der Jabber-ID (JID) ''<username>@jabber.ff3l.net'' erreichbar. Wähle als nächstes ein sicheres Passwort ("Password"). Das Passwort muss zweimal eingetragen werden, um Tippfehler auszuschließen. Zusätzlich gibt es noch ein "Captcha". Dieses verhindert die automatische Registrierung von Benutzerkonten durch Schadsoftware. Um die Prüfung zu bestehen, muss die im Bild dargestellte Zahl in das Feld unter Punkt 5 eingetragen werden. Danach bleibt nur noch der Klick auf das Feld "Register". Direkt im Anschluss kannst du dich unter deinem Benutzernamen und mit dem gewählten Passwort anmelden. Geeignete Klienten für dein Betriebssystem findest Du im nächsten Abschnitt. |
| | + | |
| | + | [[File:Jabber_registrierung.png]] |
| | | | |
| | = Klienten = | | = Klienten = |
| | | | |
| − | Die folgende Tabelle enthält eine Auflistung empfohlener Klienten. Hilf uns mit, diese zu vervollständigen! | + | Die folgende Tabelle enthält eine Auflistung empfohlener Klienten. Helft uns mit, diese zu vervollständigen! Wie sich die Klienten im Einzelnen konfigurieren lassen, entnehmt ihr am besten der zugehörigen Dokumentation. In der Regel sollte dies kein Hexenwerk sein. |
| | | | |
| | {|class="wikitable" | | {|class="wikitable" |
| Zeile 18: |
Zeile 21: |
| | |OSX | | |OSX |
| | |[http://adium.im adium.in] | | |[http://adium.im adium.in] |
| − | | | + | |basiert auf libpurple und kann daher nicht alle aktuellen [https://xmpp.org/xmpp-protocols/xmpp-extensions/ XEPs] <ref name="Anm_1">Es geht darum XMPP so nutzen zu können wie Hangouts oder Facebook Messanger oder auch Whatsapp. <br /> Wichtig zu nennen, wären hierbei: Message Archiving, Stream Management, Message Carbons, Archive Management, Push und auch Impact of TLS and DNSSEC on Dialback. <br />Höre dazu auch: http://blog.binaergewitter.de/2015/03/26/binaergewitter-talk-118-zu-frisch-fuer-debian-stable (der Talk zu XMPP geht recht spät los)</ref> |
| | + | |- |
| | + | |Conversations<ref name="Anm_2">Empfohlen</ref> |
| | + | |[https://github.com/siacs/Conversations github.com/siacs/Conversations] |
| | + | |Android |
| | + | |OTR für sichere End-zu-Endverschlüsselung |
| | |- | | |- |
| − | |Gajim | + | |Gajim<ref name="Anm_2" /> |
| | |Linux, Windows, OSX | | |Linux, Windows, OSX |
| | |[http://gajim.org gajim.org] | | |[http://gajim.org gajim.org] |
| − | | | + | |OTR für sichere End-zu-Endverschlüsselung gibt es [https://trac-plugins.gajim.org/wiki/OffTheRecordPlugin hier] |
| | + | |- |
| | + | |ChatSecure |
| | + | |iOS, Android |
| | + | |[https://chatsecure.org chatsecure.og] |
| | + | |OTR für sichere End-zu-Endverschlüsselung. Unterstützt leider keine aktuellen [https://xmpp.org/xmpp-protocols/xmpp-extensions/ XEPs]<ref name="Anm_1" /> |
| | |- | | |- |
| | |Pidgin | | |Pidgin |
| | |Linux, Windows | | |Linux, Windows |
| | |[http://pidgin.im pidgin.im] | | |[http://pidgin.im pidgin.im] |
| − | |Umfangreicher Instant Messaging-Klient, welcher sich nicht nur auf XMPP beschränkt. | + | |Umfangreicher Instant Messaging-Klient, welcher sich nicht nur auf XMPP beschränkt <br/> OTR für sichere End-zu-End-Verschlüsselung über ein Plugin verfügbar <br/> basiert auf libpurple und kann daher nicht alle aktuellen [https://xmpp.org/xmpp-protocols/xmpp-extensions/ XEPs] <ref name="Anm_1" /> |
| | + | |- |
| | + | |Yaxim |
| | + | |[http://yaxim.org yaxim.org] |
| | + | |Android |
| | + | | |
| | |} | | |} |
| | | | |
| − | = XMPP-Server mit ejabberd =
| + | <references /> |
| − | XMPP-Server gibt es an der Zahl viele. Ein populärer, freier XMPP-Server ist [https://www.ejabberd.im/ ejabberd]. ''Ejabberd'' ist unter Windows und Unix-Derivaten verfügbar. Neben diversen Modulen und Transports unterstützt ''ejabberd'' die Einrichtung von Clustern, so dass durch den Parallelbetrieb mehrerer Server eine hohe Ausfallsicherheit erzeugt werden kann.
| |
| | | | |
| − | == Installation und Konfiguration ==
| + | Der Pidgin Instant Messaging-Klient: |
| − | Im Folgenden wird die Installation und Einrichtung unter Debian Wheezy als Benutzer ''root'' beschrieben.
| |
| − | Als erstes installieren wir das Paket mit dem Server und ImageMagick, welches für die Erstellung der Captchas benötigt wird:
| |
| | | | |
| − | apt-get install ejabberd imagemagick
| + | [[File:Jabber_pidgin.png]] |
| | | | |
| − | Im Anchluss führen wir eine Grundkonfiguration durch:
| + | =Konferenzen= |
| | + | Neben der Möglichkeit zu Einzelverbindungen, lassen sich in Jaber auch Konferenzräume oder Chat Rooms anlegen. Der Name des Servers lautet anders als auf dem Bild gezeigt ''conference.jabber.ff3l.net''. In einer Konferenz / einem Chat können sich mehrere Benutzer gleichzeitig unterhalten. Das beste daran: Jeder Benutzer kann diese Räume anlegen. Optional lassen sie sich mit eiem Passwort schützen (geschlossene Konferenz). Für allgemeine, gepflegte Konversation haben wir den Raum "ff3l" erstellt. |
| | | | |
| − | dpkg-reconfigure ejabberd
| + | Erstellung / Beitritt zu einer Konferenz mit dem Pidgin Instant Messaging-Klienten: |
| | | | |
| − | Im Zuge der Grundkonfiguration geben wir die Domain ''<domain>'' des Servers, sowie einen Namen für den Administrator ''<administrator>'' sowie ein Passwort ein. Debconf nimmt im Anschluss automatisch die notwendigen Änderungen in der zentralen Konfigurationsdatei ''/etc/ejabberd/ejabberd.cfg'' vor. Dort sollten wir nach Abschluss der Grundkonfiguration den folgenden Abschnitt finden:
| + | [[File:Jabber_chat.png]] |
| | | | |
| − | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
| + | =Öffentliches Benutzerverzechnis= |
| − | %% Options which are set by Debconf and managed by ucf
| |
| − |
| |
| − | %% Admin user
| |
| − | {acl, admin, {user, "<administrator>", "<domain>"}}.
| |
| − |
| |
| − | %% Hostname
| |
| − | {hosts, ["<domain>"]}.
| |
| | | | |
| − | Da dies noch nicht ausreichend ist, öffnen wir die Konfigurationsdatei ''/etc/ejabberd/ejabberd.cfg'' im Anschluss mit dem Editor unserer Wahl und bessern an einigen Stellen nach. | + | Da Jabber alleine relativ wenig Freude bereitet, haben wir ein öffentliches Mitgliederverzeichnis erstellt. Wenn ihr erreicht werden wollt und das Licht nicht scheut, könnt ihr eure Jabber ID (JID) dort hinterlegen. |
| − | Damit wir als Administrator informiert werden, wenn der ''ejabberd''-Prozess außer Kontrolle gerät, aktivieren wir den Watchdog:
| |
| | | | |
| − | %%
| + | {|class="wikitable sortable" |
| − | %% watchdog_admins: If an ejabberd process consumes too much memory,
| + | !Name |
| − | %% send live notifications to those Jabber accounts.
| + | !Jabber ID |
| − | %%
| + | !Bemerkungen |
| − | {watchdog_admins, ["<admin>@<domain>"]}.
| + | |- |
| − | | + | |Bernd Kalbfuss-Zimmermann |
| − | Weiterhin wollen wir ''ejabberd'' über die eingebaute Web-Oberfläche konfigurieren können und Nutzern die Möglichkeit zur Web-basierten Registrierung bieten. Hierfür aktiviern wir den eingebauten Web-Server mit den entsprechenden Modulen. Durch Hinzufügen der Zeile ''tls, {certfile, "/etc/ejabberd/ejabberd.pem"}'' erzwingen wir die Verwendung von TLS:
| + | |[xmpp://langweiler@jabber.ff3l.net langweiler@jabber.ff3l.net] |
| − | | + | | |
| − | {5280, ejabberd_http, [
| + | |- |
| − | tls, {certfile, "/etc/ejabberd/ejabberd.pem"},
| + | |Markus Siniawa |
| − | {request_handlers,
| + | |[xmpp://markus@jabber.ff3l.net markus@jabber.ff3l.net] |
| − | [
| + | | |
| − | {["pub", "archive"], mod_http_fileserver}
| + | |- |
| − | ]},
| + | |Stefan Rauscher |
| − | captcha,
| + | |[xmpp://srauscher@jabber.ff3l.net srauscher@jabber.ff3l.net] |
| − | http_bind,
| + | | |
| − | http_poll,
| + | |- |
| − | web_admin,
| + | |Benjamin Lütker |
| − | register
| + | |[xmpp://benlue@jabber.ff3l.net benlue@jabber.ff3l.net] |
| − | ]}
| + | | |
| − | | + | |- |
| − | Benutzern soll es prinzipiell erlaubt sein, sich selbst mittels ihrer Klienten zu registrieren:
| + | |Thomas |
| − | | + | |[xmpp://templis@jabber.ff3l.net templis@jabber.ff3l.net] |
| − | %% No username can be registered via in-band registration:
| + | | |
| − | %% To enable in-band registration, replace 'deny' with 'allow'
| + | |- |
| − | % (note that if you remove mod_register from modules list then users will not
| + | |Rüdiger Lorenz |
| − | % be able to change their password as well as register).
| + | |[xmpp://pepto@jabber.ff3l.net pepto@jabber.ff3l.net] |
| − | % This setting is default because it's more safe.
| + | | |
| − | {access, register, [{allow, all}]}.
| + | |- |
| − | | + | |Heinz Knies |
| − | Statt Englisch möchten wir Deutsch als Standardsprache für alle Meldungen:
| + | |[xmpp://degrtbw@jabber.ff3l.net degrtbw@jabber.ff3l.net] |
| − | | + | | |
| − | %%
| + | |- |
| − | %% language: Default language used for server messages.
| + | |Puppet Team |
| − | %%
| + | |[xmpp://puppet-team@jabber.ff3l.net puppet-team@jabber.ff3l.net] |
| − | {language, "de"}.
| + | |Git Broadcast Service |
| − | | + | |- |
| − | Um die Registrierung von Benutzern vor Bots zu schützen, aktivieren wir die Erstellung von Captchas:
| + | |Julian |
| − | | + | |[xmpp://d3dx9@jabber.ff3l.net d3dx9@jabber.ff3l.net] |
| − | {captcha_cmd, "/usr/lib/ejabberd/priv/bin/captcha.sh"}.
| + | | |
| − | | + | |- |
| − | Um sicherzustellen, dass die Erstellung der Captchas auch funktioniert, empfiehlt sich ein Test der Befehlszeile ''/usr/lib/ejabberd/priv/bin/captcha.sh'' in der Konsole als Benutzer ''ejabberd''. Weiterhin passen wir den URL für das Captcha an, welcher an die Klienten übermittelt wird:
| + | |} |
| − | | |
| − | <nowiki>{captcha_host, "https://<domain>:5280"}.</nowiki>
| |
| − | | |
| − | Zuletzt stellen wir noch sicher, dass das Modul ''mod_register'' für die Benutzerregistrierung aktiviert ist und tragen unter ''registration_watchers'' unseren Administrator ein. In Zukunft sollten wir informiert werden, nachdem sich ein Benutzer registriert hat. Mittels ''ip_access'' beschränken wir die Selbstregistrierung auf das Freifunknetz. Weiterhin aktivieren mit der Direktive ''captcha_protected'' die Verwendung eines Captcha. Durch hinzufügen der letzten Zeile aktivieren wir zusätzlich das Modul ''mode_register_web'', welches für für die Web-basierte Registrierung benötigt wird.
| |
| − | | |
| − | {mod_register, [
| |
| − | %%
| |
| − | %% After successful registration, the user receives
| |
| − | %% a message with this subject and body.
| |
| − | %%
| |
| − | {welcome_message, {"Welcome!",
| |
| − | "Welcome to a Jabber service powered by Debian. "
| |
| − | "For information about Jabber visit "
| |
| − | "http://www.jabber.org"}},
| |
| − | %% Replace it with 'none' if you don't want to send such message:
| |
| − | %%{welcome_message, none},
| |
| − |
| |
| − | %%
| |
| − | %% When a user registers, send a notification to
| |
| − | %% these Jabber accounts.
| |
| − | %%
| |
| − | {registration_watchers, ["<admin>@<domain>"]},
| |
| − | {ip_access, [{allow, "10.119.0.0/16"}]},
| |
| − | {access, register},
| |
| − | {captcha_protected, true}
| |
| − | ]},
| |
| − | {mod_register_web, []},
| |
| − | | |
| − | Im Anschluss starten wir ''ejabberd'' erneut, damit die Änderungen übernommen werden:
| |
| − | | |
| − | service ejabberd restart
| |
| − | | |
| − | Im Normalfall sollte unser Rechner durch eine Firewall geschützt sein. Damit ejabberd funktionieren kann, müssen die Ports 5222, 5269 und 5280 für eingehende Verbindungen geöffnet werden. Falls die ''Uncomplicated Firewall'' verwendet wird, gelingt dies mit:
| |
| − | | |
| − | ufw allow 5222 # client connections
| |
| − | ufw allow 5269 # server connections
| |
| − | ufw allow 5280 # web configuration interface
| |
| − | | |
| − | Ab sofort sollten sich Klienten registrieren und mit dem Server verbinden können. Die Administrationsoberfläche erreichen wir unter ''<nowiki>https://<domain>:5280/admin/</nowiki>''. Für den Login verwenden wir den zuvor angelegten Administrator sowie das zugehörige Passwort. Benutzer können sich ab sofort unter der Adresse ''<nowiki>https://<domain>:5280/register/</nowiki>'' selbst registrieren.
| |
| − | | |
| − | == Clustering ==
| |
| − | Um die Ausfallsicherheit des XMPP-Dienstes zu erhöhen bzw. um den Dienst zu skalieren, lassen sich mehrere Knoten zu einem Cluster zusammenschalten. Voraussetzung hierfür ist die Grundkonfiguration wie im vorherigen Abschnitt beschrieben. Im Folgenden Beispiel wird von zwei Knoten <host1> und <host2> ausgegangen. Wichtig: <host1> und <host2> beschreiben hierbei die Host-Namen '''ohne''' Domain-Erweiterung!
| |
| − | Damit Erlang in der Lage ist, die Host-Namen auch ohne DNS-Server aufzulösen, ergänzen wir die Datei ''/etc/hosts'' auf '''beiden''' Knoten um die folgenden Einträge:
| |
| − | | |
| − | <ipv4-host1> <host1> <host1>.<domain1>
| |
| − | <ipv4-host2> <host2> <host2>.<domain2>
| |
| − |
| |
| − | Zusätzlich müssen wir die Firewall öffnen, damit sich die Erlang-Knoten miteinander verbinden können. Zunächst beschränken wir den genutzten Portbereich, indem wir in der Datei ''/etc/default/ejabberd'' die folgende Zeile einfügen:
| |
| − | | |
| − | FIREWALL_WINDOW=9001-9005
| |
| − | | |
| − | Im Anschluss öffnen wir den Port 4369 für den Erlang-DNS-Server ''empd'' und den zuvor festgelegten Portbereich von 9001 - 9005. Wie im vorherigen Abschnitt wird von der Verwendung der ''Uncomplicated Firewall'' ausgegangen:
| |
| − | | |
| − | ufw allow 4369
| |
| − | ufw allow 9001:9005
| |
| − | | |
| − | Eine weitere Voraussetzung für den Austausch der Knoten ist die Verwendung des selben Erlang-Cookies. Dieser ist in der Datei ''/var/lib/ejabberd/.erlang.cookie'' hinterlegt. Nachdem wir den Cookie ''<cookie>'' des ersten Knotens ''<host1>'' in Erfahrung gebracht haben, übertragen wir diesen auf den zweiten Knoten ''<host2>'':
| |
| − | | |
| − | echo -n "<cookie>" > /var/lib/ejabberd/.erlang.cookie
| |
| − | | |
| − | Falls ''ejabberd'' bereits läuft, fahren wir den Dämonen herunter:
| |
| − | | |
| − | service ejabberd stop
| |
| − | | |
| − | Danach nehmen wir die Identität des Benutzers ''ejabberd'' an:
| |
| − | | |
| − | su ejabberd
| |
| − | | |
| − | Jetzt starten wir von Hand eine Erlang-Konsole unter Eingabe der folgenden Befehlszeile:
| |
| − | | |
| − | erl -sname ejabberd -mnesia dir '"/var/lib/ejabberd/"' -mnesia extra_db_nodes "['ejabberd@<host1>']" -mnesia
| |
| − | | |
| − | Sollte es zu einer längeren Fehlermeldungen mit vielen Klammern kommen (sehr vielen Klammern!), so liegt dies vermutlich daran, dass der ''ejabberd'' nicht korrekt heruntergefahren wurde. In diesem Fall muss der Prozess manuell mittels ''kill'' beendet werden.
| |
| − | Nachdem die Konsole erfolgreich geöffnet wurde, lässt sich der Status der ''Mnesia''-Datenbank abfragen:
| |
| − | | |
| − | mnesia:info().
| |
| − | | |
| − | Hinweis: Erlang-Befehle werde immer mit einem Punkt abgeschlossen. Dieser ist nicht optional!
| |
| − | In der Folge sollte sich ein Schwall von Informationen über den Schirm ergießen. Wenn alles in Ordnung ist und die Verbindung mit ''<host1>'' zustande kanm, dann sollte sich die folgende Zeile darunter befinden:
| |
| − | | |
| − | runnning db nodes = [ ejabberd@<host1>, ejabberd@<host2> ]
| |
| − | | |
| − | Sollte die Verbindung nicht zustande gekommen sein, empfiehlt es sich manuell ein paar Tests durchzuführen. Auf der Seite [https://www.ejabberd.im/interconnect-erl-nodes Interconnecting Erlang Nodes] findet man Anweisungen, um manuell eine Verbindung zwischen zwei Erlang-Knoten herzustellen. Zuvor muss ''ejabberd'' allerdings auf '''beiden''' Knoten gestoppt werden.
| |
| − | War alles erfolgreich, dann geht es weiter mit der Kopplung der Datenbanken. Diese erreichen wir mit der folgenden Befehlszeile:
| |
| − | | |
| − | mnesia:change_table_copy_type(schema,node(),disc_copies).
| |
| − | | |
| − | {{Tip|In seltenen Fällen kann es zur folgenden Fehlermeldung kommen: "** FATAL ** Failed to merge schema: Bad cookie in table definition". Dies ist ein Hinweis darauf, dass die ''Mnesia''-Datenbank korrumpiert wurde. Um das Problem zu beheben, müssen wir die [[Datenbank zurückzusetzen]].}}
| |
| − | | |
| − | Im Anschluss überprüfen wir erneut den Status der ''Mnesia''-Datenbank. Das Ergebnis sollte in etwa wie folgt aussehen:
| |
| − | | |
| − | ---> Processes holding locks <---
| |
| − | ---> Processes waiting for locks <---
| |
| − | ---> Participant transactions <---
| |
| − | ---> Coordinator transactions <---
| |
| − | ---> Uncertain transactions <---
| |
| − | ---> Active tables <---
| |
| − | schema : with 36 records occupying 4696 words of mem
| |
| − | ===> System info in version "4.7", debug level = none <===
| |
| − | opt_disc. Directory "/var/lib/ejabberd" is used.
| |
| − | use fallback at restart = false
| |
| − | running db nodes = ['ejabberd@box-1719',ejabberd@altegurke]
| |
| − | stopped db nodes = []
| |
| − | master node tables = []
| |
| − | remote = [acl,bytestream,caps_features,captcha,config,iq_response,
| |
| − | irc_custom,last_activity,local_config,mod_register_ip,
| |
| − | motd,motd_users,muc_online_room,muc_registered,muc_room,
| |
| − | offline_msg,passwd,privacy,private_storage,pubsub_index,
| |
| − | pubsub_item,pubsub_last_item,pubsub_node,pubsub_state,
| |
| − | pubsub_subscription,reg_users_counter,roster,
| |
| − | roster_version,route,s2s,session,session_counter,
| |
| − | temporarily_blocked,vcard,vcard_search]
| |
| − | ram_copies = []
| |
| − | disc_copies = [schema]
| |
| − | disc_only_copies = []
| |
| − | [] = [local_config,caps_features,mod_register_ip]
| |
| − | [{ejabberd@altegurke,disc_copies},{'ejabberd@box-1719',disc_copies}] = [schema]
| |
| − | [{'ejabberd@box-1719',disc_copies}] = [config,pubsub_subscription,privacy,
| |
| − | passwd,irc_custom,roster,last_activity,
| |
| − | roster_version,motd,acl,pubsub_index,
| |
| − | vcard_search,motd_users,muc_room,
| |
| − | pubsub_state,muc_registered,
| |
| − | pubsub_node]
| |
| − | [{'ejabberd@box-1719',disc_only_copies}] = [offline_msg,vcard,private_storage,
| |
| − | pubsub_item]
| |
| − | [{'ejabberd@box-1719',ram_copies}] = [reg_users_counter,bytestream,
| |
| − | pubsub_last_item,route,s2s,captcha,
| |
| − | session_counter,session,iq_response,
| |
| − | temporarily_blocked,muc_online_room]
| |
| − | 4 transactions committed, 0 aborted, 0 restarted, 3 logged to disc
| |
| − | 0 held locks, 0 in queue; 0 local transactions, 0 remote
| |
| − | 0 transactions waits for other nodes: []
| |
| − | | |
| − | Sofern sich Erlang nicht beschwert, wurden die Datenbanken erfolgreich gekopplet und die Knoten befinden sich nach dem Neustart von ''ejabberd'' im selben Cluster.
| |
| − | Wir verlassen die Erlang-Konsole:
| |
| − | | |
| − | q().
| |
| − | | |
| − | Und schlüpfen zurück in die Rolle des Benutzers ''root'':
| |
| − | | |
| − | exit
| |
| − | | |
| − | Bevor wir ''ejabberd'' erneut starten nehmen wir noch eine kleine Änderung in der Konfiguration vor. Da die beiden Knoten normalerweise neben der lokalen Domain <local_domain> einen gemeinsame Domain <joint_domain> bedienen sollten, ergänzen wir diese in ''/etc/ejabberd/ejabberd.cfg'':
| |
| − | | |
| − | %% Hostname
| |
| − | {hosts, ["<local_domain>", "<joint_domain>"]}.
| |
| − | | |
| − | Diese Änderung muss auf '''beiden Knoten''' vorgenommen werden! Zuletzt starten wir ''ejabberd'' erneut:
| |
| − | | |
| − | service ejabberd start
| |
| − | | |
| − | Ob wir erfolgreich waren, können wir bequem über die Web-Oberfläche von ''ejabberd'' abfragen. Hierzu öffnen wir den Link ''<nowiki>http://<domain>:5280/admin/</nowiki>'' und authentifizieren uns als Administrator. Unter dem Menü-Punkt ''Nodes'' sollten ab sofort zwei Knoten ähnlich dem folgenden Bildschirmfoto dargestellt werden:
| |
| − | | |
| − | [[File:Ejabberd_nodes.png]] | |
| − | | |
| − | Um den Cluster als solchen zu nutzen fehlt nur noch ein Round-Robin DNS-Eintrag für die gemeinsame Domain <joint_domain>, welcher auf die beide Knoten verweist mittels ihrer IP-Adressen verweist.
| |
| − | | |
| − | == Datenbank zurücksetzen ==
| |
| − | | |
| − | In seltenen Fällen kann es zu einer Korrumpierung der ''Mnesia''-Datenbank kommen. Um die Datenbank zurückzusetzen stoppen wir als erstes den ''ejabberd'':
| |
| − | | |
| − | service ejabberd stop
| |
| − | | |
| − | Danach öffnen wir als Benutzer ''ejabberd'' eine Erlang-Konsole mit der folgenden Befehlszeile:
| |
| − | | |
| − | erl -sname ejabberd -mnesia dir '"/var/lib/ejabberd"'
| |
| − | | |
| − | Die Datenbank setzen wir mit dem folgenden Befehl zurück:
| |
| − | | |
| − | mnesia:delete_schema(['<host2>'])
| |
| − | | |
| − | Im Anschluss müssen wir die Datenbanken wie unter [[Clustering]] beschrieben erneut synchronisieren.
| |
| − | | |
| − | == Load Balancing und Failover mit HAProxy==
| |
| − | Um alle Knoten in einem Jabber-Cluster nutzen zu können benötigen wir noch eine Instanz, welche die Klienten auf die einzelnen Knoten verteilt ("Load Balancing"). Stellt diese Instanz zudem sicher, dass Klienten ausschließlich an funktionale Knoten geleitet werden, entsteht gleichzeitig eine "Failover"-Lösung. Eine einfache Möglichkeit dies zu erreichen besteht in der Verwendung eines TCP-Proxys. Im Folgenden wird die Realisierug unter Verwendung von [http://www.haproxy.org HAProxy] beschrieben. Die Anleitung folgt dem [http://blog.onefellow.com/post/76702632637/haproxy-and-ejabberd Blog-Artikel] von Zbyszek Żółkiewski.
| |
| − | | |
| − | Der HAProxy wird auf einem Gateway installiert, welches aus dem Internet erreichbar ist. Hierbei ist es wichtig, dass die Jabber-Domain (zumindest die globale) per DNS auf dieses Gateway aufgelöst wird.
| |
| − | Im ersten Schritt installieren wir das Paket:
| |
| − | | |
| − | apt-get install haproxy
| |
| − | | |
| − | Im Anschluss bearbeiten wir die Konfiguration in der Datei ''/etc/haproxy.cfg''. Die Einstellungen in der Sektion "global" können wir unverändert lassen. Die Sektion "defaults" ersetzen wir mit dem folgenden Abschnitt. Wichtig ist, dass HAProxy im TCP-Modus ("mode tcp") betrieben wird, d.h. Verbindungen werde ohne Modifikationen weitergeleitet. Wir erlauben insgesamt 3 Verbindungsversuche ("retries 2"). Danach wird versucht, die Verbindung an einen anderen Knoten zu vermitteln ("option redispatch"). Um TCP-Verbindungen auch über einen längeren Zeitraum am Leben zu halten, aktivieren wir den Versand von "Keep Alive"-Mitteilungen ("option tcpka", "option clitcpka" und "option srvtcpka"):
| |
| − | | |
| − | defaults
| |
| − | log global
| |
| − | mode tcp
| |
| − | retries 2
| |
| − | option redispatch
| |
| − | option tcplog
| |
| − | option tcpka
| |
| − | option clitcpka
| |
| − | option srvtcpka
| |
| − | timeout connect 5s #timeout during connect
| |
| − | timeout client 24h #timeout client->haproxy(frontend)
| |
| − | timeout server 60m #timeout haproxy->server(backend)
| |
| − | | |
| − | Danach definieren wir zwei "frontends". Das eine "frontend" nimmt Klienten-zu-Server-Verbindungen auf dem Port 5222 entgegen, das andere Server-zu-Server-Verbindungen auf dem Port 5269. Der Platzhalter <gateway_ip> bezeichnet die öffentliche IP-Adresse des Gateways, auf welche der DNS-Eintrag zur Jabber-Domäne verweist:
| |
| − | | |
| − | frontend access_clients <gateway_ip>:5222
| |
| − | default_backend cluster_clients
| |
| − | | |
| − | frontend access_servers <gateway_ip>:5269
| |
| − | default_backend cluster_servers
| |
| − | | |
| − | Passend zu den "frontends" deklarieren wir zwei "backends". In diesen wiederum legen wir Verweise auf die einzelnen Knoten ("server") an. Im Folgenden Beispiel wird von zwei Knoten ausgegangen ("server1" und "server2").
| |
| − | Die Platzhalter <server1_ip> und <server2_ip> bezeichnen die IP-Adressen der Knoten innerhalb des Freifunknetzes. Beim Hinzufügen weiterer Knoten ist auf die Eindeutigkeit der vergebenen IDs zu achten.
| |
| − | Die Verteilung von eingehenden Verbindungen erfolgt entsprechend der Gewichte ("weight 50") und kann angepasst werden. HAProxy überprüft, ob die Knoten tatsächlich erreichbar sind ("check"). Nach drei Fehlversuchen ("fall 3") wird ein Knoten als offline angenommen. Die Überprüfung erfolgt in Abständen von 5000 ms ("inter 5000"). Nach drei erfolgreichen Antworten ("rise 3") gilt der Knoten wieder als online und wird über einen Zeitraum von 120000 ms langsam hochgefahren ("slowstart 120000"). Die Option "balance leastconn" sorgt dafür, dass der Knoten mit der geringsten Anzahl an Klienten bei der Vergabe bevorzugt wird:
| |
| − | | |
| − | backend cluster_clients
| |
| − | log global
| |
| − | balance leastconn
| |
| − | option independant-streams
| |
| − | server server1 <server1_ip>:5222 check fall 3 id 1001 inter 5000 rise 3 slowstart 120000 weight 50
| |
| − | server server2 <server2_ip>:5222 check fall 3 id 1002 inter 5000 rise 3 slowstart 120000 weight 50
| |
| − | | |
| − | backend cluster_servers
| |
| − | log global
| |
| − | balance leastconn
| |
| − | option independant-streams
| |
| − | server server1 <server1_ip>:5269 check fall 3 id 1011 inter 5000 rise 3 slowstart 60000 weight 50
| |
| − | server server2 <server2_ip>:5269 check fall 3 id 1012 inter 5000 rise 3 slowstart 60000 weight 50
| |
| − | | |
| − | Wir speichern die Datei ab und starten den HAProxy erneut:
| |
| − | | |
| − | service haproxy restart
| |
| | | | |
| − | Ab sofort sollten auf dem Gateway eingehende Klienten- und Serververbindungen auf die Knoten verteilt werden.
| + | [[Kategorie:Dienste]][[Kategorie:Jabber]] |
