Greg Hudson’s MIT blog

jabber.mit.edu now runs Openfire instead of jabberd2. This hasn’t been widely publicized because we don’t really have an announcement list or other public infrastructure related to that service.

Other than a somewhat richer set of chatroom features, Openfire doesn’t directly offer much to XMPP users that they didn’t have before. But it will hopefully allow us to offer new features in the future such as presence via the web, click-to-chat for support organizations (the MIT Libraries may be piloting this soon), and possibly some kind of SIP integration.

This changeover has been a big part of what I’ve been working on for the past few months. Some issues related to the deployment:

* It actually went live twice. The first time (last Wednesday night), it had to be backed out because GSSAPI authentication wasn’t working. There’s a property you have to set if the hostname doesn’t match the XMPP domain, which is true on the production server but not the test server. We deployed it again late Thursday night and I fixed the problem in the wee hours of the morning.

* Roster items and queued messages were migrated across systems, but chatroom settings were not. This led to a lot of nonfunctional chatrooms: rooms would get into a state where someone had created the room but not configured it, so it would be “locked,” inaccessible to other people. This probably happened most frequently due to clients auto-joining rooms upon reconnecting, but could also happen when people joined rooms from clients which didn’t support chatroom configuration. I fixed most of the affected rooms by hand.

* The new chatroom configuration dialog uses a multi-value list field for “Roles for which presence is broadcast.” Unfortunately, Gaim/Pidgin has a bug in the handling of multi-value list fields, such that it smashes the list of pre-selected items down to the first item. So every time you configure a chatroom, you have to manually reselect all three options or the room reverts to only displaying presence for moderators. I debugged this problem yesterday and submitted bug reports. We’ll fix the Athena deployment of Gaim, but that probably only accounts for a minority of Gaim usage.

* Barnowl couldn’t connect to the new server. I debugged that problem Friday; it was due to a bug in XML::Stream which would close the stream if the server reused TLS session IDs. Or something. Once I figured out where the code was doing the wrong thing, I was able to google for the answer and find a fix on the web, which I think has now been deployed.