Small Talk

Used responsibly, instant messaging (IM) offers the benefit of instant communication and collaboration on the corporate intranet. However, many companies, fearing IM's adverse affect on productivity, tweak their corporate firewalls to block all ports ferrying IM traffic. A better approach is to control the IM server by bringing it in-house. The Java-based, cross-platform Openfire server [1] makes it easy to host your own IM server.

The Extensible Messaging and Presence Protocol (XMPP) is one of the most popular protocols for powering an IM server. There are several XMPP-based IM servers available, but Openfire is one of the easiest to deploy and manage. Openfire implements many of the XMPP protocol's commonly used features [2] and scales well.

The Openfire server can be deployed on Windows, Mac OS X, and on various Linux distros, such as Debian, CentOS, Ubuntu, and Fedora [3]. To get started with Openfire, first make sure your server has the Java Runtime Environment (JRE) installed. If you are deploying Openfire on an RPM-based system such as CentOS, you're all set since the Openfire RPM package bundles the JRE.

On a DEB-based system such as Debian or Ubuntu, you need to install the JRE from the distro's repository with:

sudo apt install openjdk-8-jdk

When it's done, you can install the server with:

sudo dpkg -i openfire_4.4.2_all.deb

After it's installed, you will find Openfire under the /opt/openfire directory. You can control Openfire just like any other service with:

systemctl {start | stop | restart | status} openfire

The first time you run Openfire, you need to configure it by pointing your web browser to port 9090 on your server. For example, if the Openfire server is on a machine with the IP address 192.168.0.14, head to http://192.168.0.14:9090 to configure the server. A five-step configuration wizard will ask you basic questions, such as the database details for storing user information and a directory server for fetching authentication information.

After selecting the language in the first step, the configuration wizard will ask you to tweak basic server settings, such as the domain name (Figure 1). You should also change the default ports for accessing the administration console for security purposes. Furthermore, you should also encrypt the server's system properties by selecting one of the two encryption algorithms offered (Blowfish and AES) and specifying a key.

Figure 1: Click on the ? icon for help with the individual fields.

In the next step, you're asked to select a database (Figure 2) for storing information, such as user profiles and offline messages. If you are deploying Openfire on a small network, you can choose to use the built-in HSQLDB database, which doesn't require you to set up an external database server. However, if you'll be servicing hundreds of users concurrently, you should select the option to connect to an external database, such as MySQL.

Figure 2: Depending on your network and use, you can also control the number of connections to the database.

Similarly, in the following step, you are asked to select a mechanism for fetching user authentication information. Unless you have a directory server already managing users, you should use the default option, which entrusts user management to Openfire. In the last step, you are asked for the administrator's email address along with the password for accessing the admin interface on subsequent visits. Your Openfire server is now ready to accept connections and facilitate communications inside your network.

Until you have gained experience with Openfire, you should use its built-in HSQLDB database instead of an external one. Similarly, when deploying Openfire in a test environment, it's more convenient to entrust user management to Openfire instead of your directory server.

Using the Server

Your server is now up and running. You can connect to it via any IM client that supports the XMPP protocol, such as Pidgin, Gajim, Kopete, or Psi. For best results, I'll use the Spark IM client, which is designed by the Openfire developers specifically to be used with their IM server. Like the server, the Spark client also is written in Java. While its RPM version includes the JRE, the DEB version does not, so make sure you pull in the JRE (if you haven't already) before installing Spark.

Once installed, all you need to connect to the Openfire server is the server's location and your authentication information. Remember, however, that the new Spark versions are based on the latest Smack library, which doesn't allow you to connect if you are using IP addresses instead of domain names. You can temporarily work around this problem by disabling hostname verification in Spark [4].

The first order of business is to add some users, since your server currently doesn't have any users besides the default admin user. You can add users either via the web-based administration console or from within the client. If you prefer the first route, log into the server's administration console by heading to http://192.168.0.14:9090. This time however, instead of the configuration wizard, you'll be greeted by a login page. Enter the username (admin) and the password you specified in the last step of the configuration wizard to access Openfire's admin interface (Figure 3).

Figure 3: Openfire's dashboard has a tabbed interface that's logically arranged and intuitive to navigate.

To add a user, head to the Users/Group tab in the admin console, click on Create New User, and fill out the user's details. Users can also register themselves with the Openfire server from their clients. Click the Accounts button on the Spark login page and simply fill out the login details in the pop-up window.

Explore the Console

Openfire has a simple and straightforward administration console. It's divided into several tabs with each tab housing multiple configuration options. From within these, you can tweak every aspect of the server and integrate it with existing network services. The other aspect of running a server is being able to monitor its activity. The interface is also designed to provide you with visual feedback at a glance to help you keep tabs on the server and gauge its performance.

When you log into the server, you're presented with basic details about the server including which Openfire version you are running, the platform you are running it on, how long it has been running, the Java version powering the server, how much memory it is consuming, and so on.

On this page, you can also see which ports Openfire uses and for what purpose. Like other aspects of the server, these ports are also configurable. For instance, you can change the default secured (9091) and unsecured (9090) ports for accessing the server administration console by clicking the Edit Properties button in the Server Ports section.

You can also choose to change your time zone from a drop-down menu under Language and Time. Don't be too adventurous with this option, as the logs are time stamped based on the time zone you've selected here. If you select a time zone that's different from your location, you'll have trouble understanding the logs when troubleshooting a problem.

