Recently, I had the pleasant experience of setting up ejabberd on Centos 5, and because of this afternoon of grueling fun, I’ve decided to point out some not so obvious problems that you may run into. Ultimately, we’re going to be running this chat service in a clustered environment, which should be even *more* fun I’m sure, but lets start with the basics.
First of all, ejabberd is written in erlang, which is an extremely smart multi-threaded language, that is also extremely difficult to use for the casual user. Because of this, everything you know about setting up and running normal services written in C usually doesn’t apply… and this is exactly where it gets interesting! Before even installing ejabberd, make sure that the version of erlang you have is identical to the version that ejabberd was built against. If you don’t, ejabberd is proven to eat babies at will, and we can’t have dead babies laying around on our operating system now can we.
When I setup my install I wasn’t able to find any erlang packages lying around for Centos 5, so I built the most recent version. A quick rpm search for ejabberd, however, had plenty of packages around the interwebs that were ready to go. While this is not the best practice anyways, I figured what the hell, why not just use my local erlang and the world built ejabberd. Well… I quickly found out why.
[root@host ~]# /sbin/service ejabberd start
Starting ejabberd: [ OK ]
Ok, great!
[root@host ~]# /usr/sbin/ejabberdctl status
Node ejabberd@host is started. Status: started
ejabberd is not running
WTF.
This is one of the great things about ejabberd, erlang, and init scripts. Just because the init script started the erlang service, that doesn’t mean that ejabberd itself is running, only that erlang is ready to run it. Thankfully, you can startup ejabberd directly and save yourself the trouble of guessing what went wrong. You’ll see a bunch of debug code, but this is what you’re looking for:
[root@host ~]# /usr/sbin/ejabberdctl live
=CRASH REPORT==== 20-Jun-2008::15:09:24 ===
crasher:
pid: <0.118.0>
registered_name: stringprep
exception exit: {{case_clause,{error,driver_incorrect_version}},
[{stringprep,init,1},
{gen_server,init_it,6},
{proc_lib,init_p,5}]}
in function gen_server:init_it/6
initial call: gen:init_it(gen_server,<0.117.0>,<0.117.0>,
{local,stringprep},
stringprep,[],[])
Now, this is awesome for those who understand erlang and can read tracebacks, but for your average user, good luck! In reality, all it is trying to tell you with “error, driver_incorrect_version” is that your version of erlang is wrong. Unfortunately, most error messages are even more cryptic. It is good that erlang has such great debugging features for coders, but you’ll never see a
“Erlang version: XXX found. Incorrect version.” Installing the matching erlang version with ejabberd quickly fixes this issue.
Moving on… there is one other problem that I ran into that was very difficult to debug and probably didn’t need to be, especially because of how simple of an issue it was to fix.
Ejabberd uses a cookie system to keep track of instances and probably also relates to it’s multi-threaded, cluster ability… but your cookies have to be properly setup or *BOOM*, it no worky. Also, ejabberd is VERY finicky about permissions. Everything needs to be running as an ejabberd user and group, or the program will not even run. Trying running as root, or changing jabber files to root:root and it basically explodes in your face. Back to the cookies though… the first time you run the init script or the jabber service manually, you’ll see the mnesia database created in /var/lib/ejabberd, along with this file:
[root@host ejabberd]# ls -lart /var/lib/ejabberd | grep cookie
-r-------- 1 ejabberd ejabberd 20 Jun 23 11:35 .erlang.cookie
If you cat the file there will be a random string of characters, such as: LVLUUTHHNVTIXKHRKLBJ
Ok, where does the trouble come from? First of all, there are multiple cookies that I’ve found and they all need to be the same string and have the perms be 400 erlang:erlang, or this happens:
"Error when reading /var/lib/ejabberd/.erlang.cookie: eacces"
"Cookie file /var/lib/ejabberd/.erlang.cookie must be accessible by owner only"
Now that takes care of /var/lib/ejabberd, everything should be good now right? Nope! Not yet! On each startup everything looks happy, except now it says:
[root@host ejabberd]# ejabberdctl status
RPC failed on the node ejabberd@nbabbles: nodedown
At this point I’ve about had it. Talk about frustrating, and I haven’t even configured the server yet! As it turns out, when I ran “ejabberdctl live” (or start) as root, it created yet another cookie, this time in /usr/lib64/ejabberd, the file is owned by root which ejabberd can’t read, and the data inside doesn’t match the first cookie. Great. Ok, easy fix. Copy the first cookie and perms over to this cookie:
[root@host ejabberd]# ejabberdctl status
Node ejabberd@nbabbles is started. Status: started
ejabberd is running
It’s about freaking time! *sigh* Yes, yes, I know… ejabberd and erlang are super-licious powerful… and also a pain in the ass! I guess good things don’t come easy, but you’d thinl there would be a little more info in error messages or on the web. Sadly, it seems like ejabberd is one of those mysterious and frightful programs that people don’t like to speak about. I you want some info about actually configuring the config, there is a basic tutorial over here. Good luck!
Downloads
