The problem comes when you try to snap objects to it with magnets or edit the shapes in any way. You realise its just a square box with an image inside. You can’t remove elements, change colours or manipulate it in any way.

Additionally, the existing set didn’t have any labels so you would need to check regularly as to what they all were.

So I set out to see if I couldn’t create better shapes from the Amazon’s original vector icons.

My results are linked at the bottom and are going up on Graffletopia shortly.

To make this I used the following process:

1. Download and unzip the EPS/SVG package available here.
2. Using Terminal, change to the downloaded directory, and then to the subdirectory eps_v1.4.
3. Convert the EPS files to PDF using pstopdf:
   

   $ mkdir pdf
   $ for i in *.eps; do pstopdf "$i" -o "pdf/$i.pdf"; done

4. The PDF files will now be available in the pdf subdirectory.
5. In OmniGraffle, touch the cog at the top of the Stencil window and select New Stencil.
6. Now, if you drag the converted PDF files to the OmniGraffle icon in your dock it will create a new graffle document (called Untitled) with the PDF contents converted to shapes.
7. Don’t just drag the pdf files directly into your graffle documents, this will just add the PDF’s preview image (a PNG) to your document.

Note: I did try the Visio stencils first thinking that might be easier but OmniGraffle Pro 5.4.2 (v139.16) did not like them at all.

Anyway, the resulting stencils are available here. To use, extract the zip file and drag the AWS folder into Library/Application Support/The Omni Group/OmniGraffle/Stencils/.

-Rob

Photo: Stéfan

Let’s get it out-of-the-way up front: I like arcades. So much so that I spent a good chunk of time in my not-so-recent (May 2012) trip to Japan in their arcades (Taito Stations, Game Stations, etc) throwing 100円 coins in pachinko, slots and UFO machines (or skill testers as they are more commonly referred to here). There is a huge variety of video games available in a Japanese arcade that you could easily blow your large chunks of your travel budget there, unlike the typical fare in the Australian equivalents.

But I digress; while there are many posts that could be written on the Japanese arcade, this one is about my favourite of them: Konami’s Jubeat machines (the Engrish on that site is great).

While I initially avoided them due to lack of familiarity I did eventually give them a go in Kyoto at an arcade on Kawaramachi-dori. And I was hooked, first go. It’s a simple concept, like Guitar Hero and its cohorts: tap the squares in time with the music.

Unlike Guitar Hero et al, Jubeat’s main screen is actually inside the squares themselves. A 4×4 grid of plastic squares contain the displays that prompt your interaction; the squares light up in sequence and you hit them at the appropriate time, in harmony with the music, to score points.

Anyway, while attempting to find an iOS game that might replicate the functionality of the original game I discovered that KONAMI had released the original game to the app store as jukebeat (Australian/US Store) or jubeat plus (Japanese iTunes Store link). Imagine my surprise! An opportunity to throw hours at the game that capitivated me in Japan without the need to feed the machine 100円 coins.

jubeat copious. Source: Wikimedia Commons

I installed the original Japanese version of the game (as that is the one I fell for, after all; but a Japanese iTunes account is required) but a few minutes with the jukebeat game from the Australian stores suggests they are the same, aside from the available music. The game itself is free. Konami charges for additional music tracks available via in-app purchase, should you wish to progress beyond the three bundled songs.

Each track has three levels available: a Basic level for beginner and intermediate players, an Advanced level, and an Extreme level for those who consider themselves insane. Naturally the levels are arranged in order of difficultly from 1-10, with your typical Basic level running 1-5, Advanced 5-8 and Extreme 7-10.

Playing the game by yourself can be quite amusing, hit the Single button to start a song on your own and attempt to beat your own score. Your performance is ranked a Failure (D and below), or Clear (C, B, A, S, SS and SSS). Hitting every square at the right time during the song will net you a Full Combo.

The difficulty curve is quite decent, though some games of the same level vary in difficulty; presumably that comes down to your playing style. It is pretty simple to learn to play though, and quite hard to master.

The music choice is varied. Interestingly, a decent chunk of the Japanese music is available via in-app purchase in the Australian/US version but not vice-versa. The majority of the music available is stuff that KONAMI has created themselves – either as originals for the game (KONAMI or copious packs) or from other games they have created. There’s a few packs in there from pop/rock/oldies though so it mixes it up reasonably well.

Additionally, you can host and join games (much like the original jubeat machines which are networked) over the local network and bluetooth (I was unable to find anyone willing to subject themselves to humiliating defeat in a match against me); just pick your song and host a game. Likewise Game Centre is built in, its depressing looking at the leader boards though.

But the proof is in the pudding: I’ve spent about ~40 hours playing since I rediscovered it a few weeks back. It is rather addictive; the innocent thought “one more go” common among the pounding of the iOS device screen. Speaking of, I’ve found it easier to play on my iPad than my iPhone (Giraffe Phone or otherwise) as you can use full hands and many fingers to play. My iPad has so far survived several dozen drummings without being worse for wear; but gentle players need not hammer the screen at all, just press carefully.

My advice: give it a go. It’s great fun and can be quite addictive. And if you’re after a challenge on a real jubeat machine, the old Hollywood Karaoke building on Bourke St in the Melbourne CBD (next to Hungry Jacks) has an arcade with two Jubeat machines. Be ready to take a pocket of shiny gold coins though: $1 will buy you four songs.

-Rob

PS. For fun, here’s someone attempting one of the bundled songs (Japanese version) on Extreme:

Installing PHP 5.4.4

At the time of writing PHP 5.4.4 is the current stable release of PHP, so we’ll be installing that and a dozen or so modules. I used to be a PHP developer in a past life (or so it feels, sometimes) so there are a lot of modules I used to make regular use of.

Additionally, I run a lot of the usual software like WordPress, Roundcube,  Gallery2, WebSVN, etc.

A quick look at the modules installed on Tyrande (the existing server):

[root@tyrande /]$ php -m
# [PHP Modules]
# bz2
# Core
# ctype
# curl
# date
# dom
# ereg
# fileinfo
# filter
# gd
# gettext
# hash
# iconv
# imap
# json
# ldap
# libxml
# mbstring
# mcrypt
# mhash
# mysql
# mysqli
# openssl
# pcre
# PDO
# pdo_mysql
# pdo_pgsql
# pdo_sqlite
# pgsql
# posix
# Reflection
# session
# SimpleXML
# snmp
# soap
# sockets
# SPL
# SQLite
# ssh2
# standard
# tidy
# tokenizer
# xml
# xmlreader
# xmlwriter
# zip
# zlib
# 
# [Zend Modules]

[root@tyrande /]$

Read on for full installation instructions..

Back on Shana, let’s go installing! We’ll be using the ports tree for the installation, so make sure it is up to date.

We want the following options in the port config:

• CLI (default)
• APACHE
• IPV6 (default)
• LINKTHR (default)

[root@shana /]$ cd /usr/ports/lang/php5

[root@shana /usr/ports/lang/php5]$ make install clean
# ===>  License PHP301 accepted by the user
# ===>  Found saved configuration for php5-5.4.4
# => php-5.4.4.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/.
# <snip>
# ***************************************************************
#
# Make sure index.php is part of your DirectoryIndex.
# 
# You should add the following to your Apache configuration file:
# 
# AddType application/x-httpd-php .php
# AddType application/x-httpd-php-source .phps
# 
# ***************************************************************
# <snip>
# ===>  Cleaning for apache-2.2.22_5
# ===>  Cleaning for php5-5.4.4

Once we’ve installed PHP we can check what modules are installed by default:

[root@shana /usr/ports/lang/php5]$ php -m
# [PHP Modules]
# Core
# date
# ereg
# libxml
# mysqlnd
# pcre
# Reflection
# SPL
# standard
# 
# [Zend Modules]

Not many at all. Fortunately, installing the rest is easy, if a little bit time consuming. Lets start with bz2.

Installing PHP Modules

Modules are available to be installed through ports also. This is rather useful as it will check for dependencies and install those if necessary. To install a module, you need to locate its port. The ports are generally named php5-<modulename>, like so:

[root@shana /usr/ports/lang/php5]$ whereis php5-bz2
php5-bz2: /usr/ports/archivers/php5-bz2

To install it, change over to there and run the usual make install clean.

[root@shana /usr/ports/lang/php5]$ cd /usr/ports/archivers/php5-bz2
[root@shana /usr/ports/archivers/php5-bz2]$ make install clean
# ===>  License PHP301 accepted by the user
# ===>  Extracting for php5-bz2-5.4.4
# => SHA256 Checksum OK for php-5.4.4.tar.bz2.
# ===>  Patching for php5-bz2-5.4.4
# ===>   php5-bz2-5.4.4 depends on file: /usr/local/bin/phpize - found
# ===>   php5-bz2-5.4.4 depends on file: /usr/local/bin/autoconf-2.69 - found
# ===>  PHPizing for php5-bz2-5.4.4
# Configuring for:
# PHP Api Version:         20100412
# Zend Module Api No:      20100525
# Zend Extension Api No:   220100525
# <snip>
# ===>  Installing for php5-bz2-5.4.4
# ===>   php5-bz2-5.4.4 depends on file: /usr/local/include/php/main/php.h - found
# ===>   Generating temporary packing list
# ===>  Checking if archivers/php5-bz2 already installed
# ===>   Registering installation for php5-bz2-5.4.4
# ****************************************************************************
#
# The following line has been added to your /usr/local/etc/php/extensions.ini
# configuration file to automatically load the installed extension:
# 
# extension=bz2.so
# 
# ****************************************************************************
# ===>  Cleaning for php5-bz2-5.4.4

What happens is the following:

1. It extracts the PHP source into a separate working directory.
2. Changes into the extensions subdirectory.
3. Runs phpize, which will setup the subdirectory with your local PHP configuration ready to build.
4. Runs ./configure in the extension’s subdirectory.
5. Runs make in the extension’s subdirectory.
6. Runs make install to install the extension and activates it in your /usr/local/etc/php/extensions.ini

Pretty easy, yes? It gets even easier. If you’ve installed portupgrade (and you should if you haven’t), you can condense the above into a single command:

[root@shana /]$ portinstall php5-dom
# [Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 74 packages found (-0 +0)  done]
# [Gathering depends for textproc/php5-dom ................................................... done]
# ** Port marked as IGNORE: www/apache22:
# 	Do not install. Installed manually.
# --->  Skipping 'textproc/php5-dom' because a requisite port 'www/apache22' failed (specify -k to force)
# ** Listing the failed packages (-:ignored / *:skipped / !:failed)
# 	- www/apache22
# 	* textproc/php5-dom

You will see that that failed because the dependency of apache22 is marked as IGNORE. What can we do? Just run portinstall -k <portname> and it will install it anyway.

[root@shana /]$ portinstall -k php5-dom
[Gathering depends for textproc/php5-dom ................................................... done]
# --->  Installing 'php5-dom-5.4.4' from a port (textproc/php5-dom)
# --->  Building '/usr/ports/textproc/php5-dom'
# ===>  Cleaning for php5-dom-5.4.4
# <snip>
# ===>  License PHP301 accepted by the user
# ===>  Extracting for php5-dom-5.4.4
# => SHA256 Checksum OK for php-5.4.4.tar.bz2.
# ===>  Patching for php5-dom-5.4.4
# ===>   php5-dom-5.4.4 depends on file: /usr/local/bin/phpize - found
# ===>   php5-dom-5.4.4 depends on file: /usr/local/bin/autoconf-2.69 - found
# ===>   php5-dom-5.4.4 depends on executable: pkg-config - found
# ===>   php5-dom-5.4.4 depends on shared library: xml2.5 - found
# ===>  PHPizing for php5-dom-5.4.4

You can repeat this for the rest of your modules.

WARNING: Some of these ports have dependencies on x11 (the graphical user interface). To prevent ports from installing x11, you need to add WITHOUT_X11=yes to your /etc/make.conf.

Then you can install whatever modules you need.