Speaking of logs, the administration console has a log viewer that you can use to view the server logs. Under the Logs option, you can get a snapshot of the Error, Warn, Info, and Debug logs. All of these logs, except Debug, are enabled by default. Enable the Debug log if the server is misbehaving (e.g., after you alter a system property or add a new component).

The Openfire server manages several tasks and resources. For all the components it has to maintain, the server keeps track of their maximum permissible size, their current size, usage as a percentage, and the resource's effectiveness. The effectiveness, as explained in the interface itself, measures how well your cache is working. If the effectiveness is low, this usually means that the cache is too small. Openfire flags such caches. You can view these caches under Cache Summary (Figure 4). To clear any individual cache, select the checkbox in the rightmost column for the cache you want to empty, then scroll down, and click the Clear Selected button.

Figure 4: You can click on any cache to view its contents.

Plugins

You can extend Openfire and infuse new functionality by adding plugins. The default Openfire installation ships with over 20 plugins that have been thoroughly tested. There are plugins that add useful features such as the ability to broadcast messages to all users and to filter messages based on their content. There also are plugins that help hook up Openfire to existing services on the network, such as the Asterisk private branch exchange or an email server.

To enable a plugin, head to the Plugins tab and click on Available Plugins to see a brief description of each plugin, as well as buttons to view each plugin's readme file and changelog (Figure 5). To install a plugin, click on the green + button next to it. Some plugins worth exploring are Broadcast, which sends messages to all users at once; the Email listener, which connects to your mail server and alerts users of incoming emails; and the Packet filter, which keeps conversations polite.

Figure 5: Besides the official plugins, you can find some third-party plugins for Openfire as well.

Share Rosters

Although Openfire has tons of useful features, I find roster sharing to be particularly useful for my deployments. Roster sharing allows you to populate your users' rosters in advance. In XMPP parlance, a roster is a friends list. With this feature, all your users can have their coworkers in their contact list as soon as they log in. This will work as long as you have a categorized list of groups and users within these groups, irrespective of whether this information comes from a directory server or has been created manually using the admin interface.

To allow members of each group to see each other, go to the Users/Groups tab in the admin interface. Switch to the Groups tab and click on any one of the listed groups. Scroll down to the Contact List (Roster) Sharing section and toggle the Enable contact list group sharing option and enter the name of the group in the text box (Figure 6).

Figure 6: You can share a roster with a specified group of users.

By default, members of a group are added in the contact list of other members of the same group. However, besides members of their own groups, certain users should be in everyone's roster, such as the IT department. For this, toggle the All users radio button under the Share group with sub-setting, which will give all users in every department access to users from IT in their contact list. Save the settings, and repeat the procedure for all the groups on your server.

Ready for Rollout

After you've tested Openfire and tried it in a pilot project, you'll want to put it into production. When you deploy the Openfire server on your production network, it's a good idea to hook it up to an external database instead of the built-in one, which doesn't offer the same level of performance and flexibility as an external database such as MySQL.

To connect Openfire to a MySQL database server, first create an empty database on that server, for instance with something like:

mysqladmin create openfire_db

Then, from under the Openfire installation (/opt/openfire/resources/database/), copy the database schema (openfire_mysql.sql), and use it to populate the database with something like:

cat openfire_mysql.sql | mysql openfire_db;

Openfire ships with database schemas for several databases, such as PostgreSQL, IBM's Db2, Microsoft SQL Server, Oracle, and more.

You'll also want to connect the Openfire server to a directory server such as OpenLDAP, if you have one running on your network [5]. You need to know the hostname or IP address and the port of the machine on which the directory server is running, its base DN (look for it in your OpenLDAP configuration file), and the authentication information. In the Openfire admin interface, toggle the Directory Server radio button in the Profile Settings step in the configuration wizard. Select the type of directory server you are running and enter and test the settings. If Openfire is able to connect to your directory server, you'll be able to pick out the elements from the directory server that you want to use to populate the users' IM profiles.

The easiest way to make changes to the Openfire server's database or profile settings is to rerun the setup wizard. For this you'll have to disable the administration console, by editing the /opt/openfire/conf/openfire.xml file and changing the <setup>true</setup> entry to <setup>false</setup>. Save the file and restart the server, which will now greet you with the setup wizard instead of the administration console login page.

Openfire behaves nicely with most network components if you have the right connection settings. Don't forget to configure your firewall to handle Openfire traffic. In addition to the admin console that runs on port 9090, Openfire uses some other ports to facilitate communication. In your firewall, make sure to forward traffic on port 5222, which clients use to connect to Openfire; port 7777, for file transfers; and any other port specified in your Openfire configuration.

Lots to Explore

Although I have covered a lot of ground, Openfire is capable of much more. For instance, you can create and manage chatrooms, run Openfire as a distributed load-balancing server across multiple physical installations, and connect users from two Openfire servers from different locations.

You can also use the Asterisk-IM plugin to link Openfire into your Asterisk VoIP gateway for unified communication. Besides enabling users to communicate with each other within your organization, you can also use the Candy plugin to hook Openfire to your website and use it to run an online help desk.

As with any server software, a shopping list of your exact IM needs should help you select the most useful software. However, Openfire is so diverse and malleable that you can use it in pretty much any situation to enhance communication.