From ccbf6e4061bac6ad7e6452c44d0743fb0d67fef2 Mon Sep 17 00:00:00 2001 From: Micha Date: Wed, 28 Jan 2015 18:38:36 +0100 Subject: migrated jabber.spline.de posts --- blog/2011/10-27-jabber-now-open.html | 22 ++++++ blog/2012/03-04-reclustering-ejabberd.html | 114 +++++++++++++++++++++++++++++ blog/2013/10-21-jabber-and-accounts.html | 36 +++++++++ blog/2014/01-02-jabber-s2s.html | 26 ++++++- 4 files changed, 196 insertions(+), 2 deletions(-) create mode 100644 blog/2012/03-04-reclustering-ejabberd.html create mode 100644 blog/2013/10-21-jabber-and-accounts.html (limited to 'blog') diff --git a/blog/2011/10-27-jabber-now-open.html b/blog/2011/10-27-jabber-now-open.html index 1b7eb35..f713745 100644 --- a/blog/2011/10-27-jabber-now-open.html +++ b/blog/2011/10-27-jabber-now-open.html @@ -8,6 +8,28 @@ Unser [Jabber](http://jabber.spline.de)-Server ist jetzt testweise für alle offen. Wir können IPv6, SSL und sind (mit dns srv) redundant. +--- + +Ab sofort wird der [Spline](http://www.spline.de) Jaber-Server für jeden +nutzbar sein. Das bedeutet, man kann sich mit einem +[Jabber-Client](http://xmpp.org/xmpp-software/clients/) seiner Wahl einen +Account für jabber.spline.de registrieren. Falls ihr der Startcom SSL CA nicht +traut, ist hier der Fingerprint des SSL-Zertifikats: + +
+ + +``` +0d:16:b6:9a:08:d1:52:13:1b:ff:f7:0a:c8:75:7f:93:58:fb:41:0a +``` + +
+ +Bei Schwierigkeiten oder Fragen könnt ihr euch per Mail an die +[Maintainer](jabber@spline.de) wenden oder im IRC-Channel #spline auf +*irc.freenode.net* vorbei schauen. + + {% endfilter %} {% endmark %} diff --git a/blog/2012/03-04-reclustering-ejabberd.html b/blog/2012/03-04-reclustering-ejabberd.html new file mode 100644 index 0000000..b6dfadc --- /dev/null +++ b/blog/2012/03-04-reclustering-ejabberd.html @@ -0,0 +1,114 @@ +{% meta %} + title: reclustering ejabberd + tags: [ejabberd, jabber] +{% endmeta %} + +{% mark body %} +{% filter markdown %} + +Der Jabber-Dienst ist dieser Tage etwas instabil, das hat 2 Gründe: + ++ Unser Storage macht uns schwere Sorgen. Wir benutzen iscsi und der Server, +der die Volumes verteilt rebootet in regelmäßigen Abständen ohne ersichtlichen +Grund. Das hat inkonsistente bzw read-only Dateisysteme zur Folge und lässt +fast alle Dienste in einem halb-funktionierenden Zustand. Wir arbeiten an einer +Lösung. ++ Das Clustering der Ejabberd-Knoten scheint irgendwie nicht funktioniert zu +haben, sodass wir, so scheint es, kein redundantes, sondern ein voneinander +abhängiges Setup hatten. Ich habe hier mal zusammengetragen, was man tun muss, +um wirklich ordentliches Fail-Over zu haben. Das sind zwar sinnvolle +Einstellungen, aber wir garantieren natürlich nicht, dass das so funktioniert +:) Zu Doku-Zwecken ist der folgende Teil auf Englisch. + +Assume we have a 2-node setup (vm-jabber{0,1}) which has a broken replication +scheme and start over be purging vm-jabber1 completely. Since Ejabberd V 2.1.x +there is a nice way to remove a db node from a setup.
+ +On our master server (vm-jabber0): Make sure to include the following line in +ejabberd.cfg + + {modules, + [ + [...] + {mod_admin_extra, []}, + [...] + +After this, restart the ejabberd process and run: + + ejabberdctl remove_node 'ejabberd@vm-jabber1' + +In a debug shell (or the webinterface) confirm that the node has been purged: + + $ ejabberdctl debug + Attaching Erlang shell to node ejabberd@vm-jabber0. + To detach it, press: Ctrl+G, q, Return + + Erlang R14A (erts-5.8) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [kernel-poll:false] + + Eshell V5.8 (abort with ^G) + (ejabberd@vm-jabber0)1> mnesia:info(). + // SNIP // + running db nodes = ['ejabberd@vm-jabber0'] + stopped db nodes = [] + master node tables = [] + // SNIP // + // Hit Ctrl-C twice to abort the debug shell + +On the *purged* node, stop ejabberd, remove all database files and get a fresh +ejabberd.cfg copy from the master. Also, we will need the master cookie to +authenticate the nodes with each other. + + /etc/init.d/ejabberd stop + rm -rf /var/lib/ejabberd/* + scp root@vm-jabber0:/etc/ejabberd/ejabberd.cfg /etc/ejabberd/ + chown root:ejabberd /etc/ejabberd/ejabberd.cfg + chmod 640 /etc/ejabberd/ejabberd.cfg + scp root@vm-jabber0:/var/lib/ejabberd/.erlang.cookie /var/lib/ejabberd/ + chown ejabberd:ejabberd /var/lib/ejabberd/.erlang.cookie + chmod 440 /var/lib/ejabberd/.erlang.cookie + +When we are done we have to rebuild the mnesia database i.e. import the schema +(to disc) and get copies for all tables from the master. So we start a basic +erlang process and not ejabberd since this would recreate the ejabberd db for +a new local setup. + + su - ejabberd -c bash + erl -sname ejabberd@vm-jabber1 -mnesia dir '"/var/lib/ejabberd/"' \ + -mnesia extra_db_nodes "['ejabberd@vm-jabber0']" -s mnesia + [...] + (ejabberd@vm-jabber1)1> mnesia:change_table_copy_type(schema, node(), disc_copies). + // submit and hit ctrl-c twice to exit or check the newly populated db with mnesia:info(). + +Now you can fire up the second ejabberd node on vm-jabber1. But there is still +work to do. Ejabberd makes some weird decisions storing the data. Basically we +want to store as much shared data as possible in ram AND disc so that the slave +node can start ejabberd on its own because it has a copy of everything on disc. +Of course some tables are not required to start the jabber server. Session or +s2s data for example can be stored in ram only. The important thing is to +elliminate or at least reduce the number of "remote copy" entries since this +could block failover. Some memory eating things like offline_msg can be ignored +if there is not enough ram to begin with. I found it very handy to use the +web_admin module to go through the replication type of each table, here is +a reminder on how to tunnel it through to your client (we do not forward port +5280 here): + + ssh vm-jabber0 -L 8000:localhost:5280 # and fire up a browser to http://localhost:8000/admin + +First go through the master table and make sure every table has a sane type +- you need a disc copy if the nodes hast to start on its own! + +
+ +Here are the basic rules we implemented: + ++ default to RAM and Disc copy on both ends ++ if the table is machine dependent use RAM copy on both ends ++ use Disc only copy only for memory eating tables on the master and Remote copy on the slave + +
+That's it. Good Luck :) + + + +{% endfilter %} +{% endmark %} diff --git a/blog/2013/10-21-jabber-and-accounts.html b/blog/2013/10-21-jabber-and-accounts.html new file mode 100644 index 0000000..30cf527 --- /dev/null +++ b/blog/2013/10-21-jabber-and-accounts.html @@ -0,0 +1,36 @@ +{% meta %} + title: ejabberd + accounts.spline.de + tags: [accounts, jabber] +{% endmeta %} + +{% mark body %} +{% filter markdown %} + +Es ist endlich soweit. +Der jabber-Server funktioniert jetzt auch mit + +[https://accounts.spline.de](https://accounts.spline.de) + +Wir benutzen jetzt: + + {auth_method, [ldap, internal]}. + +Das heisst, Menschen können sich sowohl mit dem alten Passwort, als auch mit +dem accounts-Passwort anmelden. Intern gibt es dann tatsächlich zwei Einträge +in der auth-Tabelle, aber die Roster etc sollten davon nicht betroffen sein. +Solltet ihr doch Probleme haben, bitte meldet mir das sofort. + +Ausserdem habe ich `mod_register` durch `mod_register_refer` ausgetauscht. Der Code dazu liegt hier: + + +[http://git.spline.de/ejabberd/mod_register_refer/](http://git.spline.de/ejabberd/mod_register_refer/) + + +Da ich nicht durch den ganzen ejabberd-Code bin, kann da sicherlich was schief +gelaufen sein und ich wäre euch sehr verbunden, wenn ihr mal das +Neu-Registrieren mit euren Clients (libpurple, gajim, psi hab ich getestet) +probiert und mir schreibt, wenn irgendetwas falsch läuft. + + +{% endfilter %} +{% endmark %} diff --git a/blog/2014/01-02-jabber-s2s.html b/blog/2014/01-02-jabber-s2s.html index 93c9eb2..6a36d48 100644 --- a/blog/2014/01-02-jabber-s2s.html +++ b/blog/2014/01-02-jabber-s2s.html @@ -1,12 +1,34 @@ {% meta %} title: jabber.spline.de s2s encryption - tags: [jabber] + tags: [jabber, security] {% endmeta %} {% mark body %} {% filter markdown %} -Spline schaltet am Wochenende s2s encryption an, das kann und wird Probleme mit google erzeugen, genaueres auf dem [jabber blog](http://jabber.spline.de/). +Spline schaltet am Wochenende s2s encryption an, das kann und wird Probleme mit google erzeugen. + +--- + +There has been a long discussion about how to handle server to server +encryption or the lack of it on the [xmpp operators mailing +list](http://mail.jabber.org/mailman/listinfo/operators). Admins would like to +switch it on of course but the biggest player in the federation network, +Google, is blocking this. +However, both admins and developers have created and signed a manifesto on how +to deal with this issue that puts pressure on Google and might in the worst +case result in a federation split and the loss of a huge user base: + +
+[https://github.com/stpeter/manifesto/blob/master/manifesto.txt](https://github.com/stpeter/manifesto/blob/master/manifesto.txt) +
+ +I, personally, fully support this manifesto and hence decided to play along and switch to: + + -{s2s_use_starttls, optional}. + +{s2s_use_starttls, required_trusted}. + +on Saturday, January 4th. Let's see how it goes :) {% endfilter %} {% endmark %} -- cgit v1.2.3-1-g7c22