Jabber

ejabberd 2.0.0

Send to Kindle

I have been running ejabberd 1.1.3 since I christened my current server nearly a year ago. In this post, I reported on some of the problems I had getting ejabberd to work with the Python-based ICQ and AIM transports. All of the problems were mine, and not the fault of the software.

The above link to ejabberd is to the company behind it. Here is the link to the community site.

What I didn’t mention in that post, and didn’t bother writing about in a separate post later on, was the trouble that I had with the pre-built binary installer for Linux. No matter what I tried (and I tried many things!), I couldn’t get it to work. It’s important to have a binary installer, because ejabberd requires Erlang, which is not typically installed on most Linux distros.

It turned out that the first download that I tried had a problem in that it didn’t have SSL support compiled into the Erlang binary, so even if I could have wrangled it to work, I wouldn’t have been happy, since I always use TLS (previously SSL) in my Jabber communications.

In the end, I downloaded and compiled Erlang, and then downloaded and compiled the ejabberd source as well. I got it working, but it was way more painful than it needed to be. A number of months ago, ejabberd 1.1.4 was released. It included a number of changes that I had no need for. Still, I downloaded it to see if the binary installer would work for me. It didn’t. I spent a bit of time really trying, and again, failed. This time though, it wasn’t worth going through the entire dance, since I had no need for the newer updates.

Two weeks ago, they released ejabberd 2.0.0. This was significant enough to warrant an install. I shuddered to think that they hadn’t fixed the binary installer problem, but I was prepared to slog through a full source install if that was the case.

My fears appeared to be justified. After installing, I received an error message that the installation failed. However, I tried running it anyway, and happily, I can report that even though the message claimed failure, ejabberd 2.0.0 worked perfectly once I tailored the default configuration file! Yippee!

I installed it last Friday, and it’s been running happily for four days now. It’s too early to be sure, but it’s possible that it has solved another problem. A few months ago I started having sporadic problems with the AIM and ICQ transports (I use the Python-based ones). One or the other one would fail, on occasion, and log me out. It was happening frequently enough for me to write separate init.d scripts to stop and start each separately, but not frequently enough for me to seriously considering investigating alternatives.

I have switched a number of times between Gajim and Pidgin (the new name for GAIM). There’s something that I like about Gajim, but somehow, every time, it ends up disappointing me or annoying me in some way. When I switched back from Gajim to Pidgin, the transports became slightly more stable, so I was a little happier, and committed (at least for a while) to just sticking with Pidgin.

Anyway, for the past four days, not a single problem with the transports, so it’s also possible (but too early to be sure) that ejabberd itself was somehow involved in the equation (perhaps it was too sensitive to problems in the client). I’m certainly crossing my fingers that the transport problems are behind me.

Welcome ejabberd 2.0.0! 🙂

New Machine

Send to Kindle

On April 23rd I announced the christening of my new server. At the time, I put the percentage of services that had been ported over at 95. It’s been at least 5 days since I’ve been at 100%, so the new machine is definitely “official”. Everything has been updated to point to the new machine, and all but one thing are running as expected.

The only problem I have is with one VoIP provider. I can’t get any audio to work between us, and the problem is definitely on my end, which is the main reason for not naming the provider. I can still connect reliably to them from my old server, from a different server that I control, and from a softphone as well, so something is broken on my new server in the config for them. That said, all other providers work, including identically configured ones, so it’s not a firewall problem, nor generically a broken Asterisk install. I’m not happy with this, because I can’t think of anything more to test. I’ve written twice to the Asterisk mailing lists, with no useful suggestions left to try. 🙁

I could probably write for hours on the experience of building the new machine. Very few people would maintain interest in that, I’m sure. I also don’t need it for a cathartic release, because I took very copious notes on the whole thing in a Google Notebook.

So, I’ll try to boil the essence down here, with the hope of not losing your interest too quickly. 🙂

The purpose of the change was to upgrade the OS from Red Hat 9 to CentOS 5.0. That worked well. I actually installed CentOS 5.0 Beta first, and then did an upgrade through yum, which worked fine!

My first real disappointment was attempting to build OpenPKG on the new box. The concept sounded really cool to me. The biggest reason for moving from RH9 to CentOS5 was that newer RPMs were harder and harder to find for RH9. OpenPKG held out the promise that one wouldn’t have to worry about this in the future, with the added benefit that you would never accidentally step on the operating system’s packages.