[root@shana /]$ portinstall php5-ctype
[root@shana /]$ portinstall php5-curl
[root@shana /]$ portinstall php5-fileinfo
[root@shana /]$ portinstall php5-filter
[root@shana /]$ portinstall php5-gd
[root@shana /]$ portinstall php5-gettext
[root@shana /]$ portinstall php5-hash
[root@shana /]$ portinstall php5-iconv
[root@shana /]$ portinstall php5-imap
[root@shana /]$ portinstall php5-json
[root@shana /]$ portinstall php5-ldap
[root@shana /]$ portinstall php5-mbstring
[root@shana /]$ portinstall php5-mcrypt
[root@shana /]$ portinstall php5-mysql
[root@shana /]$ portinstall php5-mysqli
[root@shana /]$ portinstall php5-openssl
[root@shana /]$ portinstall php5-pdo
[root@shana /]$ portinstall php5-pdo_mysql
[root@shana /]$ portinstall php5-pgsql
[root@shana /]$ portinstall php5-pdo_pgsql
[root@shana /]$ portinstall php5-sqlite3
[root@shana /]$ portinstall php5-pdo_sqlite
[root@shana /]$ portinstall php5-posix
[root@shana /]$ portinstall php5-session
[root@shana /]$ portinstall php5-simplexml
[root@shana /]$ portinstall php5-snmp
[root@shana /]$ portinstall php5-soap
[root@shana /]$ portinstall php5-ssh2
[root@shana /]$ portinstall php5-tidy
[root@shana /]$ portinstall php5-tokenizer
[root@shana /]$ portinstall php5-xml
[root@shana /]$ portinstall php5-xmlreader
[root@shana /]$ portinstall php5-xmlwriter
[root@shana /]$ portinstall php5-zip
[root@shana /]$ portinstall php5-zlib

Enabling PHP support in Apache

Now that we’re setup, the last step is to enable support for PHP in Apache. It will have already done one step of this process for us, adding this line:

LoadModule php5_module        /usr/local/libexec/apache22/libphp5.so

to your /var/www/conf/httpd.conf file.

The other bit, as mentioned above when we installed PHP is to add the .php extension.

Open up your /var/www/conf/httpd.conf file, and search for the existing AddType references. It shows up on about line 359 for me.

Add these in anywhere there; I put mine in after the AddType application/x-gzip .gz .tgz line.

AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps

And we’re done! In the next part we’ll install Subversion, then in Part 4 we configure Apache and setup some websites.

I’ll lay this out up front: I don’t like the FreeBSD layout for Apache. Everything is scattered throughout /usr/local and buried deep in the system. I got used to using the OpenBSD layout during my stint with that OS, and so I continue to use that on FreeBSD. It puts everything in /var/www/ and keeps it nice and clean together.

That said, the binaries and other bits and pieces should remain in /usr/local/.

Building from Scratch

For once we’re not going to install Apache from ports. Why? Because it’s too damn hard to adjust the layout without building a completely custom port. What we can do though is use the ports tree to do a big chunk of the work for us.

Configure your options

Run make config in the port and select the options you want installed. I go with the defaults here usually.

[root@shana /]$ cd /usr/ports/www/apache22
[root@shana /usr/ports/www/apache22]$ make config

Install the dependencies

Now that we’ve selected our options, we can also use it to build and install the dependencies, much the same as we would do if we were installing Apache through ports.

[root@shana /usr/ports/www/apache22]$ make depends
# ===>   apache-2.2.22_5 depends on file: /usr/local/bin/perl5.12.4 - found
# ===>   apache-2.2.22_5 depends on file: /usr/local/bin/perl5.12.4 - found
# ===>   apache-2.2.22_5 depends on shared library: expat - found
# ===>   apache-2.2.22_5 depends on shared library: apr-1 - found
# ===>   apache-2.2.22_5 depends on shared library: pcre - found
# ===>   apache-2.2.22_5 depends on shared library: iconv.3 - found
# ===>   apache-2.2.22_5 depends on file: /usr/local/bin/perl5.12.4 - found
# ===>   apache-2.2.22_5 depends on file: /usr/local/bin/autoconf-2.69 - found
# ===>   apache-2.2.22_5 depends on package: libtool>=2.4 - found
# ===>   apache-2.2.22_5 depends on file: /usr/local/bin/perl5.12.4 - found

So that is everything we should need.

Generating the configure command

Now we let the port install get as far as configuring the build, that will generate the configure command that was used, and we can copy that command and use it to build our own setup.

[root@shana /usr/ports/www/apache22]$ make configure
#
#  To enable a module category: WITH_<CATEGORY>_MODULES
#  To disable a module category: WITHOUT_<CATEGORY>_MODULES
#
#  Per default categories are:
#   AUTH AUTHN AUTHZ DAV CACHE MISC
#  Categories available:
#   AUTH AUTHN AUTHZ CACHE DAV EXPERIMENTAL LDAP  MISC PROXY SSL SUEXEC THREADS
#
#   To see all available knobs, type make show-options
#   To see all modules in different categories, type make show-categories
#   You can check your modules configuration by using make show-modules
#
# ===>  Found saved configuration for apache-2.2.22_5
# ===>  Extracting for apache-2.2.22_5
# <snip>
# config.status: creating include/ap_config_auto.h
# config.status: executing default commands

Setting up our own build environment

Now we’ve had our fun with ports it is time to build our own copy of Apache. I do my compilation in a directory called /archive/compile, but you can do it anywhere you like.

Grab the source

Ports will have also downloaded the source for you, so you can just extract it directly.

[root@shana /archive/compile]$ tar -zxf /usr/ports/distfiles/apache22/httpd-2.2.22.tar.bz2 
[root@shana /archive/compile]$ cd httpd-2.2.22/
[root@shana /archive/compile/httpd-2.2.22]$

Create our custom layout

Now we also need to add the layout to the config.layout file. Just add this to the bottom of /archive/compile/httpd-2.2.22/config.layout.

#   iTransit Layout
<Layout iTransit>
    prefix:        /var/www
    exec_prefix:   /usr/local
    bindir:        ${exec_prefix}/bin
    sbindir:       ${exec_prefix}/sbin
    libdir:        ${exec_prefix}/lib
    libexecdir:    ${exec_prefix}/libexec/apache22 
    mandir:        ${exec_prefix}/man      
    sysconfdir:    ${prefix}/conf
    datadir:       ${prefix}
    installbuilddir: ${exec_prefix}/share/apache22/build
    errordir:      ${prefix}/error
    iconsdir:      ${prefix}/icons
    htdocsdir:     ${prefix}/htdocs
    manualdir:     ${exec_prefix}/share/doc/apache22
    cgidir:        ${prefix}/cgi-bin
    includedir:    ${exec_prefix}/include/apache22  
    localstatedir: ${prefix}
    runtimedir:    ${prefix}/logs
    logfiledir:    ${prefix}/logs
    proxycachedir: ${prefix}/proxy
</Layout>

This layout is a mixture of the FreeBSD and OpenBSD layouts.

Obtain the configure script

When you run configure it will create a file called config.nice that has the command used to call configure. Copy it to your current directory under a different name. This would work for most people:

[root@shana /archive/compile/httpd-2.2.22]$ cp /usr/ports/www/apache22/work/httpd-2.2.22/config.nice t.sh

It would create a file called t.sh in your local directory. If, like me, you’ve moved your ports working directory, check under that.

[root@shana /archive/compile/httpd-2.2.22]$ cp /usr/obj/usr/ports/www/apache22/work/httpd-2.2.22/config.nice t.sh

Customise the configure script

You can now modify your t.sh file to make whatever adjustments you need to configure. In my case we want to use the custom layout we added above. Open up t.sh and change line 9 from:

"--enable-layout=FreeBSD" \

to

"--enable-layout=iTransit" \

Then head on down to line 59 and delete the prefix line, otherwise it will overwrite the prefix specified in the layout.

"--prefix=/usr/local" \

Applying Patches

There are a couple of FreeBSD-specific patches that we should really apply before we start compiling it. Without these, your custom build of Apache won’t build at all.

Patches can be found in /usr/ports/www/apache22/files/, we’ll take what we need and apply them directly.

[root@shana /archive/compile/httpd-2.2.22]$ patch </usr/ports/www/apache22/files/patch-server__util_pcre.c 
# Hmm...  Looks like a unified diff to me...
# The text leading up to this was:
# --------------------------
# |--- server/util_pcre.c.orig	2005-11-10 16:20:05.000000000 +0100
# |+++ server/util_pcre.c	2012-02-13 23:11:17.898984171 +0100
# --------------------------
# Patching file server/util_pcre.c using Plan A...
# Hunk #1 succeeded at 137.
# done

So that’s one done, lets do the rest.

[root@shana /archive/compile/httpd-2.2.22]$ patch </usr/ports/www/apache22/files/patch-configure.in
[root@shana /archive/compile/httpd-2.2.22]$ patch </usr/ports/www/apache22/files/patch-modules__proxy__mod_proxy_connect.c
[root@shana /archive/compile/httpd-2.2.22]$ patch </usr/ports/www/apache22/files/patch-server__core.c
[root@shana /archive/compile/httpd-2.2.22]$ patch </usr/ports/www/apache22/files/patch-support__Makefile.in
[root@shana /archive/compile/httpd-2.2.22]$ patch </usr/ports/www/apache22/files/patch-support__ab.c 
[root@shana /archive/compile/httpd-2.2.22]$ patch </usr/ports/www/apache22/files/patch-support__apachectl.in
[root@shana /archive/compile/httpd-2.2.22]$ patch </usr/ports/www/apache22/files/patch-support__apxs.in

Installing Apache

Now we can build and install Apache the same way we would for anything else we’re building from source.

Running configure

To configure the source directory with all the pre-requisites, just run the t.sh command from earlier.

[root@shana /archive/compile/httpd-2.2.22]$ ./t.sh
# checking for chosen layout... iTransit
# checking for working mkdir -p... yes
# <snip>
# config.status: creating include/ap_config_auto.h
# config.status: executing default commands

Building the Source

So the configure completed successfully, now we just run make.

[root@shana /archive/compile/httpd-2.2.22]$ make
# Making all in srclib
# Making all in os
# Making all in unix
<snip>
# /usr/local/share/apr/build-1/libtool --silent --mode=link cc -g -I/usr/local/include  -O2 -pipe -I/usr/include -fno-strict-aliasing  -rpath=/usr/lib:/usr/local/lib -L/usr/lib -L/usr/local/lib -L/usr/local/lib/db42  -rpath=/usr/lib:/usr/local/lib -L/usr/lib    -o mod_rewrite.la -rpath /usr/local/libexec/apache22 -module -avoid-version  mod_rewrite.lo

Creating the users

If you haven’t already, we’ll need to create the users. The port normally does this for you but it is a requirement that it is done. Run the following commands:

[root@shana /archive/compile/httpd-2.2.22]$ pw groupadd -n www -g 80
[root@shana /archive/compile/httpd-2.2.22]$ pw useradd -n www -u 80 -d /nonexistent -g www -s /usr/sbin/nologin

Installing Apache

Now that that is all done, lets install this beast.

[root@shana /archive/compile/httpd-2.2.22]$ make install
# Making install in srclib
# Making install in os
# Making install in unix
# <snip>
# Installing configuration files
# mkdir /var/www/conf
# mkdir /var/www/conf/extra
# mkdir /var/www/conf/original
# mkdir /var/www/conf/original/extra
# Installing HTML documents
# mkdir /var/www/htdocs
# Installing error documents
# mkdir /var/www/error
# Installing icons
# mkdir /var/www/icons
# Installing CGIs
# mkdir /var/www/cgi-bin
# Installing header files
# Installing build system files
# Installing man pages and online manual

All installed! And in the correct places too.

Creating the rc scripts

Now we just need to create the necessary rc files to control starting/stopping Apache. Fortunately ports has us covered there too. We just need some minor modifications to the ones supplied with ports in order to get our very on /usr/local/etc/rc.d/apache22 and /usr/local/etc/rc.d/htcacheclean files.

[root@shana /archive/compile/httpd-2.2.22]$ cat /usr/ports/www/apache22/files/apache22.in | sed 's/%%PREFIX%%/\/usr\/local/g' > /usr/local/etc/rc.d/apache22
[root@shana /archive/compile/httpd-2.2.22]$ cat /usr/ports/www/apache22/files/htcacheclean.in | sed 's/%%PREFIX%%/\/usr\/local/g' > /usr/local/etc/rc.d/htcacheclean

