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.