Unfortunately, I ended up wasting a ton of time on it, and it eventually failed to install itself, claiming that gcc couldn’t create executables on the system. Of course it could, as I built quite a number of packages from source… So, great concept, just not right for me at this time…

Had a minor glitch with SELinux (first time I’ve been on a system that was running it). Had to temporarily disable some of the checks to get a package installed and running, but was able to turn it back on afterwards, and haven’t had a problem since.

I have been a very happy user of Courier-IMAP for years, and felt guilty about even considering an alternative (just a loyalty thing). But, I’d read a number of nice things about Dovecot, and it just went official 1.0 a few days before, so I decided to try it. I’m really happy with it. It worked correctly the first time, and configuration was as straightforward as I was led to believe. On the other hand, it wasn’t a quick config, because there are so many things that you can (and sometimes should) set. The single config file (which I like!) is huge, because it’s so well documented, that the choices are relatively simple. You just have to read all those darn docs… 😉

Also installed the latest Postfix 2.4.0. I’ve been really happy with Postfix for years, and had little intention of switching that.

One minor nit about Linux in general. It’s a little annoying that dependencies can get out of whack quite easily. Some system thing depends on openssl-0.9.7 (for example), and you know that 0.9.8e fixes some bugs, and perhaps some new software you’re installing wants that. So, now it needs to go in it’s own directory (’cause you can’t mess with the system one), and then every package has to be told where to find the new one, etc. It all works, but it’s still a PITA.

Installed the latest WordPress (which of course meant MySQL and PHP, etc.). This time, the email config problem that I had on the old machine just disappeared (hooray!). I didn’t config it any differently, so who knows what was wrong before…

Installed the latest Zope (2.10.3, not Zope 3), and had remarkably few problems slurping up my old Data.fs file from a Zope 2.6.x installation. Very cool.

Switched from one webmail client to another, even though I had been happy with the former for years. The latter does more, of which I’m sure I won’t partake of the additional functionality anyway. It works, so that’s all I care about. I rarely use webmail, but when it’s necessary, it’s also ultra convenient (and, as stated, necessary). 😉

One of the bigger odysseys was the installation of a Jabber server. This should probably be its own post, but if it was, I would never condense it, so I’ll do my best not to go on too much here. On the old machine, I was running jabberd-1.4.3 for years. Jabberd2 was just out at the time that I first installed 1.4.3 (they are not the same project). I was able to get jabberd2 to work at the time, but I could not get the AIM and ICQ transports to work, so I reverted to 1.4.3.

The jabberd14 project is still alive and kicking, and I could have saved a lot of headaches if I had stuck with it. But, for a while, I wanted to try ejabberd. It is the official server of jabber.org since February 2007, which seemed impressive to me. 😉

Ejabberd is written in Erlang, and is supposed to scale like crazy (not that I have the slightest need for scale). The concept intrigued me. I’ll spare you all of the insane problems I had getting it to work right. Suffice it to say that it was not my fault, which is rare in these situations. 😉

When I finally got it to work stably, I installed the Python-based AIM and ICQ transports (PyICQ-t and PyAIM-t). The AIM transport worked correctly, and the ICQ one was flaky (solution later on).

Then Rob Page asked me to take a look at Openfire (previously called Wildfire). It sounded cool, and since I was having a problem with the ICQ transport, I figured I’d give it a shot. Man, it installed so easily from RPM, didn’t touch a single file on the system, could be uninstalled trivially, etc. In summary, I liked it instantly. I wasn’t crazy about running a JVM on the system full time, but the load would be negligible, so I decided to switch to it. Of course, while it worked well, and the administration was wonderful, the ICQ plugin was experimental (the AIM one is production), and it behaved like an experimental plugin, which put me where the other one did. There were a few other small annoyances in Openfire as well.

That made me decide to go back and beat my head on the ejabberd server and transports. Long story short, after investigating my setup on the old machine (prompted by Z_God in the Python Transports conference room), I noticed that I didn’t understand how transports speak to the main server. I had them both speaking on the same port (which the sample config file showed!), but on the working server, each transport spoke to the server on its own port! I switched ICQ and AIM to speak to ejabberd on separate ports, and voila, it has been rock solid ever since. I have retired Openfire, and am a very happy ejabberd and python-transports customer! 🙂

That’s pretty much it (at least at a high level). I’m happy with the machine. As usual, more twists and turns than one hopes for, but also more learning experiences than I expected, and interesting ones at that, mostly ending in success. Now if I can only figure out that one SIP provider audio problem, I could get back to some serious poker playing. 😉