Preventing the port from installing

The other thing we will want to do is prevent the port from installing. In some cases another port will have Apache listed as a dependency. Ports, being the clever thing it is, will attempt to install those missing dependencies for you, which will blow away your custom Apache install.

Lets mark the port as forbidden, add this to the top of /usr/ports/www/apache22/Makefile:

FORBIDDEN=       Do not install. This was installed manually.

And that’s it. We’re finished.

In the next part, I’ll setup some test virtual hosts, install PHP and Subversion.

Warning: This is another long one.

I use the OpenBSD Packet Filter, or pf, for my server-level firewall. Why? Based originally on ipf, I find it to be much simpler and more powerful than the usual tools like iptables. How powerful? One line will normalise all incoming traffic. Normalisation is the process of cleaning up bad or invalid packets that can wreak havoc in poorly written server software.

It has the usual port filtering and Network Address Translation (NAT) features, plus traffic redirection (port forwarding),  Operating System-based filtering, packet queuing, prioritisation, address pools, and load balancing. Yep, when paired with CARP (the Common Address Redundancy Protocol), pf can bring you the same level of redundancy and load balancing as enterprise level Cisco gear. I had a series of four servers setup in an old workplace, each was redundant for the other using CARP + pf. You could even control the order of failover across all four servers.

Anyway, pf is installed by default, we just need to setup our rules and enable it. The first thing you need to know though, is don’t turn it on with untested rules. If you do you’re more than likely to lock yourself out of the server, at which point you’d better hope your console access is working.

Before we dive into my configuration, an overview of the configuration file is probably in order. A pf.conf file is generally broken into several sections.

Now, while my general configuration has a few interesting things you can do with pf, it is actually rather boring compared to some setups I’ve done in the past. I don’t use traffic redirection, queuing, prioritisation or load balancing. It’s just a server firewall.

The most useful resource you will find for pf is the OpenBSD FAQ page on the topic.

Read on for my configuration and the step by step instructions to set it up.

My Entire Configuration

This is my /etc/pf.conf file in its entirety.

#
# Shana pf.conf
#

# Variables
ext_if = "bge0"
ext_ip = "( " $ext_if " )"

# Tables
table persist file '/etc/pf.china'
table persist file '/etc/pf.korea'
table persist
table persist file '/etc/pf.blacklist'

#
# Options
#

# Return a reset for all blocks
set block-policy return

# Gather stats for the primary interface
set loginterface bge0

# Ignore the loopback
set skip on lo0

# Normalisation
scrub in all

#
# Rules
#

# Default deny
block log all

# Anything in the blacklist should be stopped here
block in quick on $ext_if from to any
block in quick on $ext_if from to any
block in quick on $ext_if from to any
block in quick on $ext_if from to any

# Outgoing traffic
pass out on $ext_if proto { tcp, udp } from $ext_ip to any keep state

# Allow ICMP traffic
pass proto icmp all

# Allow SSH
pass in on $ext_if proto tcp from any to $ext_ip port 22 flags S/SA keep state (max-src-conn-rate 5/60, overload flush global)
pass out on $ext_if proto tcp from $ext_ip to any port 22 keep state

# NTP
pass out on $ext_if proto { tcp, udp } from $ext_ip to any port ntp keep state

# Allow web
pass in on $ext_if proto tcp from any to $ext_ip port { 80, 443 } keep state
pass out on $ext_if proto tcp from $ext_ip to any port { 80, 443 } keep state

# Allow mail
pass in on $ext_if proto tcp from any to $ext_ip port { 25, 143, 993, 995 } keep state
pass out on $ext_if proto tcp from $ext_ip to any port { 25, 143, 993, 995 } keep state

# Allow DNS
pass in on $ext_if proto { tcp, udp } from any to $ext_ip port 53 keep state
pass out on $ext_if proto { tcp, udp } from $ext_ip to any port 53 keep state

My Configuration Explained

There’s a lot there, so lets step through that one section at a time.

Macros and Tables

# Variables
ext_if = "bge0"
ext_ip = "( " $ext_if " )"

Here we set a couple of very simple variables.

# Tables
table persist file '/etc/pf.china'
table persist file '/etc/pf.korea'
table persist
table persist file '/etc/pf.blacklist'

And some very simple tables. The <china> and <korea> tables load up a couple of files. Those files contain a list (a list with an IP Address or subnet on each line) of subnets that are typically in use in China and Korea, respectively. Why do I block those? I do no business with anyone in those countries, and don’t host any resources they might need. However, putting a blanket block on those ranges dramatically reduces the amount of security issues I have to deal with. Everything from attempts to bruteforce my SSH server (more on this later) to worms hitting my websites.

The <ssh_bruteforce> is a special table that holds IP Addresses of people who have attempted to bruteforce the SSH server, and the <blacklist> table holds ranges and IP addresses that I’ve blacklisted manually. More on those two at the end of this post.

PF Options

Here I set some of the runtime options for pf. One by one they are:

# Return a reset for all blocks
set block-policy return

This will cause pf to return a reset on blocked packets. By default most firewalls will just silently drop blocked packets, which means the connecting client has to wait for a timeout on their end. I return a reset for a couple of reasons:

• Client performance. If I’m trying to connect to the server but specify the wrong port it gets annoying, you either need to kill your connection and try again, or wait for the timeout. This penalises legitimate connections to your server.
• Security. Port scanning tools like nmapknow the difference between a blocked (dropped packet) and a closed port. So if you’re scanned while dropping packets, it will return a list of all ports that are open (you’re running a service on that port), ports that are closed (the port isn’t firewalled, but there is no service listening on that port), and ports that are firewalled. This gives a potential attacker extra information; that you are running a firewall, and that some services that are normally running aren’t running.If you return a reset, though, then all ports are either open or closed and the scanner doesn’t know if it is because they’re firewalled or not.

# Gather stats for the primary interface
set loginterface bge0

This line sets our log interface. pf will gather statistics on that interface, like packets and bytes in/out. In my case I want to gather statistics for all traffic on my external interface.

# Ignore the loopback
set skip on lo0

And a simple skip mechanism for the loopback. This means that any traffic sent to localhost/127.0.0.1 on the loopback interface won’t be filtered by the firewall. After all, if the traffic is already internal to the server filtering it again won’t be much help, but processing all loopback traffic could be a large performance hit on your server.

Normalisation

Here is a one of the niceties that found their origins in pf. I’m not sure if it’s available in other firewalls or not these days, but it’s certainly useful.

# Normalisation
scrub in all

From the FAQ:

“Scrubbing” is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations.

Pretty cool, eh? For this rule we’re just scrubbing on the in direction.

Port Filtering

Now we get into the meat of my setup. Let’s dive right in:

# Default deny
block log all

This is the default behaviour. It is a good idea at this point to mention that pf will run a packet through an entire ruleset and use the rule that it matched last. (Unless you use the quick keyword, see the next bit).

This means that you put your default behaviour at the top of your ruleset, and then your allow rules after it. So by default I block everything that comes in, then specifically allow ports that I want to be open.

As this is the first rule we’ve encountered, it might be good to explain the syntax. The FAQ also explains it in painstaking detail.

# Anything in the blacklist should be stopped here
block in quick on $ext_if from to any
block in quick on $ext_if from to any
block in quick on $ext_if from to any
block in quick on $ext_if from to any

This is where our blacklists are configured. The quick keyword tells pf to stop processing the rules that follow if the packet matches. I don’t log these blocks. We’ve expanded the syntax here, so another breakdown might be good.

# Outgoing traffic
pass out on $ext_if proto { tcp, udp } from $ext_ip to any keep state

This is our first pass rule, and an important one at that. It allows all outgoing traffic on the external interface.

# Allow ICMP traffic
pass proto icmp all

Allow all ICMP traffic. Some people who are extremely security conscious may block all ICMP traffic, but I find it invaluable for monitoring and troubleshooting. You’re left to yourself to decide how pedantic you want to get with ICMP filtering.

Filtering for Specific Services

Here is where things get interesting. We now go in and allow specific services (ports) through the firewall.

# NTP
pass out on $ext_if proto { tcp, udp } from $ext_ip to any port ntp keep state

This will allow NTP traffic out from our local server to any NTP server on port 123 (NTP).

But wait, if I’ve already passed all outgoing traffic, what is this rule for? Simple: statistics. The loginterface we specified above does more than just do general statistics for the interface, it does it for every rule on that interface. That means by adding a more specific pass rule, even if the packet was already passed, we can get statistics on how many packets out and bytes out for this rule. I do this for all services I host so I can get detailed stats on how much bandwidth each is consuming. There will be a follow up post that goes into detail on the stats I consume and where I get them from.

# Allow web
pass in on $ext_if proto tcp from any to $ext_ip port { 80, 443 } keep state
pass out on $ext_if proto tcp from $ext_ip to any port { 80, 443 } keep state

These two rules allow incoming (and the corresponding outgoing) packets to our local web server on ports 80 (HTTP) and 443 (HTTPS).

# Allow mail
pass in on $ext_if proto tcp from any to $ext_ip port { 25, 143, 993, 995 } keep state
pass out on $ext_if proto tcp from $ext_ip to any port { 25, 143, 993, 995 } keep state

These two rules allow incoming and outgoing packets to our postfix and dovecot setup on ports 25 (SMTP), 143 (IMAP), 993 (IMAPS) and 995 (POP3S).

# Allow DNS
pass in on $ext_if proto { tcp, udp } from any to $ext_ip port 53 keep state
pass out on $ext_if proto { tcp, udp } from $ext_ip to any port 53 keep state

These two rules allow DNS traffic to our server on port 53 (DNS).

# Allow SSH
pass in on $ext_if proto tcp from any to $ext_ip port 22 flags S/SA keep state (max-src-conn-rate 5/60, overload flush global)
pass out on $ext_if proto tcp from $ext_ip to any port 22 keep state

And the fun one. These rules allow traffic to our SSH server on port 22 (SSH). The bit at the end is quite powerful, it is an extra you can do for your stateful connections and rate limiting, or blacklisting in my case.

When another server connects more than 5 times in 60 seconds (max-src-conn-rate 5/60), add the IP address to the table <ssh_bruteforce> (overload <ssh_bruteforce>) and kills any matching states for that IP (flush global). When coupled with the block quick from <ssh_bruteforce> rule above it means that any attacker that tries to brute force my SSH server gets five shots at it before they’re blacklisted.

It also means that if I connect more than 5 times in a minute that I’ll get blacklisted, but that hasn’t happen to me yet.

Enabling pf and Testing the Configuration

Now that our ruleset has been created (the ruleset goes into /etc/pf.conf, by the way), we can enable pf and get started with our testing.

To enable pf, just add the following to your /etc/rc.conf.

pf_enable="YES"
pflog_enable="YES"

pflog is the logging setup, if you don’t want to worry about logging then you don’t have to enable it.

Now the first thing you want to do before starting pf though is to check your rules. Run the following to parse your ruleset, but not load it.

[root@shana /]$ pfctl -nf /etc/pf.conf
# /etc/pf.conf:13: cannot load "/etc/pf.china": No such file or directory
# /etc/pf.conf:14: cannot load "/etc/pf.korea": No such file or directory
# /etc/pf.conf:16: cannot load "/etc/pf.blacklist": No such file or directory

Right, I need to populate those files first!

[root@shana /]$ scp xxx@172.16.0.13:/Volumes/Drobo/Backup/itransit/tyrande/etc/pf.{china,korea,blacklist} /etc/
# pf.china                                     100%    0     0.0KB/s   00:00    
# pf.korea                                     100%    0     0.0KB/s   00:00    
# pf.blacklist                                 100%    0     0.0KB/s   00:00

A straight copy from the backups of Tyrande will do it. As mentioned, those files are just text files with an IP address or subnet on each line. Let’s try that parsing again now.

[root@shana /]$ pfctl -nf /etc/pf.conf

[root@shana /]$

No errors? Great! Now the fun bit. To start pf and hope that you haven’t just locked yourself out, run:

