Installing our XMPP server

There are a large number of XMPP servers in the wild, from proprietary to open source, with communities of varying sizes. The XSF maintains a list of servers on its website at http://xmpp.org/xmpp-software/servers/ . However, this list does not take into account whether the projects are inactive or not; nor does it indicate the state of their implementations. Four open source servers worth having a look at which include:

• Openfire: A hugely popular Java-based server with a large community supporting a large number of plugins and that is actively developed (for more information can be found at: http://www.igniterealtime.org/projects/openfire/)
• Tigase: A popular Java-based server with active development and a great community, for more information can be found at http://www.tigase.net/
• MongooseIM: An Erlang-based server forked from a previous XMPP server implementation and actively developed by Erlang Solutions, which can be found at https://github.com/esl/MongooseIM
• Prosody: A fast and resource-light Lua-based server with a great core development team and an active community, which can be found at http://prosody.im

In this book, we're going to make use of Prosody since it is very easy to install, run, and configure. Before deploying to production, we recommend that you investigate the advantages and disadvantages of each system to see what works best for your particular requirements and environment. As XMPP is a standard, you'll be able to swap out servers without making any code changes, a great benefit of working with this setup.

Installing the server

Installing Prosody on an Ubuntu system is very easy since it is included in the main package repositories. In order to install Prosody, run the following command at the command line:

$ sudo apt-get install prosody

Prosody can then be started and stopped using the following standard methods:

$ sudo service prosody start
$ sudo service prosody stop

If you are not using Ubuntu, then Prosody may be available via your respective package manager. The best installation instructions for Prosody can be found at http://prosody.im/doc/install.

Prosody also produces Docker images of their releases, which are available from the official Docker hub: https://registry.hub.docker.com/u/prosody/prosody/ .

Configuring the server

By default, Prosody will store its configuration file at /etc/prosody/prosody.cfg.lua. The configuration file itself is rather simple and is written in the Lua language, which is the same language in which the Prosody server is written.

Shown here is the configuration file we are going to use throughout this book. Following the configuration example is an explanation of each part of these settings. As always, for the most up-to-date and detailed information, please visit the Prosody website (http://prosody.im):

modules_enabled = { 
        "roster"; 
        "saslauth"; 
        "tls"; 
        "dialback"; 
        "disco"; 
        "version"; 
        "uptime"; 
        "time"; 
        "ping", 
        "register"; 
        "posix"; 
        "bosh"; 
}; 
allow_registration = true; 
daemonize = true; 
consider_bosh_secure = true; 
cross_domain_bosh = true; 
pidfile = "/var/run/prosody/prosody.pid"; 
c2s_require_encryption = false 
authentication = "internal_plain" 
 
log = { 
        debug = "/var/log/prosody/prosody.log"; 
        error = "/var/log/prosody/prosody.err"; 
        { levels = { "error" }; to = "syslog";  }; 
} 
 
VirtualHost "localhost" 
    enabled = true 
    ssl = { 
        key = "/etc/prosody/certs/example.com.key"; 
        certificate = "/etc/prosody/certs/example.com.crt"; 
    } 
 
VirtualHost "anon.localhost" 
   authentication = "anonymous" 
 
Component "component.localhost" 
    component_secret = "mysecretcomponentpassword" 

Now, let's discuss each of the sections of the configuration file:

• modules_enabled: describes the modules to load when Prosody is started. At its core, Prosody is quite small, but many of the XMPP features are implemented within modules. If you ask members of the Prosody team whether the server supports a new feature, the response will generally be "There's a module for that." A full list of modules and configuration can be found at http://prosody.im/doc/modules .
• The modules we are loading here are mostly the defaults which are set by Prosody on installation:

  Module	Description
  roster	roster is like an address book for XMPP.
  saslauth	Simple Authentication and Security Layer (SASL) is a framework for authentication. It separates authentication mechanisms from application protocols, allowing any authentication mechanism supported by SASL to be used with any application protocol that uses SASL. It is within the SASL framework that we see the more secure authentication mechanisms.
  tls	Transport Layer Security provides encrypted communications for XMPP data transfer.
  dialback	Provides server identity verification using DNS when attempting to talk to remote servers.
  disco	Short for discovery, this allows the server to advertise what features it supports to other servers and clients.
  version	Replies to software version requests.
  uptime	Reports on how long the server has been active.
  time	Reports back on the time according to the server.
  ping	Sets up the server to reply to ping requests.
  register	Allows clients to create new user accounts on sign-up.
  Posix	Required for daemonizing and syslog logging.
  Bosh	Bidirectional-streams Over Synchronous HTTP (BOSH) is a long polling setup that allows two way XMPP communication over HTTP. It is a predecessor of WebSockets but still very useful in situations where connectivity isn't perfect.

• allow_registration=true;: Allow users to create an account from a client.
• daemonize = true;: Run Prosody as a daemon. If running in Docker, set this to false.
• consider_bosh_secure = true;: Generally, rather than talking to Prosody's BOSH endpoint directly, we proxy it via a web server (such as Nginx) and use that to handle SSL. Therefore it's safe to consider BOSH requests as secure.
• cross_domain_bosh = true;: This adds COR headers to BOSH responses to allow requests to come from any domain.
• pidfile = "/var/run/prosody/prosody.pid";: This is the location of the Process ID (pid) file for Prosody.
• c2s_require_encryption = false;: In production, we'd have this set to true for security, but for development, it's safe to set this to false. If set to true, then we'd be insisting on encrypted connections.
• authentication = "internal_plain";: The authentication mechanism used for clients. Here, we're saying to store the password as plain text, but in production, we'd store passwords as encrypted strings. This then also affects the usable authentication mechanisms.
• The log entry: Sets the log locations and the level at which we perform logging. Our setup pushes even the most detailed entries to the log files.
• Next, we define a set of virtual hosts, much like we would with a web server. Here, we have defined two virtual hosts for different reasons:
  • VirtualHost "localhost": This is our main virtual host and the one on which our users will exist. A user's JID will appear as test@localhost, for example.
  • VirtualHost "anon.localhost": Here we define what is known as an anonymous domain. This allows users to connect without an XMPP account. Generally, it is a best practice to prevent anonymous accounts from communicating with other servers in order to prevent spam.
• Lastly, we define a component connection (more about these later). We define our component to run on a subdomain. When a component attempts to connect to a server, the component sends a shared secret (i.e. a password known in configuration files for both the component and the server) as an authentication mechanism. Generally, components are run on the same server, so this method of authentication is considered appropriate.

Then we save this configuration file to /etc/prosody/prosody.cfg.lua and restart the server:

$ sudo service prosody restart

Testing our setup

Next, we're going to test our Prosody setup. First, we will test whether Prosody is listening to the client-to-server (C2S) and server-to-server (S2S) ports. By default, with XMPP, the C2S port is 5222 and the S2S port is 5269. We can perform a quick and easy test using telnet. If your server is running as expected, you will see an output similar to the following screenshot:

Testing Prosody connections using telnet

Next, we will also verify whether we have set up our BOSH endpoint correctly by visiting the endpoint in a browser, by visiting http://localhost:5280/http-bind/, port number 5280 being the default BOSH port, we should see the following screenshot:

Testing Prosody's BOSH endpoint from a browser

Creating a test account

Prosody has a great command-line utility, prosodyctl, which allows us to create and update user accounts as well as command the server. Here, we're going to use it to create our first XMPP account on the server. Type the following command in the command line:

$ sudo prosodyctl adduser test@localhost

You will then be prompted to enter a password. Let's use the Password password for now. Once this is complete, we have our XMPP account. We'll test this with a client in a moment.

Tip

If you ever forget your user passwords, it's simply a case of running the preceding command but replacing adduser with passwd. You will then be prompted for a new password.

Installing an XMPP client

Lastly, we'll install a standard desktop XMPP client, which will allow us to interact with our code. A list of XMPP clients is held on the XMPP website (http://xmpp.org/xmpp-software/clients/). Find one suitable for your platform and follow the installation instructions.

In this book, we're going to use Empathy (https://live.gnome.org/Empathy) since it comes installed as standard in the Ubuntu desktop:

1. First, load the Empathy application and you will be presented with the main window.
2. From here, select Accounts from the Empathy menu in the title bar.
3. Choose to add an account and select the Jabber option.
   

   Setting up an XMPP account in Empathy on Ubuntu

4. Next, in the Jabber ID box, enter test@localhost; and for the Password, enter password.
5. Once your details are entered, pop open the Advanced box and uncheck Encryption required, since we won't need this while developing.
6. After clicking on Done, your client should be connected to your local XMPP server; it's not very exciting so far.
7. To doubly verify that you are connected, you can check the Prosody log file and you should see entries similar to the following:

   $ sudo tail /var/log/prosody/prosody.log
   Feb 09 20:37:43 c2s2250e30  info  Client connected
   Feb 09 20:37:43 c2s2250e30  info  Authenticated as test2@localhost
   

Note

In addition to the main log file, there is also an error log file located at /var/log/prosody/prosody.err (by default). Should something be happening that you aren't expecting, this is also a good location to check.