If you have enough space in your home directory (or elsewhere on your filesystem) then you can use this as a temporary swap file without making a partition.

First we allocate the file that will be used as swap. This is where we set the size. In this example, I’ve chosen 10GB.

truncate -s 10G ~/tempswap

Now we tell this file to be a swap file:

mkswap ~/tempswap

And finally we can tell our system to use the new swap file (on top of any existing swap files):

sudo swapon ~/tempswap

To check on your memory and swap availability and usage, try:

free -m

This swap file won’t be used as swap on next boot unless you add it to your /etc/fstab, but you’ll still have to delete the file to get the space back. To clear up after yourself manually, do this:

sudo swapoff ~/tempswap
rm ~/tempswap

A few weeks back one of the hard drives failed. Service continued as normal but it was an acute reminder that the server was getting old.

Recently Chris bought a powerful server for use as a VMWare ESXi hypervisor, along with a large iSCSI SAN to host all the disk images, and powerful shared MySQL database server. As he was moving lots of his servers from physical boxes to virtual machines, I decided to do likewise.

So this website, and my other sites, are now hosted on a CentOS virtual machine, with their databases on a separate CentOS database server. Given that the load average on the old P3 wasn’t very high I wasn’t expecting a noticeable improvement in performance. But how wrong I was! The site is noticeably faster to load and navigate, and in particular the WordPress management interface is miles faster.

All in all, I’m happy with the new platform. To anyone else considering replacing old servers with a virtualised infrastructure, I say go for it. You’ll save tons of electricity, take up less rack space, pave the way for later expansion (by adding more hypervisors or more disks to the SAN) and have better manageability and backupabilitiy.

But one thing I’ve steered clear of until now is running my own email server.

I’ve always thought it would be fairly easy to set up, but much harder to make secure. I don’t want to receive tonnes of spam and I don’t want spammers using my SMTP server as an open relay. In the past I’ve read about building SMTP servers with sendmail, postfix and exim but there was all sorts of conflicting information when it came to integrating milters and so on. Different guides all seemed to give contradictory advice and require all sorts of strange configuration steps that I couldn’t understand.

But all that changed when I heard about ClearOS. In short, it’s a spin of CentOS which uses a custom web interface to configure various software “modules”, including things like web server, email server, firewall gateway, database server, and so on.

I installed it on a virtual machine and after only a few clicks I was running a mail server: an MX for receiving mail for my domains, an authenticated SMTP server for personal outgoing mail, and a secure IMAP server for storing and accessing my mail. The frontend sets up postfix and cyrus to do its dirty work.

For ultimate ease, users (just me, in this case) are authenticated using a local LDAP directory, rather than by using system accounts. All SSL certificates for IMAPS and HTTPS were added automatically. Email antivirus scanning is done by Amavis and spam filtering is done by Spamassassin.

I had a little bit of trouble setting up Horde to access webmail and a web interface for configuring sieve rules. By “trouble” I mean the default Apache virtual host declarations needed some changing around and some aliases adding. If you’re familiar with Apache this won’t be a problem.

There are some aspects of ClearOS I don’t like so much, and I would prefer to use CentOS. But now ClearOS has written out all my configs it should be trivial to move my new mail setup to a plain old CentOS installation, where I already run my websites from. I have definitely learnt a lot about how email works by simply reading and understanding the config files written by the frontend.

So if you want to build an email server but don’t know where to start – try ClearOS. It’s a great introduction to the “scary” parts of setting up an email server, like milters and certificates.

I’ve edited these notes slightly to make them suitable for a wider audience, but in essence it’s the same stuff. Hope it’s useful!

OS installation

I recommend using CentOS. It doesn’t really matter whether you choose 32-bit (i386) or 64-bit (x86_64) but use ideally use 64-bit unless there’s a reason not to.

Boot from the CD or DVD of your choice. It doesn’t matter whether you use the full DVD, or the network install CD.

