Valid HTML 4.01 Transitional

Setting Up Openfire

James F. Carter <jimc@math.ucla.edu>, 2013-07-26

Having flamed out while setting up several XMPP servers, now I'm trying the ones based on Java. I don't know Java, I'm unhappy with their continuous security issues, and I've had bad experiences in the past with Java hogging resources. Nonetheless, my choice is now Java or nothing.

First will be Openfire. The current version is 3.8.2 dated about 2013-05-xx. The product hype on the website says:

Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache License. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.

This version is available on the SuSE Build Service. I downloaded and installed openfire (12Mb compressed, oink) and openfire-doc (1.1Mb). Non-cryptic install dependencies are only Java and basic utilities like grep. Documentation starts at /usr/share/doc/packages/openfire-doc/index.html .

You will need some kind of database. Drivers are bundled for MySQL, PostgreSQL, Microsoft SQL Server, and HSQLDB. The latter is the internal database and it requires no configuration options. Separate database schemas are provided for these four plus Oracle, Sybase and IBM DB2, implying that you will need to hack if you use others. You are warned that HSQLDB does not give high performance and a real database is recommended for a heavily used site. (SQLite…)

Files, from the SuSE package, end up in these places:

This is clearly not a LSB file layout. In particular, the log files are going to have to be moved to /var/log, the conf files have to be moved to /etc so they can be backed up, and the database has to go into /var/lib; I don't see where they're putting that. Logs from external commands can be redirected in /etc/sysconfig/openfire; I'm using /var/log/openfire (which I have to create by hand, owned by the Openfire user). The log files also have to be rotated; I copied one of my hacked scripts in /etc/logrotate.d .

Openfire runs as a non-root user. The docs mention a user jive, but the provided LSB script uses daemon if it is not set in /etc/sysconfig/openfire. I'm going to recycle ejabberd. No, I'm not. The RPM sets ownership of the software to daemon:daemon and the main dir /usr/share/openfire has mode 750. Temporarily I'm changing to daemon.

To configure Openfire, first make any needed changes in /etc/sysconfig/openfire. Then start it up and connect HTTP to port 9090. URL to connect to admin port 9090. Once TLS is configured it will listen on 9091 as well. It will not listen on 5222 until it has been configured.

When you connect it will run a setup wizard which will take care of the basic settings. These were my configuration choices:

The next step is to clean up the server properties, from the admin console. You start out in the Server Manager tab. Most of these are informational only.

Now in the Server Settings tab: The sections that I didn't change (most of them) are not shown.

On the User/Group tab you can view your user roster, but this is kind of useless with LDAP. On the Sessions tab you can see the active sessions, including kicking off users. Under Group Chat you can create multi-user chat rooms.

On the Plugin tab you can view which plugins are installed and add new ones from Openfire's repository.

The user experience: A user on localhost can connect and get a session secured by TLS. The client complains about the unverifiable host cert; blow off the error message. Any user on any other machine: it chatters back and forth but never actually begins the session. (Thus it's not a firewall issue, nor an issue of listening to the required port and/or interface.) The client (Pidgin) says TLS handshake failed, timed out. Command line for testing this with s_client:

openssl s_client -connect jacinth.jfcarter.net:5222 -CApath /etc/ssl/certs -starttls xmpp

It does not do TLS at all! s_client reports that it can connect but no peer cert is available.

Isn't that cute? I restarted Openfire and tried to log in again to the admin console, and it won't let me on. I think what happened is, I changed the domain name to jfcarter.net, and the administrator was defined as jimc@jacinth.cft.ca.us. When jimc@jfcarter.net authenticates, it is not the administrator. And there is no way to go back, short of manually jiggering the database, for which I have no maintenance tools. I think that's the end of Openfire.

Conclusion on Openfire: I have these objections:

On the other hand, the setup and admin interface is nicely and professionally done, and so far the software, within its design limitations, seems to be stable. I'm sure that if I reinstalled it with a compromise domain name that both it and I can live with, it would work, which is a big advantage over the competitors.

However, I'm going to keep working on other XMPP servers, and only return to Openfire if all of them fail.