Deploy a real-time collaboration server

Small Talk

© Lead Image © orson,

© Lead Image © orson,

Article from Issue 229/2019

Openfire is an instant messaging and group chat server that lets users communicate via the popular XMPP standard.

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, head to 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 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.


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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • DotGNU

    Write C# programs in Linux with the free and vendor-neutral DotGNU.

  • MTP in Linux

    Just because the MTP protocol is promoted by Microsoft doesn't mean you can't get music onto your MTP devices.

  • PelicanHPC

    Crunch big numbers with your very own high-performance computing cluster.

  • Tutorials – Apache Spark

    Churn through lots of data with cluster computing on Apache's Spark platform.

  • Ulteo OVD

    Serve up a fully functional virtual desktop through a web browser – with Windows and Linux apps running side by side.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More