Choose the text-based installer from the boot prompt by typing linux text. The text installer doesn’t install as much extra rubbish as the GUI installer.

In most cases the default options are good enough. One option you should change is to use an NTP time server. This is especially important with virtual machines, since they suffer badly from clock drift.

Choose a strong root password. You will only need it once again. After that, you won’t even even need it for logging on, so there is no need to pick anything memorable. In fact, you are best off choosing a long, random string of mixed-case letters and numbers.

When it comes to choosing packages, deselect as many of the groups as possible. We will add the packages we need individually later on.

Let the installer run its course, and reboot.

Users and passwords

Upon first boot, log in as root using the password you picked before. Now create new user accounts and set passwords:

useradd yourusername
passwd yourusername

Now for setting sudo access. This is like “run as admin” on Windows. Type visudo. In the text file that opens, read down to the line that says

root    ALL=(ALL)       ALL

Duplicate it twice by pressing yyp. Go into insert mode by pressing i and change the username root to your username. When you are done, hit Esc and type :wq to save and exit. Gotta love vi commands

To disable remote root login via ssh, edit the file /etc/ssh/sshd_config using your favourite editor. If you don’t already have a favourite editor, use vi.

Find the line:

#PermitRootLogin yes

and uncomment it and change the value to no:

PermitRootLogin no

Restart the ssh daemon by doing

sudo /sbin/service sshd restart

From now on you can gain root access by using the sudo command, and you won’t need to log in as root again. Log out now by typing exit and re-login as your own user. Forget the root password forever.

Installing packages

First we add a couple of third-party software repositories that have useful stuff.

sudo rpm -Uvh http://download1.rpmfusion.org/free/el/updates/testing/5/i386/rpmfusion-free-release-5-0.1.noarch.rpm http://download1.rpmfusion.org/nonfree/el/updates/testing/5/i386/rpmfusion-nonfree-release-5-0.1.noarch.rpm

Let’s get rid of the stuff we don’t want or need. There are no doubt more than things that can be removed than I’ve listed here, but they can be removed later.

sudo yum remove bluez* pcsc*

Update the system so you’re sure that that latest versions of all software are installed.

sudo yum update

Now we can install the stuff we want for LAMP!

sudo yum install httpd mysql-server php php-mysql

If you are wanting to use any PHP modules/libraries they can be installed here too, such as the commonly-used graphics library gd.

Services

Let’s start the two daemons for Apache and MySQL, and tell them to start on boot.

sudo /sbin/service httpd start
sudo /sbin/service mysqld start
sudo /sbin/chkconfig httpd on
sudo /sbin/chkconfig mysqld on

Apache in its default state will run out of the box. MySQL just needs a root password setting.

mysqladmin -u root password NEWPASSWORD

From now on it’s advisable to GRANT access to specific users on specific databases/tables. Go read about MySQL users.

Firewall

Let’s assume you want HTTP on port 80 open to the world. Open /etc/sysconfig/iptables for editing, and add this line.

-A RH-INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Save and close, and run this to make the changes live.

sudo /sbin/service iptables restart

Editing configs

The main config file for Apache is at /etc/httpd/conf/httpd.conf. It doesn’t need any changes for basic operation, but if you edit it you need to restart the httpd service to pick up the changes.

If you get serious with web publishing from a LAMP platform, you will probably want to read about name-based virtual hosts.

Adding content

In its basic configuration, you should add PHP scripts, HTML pages and other content like images and stylesheets to /var/www/html/. You do not need to restart the daemon for it to pick up new content.

When debugging pages, you will probably find it handy to refer to the error log, at /var/log/httpd/error_log.

Tip: Open two SSH windows to the server – one for editing stuff, and the other for watching the log scroll by as events occur. Use Ctrl-C to break out of it. Do this:

sudo tail -f /var/log/httpd/error_log

I wouldn’t normally go upgrading my OS to the latest on the day of release, but frankly anyone who runs Fedora is an early adopter by definition.

