server migration the final piece
On Monday, we finally completed the final piece of server migration, migrating our Jabber service. This was our hardest task of the actual migration, in my opinion. It had the most users, and we, for whatever reason, couldn’t just use the same software we had been using. On our old machine, we had been running jabberd 1.4.3, with a conference component as well as several bridges to other IM systems (AIM and ICQ, if I recall). It hung occasionally, but generally we were happy with it. Well, as long as we didn’t need to touch it.
First, we were interested in a more modern server. For instance, one that supported STARTTLS. So we first tried Jive Messenger, a Java-based jabber server with a built in conference component. Since we already had Java 5 installed, this seemed like a good idea. Because this was a new bit of software, I decided to test it out on my own home server before subjecting our users to it. It was all great until I tied to join a chat room from our existing 1.4.3 server. That exposed a series of s2s bugs that pushed Jive to the bottom of the stack. Let me be clear, however: I am a big fan of Jive Messenger. I think that it will someday be the best jabber server for small installations. And for some folks, it is probably the best server right now.
Next, I tried (locally) to use jabberd2, my next choice. On my home box (which is an AMD64), the s2s component kept crashing when using the conference component. Ok, next server, jabberd 1.4.4, a point upgrade to what we were using. This would actually segfault when registering a new account. No good. Try jabberd 188.8.131.52, same problem.
Next, ejabberd. Too alien.
Next, jabberd2 again. This time, I tried it on our new server, hoping that its non-64bitness would help. The conference component still had issues – it was crashing every seven seconds. At this point, we are almost back to Jive. I had one more trick, which was to use my jabberd 184.108.40.206 build to run the conference component rather than JCR.
Now, to migrate users. The migration tool that comes with the jabberd2 source has you add a service configuration blob to your jabberd 1.4 configuration and then run the tool against it. It seemed like a good idea, but, of course, didn’t actually work. For whatever reason, the migrate.pl script could ask our old jabber server about a user via this new “migrate” service, but the jabber server wouldn’t return any actual information. Hm. Must be missing a component to the jabberd 1.4 server or something.
After googling, finding a Ruby script for doing the migration in a google-cached mail message, installing Ruby, installing mysql-ruby, fixing the script to deal with inadvertent line breaks, we got the Ruby script to work. As a bonus, it migrated more stuff (vCard data and offline messages). Actually, the script was quite a nice solution, I just wish it was easier to find. So here we are, on jabberd2.