By default, jabber servers have the ability to communicate with each other, allowing a username on a server such as
jabber.org to communicate with a user on
jabber.turk-php.com without needing a username on both servers. This feature is great for public servers, but it introduces a foreign environment to a system running in a corporate setting. Protecting against any issues regarding server-to-server communication is as easy as not starting the
sm component. In such a setup, the
resolver component is also not necessary, but it is not a security problem to have it running.
Like all software,
jabberd2 too sometimes crashes and fails. Although each new release finds and fixes bugs that cause crashes, it's still important to make sure that the server never goes offline for a long period of time. You can ensure this using the
daemontools suite of tools, which monitors daemons and restarts them in the event that they die.
daemontools has a pretty straightforward installation procedure. If it's not already installed on your server, either find a package for your operating system or refer to the installation documentation and install the software.
daemontools requires a startup script for each component that it will monitor in order to use when restarting that component. Listed below is the script for the
c2s component as a reference. Paste this into a text file and save it as run. This script goes into the /service/c2s directory on your server, where /service is the default location
daemontools looks for services it needs to monitor.
#!/bin/sh exec setuidgid jabberd /opt/jabberd2/bin/c2s -D \ -c /opt/jabberd2/etc/jabberd/c2s.xml 2>&1
After you create a directory and a script for each component (
daemontools will take care of restarting these components should they die.
jabberd2 currently does not provide clustering features.
ejabberd, based on
erlang and its distributed database
mnesia, is capable of clustering out of the box and is worth considering if high availability and load balancing are priorities.
Instant messaging in the enterprise can be a very valuable and efficient tool when used properly, but its deployment needs good planning and execution. Little convenience features such as populating rosters automatically go a long way toward improving the system's acceptance.
Although I have tried to cover most of the instant-messaging needs and requirements of a typical corporation, your business will probably have different requirements that will require further research and planning. Still, this article should be helpful in deciding whether a solution based on the open Jabber protocol might suit your needs.
References and links
- Jabber Software Foundation
- jabberd2 documentation
- jabberd2 database schema
- Jabber Client Software
- Perl script for updating user rosters (direct download)
Oktay Altunergil works for a national web hosting company as a developer concentrating on web applications on the Unix platform.
Return to ONLamp.com.