I started by upgrading two unimportant Fedora 12 virtual machines at work using preupgrade. One went smoothly but the other failed because the /boot partition was too full. I cleared out all old kernels and tried again, with success. Each upgrade took less than an hour, I think, but I wasn’t really paying attention.

After brief testing to make sure all the important stuff had upgraded properly, I upgraded my work desktop PC, my home PC and my laptop too. They were all on Fedora 12 and the upgrades went without a hitch. I’m very impressed.

Massive thanks and kudos are due to the Fedora team for working so hard to get this release out and for providing such an easy upgrade path. I look forward to getting stuck into the new features of this release in time.

My next task is to upgrade my home server, which is currently running Fedora 11. Updates for Fedora (N-2) are only available for one month after the release of Fedora N, so time is now of the essence if I wish to keep my server secure. Unfortunately the reason I’m still on 11 is because the upgrade to 12 failed and I wasn’t able to get it working. I will probably take this opportunity to do a complete wipe and reinstall (scary!). Then I can also migrate from i386 architecture to x86_64.

Watch this space!

I’d never tried it before, so I followed this guide on how to do it. It was pretty straight forward, but I’ve recreated the steps here, with my own modifications.

Step 0: Take a photo

Start off by taking a photo to make into a fake miniature. The best photos are taken looking down on your subject, as a human observer would see a model on a table, for example. Include subjects such as people or cars to give a sense of “scale”.

Strong shadows also lend themselves to the effect, as you may well look at a model railway using a single desk lamp, for example.

Step 1: Adjust colours

Most models have more vivid colours than real life, due to their glossy paint. There are several ways you could achieve this.

• Go to Layer > Colors > Curves. Click at about x: 130 y: 210. Move the curve around until you get what you are looking for.
• Or, go to Colors > Auto > Color Enhance. This is the lazy man’s way of boosting the saturation.

You might also like to enhance the contrast to make the shadows stronger.

Step 2: Set gradient mask

Open the image and toggle the switch mask on. There are three ways to do this:

• Click the dotted box in the bottom left had corner of the open image, or
• Got to Select > Toggle Quick Mask, or
• Press Shift+Q.

The image will now be pink. Click on the Gradient tool. It looks like a square with a grey gradient applied to it. Set the gradient shape to Bi-linear.

Step 3: Apply mask

Pick your focal point. Decide what areas of the image you would like to be in or out of focus. Click in the center of the area you would like to be in focus and drag a line perpendicular to the direction you want to be masked, i.e. dragging the line from the “in focus” region to the “out of focus” region.

Play around with the centre, size, and angle of the mask until you get what you are looking for. Toggle the switch mask off.

Step 4: Apply blur

GIMP doesn’t have Lens Blur like Photoshop (although it can be installed). We have to make do with Gaussian Blur. Go to Filters > Blur > Gaussian Blur. In the Gaussian Blur window click on Preview and maximize the window so that you can see what you are doing.

Play with the blur radius until it looks right. A Blur radius between 5.0 and 10.0 seems to work most of the time, although I found a radius of 50.0 was needed to achieve a decent effect in my image. It depends on the resolution of your camera.

When you have the blur right, delete the quick mask by going to Select > All.

I found a tool for Linux called themonospot. Happily, it’s packaged with Fedora and can be installed simply by doing

yum install themonospot-console

Once installed it’ll quickly give you information about your video files:

[jonathan@zeus ~]$ themonospot-console /media/public/Movies/Sunshine/Sunshine.avi
File path:               /media/public/Movies/Sunshine/Sunshine.avi
Codec name:              XVID
Codec desc:              xvid
Frame size:              704 x 288
Average video bitrate:   1,423 Kb/Sec
File size:               1,525,886 KB
Total time:              01:47:26.00 seconds
Frame rate:              24.00 frames/sec
Total frames:            154,574
Video data rate:         23 frames/sec
Video quality:           113
Packet Bitstream:        False
ISFT data:               VirtualDubMod 1.5.10.2 (build 2540/release)
JUNK data:               VirtualDubMod build 2540/release
USER data:               XviD0046
Audio 01:                0x2000 (AC3) 448.00 Kb/Sec - 48000 Hz (6 Channels)

