jabber.spline.de

notes about spline's jabber service

required s2s encryption

2014-01-02 by Michael, tagged as google, security

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. 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

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 :)

ejabberd + accounts.spline.de

2013-10-21 by Michael

Es ist endlich soweit.
Der jabber-Server funktioniert jetzt auch mit

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/

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.

reclustering ejabberd nodes

2012-03-04 by Michael
Der Jabber-Dienst ist dieser Tage etwas instabil, das hat 2 Gründe:
  1. 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.
  2. 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:
  1. default to RAM and Disc copy on both ends
  2. if the table is machine dependent use RAM copy on both ends
  3. use Disc only copy only for memory eating tables on the master and Remote copy on the slave
That's it. Good Luck :)

yes, we're open

2011-10-12 by mk

Ab sofort wird der Spline Jaber-Server für jeden nutzbar sein. Das bedeutet, man kann sich mit einem Jabber-Client 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 wenden oder im IRC-Channel #spline auf irc.freenode.net vorbei schauen.