Today I finally got round to setting up my local user ssh config on my new work laptop and figured I’d do a quick write up on it and it’s uses.

You can create a configuration file in your home directory that will override the options set in your machine-wide config.

Your configuration files

Your local config can be found/created in:


And your machine-wide configuration is in:


Rather than editing my ssh config across my whole machine I’m doing it for my local user specifically.

Reading the man page for ssh_config will give you a full list of available options, below I will outline several that I use and find very useful.

Your host definitions

First things first, we need to define a host.


Each host you add to your config will need to have a host …

Over the last two days I’ve had the interesting task of online some VMs from clones and increasing their disk space to accommodate a mass of user uploaded content. I’ve done this before but never actually with an Logical Volume Management (LVM) disk.

My first approach, like a fool, was to clone the VM from source and boot it from a remotely mounted GParted ISO, this didn’t actually go as expected and I was unable to add it to the LVM, I found a nice guide online and consulted a colleague because I knew he’d done something similar recently. After the first successful size increase I realised I was able to do it without ever rebooting the machine itself, this is accomplished by actually adding an extra disk to the VM, this disk can then be partition with cfdisk and then added to the LVM, thus …

This is yet another follow up to post to several previous posts about using nginx as a reverse proxy with caching. It is actually a direct addition to my post from a week or so ago which outlined how to actually using nginx’s proxy caching feature which can be read here — /2010/02/07/nginx-proxy_cache-and-explained-benchmarked/.

Even more changes?

Yes, even more changes, these are basic changes that are there to improve the caching capabilities and also implement load balancing.

Cache changes

The first set of changes are in the main nginx configuration file


These changes basically just change the proxy_cache key

proxy_cache_path /var/www/nginx_cache levels=1:2 keys_zone=cache:8m max_size=1000m inactive=600m;
proxy_temp_path /tmp/nginx;
proxy_cache_key "$scheme://$host$request_uri";

I’ve decided to put the temporary caches file in to an nginx specific directory, just to separate them from other cache files …

I have written a much newer, clearer and better article on DomainKeys signing email `here`_.


This guide is a sister to another guide I wrote a while back about how to use DomainKeys Identified Mail (DKIM) with Postfix on Debian, which can be read here - /2010/01/11/dkim-on-debian-with-postfix/.

DomainKeys is an older implementation than DKIM, DKIM is a merge of DomainKeys and Identified Mail. Both DomainKeys and DKIM are used so having both configured is a good idea.

Getting started

Lets start off by installing the dk-filter

sudo apt-get install dk-filter

Once installed you can can create a public and private key set using the commands below, if you’re already using DKIM you can skip this step and just use your already existing key.

openssl genrsa -out private.key 1024
openssl rsa -in private.key -out public.key -pubout -outform PEM
sudo mkdir /etc/mail
sudo …

You can get a basic overview on what SPF is, what it’s for and it’s more advanced usages here -

This article is to give only a basic insight in to how you can use an SPF record to valid mail from your servers.


SPF records work from your DNS, it’s really simple. Technically there is a DNS type defined for SPF records as of RFC 4408, but since not all servers recognise this type it also works in the TXT type.

A simple usage of SPF is

v=spf1 a mx -all

Imagine this exists on this domain, This spf record would mean that ALL AN and MX servers listed in the DNS records of would be valid senders.

The hypen (-) before all means that if the mail appears to be coming from a server that isn …


Simple, if it’s not installed already then run the following commands

sudo apt-get install iptables
sudo /etc/init.d/iptables start

The safest and best way of configuring iptables, in my opinion, is to have two files. The first is a temporary/test set that you will save to first, the second is the actual rule set that will be loaded to iptables.


So, first we’ll create an empty temp rules file

sudo touch /etc/iptables.temp.rules

Add some simple rules to it:

# Allows all loopback traffic and drop all traffic to 127/8 that doesn't use lo

-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d -j REJECT

# Accepts all established inbound connections

# Allows all outbound traffic

-A INPUT -p tcp -m …

The beginning

Where to begin? nginx would be a good start I suppose. It’s far easier and makes much for sense for you to actually read about nginx from it’s own website - - but just to give a simple explanation too; `nginx is king of static content HTTP servers.`

Anyone that has dealt with Apache on medium to high traffic websites will know that Apache is bit of a `wheezy, old geezer` when it comes to content serving using it’s mpm-worker (threaded). Very often high traffic will cause server load to go through the roof but for serving dynamic content, there really is no better HTTP server than Apache, so this leaves us in a bit of a predicament; a high powered website with dynamic content and lots of static files like JS, CSS and imagery, what do we do?!

In this example `dynamic …

The problem

So lets get to the problem first. I have several lightly to medium loaded sites running on some virtual servers, they servers themselves are highly configured to run beautifully on our host environments, very, very RAM intensive but low disk I/O and low CPU usage.

As mentioned, the sites are relatively low loaded, they’ll generally hang around at between 3,000-5,000 unique hits a day and are run through Apache using PHP, various PHP modules and MySQL, a simple generic LAMP environment, yet customised to suit it’s surroundings and host.

The sites themselves run fine on that setup, no issues at all on normal days, but on set days of the week these sites can double in unique hits or even more than double, with KeepAlive enabled and a KeepAliveTimeout set low Apache has problems handling this kind of load (I should point out …