As you can see, my copy of Sunshine has 6-channel audio (i.e. 5.1). But what if you want to run a batch job to check all of your films and see which ones have surround sound?

Then use perl.

I wrote an extremely hacky script that takes a path as an argument and whizzes round to fetch the encoding of all .avi or .AVI files in the directory. It prints the names of any that have more than 2 audio channels (i.e. better than stereo).

It sometimes goes wrong if the output of themonospot-console varies, as it occasionally does.

So you get output like this…

[jonathan@zeus ~]$ ./findAudioEncoding.pl /media/public/Movies/
/media/public/Movies/Catch Me If You Can/Catch Me If You Can.avi : 6
/media/public/Movies/National Treasure - Book of Secrets/National Treasure - Book of Secrets.avi : 6
/media/public/Movies/Never Been Kissed/Never Been Kissed.avi : 6
/media/public/Movies/Rescuers, The/Rescuers, The.avi : 5
Argument "" isn't numeric in numeric gt (>) at ./findAudioEncoding.pl line 12.
/media/public/Movies/Brideshead Revisited/Brideshead Revisited.avi : 5
/media/public/Movies/Passion of the Christ, The/Passion of the Christ, The.avi : 6

If you’re interested in the source, here it is. If you find this useful, why not “like” my post? (The at the bottom)

#!/usr/bin/perl -w
# findAudioEncoding.pl

use strict;
my $path = $ARGV[0];
chomp (my @files = `find $path 2> /dev/null | grep -i .avi`);
foreach my $file (@files) {
        chomp (my $channels = `themonospot-console "$file" | grep \"Audio 01\" | awk \' { print \$10 } \'`);
        $channels =~ s/\(//g;
        if ($channels > 2) {
                print "$file : $channels\n";
        }
}

From these graphs, it seems that the higher the outdoor temperature, the more free memory the system has available. I’m sure this is just a coincidence, though…

Outdoor temperature

Free memory

Well, now it’s too cold. The UK has had a bit of a cold snap lately. Outdoor temperatures in Bristol last night got as low as -3 °C, and in turn the temperature in my loft went down to 2.5 °C.

Ambient temperature in my loft

Thing is, that’s probably a bit too cold for my server now. The CPU is happily sitting there at 24 °C but the disks are all around 15 °C.

According to Wikipedia:

A common misconception is that a colder hard drive will last longer than a hotter hard drive. The Google study seems to imply the reverse – “lower temperatures are associated with higher failure rates”. Hard drives with S.M.A.R.T.-reported average temperatures below 27 °C had failure rates worse than hard drives with the highest reported average temperature of 50 °C, failure rates at least twice as high as the optimum S.M.A.R.T.-reported temperature range of 36 °C to 47 °C.

So my disks appear to be at risk of failing sooner. Worse yet, they’re not consistently at 15 °C but fluctuate wildly on a daily and seasonal basis. Looks like all I can do is keep my data on a redundant array and swap out any disks when (not if) they fail.

Today I was prompted to upgrade to the new version, 9.10. On my connection at work (via Janet) the upgrade didn’t take long at all…

Upgrade Screenshot

After 9 minutes of frenzied downloading, the upgrade itself took around an hour and a half. Afterwards, I rebooted. I like what they’ve done with the UI!

Ubuntu Screenshot

The roll-over animations make it look and feel nice and polished to use. They’ve also paid close attention to certain aspects of the interface, such as the package manager. It’s a breeze to configure the system.

One notable new addition is Ubuntu One, a free cloud storage service. I have no need for it, as I have my own server, but it’s a handy feature for most people.

Most of the stuff is the same old. Most things work the same as they used to, so it takes no time at all to find your way around the new version.

Well done Ubuntu!