This is part 2 of a 2 part tutorial on Prosody, which will show you how to install and configure extra modules to extend prosody's functionality. Part 1, which deals with basic installation and testing of prosody, is here. Here's an overview of the important additional functionality we will add to prosody:

• Multi user chats (XEP-0045)
• Server side message storage (XEP-0313 Message Archive Management)
• File and image transfer (SI File Transfer and Jingle signalling; in-band and out-of-band methods)
• Stream Management for surviving connection interruptions and switches - particularly useful on mobile (XEP-0198 Stream Management)
• Synchronising messages between multiple devices (XEP-0280 Message Carbons)
• Battery Saving techniques for mobile clients (XEP-00352 Client State Indication)
• User Blocking (XEP-0191 Blocking Command)

Not all clients support all of these XEPs. I consider the Android client Conversations (F-Droid | Google Play) to be pretty cutting edge in this respect - it's pushing forward a lot of XEPs that are required if we are going to see XMPP compete with the features of proprietary chat clients, particularly on mobile.

At the end of 2013, I wrote a series of tutorials explaining how to run an email server at home on a raspberry pi, which turned out to be very popular. I'm now aiming to do the same for instant messaging. This tutorial will:

• Introduce the Extensible Messaging and Presence Protocol (XMPP), formerly known as "Jabber"
• Discuss some of the pros and cons of XMPP vs some other proprietary protocols
• Give instructions for the installation and configuration of Prosody, a free and open source XMPP server.
• Discuss various important XMPP Extension Protocols (XEPs) and how to enable them
• Cover transport layer encryption (i.e. client-server and server-server TLS) and end-to-end encryption for clients
• Recommend client software for different platforms

Along the way, I'll expose the underlying protocol to give you the tools you need to debug the problem yourself, instead of relying on obscured error messages from GUI applications. This is part 1 of a 2 part tutorial. Part 2 can be found here.

ModSecurity is a Web Application Firewall: a program that can be used to inspect information as it passes through your web server, intercepting malicious requests before they are processed by your web application. This tutorial will show you how to install ModSecurity on Apache, and configure it with some sensible rules provided by the Open Web Application Security Project's Core Rule Set (OWASP CRS), which will help to protect your server against SQL injection, denial of service attacks, malformed requests, cross site scripting attacks, and more. And yes, you can use this guide with your Raspberry Pi if you're running Raspbian, Ubuntu, or another Debian derivative on it.

By far the most popular set of articles I have written is my Raspberry Pi Email Server tutorial. Clearly, there are plenty of people who don't like relying on freemail providers like Yahoo, Outlook and Gmail for a variety of privacy and security reasons. However, there is one major drawback of hosting your own email server: if your server is taken offline for maintenance, or your internet connection is interrupted, then incoming email can not be delivered and may bounce. This tutorial will describe how to set up another server to act as an MX backup. The backup server will be hosted on a separate internet connection with a different WAN IP address, and have a lower priority than your primary mail server in your Mail Exchanger (MX) DNS record. When your primary server is offline other MTAs will send email to the backup instead, and the backup will hold them until your primary mail server comes back online, and then deliver them. No more bounced emails. The biggest challenge when setting up a backup MX is convincing a friend or family member to allow you to run a RasPi or some other server on their network; the rest of the setup is a breeze compared to the full mail server installation described in the main tutorial, because fewer components are required (just Postfix). This guide is written for Debian and its derivatives (Raspbian, Ubuntu etc.) but since a basic postfix installation is more or less the same across different distributions you should be able to use it for any distro. My backup server runs openSUSE.

This tutorial will show you how to configure a caching BIND9 server on your local network, and configure an OpenWrt router to use it. This should result in slightly quicker DNS lookups, but to be honest, you may not notice a huge difference (my DNS lookups now take 30% less time, but I don't think this has made page loading noticeably faster). Here are a few situations where it could be particularly worthwhile:

• You have a large LAN with lots of clients, and you want to take some load off your router
• You are using something like modsecurity's real time RBL lookups and you want to reduce latency
• Your ISP's nameservers are slow but you would still like to use them
• You are a curious soul and you want to learn about DNS ;)

This article aims to explain what various DNS records are and how to use them. It is aimed at people hosting websites and email servers on a home server such as a raspberry pi.

How DNS Works

DNS stands for Domain Name System. In a nutshell, it's the system that we use to translate human readable domain names (e.g. samhobbs.co.uk) into the Internet Protocol (IP) addresses for those services (e.g. 195.166.151.235). The DNS system has a strict hierarchy, and lookups are performed recursively using a client/server model. This means that when your computer asks for the IP address for "subdomain.example.com", the DNS resolver you are using starts at the top and works backwards to find the address. The servers at the top of the pyramid (root name servers) direct clients to the name servers reponsibe for Top Level Domains (TLD, e.g. .com), and that server in turn is able to tell the client which name server is authoritative for the second level domain (e.g. example.com), and so on. Usually for small sites, the DNS records for your domain are managed by your Domain Name Registrar. The DNS resolver doesn't have to perform all these lookups every time, because each record has a Time To Live (TTL) in seconds, which tells the client how long they can cache the information for until it should be refreshed. That's Time To Live (live free), not Live (live electrical circuit), which is how I first read it! There are loads of different types of DNS record, so I've picked the most important ones you might need or want to use. These are:

1. DNS A - used to map a host name to an IP address
2. Mail Exchanger (MX) - used to tell clients which hostnames are used for email services
3. Sender Policy Framework (SPF) - used to define which servers are allowed to send email from your domain name
4. Pointer (PTR) - the opposite of DNS A, this record maps an IP address to the hostname

For a website, you only need a DNS A record. For an email server, you need at least a DNS A record and an MX record; PTR and SPF records will help you get your email through spam filters. I'll be illustrating how to set up the different types of record using Namecheap, my Domain Name Registrar, as an example. If you haven't registered a domain name yet, I'd recommend Namecheap -avoid GoDaddy if you can, since they have some pretty horrible pricing practices and consistently back the wrong side when it comes to internet censorship acts like SOPA and PIPA.

Google recently announced that it is going to start prioritising websites that offer HTTPS by default in its search engine results. At first, the positive effect will be small to give webmasters time to switch to HTTPS, but it will gradually become more of a significant signal. This is a good thing for the internet: SSL doesn't cost much for webhosts, and it makes it more difficult to spy on everyone all the time! The Electronic Frontier Foundation praised the decision calling it a "bold and welcome move to protect users". I wanted to start offering some of the services I run on my server to other friends and family, and I couldn't easily install the CAcert root on all of their devices, so this seemed like a good time to purchase a cert. The following describes how I configured the various services (Apache, Postfix, Dovecot) to use the new certificate from COMODO.

In my previous tutorial for installing Wordpress on a Raspberry Pi, I showed how to do a "quick and dirty" installation, by changing ownership of the whole Wordpress installation folder to the web server process (www-data). This gets the job done, because Wordpress is able to make changes to its own configuration files, themes and plugins.

Got a spare RasPi knocking around? Why not hook it up to your all-in-one and use it as a handy print and scanner server? I have previously tried to get my multifunction printer/scanner working with OpenWrt, but ran into difficulty with the scanner. Having tried it with the RasPi, I'm pleased to report that it's as easy as Pi ;) Print server capability is provided by the Common Unix Printing System (CUPS), and scanner capability is provided by Scanner Access Now Easy (SANE).