[root@shana /]# /etc/rc.d/pf start
# Enabling pf
# No ALTQ support in kernel
# ALTQ related functions disabled
# No ALTQ support in kernel
# ALTQ related functions disabled
# Write failed: Broken pipe

[bok@Macbook ~]$

Oh no. Looks like I just locked myself out! Even I’m not immune to this sort of trap either. The server is pingable, so it looks like the ICMP rule was correct. Better go plug in that console…

So you’ve locked yourself out

Right, now that I’ve connected a monitor and keyboard, lets see what the console says. There are a few commands here that you will find useful. For starters, you can list the loaded ruleset:

[root@shana /]$ pfctl -s rules
# No ALTQ support in kernel
# ALTQ related functions disabled
# scrub in all fragment reassemble
# block return log all
# <snip>
# pass in on bge0 proto udp from any to (bge0) port = domain keep state

By the way, you can ignore the ALTQ warnings unless you’re looking for queuing and prioritisation support.

You can scan that to see what you did wrong, or you can check the logs. If you’ve enabled pflog support, then it will have created a psuedo-interface called pflog0. You can then use tcpdump to watch that interface, and pf will log all packets matched with a log keyword there.

The following tcpdump command line will show you what packets are being dropped, I’m not going to go into detail on it though as that is beyond the scope of this article. The last bit is useful though; I’ve lost SSH access on port 22 to the server. At the end of the tcpdump statement you usually put a filter; this is useful if you’re on a local network with Windows boxes that will be spouting crap all across your filters. All of which will be being logged now.

It is generally a good idea to be narrow in your troubleshooting if you can afford to be, it helps you be more specific and get to the bottom faster than wading through thousands of lines of the log. Anyway, lets go:

[root@shana /]$ tcpdump -A -e -ttt -i pflog0 port 22
# tcpdump: WARNING: pflog0: no IPv4 address assigned
# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
# listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes

Now that we’re listening for logged packets, let’s try connecting again via SSH and see what comes up.

00:00:00.000000 rule 0..16777216/0(match): block in on bce0: 172.16.0.127.52101 > 172.16.0.4.ssh: Flags [S], seq 2892016496, win 65535, options [mss 1460,nop,wscale 3,nop,nop,TS val 854162648 ecr 0,sackOK,eol], length 0

A matched packet! This tells you that a packet from 172.16.0.127 (my Macbook) bound for 172.16.0.4 (Shana) on port 22 was blocked using the rule block in on bce0.

Wait, bce0? Uh oh. Looks like the network driver in this server is different from my old server, hence it appears to have a different network interface name.

[root@shana /]$ ifconfig | grep flags
# bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
# bce1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
# lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
# pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33152

Yep, looks like I have bce0 and bce1 instead of bge0 and bge1 on this server. That should be a simple fix, open the /etc/pf.conf and update the ext_if Macro to use bce0 instead.

We can then reload the ruleset and try connecting again.

[root@shana /]$ pfctl -f /etc/pf.conf
# No ALTQ support in kernel
# ALTQ related functions disabled

Success! I can SSH back in, and telnets to the other ports work as expected.

Update: Lets lock down SSH further (05/09/2012)

So in the last few days the number of brute force connections against Shana have skyrocketed. Previously there would be 3-4 cracks at it a day (remembering that each remote host is blacklisted after 5 connection attempts), but now there are dozens and each attempt is trying password authentication at least three times per connection (the limit).

Why they didn’t do that previously I’m not sure, but here we are.

I discovered too that my blacklists for /etc/pf.china and /etc/pf.korea were empty. I found a website with a good database for it too over here. In the right hand column pick your country, make sure CIDR format selected and copy/paste the resulting subnet list into your file.

Anyway, China and Korea aren’t the only countries with a high percentage of malware infected machines, they can come from anywhere and your server can’t be cut off from the entire world; that would defect the purpose. What we can do though is lock down SSH to our country of origin only. I’m 99% sure I’ll never need to SSH into Shana from outside of Australia, and if I did there are other hosts I can connect through anyway.

Create the Australian table

So lets create /etc/pf.australia with the Australian IP database. Then we can add a table for australia in our /etc/pf.conf up the top in the Tables section, like so:

table <australia> persist file '/etc/pf.australia'

It’s a good idea to test several of the IP Addresses (like your home connection, work, etc) against your new table before we activate it, to make sure you won’t be locked out. To do that you can use pfctl.

# Reload the configuration file to activate our new table
[root@shana /]$ pfctl -f /etc/pf.conf

# Test an IP against the table
[root@shana /]$ pfctl -t australia -T test 202.62.159.130
# 1/1 addresses match.

It’s a match! We can move on.

Restrict SSH access to that table

Now we can update the SSH rule to lock it down to the <australia> table:

# Allow SSH
pass in on $ext_if proto tcp from <australia> to $ext_ip port 22 flags S/SA keep state (max-src-conn-rate 5/60, overload <ssh_bruteforce> flush global)
pass out on $ext_if proto tcp from $ext_ip to <australia> port 22 keep state

So here we change the from any to $ext_ip to be from <australia> to $ext_ip. Similarly with the pass out but reversed.

Restart pf and hope you don’t get locked out and we’re done. Those pesky security emails should be quieter now.

In this post I’ll go through setting up Bind and configuring a test domain. If you’re not sure what DNS is or how it works, hit up Google and find out. This article by How Stuff Works isn’t too bad an overview either.

For my DNS setup, I run Bind as the master server, and have an account with EasyDNS for additional DNS servers that synchronise changes from the master server to their copy. This is more commonly known as a Secondary DNS.

Picture time! (I like pictures).

Overview of my DNS Setup

What happens when a DNS request comes in (say you want to load this blog), is that your ISP’s DNS servers will lookup the name servers for my domain, which would return one of the four options above. At that point your ISP’s DNS server will pick one at random and ask it for the IP address of my blog (known as an A record). Your computer can then connect directly to the server and open the blog.

Each of the EasyDNS servers listed above is actually an anycast constellation, which means it has four or five DNS servers spread across the globe. For example, at the time of writing, the EasyDNS 1 constellation had servers in Ashburn, Chicago, San Jose, Amsterdam and Tokyo.

The EasyDNS servers stay in sync through a method called a zone transfer. When I update the records on Shana, she will send a message to the EasyDNS transfer server that there is an update available for a specific domain. EasyDNS then requests a zone transfer to grab the most recent copy of the DNS records for that domain and updates their local server records.

Installing Bind

That’s probably enough of an overview of my setup for now, lets get cracking on installing and configuring Bind. Fortunately, we don’t have to do anything here, Bind is already installed by default on FreeBSD.

[root@shana /]$ named -V
# BIND 9.8.1-P1 built with '--prefix=/usr' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' '--enable-getifaddrs' '--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' '--without-libxml2'
# using OpenSSL version: OpenSSL 0.9.8q 2 Dec 2010

It is worth noting here that the service/daemon that runs is actually called named. From here on out I’ll refer to everything using named as the product name “Bind” is rarely mentioned.

Configuring Named

As it is already installed, you can imagine that a good chunk of the setup is already done for you too. This is true, all of the named configuration files can be found in /etc/namedb/. Lets check what we have in there.

[root@shana /etc/namedb]$ ls -F -1
# dynamic/
# master/
# named.conf
# named.root
# slave/
# working/

You might notice too that the dynamic, slave and working directories are owned and writable by the bind user. That is because named will write to these directories itself.

For this post, we’re only really interested in the named.conf file and the master subdirectory.

General Configuration

There are a few general setup items we need to change, these all exist inside the options directive.

Firstly, turn recursion off for an authoritative server. We don’t need to be serving requests from users for domains that we are not authoritative for. While it is unlikely someone will try to use us for recursive DNS, it is still a waste of CPU cycles and network if they do.

recursion no;

Secondly, if we’re serving domains we need to listen on the external IP address, otherwise no one can reach us.

listen-on { 127.0.0.1;; };

Adding a Zone

Time to add our test zone! We’ll go ahead and setup a fake somedomain.com for testing named.

Creating the Zone in named.conf

Add the following to the bottom of your /etc/namedb/named.conf file.

// somedomain.com - A Test domain
zone "somedomain.com" {
type master;
file "/etc/namedb/master/somedomain.com";
zone-statistics true;

allow-transfer { ww.xx.yy.zz; };
also-notify { ww.xx.yy.zz; };
};

Please be very specific about the placement of your semicolons (;), otherwise it will fail. In more detail:

zone "somedomain.com" {

This line starts a zone record, with the domain name of the zone. In this case it is somedomain.com.

type master;

The type of zone, we want to be authoritative and returns results for this zone, so we’re the master.

file "/etc/namedb/master/somedomain.com";

This line tells named where to find the file that contains the DNS records for that zone.

zone-statistics true;

I enable zone statistics on my zones for reporting and dashboards. With a simple script I can see how many requests are being served for this domain, etc. More detail on how to do this will follow in a later post.

allow-transfer { ww.xx.yy.zz; };

By default, zone transfers are not allowed for any domain. This is for security reasons mostly as there is no need to let clients know all of the records you have. They might find your porn server, for instance. This line will allow specific IP Addresses to request a zone transfer for this domain.

also-notify { ww.xx.yy.zz; };

To take it the step further, this line will cause named to notify the IP address(es) listed whenever the serial number on this zone is updated.

For a better overview of how your named.conf file works and the configuration options available, check out this guide from CentOS.

Creating the Zone File

I generally name the files in my master/ subdirectory the same as the domain name themselves. Lets create our somedomain.com file and we’ll step through what it means.

;
; somedomain.com Zone File
;
; Created: 6 July 2012
; By: Rob Amos
;
$ORIGIN somedomain.com.
$TTL 6h

@ IN SOA shana.somedomain.com. postmaster.somedomain.com (
2012070601 ; serial number
1h ; refresh time
30m ; retry values
7d ; record cache expiry
1h ; minimum time to cache
)

; Name Servers
NS shana.somedomain.com.

; Mail Servers
MX 5 shana.somedomain.com.

; SPF Record
TXT "v=spf1 mx:somedomain.com ~sll"

; Subdomains
A 172.16.0.4
shana A 172.16.0.4
www CNAME shana.somedomain.com.

And in some more detail:

$ORIGIN somedomain.com.

The $ORIGIN record is the domain that would be appended to any unqualified records. Meaning that if you wrote subdomain instead of subdomain.somedomain.com, then the somedomain.com would be appended automatically.

$TTL 6h

Our $TTL (Time to Live) value tells servers how long these records should remain valid for.

@ IN SOA shana.somedomain.com. postmaster.somedomain.com (
2012070601 ; serial number
1h ; refresh time
30m ; retry values
7d ; record cache expiry
1h ; minimum time to cache
)

This is our Start of Authority record, more commonly known as the SOA. This provides information about the authoritative server and zone information for this domain. Read this guide for more info, but I will suggest you set the serial number to today’s date plus a two digit counter that you increment the more times you change it during that day.

The serial number is especially important when you’ve got slave or secondary name servers. They use the serial number to know whether they need to update your domain, so make sure you increment the serial number every time you make a change.

NS shana.somedomain.com.

A name server record, there should be one of these for each of your servers, the order doesn’t matter.

MX 5 shana.somedomain.com.

A Mail Exchange (MX) record. This tells email clients where to find your mail server. The number indicates the priority of the server record with the lowest number having the highest priority. Note the trailing dot (.), it is very important. If you do not put that there named will append $ORIGIN to the listed name.

TXT "v=spf1 mx:somedomain.com ~all"

An SPF record. This one says that only the MX record for subdomain.com is allowed to send email for somedomain.com. Microsoft has a handy tool to generate SPF records.

A 172.16.0.4
shana A 172.16.0.4

Address (A) records. This maps a subdomain to an IP address. It is useful to note that column left blank will use the record before it. So we left the first column blank for all records until shana. That means it used the last one listed, which was the @ symbol. The @ refers to the domain itself, not a subdomain.

Likewise the second column (IN) is missing, its reused from above. So you could rewrite that second like this if you wanted.

@ IN NS shana.somedomain.com.
@ IN MX 5 shana.somedomain.com.
@ IN TXT "v=spf1 mx:somedomain.com ~all"
@ IN A 172.16.0.4
shana IN A 172.16.0.4

One last one – a CNAME or alias record. Note the trailing dot again. This one will make www.somedomain.com an alias of shana.somedomain.com.

www CNAME shana.somedomain.com.

Once again, the CentOS guide has a good step by step and breakdown with more information on the Zone Files beyond my examples.

Testing our Setup

That’s effectively everything you need to setup. Enable named in your /etc/named.conf file and lets test it out.

named_enable="YES"

Starting named:

[root@shana /]$ /etc/rc.d/named start
# wrote key file "/var/named/etc/namedb/rndc.key"
# Starting named.

Check the logs to see if it was ok:

[root@ /]$ tail /var/log/messages
# Jul  9 20:29:41 shana named[15165]: starting BIND 9.8.1-P1 -t /var/named -u bind
# Jul  9 20:29:41 shana named[15165]: built with '--prefix=/usr' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' '--enable-getifaddrs' '--disable-linux-caps' '--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' '--without-libxml2'
# Jul  9 20:29:41 shana named[15165]: command channel listening on 127.0.0.1#953
# Jul  9 20:29:41 shana named[15165]: command channel listening on ::1#953
# Jul  9 20:29:41 shana named[15165]: managed-keys-zone ./IN: loading from master file managed-keys.bind failed: file not found
# Jul  9 20:29:41 shana named[15165]: running

And testing our resolution:

[root@shana /]$ host somedomain.com 127.0.0.1
# Using domain server:
# Name: 127.0.0.1
# Address: 127.0.0.1#53
# Aliases: 
# 
# somedomain.com has address 172.16.0.4
# somedomain.com mail is handled by 5 shana.somedomain.com.

[root@shana /]$ host -t NS somedomain.com 127.0.0.1
# Using domain server:
# Name: 127.0.0.1
# Address: 127.0.0.1#53
# Aliases: 
# 
# somedomain.com name server shana.somedomain.com.

[root@shana /]$ host -t TXT somedomain.com 127.0.0.1
# Using domain server:
# Name: 127.0.0.1
# Address: 127.0.0.1#53
# Aliases: 
# 
# somedomain.com descriptive text "v=spf1 mx:somedomain.com ~sll"

[root@shana /]$ host www.somedomain.com 127.0.0.1
# Using domain server:
# Name: 127.0.0.1
# Address: 127.0.0.1#53
# Aliases: 
# 
# www.somedomain.com is an alias for shana.somedomain.com.
# shana.somedomain.com has address 172.16.0.4

All done! A simple post this time.

Weight Loss to Date

Yes there has! Though I was stuck on a plateau for a while there, it has kicked up again recently.

So what happened? I don’t think too much has actually happened different. It generally helps though to remain patient, and not indulge too much. I mean your Yoghurt might be fat free, but it still contains some carbohydrates, which are more easily converted to energy than protein.

I’ve tried a whole bunch of recipes since last time, all of which come from My Dukan Diet, or Slim Kicker.

I can add a helpful tip or two though, regarding take away.

Take Away – It is still possible

There are a couple of take away food franchises that are still compatible with the Protein and Vegetable phases of your Dukan Diet: Subway, and Sumo Salad. They are compatible because you can pick and choose your ingredients so you know you are getting diet-compatible foods.

Going to subway though doesn’t mean getting a sub. You still can’t have any bread, but you can order a salad for $1.50 more. Get the Chicken Strips (or Chicken Pieces, whatever they call it) or Steak, or Ham or whatever meat you feel like (you know by now what meats you’re allowed to have). No cheese, add in the available salads and a bit of pepper if you like that.

No dressings though! They will kill the whole thing. Your best bet is to bring your own dressing so you know what is in it. You can make a pretty good honey mustard dressing with your Non-fat Yoghurt, Dijon Mustard and a bit of artificial sweetener to taste.

Sumo Salad is the same, but a bit more expensive. You can order a build your own salad, pick items from the list that you know are acceptable and go from there. They do have a Lemon Juice dressing at Sumo Salad which may be acceptable. But I prefer the dressings I make myself anyway.

Carrying on with the diet, only 11.5kgs to go!

This post will be remarkably short compared to the first one. A bit of a refresher on the setup I’m aiming for:

We’re looking at the red arrows in this one, so Dovecot, as well as setting up the Virtual Mailboxes and Sieve support. Because we’re using dovecot-lda to handle delivery of mail into the actual “mailbox” on the file system we need to have completed configuring Dovecot before our setup of Postfix from Part One will be functional.

Installation of Dovecot

Dovecot itself was installed as a dependency of Postfix back in Part One. That was because we selected Dovecot2 SASL Auth option. If you want to install Dovecot manually head on over to ports and run through the usual process, selecting the following options on the config screen:

• KQUEUE (default)
• SSL (default)
• PGSQL

[root@shana /]$ cd /usr/ports/mail/postfix
[root@shana /usr/ports/mail/postfix]$ make install clean

Under Dovecot2 the Sieve plugin support is provided by Pigeonhole, which can be easily installed via ports:

[root@shana /]$ cd /usr/ports/mail/dovecot2-pigeonhole
[root@shana /usr/ports/mail/dovecot2-pigeonhole]$ make install clean

Configuration

Lets separate our configuration into several bits to make it a bit easier to follow.

Virtual Mailboxes, Databases and Delivery

We need to start with the delivery of mail into the virtual mailboxes, so that we can finally test the Postfix setup and delivery of mail into the mailboxes.

From Post One, we setup dovecot-lda using the following line in /usr/local/etc/postfix/master.cf.

dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${recipient}

So it calls /usr/local/libexec/dovecot/deliver with the sender’s email address passed in via the -f option, and the recipient’s email via -d. We’re also running it with a user called vmail. Lets setup the user and group first.

[root@shana /]$ adduser
# Username: vmail
# Full name: Virtual Mailbox User
# Uid (Leave empty for default): 145
# Login group [vmail]:
# Login group is vmail. Invite vmail into other groups? []:
# Login class [default]:
# Shell (sh csh tcsh bash rbash nologin) [sh]: nologin
# Home directory [/home/vmail]: /var/vmail
# Home directory permissions (Leave empty for default):
# Use password-based authentication? [yes]: no
# Lock out the account after creation? [no]: yes
# Username : vmail
# Password :
# Full Name : Virtual Mailbox User
# Uid : 145
# Class :
# Groups : vmail
# Home : /var/vmail
# Home Mode :
# Shell : /usr/sbin/nologin
# Locked : yes
# OK? (yes/no): yes
# adduser: INFO: Successfully added (vmail) to the user database.
# adduser: INFO: Account (vmail) is locked.
# Add another user? (yes/no): no
# Goodbye!

Now that that is done, clear out all of the skeleton files that were copied into /var/vmail and we can update the config file for LDA.

[root@shana /var/vmail]$ rm .*

Almost all of Dovecot’s configuration can be found in /usr/local/etc/dovecot/, including the LDA settings that we’re after now. If that directory is empty for you then the README file should tell you where to find the example ones, copy the example files we need into the target directory.

[root@shana /usr/local/etc/dovecot]$ cp /usr/local/share/doc/dovecot/example-config/dovecot.conf .

[root@shana /usr/local/etc/dovecot]$ mkdir conf.d

[root@shana /usr/local/etc/dovecot]$ cp /usr/local/share/doc/dovecot/example-config/conf.d/* conf.d/

There are some things we need to setup in order to get the LDA working, including Sieve, the Passdb, Userdb and authentication. Lets go in that order.

To enable sieve, edit /usr/local/etc/dovecot/conf.d/15-lda.conf and set mail_plugins to sieve.

protocol lda {
# Space separated list of plugins to load (default is global mail_plugins).
mail_plugins = sieve
}

Because we’re delivering mail as vmail, you may need to adjust the first_valid_uid and first_valid_gid settings in /usr/local/etc/dovecot/conf.d/10-mail.conf.

Set the value to whatever UID and GID your vmail user has, unless the ID is greater than 500, in which case the default is fine. Even better, set the last_valid_uid and last_valid_gid to your vmail UID and GID. That means only vmail can deliver mail, no other user.

first_valid_uid = 145
last_valid_uid = 145

first_valid_gid = 145
last_valid_gid = 145

To setup the authentication properly, open up /usr/local/etc/dovecot/conf.d/10-auth.conf, comment out the existing include for auth-system, and uncomment the auth-sql.conf.ext line, it should look like this:

#!include auth-system.conf.ext
!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext

Then we can edit /usr/local/etc/dovecot/conf.d/auth-sql.conf.ext to point to the correct SQL configuration file, this happens under passdb and userdb.

passdb {
driver = sql

# Path for SQL configuration file, see example-config/dovecot-sql.conf.ext
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
}

userdb {
driver = sql
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
}

Then we want to open up /usr/local/etc/dovecot/dovecot-sql.conf.ext and make it look like the following. I’ll step through it after the paste.

# This file is opened as root, so it should be owned by root and mode 0600.
#

# Database driver: mysql, pgsql, sqlite
driver = pgsql

# Database connection string. This is driver-specific setting.
connect = host=/tmp dbname=mail user=mail password=xxx

# Query to retrieve the password.
password_query = SELECT DISTINCT ON (mbox) mbox as user, password, '/var/vmail/' || mbox || '/home/' as home, 'maildir:/var/vmail/' || mbox || '/' as mail, 145 as uid, 145 as gid FROM COALESCE((SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE (mailboxes.mbox = '%u' AND mailboxes.disabled = false) OR (aliases.alias = '%u' AND mailboxes.disabled = false)), (SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE (aliases.alias = '@%d' AND mailboxes.disabled = false)), (SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE (aliases.alias = '%n@' AND mailboxes.disabled = false))) as mbox JOIN mailboxes USING (mbox);

# Query to retrieve the user information.
user_query = SELECT '/var/vmail/' || mbox || '/home/' as home, 'maildir:/var/vmail/' || mbox || '/' as mail, 145 as uid, 145 as gid FROM COALESCE((SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE mailboxes.mbox = '%u' OR aliases.alias = '%u'), (SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE aliases.alias = '@%d'), (SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE aliases.alias = '%n@')) as mbox;

• driver = pgsql - Tells Dovecot that we want to connect to a PostgreSQL server
• connect – The connection string. Set host to where your UNIX socket lives (usually /tmp), and dbname, user and password to the same credentials you used configuring Postfix in Post One. Alternatively, you can use different credentials, make sure you grant the appropriate permissions to the database.
• password_query – This is the query that Dovecot will execute to retrieve the hashed password from the database. It then compares it to the hash it creates of the password given to it by the mail client to see if they match.
• user_query – This query tells Dovecot where to find information on the users and mailboxes as configured.

These queries should look similar to the ones from Part One. Lets break them down a bit for better understanding.

SELECT
DISTINCT ON (mbox) mbox as user,
password,
'/var/vmail/' || mbox || '/home/' as home,
'maildir:/var/vmail/' || mbox || '/' as mail,
143 as uid,
143 as gid
FROM
COALESCE (
(SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE (mailboxes.mbox = '%u' AND mailboxes.disabled = false) OR (aliases.alias = '%u' AND mailboxes.disabled = false)),
(SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE (aliases.alias = '@%d' AND mailboxes.disabled = false)),
(SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE (aliases.alias = '%n@' AND mailboxes.disabled = false))
) as mbox
JOIN mailboxes USING (mbox);

So it executes three subqueries that are almost identical to the ones used by Postfix, except the substitutions are different this time around.

• %u = the full email address being looked up
• %d = only the domain (the bit after the @)
• %n = only the username (the bit before the @)

It returns a lot more information though from the coalesced queries, and it checks if the email address in question is an alias too. Whereas Postfix was only looking for validation before handing it to dovecot-lda, Dovecot needs to know where and how to deliver the message to. The columns returned are as follows.

Now that we have that out of the way, its time to test mail delivery! Oh, but we need a user account.

Creating User Accounts

There are two things you need to do to create a user account:

1. Add the user in the mailboxes table in the database.
2. Create the user’s mailbox on the filesystem.

To add the user, connect to your database using psql and run the following. Change <password> to the password you generated using doveadm pw -s ssha512.

INSERT INTO mailboxes (mbox, password) VALUES ('test@test.com', '{SSHA512}cZm4VMAkPzYdA+pRb0DpmQUyx9HT8JA8AmklE7V2TUK7L2Td+I3Z8P0phNO+i7fAwC82J9IC0rFQUcX2u2toFkJ+0IU=');

Then create the directory on the filesystem to match.

[root@shana /]$ mkdir /var/vmail/test@test.com

[root@shana /]$ chown vmail:vmail /var/vmail/test\@test.com/

Then we can test!

Testing the mail delivery

If you haven’t already, we’ll need to configure Dovecot to start, add this line to your /etc/rc.conf file.

dovecot_enable="YES"

Now lets start Postfix first.

[root@shana /]$ /usr/local/etc/rc.d/postfix start
postfix/postfix-script: starting the Postfix mail system

If everything went well there shouldn’t be any errors there, or any in /var/log/maillog.

Jul 5 22:49:05 shana postfix/postfix-script[86436]: starting the Postfix mail system
Jul 5 22:49:05 shana postfix/master[86437]: daemon started -- version 2.9.3, configuration /usr/local/etc/postfix

We don’t need to start Dovecot to test mail delivery as dovecot-lda is called automatically by Postfix. Lets connect and see what happens (the comments are server responses, the rest are commands I’m typing).

[bok@tyrande ~]$ telnet 124.168.107.116 25
# Trying 124.168.107.116...
# Connected to 124-168-107-116.dyn.iinet.net.au.
# Escape character is '^]'.
# 220 mail.odynia.org ESMTP Postfix
HELO tyrande.odynia.org
# 250 mail.odynia.org
MAIL FROM:
# 250 2.1.0 Ok
RCPT TO:
# 250 2.1.5 Ok
DATA
# 354 End data with .
test
.
# 250 2.0.0 Ok: queued as 26E051E3
QUIT
# 221 2.0.0 Bye
# Connection closed by foreign host.

Accepted! Lets see where that went by checking /var/log/maillog.

Jul 5 23:44:03 shana postfix/smtpd[87478]: connect from tyrande.odynia.org[202.62.159.130]
Jul 5 23:44:23 shana postfix/policy-spf[87495]: : SPF softfail (Mechanism '~all' matched): Envelope-from: test@test.com
Jul 5 23:44:23 shana postfix/policy-spf[87495]: handler sender_policy_framework: is decisive.
Jul 5 23:44:23 shana postfix/policy-spf[87495]: : Policy action=PREPEND Received-SPF: softfail (test.com: Sender is not authorized by default to use 'test@test.com' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=unknown; identity=mailfrom; envelope-from="test@test.com"; helo=tyrande.odynia.org; client-ip=202.62.159.130
Jul 5 23:44:23 shana postfix/smtpd[87478]: 26E051E3: client=tyrande.odynia.org[202.62.159.130]
Jul 5 23:44:29 shana postfix/cleanup[87497]: 26E051E3: message-id=<>
Jul 5 23:44:29 shana postfix/qmgr[87474]: 26E051E3: from=, size=519, nrcpt=1 (queue active)
Jul 5 23:44:29 shana dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: No such file or directory
Jul 5 23:44:29 shana dovecot: lda: Fatal: Internal error occurred. Refer to server log for more information.
Jul 5 23:44:29 shana postfix/pipe[87498]: 26E051E3: to=, relay=dovecot, delay=10, delays=9.9/0.01/0/0.04, dsn=4.3.0, status=deferred (temporary failure)
Jul 5 23:44:35 shana postfix/smtpd[87478]: disconnect from tyrande.odynia.org[202.62.159.130]

Hmm, a temporary lookup failure trying to use the wrong userdb. Lets see what we missed.

Oh!

So when you’re using the SQL userdb and passdb setup you do need to have Dovecot running so it creates the authentication sockets that dovecot-lda needs. Lets start it up now then.

[root@shana /]$ /usr/local/etc/rc.d/dovecot start
Starting dovecot.
doveconf: Fatal: Error in configuration file /usr/local/etc/dovecot/conf.d/10-ssl.conf line 12: ssl_cert: Can't open file /etc/ssl/certs/dovecot.pem: No such file or directory
/usr/local/etc/rc.d/dovecot: WARNING: failed to start dovecot

Uh oh! We missed a step in setting up Dovecot. We forgot to generate the SSL certificate that is configured by default in /usr/local/etc/dovecot/conf.d/10-ssl.conf. You have a few choices here.

• Go buy a certificate from a trusted vendor and copy your public and private key files (PEM files) into /etc/ssl/certs/dovecot.pem and /etc/ssl/private/dovecot.pem respectively. This is the recommended and most secure option.
• Generate a self-signed certificate using the instructions on the Dovecot Wiki. (Note that the files mentioned in doc/ are actually in /usr/local/share/examples/dovecot/ under FreeBSD).
• Disable SSL (not recommended at all)

Once you’ve done one of those we can start Dovecot again.

[root@shana /]$ /usr/local/etc/rc.d/dovecot start
Starting dovecot.

Better. Nothing in the logs?

Jul 6 00:08:01 shana dovecot: master: Dovecot v2.1.7 starting up

Right, lets try that delivery again, that previous message was still in the queue, so lets flush it.

[root@shana /]$ postqueue -f

So, was that successful?

Jul 6 00:05:54 shana postfix/qmgr[87474]: 26E051E3: from=, size=519, nrcpt=1 (queue active)
Jul 6 00:05:54 shana dovecot: auth: pgsql(/tmp): Connected to database mail
Jul 6 00:05:54 shana dovecot: lda(test@odynia.org): msgid=unspecified: saved mail to INBOX
Jul 6 00:05:54 shana postfix/pipe[87829]: 26E051E3: to=, relay=dovecot, delay=1295, delays=1295/0.01/0/0.1, dsn=2.0.0, status=sent (delivered via dovecot service)
Jul 6 00:05:54 shana postfix/qmgr[87474]: 26E051E3: removed

Yay! It was delivered to the folder, lets check the contents.

[root@shana /]$ cat /var/vmail/test\@odynia.org/new/1341497154.M243352P87831.shana.itransit.com.au\,S\=571\,W\=579
# Return-Path:
# Delivered-To: test@odynia.org
# Received-SPF: softfail (test.com: Sender is not authorized by default to use 'test@test.com' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=unknown; identity=mailfrom; envelope-from="test@test.com"; helo=tyrande.odynia.org; client-ip=202.62.159.130
# Received: from tyrande.odynia.org (tyrande.odynia.org [202.62.159.130])
# by mail.odynia.org (Postfix) with SMTP id 26E051E3
# for ; Thu, 5 Jul 2012 23:44:19 +1000 (EST)
#
# test

One complete message, and the softfail there shows SPF is working correctly also (test.com’s SPF record is set to softfail).

Configuring IMAP and POP3

All that is left now is configuring IMAP and POP3 access, including accessing both via SSL.

But wait! It is already working. You can configure your favourite mail client to connect via POP3 or IMAP and it will already be configured and working. There is nothing additional you need to do.

Jul 6 00:15:50 shana dovecot: imap-login: Login: user=, method=PLAIN, rip=172.16.0.127, lip=172.16.0.4, mpid=87945, TLS, session=
Jul 6 00:15:50 shana dovecot: imap(test@odynia.org): Connection closed in=17 out=352

I configured Mail on my Macbook to connect as test@odynia.org, and its already coming in over SSL for IMAP too. But what about sieve?

Configuring and Testing Sieve

Lets try a simple test, create a Folder in your Mail client and we’ll create a sieve file to redirect matching mail to that folder.

We’ll need to create the home folder inside the mailbox, like so:

[root@shana /]$ mkdir /var/vmail/test\@odynia.org/home
[root@shana /]$ chown vmail:vmail /var/vmail/test\@odynia.org/home

Then we can create a .dovecot.sieve file in there. So in this example it is /var/vmail/test@odynia.org/home/.dovecot.sieve. Make sure it is owned by vmail:vmail also.

require ["fileinto"];
if anyof (header :contains "Subject" "[test]")
{
fileinto "Test Folder";
stop;
}

So if we send an email again with a subject that includes “[test]” it should get redirected automatically to that folder.

[bok@tyrande ~]$ telnet 124.168.107.116 25
# Trying 124.168.107.116...
# Connected to 124-168-107-116.dyn.iinet.net.au.
# Escape character is '^]'.
# 220 mail.odynia.org ESMTP Postfix
HELO tyrande.odynia.org
# 250 mail.odynia.org
MAIL FROM:
# 250 2.1.0 Ok
RCPT TO:
# 250 2.1.5 Ok
DATA
# 354 End data with .
From: Me
To: You
Subject: [test] This is a test

Do you like my test?
.
# 250 2.0.0 Ok: queued as E3F212D0
QUIT
# 221 2.0.0 Bye
# Connection closed by foreign host.

Lets check the logs.

Jul 6 00:26:50 shana postfix/smtpd[87988]: connect from tyrande.odynia.org[202.62.159.130]
Jul 6 00:27:01 shana postfix/policy-spf[87994]: : SPF softfail (Mechanism '~all' matched): Envelope-from: test@test.com
Jul 6 00:27:01 shana postfix/policy-spf[87994]: handler sender_policy_framework: is decisive.
Jul 6 00:27:01 shana postfix/policy-spf[87994]: : Policy action=PREPEND Received-SPF: softfail (test.com: Sender is not authorized by default to use 'test@test.com' in 'mfrom' identity, however domain is not currently prepared for false failures (mechanism '~all' matched)) receiver=unknown; identity=mailfrom; envelope-from="test@test.com"; helo=tyrande.odynia.org; client-ip=202.62.159.130
Jul 6 00:27:01 shana postfix/smtpd[87988]: E3F212D0: client=tyrande.odynia.org[202.62.159.130]
Jul 6 00:27:17 shana postfix/cleanup[87996]: E3F212D0: message-id=<>
Jul 6 00:27:17 shana postfix/qmgr[87474]: E3F212D0: from=, size=586, nrcpt=1 (queue active)
Jul 6 00:27:17 shana dovecot: lda(test@odynia.org): sieve: msgid=unspecified: stored mail into mailbox 'Test Folder'
Jul 6 00:27:17 shana postfix/pipe[88010]: E3F212D0: to=, relay=dovecot, delay=19, delays=19/0.01/0/0.04, dsn=2.0.0, status=sent (delivered via dovecot service)
Jul 6 00:27:17 shana postfix/qmgr[87474]: E3F212D0: removed
Jul 6 00:27:19 shana postfix/smtpd[87988]: disconnect from tyrande.odynia.org[202.62.159.130]

Yep. Sieve also requires no additional setup.

I sure do like your test.

ManageSieve

Now, because of the length of this post I’m going to leave setting up ManageSieve to another day. I only use it for one service anyway, which is RoundCube webmail, so we’ll setup ManageSieve when we do RoundCube.

That’s it for another day. I hope this has been helpful.

I’ve split this post into two so as not to write a novel. In this one I will run through installing and configuring Postfix to my liking, as well as hooking it up to PostgreSQL. In the second post I’ll cover setting Dovecot up in the same way for IMAP/POP3.

WARNING: Despite the split, this is still a very long post. You may need a cup of coffee.

Overview

But first, an overview of my setup, for which a picture tells many words.

This is highly simplified as there are a few extra services in there, such as ManageSieve. In a nutshell though; incoming mail is filtered first through SPF and a few other spam checks. Then the To: address is looked up in the database, in both the mailbox and alias tables, and the delivery mailbox address returned to Postfix. Postfix then delivers that mail into the correct directory. I’ll handle the rest of that picture in Post Two.

Aliasing

The aliasing system I use is slightly complex, but highly worthwhile. It allows me to use a couple of wildcard patterns to direct mail to a specific mailbox.

• Direct matching: An email address is matched in full.
• *@domain.com: A catch-all for a specific domain.
• user@*: A specific user across all domains (useful for postmaster@)

This can be easily expanded upon by adjusting the SQL query as the need arises.

Resources

Before we get too far in it is a good idea to list some of the resources that I used to learn all of this in the first place.

• Using the Dovecot LDA with Postfix on the Dovecot Wiki

I’ll add to this list when I do Part Two, as it has been so long since I set this up the first time, and a lot of it I just remember.

Installing

I installed PostgreSQL back in this post, so I won’t cover that again here. You can swap out PostgreSQL for MySQL if you desire, just change the options when we install Postfix.

Installing Postfix is very straightforward, just install the port. We want the following options.

• PCRE (selected by default)
• SASL2
• DOVECOT2
• TLS
• PGSQL

For dependencies PCRE and SASL2, leave the default options selected. It will then prompt you to install Dovecot (as required by the Dovecot2 option above). Use the following options for Dovecot (covered in more detail in the next post).

• KQUEUE (default)
• SSL (default)
• PGSQL

When asked if you want to activate Postfix in /etc/mail/mailer.conf, you say yes!

[root@shana /]$ cd /usr/ports/mail/postfix

[root@shana /usr/ports/mail/postfix]$ make install clean
# ===> Found saved configuration for postfix-2.9.3,1
# => postfix-2.9.3.tar.gz doesn't seem to exist in /usr/ports/distfiles/postfix.
# => Attempting to fetch ftp://ftp.porcupine.org/mirrors/postfix-release/official/postfix-2.9.3.tar.gz
# postfix-2.9.3.tar.gz 100% of 3672 kB 43 kBps 00m00s
# ===> Extracting for postfix-2.9.3,1
# ===> Found saved configuration for postfix-2.9.3,1
# => SHA256 Checksum OK for postfix/postfix-2.9.3.tar.gz.
# ===> postfix-2.9.3,1 depends on file: /usr/local/bin/perl5.12.4 - found
# ===> Patching for postfix-2.9.3,1
# ===> postfix-2.9.3,1 depends on file: /usr/local/bin/perl5.12.4 - found
# ===> Applying FreeBSD patches for postfix-2.9.3,1
# ===> postfix-2.9.3,1 depends on file: /usr/local/bin/perl5.12.4 - found
# ===> postfix-2.9.3,1 depends on shared library: pcre - not found
# ===> Verifying install for pcre in /usr/ports/devel/pcre
#
# ===> Registering installation for pcre-8.30_2
# ===> Returning to build of postfix-2.9.3,1
# ===> postfix-2.9.3,1 depends on shared library: sasl2.2 - not found
# ===> Verifying install for sasl2.2 in /usr/ports/security/cyrus-sasl2
#
# ===> Registering installation for cyrus-sasl-2.1.25_2
# ===> Returning to build of postfix-2.9.3,1
# ===> postfix-2.9.3,1 depends on shared library: pq.5 - found
# ===> Configuring for postfix-2.9.3,1
#
# ===> Installing rc.d startup script(s)
# Would you like to activate Postfix in /etc/mail/mailer.conf [n]? y
# # Fix compressed man pages
# To enable postfix startup script please add postfix_enable="YES" in
# your rc.conf
#
# If you not need sendmail anymore, please add in your rc.conf:
#
# sendmail_enable="NO"
# sendmail_submit_enable="NO"
# sendmail_outbound_enable="NO"
# sendmail_msp_queue_enable="NO"
#
# And you can disable some sendmail specific daily maintenance routines in your
# /etc/periodic.conf file:
#
# daily_clean_hoststat_enable="NO"
# daily_status_mail_rejects_enable="NO"
# daily_status_include_submit_mailq="NO"
# daily_submit_queuerun="NO"
#
# If /etc/periodic.conf does not exist please create it and add those values.
#
# If you are using SASL, you need to make sure that postfix has access to read
# the sasldb file. This is accomplished by adding postfix to group mail and
# making the /usr/local/etc/sasldb* file(s) readable by group mail (this should
# be the default for new installs).
#
# If you are upgrading from Postfix 2.6 or earlier, review the RELEASE_NOTES to
# familiarize yourself with new features and incompatabilities.
# ===> Correct pkg-plist sequence to create group(s) and user(s)
# ===> Compressing manual pages for postfix-2.9.3,1
# ===> Registering installation for postfix-2.9.3,1
# ===> SECURITY REPORT:
#
# ===> Cleaning for pcre-8.30_2
# ===> Cleaning for cyrus-sasl-2.1.25_2
# ===> Cleaning for dovecot-2.1.7
# ===> Cleaning for postfix-2.9.3,1

The hints and tips in the message at the end of the port install are useful, you should read them. Some of which I’ll repeat shortly.

Once that is done we should install postfix-policyd-spf, which handles the SPF lookups. I use the Perl client found in ports.

[root@shana /]$ cd /usr/ports/mail/postfix-policyd-spf-perl

[root@shana /usr/ports/mail/postfix-policyd-spf-perl]$ make install clean
# => postfix-policyd-spf-perl-2.007.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
# => Attempting to fetch http://www.openspf.org/blobs/postfix-policyd-spf-perl-2.007.tar.gz
# postfix-policyd-spf-perl-2.007.tar.gz 100% of 13 kB 17 kBps
# ===> Extracting for postfix-policyd-spf-perl-2.007
#
# ===> Checking if mail/postfix-policyd-spf-perl already installed
# The service is not enabled by default. Enable it by doing the following:
#
# 1. Add the following to /etc/postfix/master.cf:
#
# spf-policy unix - n n - 0 spawn
# user=nobody argv=/usr/local/sbin/postfix-policyd-spf-perl
#
# The user nobody is fine if you have no other daemons running as nobody.
# Otherwise, you should use a dedicated user and group for this policy
# service.
#
# 2. Add "spf-policy_time_limit = 3600" to main.cf.
#
# 3. Configure the Postfix policy service in /usr/local/etc/postfix/main.cf:
#
# smtpd_recipient_restrictions =
# ...
# reject_unauth_destination
# ...
# check_policy_service unix:private/spf-policy
# ...
#
# NOTE: Specify check_policy_service AFTER reject_unauth_destination or your
# system may become an open relay.
#
# 4. Restart Postfix.
# ===> Registering installation for postfix-policyd-spf-perl-2.007

Configuration

Enabling Postfix / Disabling Sendmail

To enable Postfix, add the following to your /etc/rc.conf file. It won’t start though until we tell it to, or you reboot your box.

postfix_enable="YES"

We should disable all of the sendmail stuff too that it tells us in /etc/rc.conf as we won’t need it anymore.

sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

And remove the sendmail maintenance routines from /etc/periodic.conf (create it if it doesn’t exist).

daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"

General Postfix Configuration

We want to change some general settings now for Postfix, particularly those that tell it server names, IP Addresses, ports and which domains to receive for. We’ll step through these.

Note: every setting that is not mentioned should be left with its default values.

Start by turning on soft_bounce, you don’t want to lose any email while we’re checking.

soft_bounce = yes

Set myhostname to what you want your server to appear as in mail logs. I prefer that my server splash her name every where, so as far as other email servers are concerned she is mail.odynia.org.

myhostname = mail.odynia.org

You can leave the mydomain one alone, the default is based on your myhostname. In my case the default mydomain would be odynia.org.

The myorigin option is the domain that is used for outgoing emails from locally posted emails, such as bounce messages and emails from root, etc. The default is to use myhostname, but I feel having mail come from @mail.odynia.org to be a bit off putting. I set it to mydomain.

myorigin = $mydomain

There is a lot of text there about my destination, but I prefer to set it to myhostname. That makes it the only domain that would receive mail should things go sour, which is perfect. All other domains will be virtual.

mydestination = $myhostname

Likewise, empty out the local_recipient_maps, recipient maps are stored in PostgreSQL as virtual mailboxes.

local_recipient_maps =

Set up your mynetworks to be a list of the IP addresses on your machine (localhost, internal and external). This way we don’t trust any other mail server, or anyone pretending to be a mail server.

mynetworks = 127.0.0.0/8, x.x.x.x/32

This is an important one. Here’s a healthy tip from me: don’t try to be an outgoing email server. Set relayhost to your ISP’s SMTP server and save yourself the headache. The most time consuming and hardest part is keeping your email server off blacklists and other fun anti-spam measures, despite the fact that you’re sending legitimate email. It’s just not worth it.

relayhost = smtp.yourisp.com

Virtual Domains and Dovecot

The mailbox_command option is where we specify Dovecot as the local delivery agent (LDA).

mailbox_command = /usr/local/libexec/dovecot/deliver

I also set the dovecot_destination_recipient_limit to 1 in order to allow a Delivered-To header to be added to my messages. When you have almost unlimited email addresses and a spammer doesn’t put you in the To header it is helpful to know which email address it was delivered to.

dovecot_destination_recipient_limit = 1

Now to configure our virtual domains. First set your virtual_mailbox_domains to a list of domains (comma separated) that you want to receive mail for.

virtual_mailbox_domains = domain.com, somedomain.com, someotherdomain.com

And set the virtual_mailbox_maps to look in a PostgreSQL configuration file. This is the key bit and the contents of this file is discussed further down in PostgreSQL Configuration. The file will be stored in /usr/local/etc/postfix/pgsql.cf.

virtual_mailbox_maps = proxy:pgsql:$config_directory/pgsql.cf

Then set your virtual_transport to dovecot.

virtual_transport = dovecot

To actually use the dovecot transport though, you will need to add the following line to your master process configuration file /usr/local/etc/postfix/master.cf.

dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${recipient}

In greater detail:

• flags=DRhu: The flags to pass to dovecot. The D flag is for setting the Delivered-To header, but i have no idea what the others are. Every resource says you need to set those flags though.
• user=vmail:vmail: The user and group to run the dovecot-lda as. I use vmail as per the examples, but you will need to create the user account and group manually. This is covered more in Part Two.
• argv=/usr/local/libexec/dovecot/deliver -f ${sender} -d ${recipient}: The command line to execute dovecot-lda. The ${sender} and ${recipient} are replaced by the sender and recipient of the email being delivered. The email body is passed to dovecot-lda on STDIN.

And so ends this portion of the Dovecot setup. The rest is covered in Part Two. It is important to note that you will not be able to receive email until the Dovecot setup has been completed.

Security and Anti-Spam

There are some basic things you should do to beef up your Postfix server’s security, even just that little bit, back over in /usr/local/etc/postfix/main.cf.

Set your smtpd_helo_required to yes. It is a basic thing but some lazy spammers don’t implement HELO in their mail clients. All “real” mail clients should implement it correctly.

smtpd_helo_required = yes

And now for the recipient restrictions. You can configure any number of restrictions about who can deliver mail to your server, these are a few of the more common ones, detailed below.

smtpd_recipient_restrictions =
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_destination,
reject_unauth_pipelining,
reject_rbl_client bl.spamcop.net,
reject_rbl_client cbl.abuseat.org,
reject_unauth_destination,
check_client_access hash:$config_directory/proct,
check_policy_service unix:private/policyd

• reject_non_fqdn_sender: Reject when the sender is not from a fully qualified domain (ie. someuser@fakedomain as opposed to someuser@fakedomain.com)
• reject_non_fqdn_recipient: Same again but for the recipient
• reject_unknown_sender_domain: This does a DNS lookup to verify that the domain is a real domain.
• reject_unknown_recipient_domain: Same again but for the recipient.
• reject_unauth_destination: Reject emails sent to domains that Postfix is not configured to receive mail for. We make sure this is here to prevent our server becoming an open relay.
• reject_unauth_pipelining: Pipelining is a way of sending all the SMTP commands to the server without waiting for each response, which speeds up delivery. It is also commonly implemented by bulk senders, so this prevents poorly built mail clients from assuming pipelining is enabled instead of asking first.
• reject_rbl_client <server>: This rejects emails by looking them up in a Relay Block List (RBL), a common, if antiquated, anti-spam technique.
• check_policy_service unix:private/policyd: This is the key to our SPF setup. It checks all emails against the SPF Policyd service, which is configured below.

Now that we have our SPF setup in the smtpd_recipient_restrictions we need to configure the policy service. To do so you need to add the following to your master process configuration file, or /usr/local/etc/postfix/master.cf for short.

policyd unix - n n - - spawn user=nobody argv=/usr/local/sbin/postfix-policyd-spf-perl

This will spawn a new instance of the postfix-policyd-spf-perl binary for each SPF lookup, running as the user nobody. And thats all it takes.

Running as a Backup Mail Exchange

I also want Shana to operate as a backup mail server for some domains that are hosted on Google Apps or Office 365. To do so you need to add the following to your /usr/local/etc/postfix/main.cf:

transport_maps = hash:$config_directory/transport

This will check /usr/local/etc/postfix/transport for domains we should use an alternate delivery transport for. To add a domain, we first need to add it to virtual_mailbox_domains or some other list of domains in /usr/local/etc/postfix/main.cf, otherwise Postfix will reject the email.

Then in your /usr/local/etc/postfix/transport file:

somedomain.com relay:mx.server.name
* :

Make sure you keep the last line, which means all other domains should still be delivered locally. Then run postmap to create the database file that Postfix uses (/usr/local/etc/postfix/transport.db).

[root@shana /usr/local/etc/postfix]$ postmap /usr/local/etc/postfix/transport

PostgreSQL Configuration

Now that we have Postfix all configured, we just need to setup our database and write the query that will look up the recipient in the database. The database design itself is very simple, a simple of mailboxes and a table of aliases.

In this case, we need to create a mail database, and a mail PostgreSQL user (with a password!):

[root@shana /]$ sudo -u pgsql -s

[pgsql@shana /]$ createdb mail

[pgsql@shana /]$ createuser -P mail
# Enter password for new role:
# Enter it again:
# Shall the new role be a superuser? (y/n) n
# Shall the new role be allowed to create databases? (y/n) n
# Shall the new role be allowed to create more new roles? (y/n) n

Mailboxes Table

The Mailboxes Table has four columns:

You can use the following SQL to create the table:

CREATE TABLE mailboxes (
"mbox" text not null primary key,
"password" text not null,
"quota" integer default 0,
"disabled" boolean not null default false
);

Then populate it with whatever you need to:

INSERT INTO mailboxes (mbox, password) VALUES ('someuser@somedomain.com', '{SSHA256}tUSmEcHBXAoyLpbwGUMKenMgguavaBS+sDbk2wIL+fdQ7wWj');

Aliases Table

The Aliases Table is a way of creating an alias for a mailbox. Both Postfix and Dovecot will treat an alias as if it really was the mailbox. That means you can login to Dovecot as an alias, should the need arise.

The Aliases Table has two columns:

You can use the following SQL to create the table:

CREATE TABLE aliases (
"alias" text not null primary key,
"mbox" text not null references mailboxes (mbox)
);

Then populate it with whatever you need to:

-- Aliasing one email address to another
INSERT INTO aliases (alias, mbox) VALUES ('anotheruser@somedomain.com', 'someuser@somedomain.com');

-- Catch all for a specific domain
INSERT INTO aliases (alias, mbox) VALUES ('@xxxdomain.com', 'someuser@somedomain.com');

-- Catch all for a user at all domains
INSERT INTO aliases (alias, mbox) VALUES ('postmaster@', 'someuser@somedomain.com');

Configuring the Postfix -> PostgreSQL Mapping

Back up a bit under Virtual Domains and Dovecot we setup our virtual_mailbox_maps to proxy:pgsql:$config_directory/pgsql.cf. This tells Postfix to lookup virtual mailbox maps (mapping an email address to a virtual mailbox) using the PostgreSQL proxy.

Once you’ve created your database we need to create the pgsql.cf file to match. Open up /usr/local/etc/postfix/pgsql.cf and add the following:

hosts = /tmp
user = mail
dbname = mail
password = somepassword

query = SELECT DISTINCT ON (mbox) mbox as userid FROM COALESCE((SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE (mailboxes.mbox = '%s' OR aliases.alias = '%s') AND mailboxes.disabled = false), (SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE aliases.alias = '@%d' AND mailboxes.disabled = false), (SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE aliases.alias = '%u@' AND mailboxes.disabled = false)) as mbox;

The hosts option it set to /tmp so that it uses the default PostgreSQL unix socket, as opposed to a TCP socket. Set your dbname, user and password to match the database you created earlier.

The query is the interesting bit of all of this, lets reformat it and break it down.

SELECT
DISTINCT ON (mbox) mbox as userid
FROM
COALESCE
(
(SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE (mailboxes.mbox = '%s' OR aliases.alias = '%s') AND mailboxes.disabled = false),
(SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE aliases.alias = '@%d' AND mailboxes.disabled = false),
(SELECT DISTINCT ON (mbox) mbox FROM mailboxes LEFT OUTER JOIN aliases USING (mbox) WHERE aliases.alias = '%u@' AND mailboxes.disabled = false)
) as mbox;

Hopefully that will make it a little clearer, apologies for the scroll. It basically runs three subqueries for the different types of lookups and returns a unique mbox from the first subquery that returns results.

Query Details

Lets look at each of those subqueries in a bit more detail.

SELECT
DISTINCT ON (mbox) mbox
FROM
mailboxes LEFT OUTER JOIN aliases USING (mbox)
WHERE
(mailboxes.mbox = '%s' OR aliases.alias = '%s') AND mailboxes.disabled = false

This will look in the mbox column of the mailboxes table and the alias columns of the aliases table for “%s”, which PostgreSQL will expand to be the full email address of the recipient.

SELECT
DISTINCT ON (mbox) mbox
FROM
mailboxes LEFT OUTER JOIN aliases USING (mbox)
WHERE
aliases.alias = '@%d' AND mailboxes.disabled = false

This will look in the alias column of the alias table for “@%d”, or the @ symbol followed by the domain name only portion of the recipient’s email address.

SELECT
DISTINCT ON (mbox) mbox
FROM
mailboxes LEFT OUTER JOIN aliases USING (mbox)
WHERE
aliases.alias = '%u@' AND mailboxes.disabled = false

This will look in the alias column of the alias table for “%u@”, or the username only portion of the recipient’s email address.

The End For Now

And thats it! A fully configured Postfix setup with PostgreSQL lookups. If you stayed with me through this absurdly long post, thanks!

It is important to know though before you leave here that you can’t yet receive email until the Dovecot setup has been completed. For that, you will need to read Part Two, which is coming tomorrow.

Installing MySQL

Naturally, the first thing you must do is install MySQL. There has been a lot of activity with Percona and MariaDB lately but we’ll stick with vanilla MySQL for the moment due to time constraints. We can drop in one of the other two later as required.

Advice for utilising an SSD in your MySQL deployment is pretty scattered and confusing. The best resource I’ve been able to find is this set of slides from Sun/MySQL.

Installing MySQL is a simple procedure using ports:

#[root@shana /]$ cd /usr/ports/databases/mysql55-server/

[root@shana /usr/ports/databases/mysql55-server]$ make install clean
# ===> Found saved configuration for mysql-server-5.5.25
# => mysql-5.5.25.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
#
# ===> Compressing manual pages for mysql-server-5.5.25
# ===> Registering installation for mysql-server-5.5.25
# ===> SECURITY REPORT:
# This port has installed the following files which may act as network
# servers and may therefore pose a remote security risk to the system.
# /usr/local/libexec/mysqld
#
# This port has installed the following startup scripts which may cause
# these network services to be started at boot time.
# /usr/local/etc/rc.d/mysql-server
#
# If there are vulnerabilities in these programs there may be a security
# risk to the system. FreeBSD makes no guarantee about the security of
# ports included in the Ports Collection. Please type 'make deinstall'
# to deinstall the port if this is a concern.
#
# For more information, and contact details about the security
# status of this software, see the following webpage:
# http://www.mysql.com/
# ===> Cleaning for cmake-2.8.8
# ===> Cleaning for mysql-client-5.5.25
# ===> Cleaning for mysql-server-5.5.25

Easy as that. You can enable MySQL (and leave the data directory in the default /var/db/mysql location) just by adding the following line to /etc/rc.conf.

mysql_enable="YES"

Then start it up:

[root@shana /]$ /usr/local/etc/rc.d/mysql start

Benchmarking

For benchmarking MySQL we’ll use sysbench. In line with the PostgreSQL testing we did, we’ll create /mydbtmp and /mylogtmp drives in ZFS as they are required.

We’ll test the following scenarios, both with MyISAM and InnoDB (the most common engines).

1. Running everything on zroot (Mirrored HDDs)
2. Running everything on zflash (Mirrored SSDs)
3. Running everything on zapps (Mirrored HDDs with SSD ZIL/L2ARC)

• Splitting the data and logs

We’ll look at ZFS optimisations after.

Setup

We repeat these steps for each benchmark. For our first three benchmarks we’ll only need /mydbtmp. Create it using ZFS:

[root@shana /]$ zfs create -o mountpoint=/mydbtmp/mydbtmp

Substituting <pool> for zroot, zapps, and zflash as required.

To tell MySQL to use those data directories, add the following to your /etc/rc.conf:

mysql_datadir="/mydbtmp"

We will also need to create the mysql database and username:

[root@shana /]$ mysqladmin create sbtest

[root@shana /]$ mysql
#
# Welcome to the MySQL monitor. Commands end with ; or \g.
# Your MySQL connection id is 12
# Server version: 5.5.25 Source distribution
#
# Copyright (c) 2000, 2011, Oracle and/or its affiliates. All rights reserved.
#
# Oracle is a registered trademark of Oracle Corporation and/or its
# affiliates. Other names may be trademarks of their respective
# owners.
#
# Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> create user 'sbtest'@'localhost';
# Query OK, 0 rows affected (0.00 sec)

mysql> grant all privileges on sbtest.* to 'sbtest'@'localhost' with grant option;
# Query OK, 0 rows affected (0.00 sec)

Then we tell sysbench to prepare the database for testing.

[root@shana /]$ sysbench --test=oltp --mysql-table-engine=myisam --oltp-table-size=1000000 --mysql-socket=/tmp/mysql.sock --mysql-user=sbtest prepare
# sysbench 0.4.12: multi-threaded system evaluation benchmark
#
# No DB drivers specified, using mysql
# Creating table 'sbtest'...
# Creating 1000000 records in table 'sbtest'...

Here we’re creating a table sbtest and populating it with a million records. Then we can run the benchmark:

[root@shana /]$ sysbench --num-threads=16 --max-requests=100000 --test=oltp --oltp-table-size=1000000 --mysql-socket=/tmp/mysql.sock --mysql-user=sbtest run
# sysbench 0.4.12: multi-threaded system evaluation benchmark
#
# No DB drivers specified, using mysql
# Running the test with following options:
# Number of threads: 16
#
# Doing OLTP test.
# Running mixed OLTP test
# Using Special distribution (12 iterations, 1 pct of values are returned in 75 pct cases)
# Using "LOCK TABLES WRITE" for starting transactions
# Using auto_inc on the id column
# Maximum number of requests for OLTP test is limited to 100000
# Threads started!
# Done.
#
# OLTP test statistics:
# queries performed:
# read: 1400000
# write: 500000
# other: 200000
# total: 2100000
# transactions: 100000 (193.98 per sec.)
# deadlocks: 0 (0.00 per sec.)
# read/write requests: 1900000 (3685.55 per sec.)
# other operations: 200000 (387.95 per sec.)
#
# Test execution summary:
# total time: 515.5274s
# total number of events: 100000
# total time taken by event execution: 8247.0597
# per-request statistics:
# min: 6.97ms
# avg: 82.47ms
# max: 785.73ms
# approx. 95 percentile: 79.73ms
#
# Threads fairness:
# events (avg/stddev): 6250.0000/0.00
# execution time (avg/stddev): 515.4412/0.02

All done! Jump into MySQL to drop the sbtest table, then we run sysbench again but this time with –mysql-table-engine=innodb.

mysql> drop table sbtest;
# Query OK, 0 rows affected (0.05 sec)

Then we can destroy the /mydbtmp filesystem and create it again on a different drive ready for the next test.

Results

The results here are interesting, mostly because of how they contradict the advice linked above.

Graphically:

MySQL Benchmark Results

Conclusion

It seems the simplest way to improve performance with MySQL is to throw everything on to the SSDs. It is noted though that the InnoDB gains much more performance benefit than MyISAM. If you’re stuck with MyISAM tables it might not be worth investing in a SSD.

For now, I’ll create /var/mysql/data on zflash and store my databases there.