Having already invested in a new power supply, I decided to pick up just a case.  In hindsight I could have probably found a good deal on a case + power supply.  This post was inspired by the fact that I really couldn’t find any reviews of the case I did select: CoolerMaster Elite 335 – currently $42.99.  There was a review of the CoolerMaster Elite 330 which is a very similar case.

Summary: After using this case for some time I’m quite happy with it, especially given the price.  There are some minor improvements that could be made, but you get a nice looking case with a useful feature set and high level of compatibility.

Read on for a full review..

(...)
Read the rest of Review: Cooler Master Elite 335 (731 words)

When I was a teenager and into my early 20′s my computer gear was always bleeding edge.  If I had forgone most of the computer gear, I probably could have had a car during university – but having the coolest setup was what it was all about. Once I started work full-time, my work supplied hardware far outpaced what I could justify at home. Somewhere between then and my 30′s I lost the drive to have the coolest stuff and got by with trailing edge gear. Until recently my desktop was a refurbished Celeron 3.06GHz machine that I picked up a couple of years ago for $200.

The issue is that even a horribly dated machine can still run everything you need, just not very fast. Especially given that your average home computing is about surfing the web and maybe some simple file management (let’s ignore the gamer machine which is a totally different story). Having recently upgraded Jenn to a dual core iMac, and also getting a dual-core laptop for work – the celeron was feeling really slow. The straw that broke the camels back was the insanely poor performance of iTunes under VMWare hosting WindowsXP.

Trent had pointed me at techreport.com, specifically the system guide as a good source for reviews and advice. I had initially thought I’d get an AMD based system until the introduction of the lower cost Core i3 early this year. After some extensive online pricing/shopping I settled on a very frugal upgrade plan.

$129.77 Intel Core i3
$114.99 Gigabyte GA-H55M-USB3
$53.77 2GB DDR3 1333MHz (1 stick)
$54.99 Corsair CMPSU-400CX 400W Power Supply
$42.99 Cooler Master Elite 335 Black ATX Mid Tower Case

Total: 396.51 + 51.55 tax

Initially I had planned to re-use the current mid-tower case my celeron system was in, however the front panel plug connectors were not compatible and I didn’t want to start splicing wires to hack things to fit. (Leaving the case intact, gives me a completely functional but slower machine to pass on)

At the top of this post the picture is a close up of the i3 chip installed on the motherboard prior to the installation of the CPU heat sink/fan. If you haven’t built a system from the ground up previously, it may look complicated but its really quite simple. I chose to install the CPU/heat sink prior to installing the motherboard into the case.

Some of my friends teased me for only going with 2GB of RAM, but with my Ubuntu based desktop and my usage (even with VMWare hosting WindowsXP) I rarely use even half of my RAM. I do plan to upgrade to more in the future (6GB or more) but I’m waiting for the price of DDR3 to drop to a reasonable cost. The single 2GB stick was cheaper than some of the 2x1GB options and provides the most flexibility for later upgrades.

The power supply was a bit of a pleasant surprise. It came with cable ties, nylon sleeved cables, and a power cord. This power supply is also 80+ certified which was one of my requirements for a new power supply. The single large fan keeps the noise level to a minimum.

My motherboard selection was based primarily on the techreport.com recommendation.  However, this is one of the few USB3.0 capable motherboards that offers integrated graphics support (when used with i3 or i5 processors).  It has 4 slots of DDR3 memory (up to 16GB), Gigabit ethernet, PCI Express x16, IDE and SATA support as well as external SATA. This is a great foundation for my new system allowing plenty of future expandability.  The only feature I noticed it was missing was SATA3.

Future upgrades will be to add a graphics card, a large SATA drive and of course more RAM. Looking further into the future, I may consider upgrading to an i7 when the prices drop. While this is still a budget system, it has legs and I’m back on the leading edge for a short while.

I was pleased that after assembly the box booted on the 1st try! Having simply moved my drive over from my previous system, I was running an up to date 32-bit Ubuntu 9.10 system. I started to exercise the box and after about 30mins got my first hang. The hang was a bit odd, the keyboard stopped working (numlock didn’t work) and the graphics froze. I was able to ssh into the box and issue a reboot. The hangs persisted, and seemed more frequent.

It turns out upgrading to Lucid Lynx (Ubuntu 10.04) was the solution to the following bug report. There was a problem with the drive for the on-board graphics which the later versions of the kernel contain updated drivers. It seems that I’ve gone from having trailing edge hardware to bleeding edge hardware. Upgrading was simple – hit ALT-F2 and enter “update-manager -d” (no quotes), the -d flag allows you to upgrade to the latest development release.

The next stumbling block was that suspend and hibernate didn’t seem to work. Fortunately someone in the forums had already solved this problem. The USB3.0 support seems to not quite be suspend friendly, so you can optionally disable it in the BIOS or modify your Lucid configuration as follows – create a script /etc/pm/sleep.d/05_xhci that contains:

#!/bin/sh
# Fix some issues with USB3

case "$1" in
hibernate|suspend)
modprobe -r xhci
;;
thaw|resume)
modprobe xhci
;;
*)
exit
;;
esac

and set the permissions appropriately (chmod 755). Now when the system goes to sleep, it will disable USB support and re-enable on resume (or hibernate).

Now that I had the system going to sleep, I wanted to be able to wake it up. The Gigabyte BIOS provides an option to wake up via PS/2 keyboard by typing in a password. I also wanted to have wake-on-lan (WOL) working, something I’ve posted about previously. The new motherboard needed new magic to enable WOL.

First use lspci to find the address of the ethernet contoller:

$ lspci -tv
+-1c.1-[0000:03]----00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller

Then match that to the contents of /proc/acpi/wakeup

$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
PCI0 S5 disabled no-bus:pci0000:00
PEX0 S5 disabled pci:0000:00:1c.0
PEX1 S5 disabled pci:0000:00:1c.1 <- this one!
PEX2 S5 disabled
PEX3 S5 disabled
PEX4 S5 disabled
PEX5 S5 disabled
PEX6 S5 disabled
PEX7 S5 disabled
HUB0 S5 disabled pci:0000:00:1e.0
UAR1 S3 disabled pnp:00:07
USB0 S3 disabled pci:0000:00:1d.0
USB1 S3 disabled pci:0000:00:1d.1
USB2 S3 disabled pci:0000:00:1d.2
USB3 S3 disabled
USB4 S3 disabled pci:0000:00:1a.0
USB5 S3 disabled pci:0000:00:1a.1
USB6 S3 disabled pci:0000:00:1a.2
USBE S3 disabled pci:0000:00:1d.7
USE2 S3 disabled pci:0000:00:1a.7
AZAL S5 disabled pci:0000:00:1b.0

So my new /etc/init.d/wakeonlan file looks like:

#! /bin/sh
### BEGIN INIT INFO
# Provides: wake on lan
# Required-Start: $network
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Configures WOL
# Description: Configures Wake-On-Lan
### END INIT INFO
#
ethtool -s eth1 wol g
echo PEX1 > /proc/acpi/wakeup

If you want to understand WOL in more detail, please review my previous post on the topic.

The last thing I needed was to make VMWare Player happy. During its normal detect a new kernel level and re-install itself process, I encountered an error:

Apr 17 12:07:23.497: app-3079280320| Building module vmnet.
Apr 17 12:07:23.497: app-3079280320| Extracting the sources of the vmnet module.
Apr 17 12:07:23.556: app-3079280320| Building module with command: /usr/bin/make -C /tmp/vmware-root/modules/vmnet-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/2.6.32-21-generic/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.4.3
Apr 17 12:07:29.384: app-3079280320| Failed to compile module vmnet!

The above is a snippet from the log file and it indicates a problem with the network module. Again, someone else had run into the problem and provided a solution. This worked fine for my VMWware Player version 3.0.0 build-203739.

The system has been stable over the last couple of days, if I run into any serious problem I will revise this post.

Having recently setup mirrored volumes with a pair of 1TB drives, I could now migrate data off the pair of 250Gb data drives to allow me to combine those two drives into a single volume.  Way back when I purchased these drives I had intended to run a mirrored setup, but at the time decided that having more storage was more important.  I had “cleverly” purchased two 250Gb drives from different manufacturers, in theory to avoid concurrent failures.  It turns out that not all 250Gb drives are made the same.

Following the instructions from my previous posting, all went well up to where I tried to add the 2nd volume to the mirrored set.  If you run into a similar problem you’ll likely see one of the two following errors:

mdadm: add new device failed for /dev/hda1 as 2: No space left on device
mdadm: add new device failed for /dev/hda1 as 2: Invalid argument

I found some good hints on how to diagnose the problem, it turns out you can check the partition sizes manually

$ cat /proc/partitions
major minor  #blocks  name

8    17  244196001 sdb1
8    65  244198552 sde1

Close, but not quite the same.  As it was, I had unluckily chosen /dev/sdb as the 1st drive in the mirrored set.  It turns out that fdisk tells an even more interesting story.

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000c0f4f

Device Boot Start End Blocks Id System
/dev/sdb1 1 30401 244196001 83 Linux

$ sudo fdisk -l /dev/sde

Disk /dev/sde: 250.0 GB, 250059350016 bytes
16 heads, 63 sectors/track, 484521 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sde1 1 484521 244198552+ 83 Linux

Yuck, looks messy. At this point I’ve got some of my live data sitting on one half of the mirrored set, and no suitable 2nd drive to act as the mirror.  Somewhat predictably there is a solution that minimizes downtime and avoids copying all of the data to a new location.

First you unmount the volume and run resize2fs on it.  We don’t need to know the correct size, just any size smaller than the 2nd volume – so I used 200Gb.

$ sudo umount /media/data/
$ sudo e2fsck -f /dev/md2
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 1890279/15269888 files (0.2% non-contiguous), 32742192/61049616 blocks
$ sudo resize2fs /dev/md2 200G
resize2fs 1.40.8 (13-Mar-2008)
Resizing the filesystem on /dev/md2 to 52428800 (4k) blocks.
The filesystem on /dev/md2 is now 52428800 blocks long.

Now we need to calculate what the correct size of the mirrored partition should be. I looked at two bits of data: the size the mdadm -D reported for the partition I wanted to resize, and the size that was in /proc/partitions for the same. These differed by 88 blocks, so I used the value 88 as a fudge factor – it may not be required but it worked for me. I then also ensured that I supplied a value that was an even multiple of 64 (blocks).

So starting with 244196001 from /proc/partitions:

(244196001 - 88) / 64 = 3815561.14

Drop the decimal places and multiply by 64 to get the number of blocks.

3815561 * 64 = 244195904

Now we feed this new size into mdadm and specify the –grow flag (which can also be used to shrink if you specify a block size smaller than the current which is what we are doing in this case).  We then re-run resize2fs without a specified size, which will cause it to expand the filesystem to fill the partition.

$ sudo mdadm --grow /dev/md2 --size=244195904
$ sudo resize2fs /dev/md2
resize2fs 1.40.8 (13-Mar-2008)
Resizing the filesystem on /dev/md2 to 61048976 (4k) blocks.
The filesystem on /dev/md2 is now 61048976 blocks long.

Now all that is left is to run a filesystem check, and remount it.

$sudo e2fsck -f /dev/md2
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 1890279/15269888 files (0.2% non-contiguous), 32742192/61048976 blocks
$ sudo mount -a

Now when you attempt to add the 2nd volume, it will be a matching size and the mirror will work.  In the future, I intend to be a little more careful when I plan to setup mirrored drives and pick the smaller volume as the starting point.

Mirrored drives are also known as a RAID 1 configuration.  It is important to note that running mirrored drives should not be used as a substitute for doing backups.  My motivation for running a RAID 1 is simply that with the drive densities today, I expect these drives to fail.  A terabyte unit is cheap enough that multiplying the cost by two isn’t a big deal, and it gives my data a better chance of surviving a hardware failure.

I purchased two identical drives several months apart – in the hopes of getting units from different batches. I even put them into use staggered by a few months as well.  The intent here was to try to avoid simultaneous failure of the drives due to similarities in manufacture date / usage.  In the end, the environment they are in is probably a bigger factor in leading to failure but what can you do?

Linux has reasonable software raid support.  There is a debate of the merits of software raid vs. hardware raid, as well as which level of raid is most useful.  I leave this as an exercise up to the reader.  The remainder of this posting will be the details of setting up a raid 1 on a live system.  I found two forum postings that talked about this process, the latter being most applicable.

We will start with the assumption that you do have the drive physically installed into your system.  The first step is to partition the disk.  I prefer using cfdisk, but fdisk will work too.  This is always a little scary, but if this is a brand new drive it should not have an existing partition table.  In my scenario I wanted to split the 1TB volume into two partitions, a 300Gb and a 700Gb.

Now let’s use fdisk to dump the results of our partitioning work:

$ sudo fdisk -l /dev/sdd

Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Device Boot         Start         End      Blocks   Id  System
/dev/sdd1               1       36473   292969341   83  Linux
/dev/sdd2           36474      121601   683790660   83  Linux


Next we need to install the RAID tools if you don’t have them already:

$ sudo apt-get install mdadm initramfs-tools

Now recall that we are doing this in a live system, I’ve already got another 1TB volume (/dev/sda) partitioned and full of data I want to keep. So we’re going to create the RAID array in a degraded state, this is the reason for the use of the ‘missing’ option. As I have two partitions I need to run the create command twice, once for each of them.

$ sudo mdadm --create --verbose /dev/md0 --level=mirror --raid-devices=2 missing /dev/sdd1
$ sudo mdadm --create --verbose /dev/md1 --level=mirror --raid-devices=2 missing /dev/sdd2

Now we can take a look at /proc/mdstat to see how things look:

$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdd2[1]
683790592 blocks [2/1] [_U]

md0 : active raid1 sdd1[1]
292969216 blocks [2/1] [_U]

unused devices: <none>

Now we format the new volumes. I’m using ext3 filesystems, feel free to choose your favorite.

$ sudo mkfs -t ext3 /dev/md0
$ sudo mkfs -t ext3 /dev/md1

Mount the newly formatted partitions and copy data to it from the existing drive. I used rsync to perform this as it is an easy way to maintain permissions, and as I’m working on a live system I can re-do the rsync later to grab any updated files before I do the actual switch over.

$ sudo mount /dev/md0 /mntpoint
$ sudo rsync -av /source/path /mntpoint


Once the data is moved, and you need to make the new copy of the data on the new degraded mirror volume the live one. Now unmount the original 1TB drive. Assuming things look ok on your system (no lost data) now we partition that drive we just unmounted (double and triple check the device names!) and format those new partitions.

All that is left to do is add the new volume(s) to the array:

$ sudo mdadm /dev/md0 --add /dev/sda1
$ sudo mdadm /dev/md1 --add /dev/sda2

Again we can check /proc/mdstat to see the status of the array. Or use the watch command on the same file to monitor the progress.

$ cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sdd2[1]
683790592 blocks [2/1] [_U]

md0 : active raid1 sda1[2] sdd1[1]
292969216 blocks [2/1] [_U] [>....................] recovery = 0.6% (1829440/292969216) finish=74.2min speed=65337K/sec

unused devices: <none>

That’s all there is to it.  Things get a bit more complex if you are working on your root volume, but in my case I was simply mirroring one of my data volumes.

As an aside, setting up a mail server that uses fetchmail to gather email from the various accounts you have, and using a smarthost configuration to send email does give you most of the benefits of running your own mail server with very few headaches.  The reason to do this might be that you don’t want to trust Google (or someone else) to hold all your email, and/or you don’t want the individual PCs in your house to be the storage for your email (hard to migrate to a new machine, recover from disaster).  This is how I started down the path of running my own true email server. [I keep thinking that someone should create an easy to install NAS add-on that provides exactly this type of email server]

Ok, maybe you don’t want to run your own email server but you’re interested in knowing what is involved… Having a static IP address is handy, mostly to save you from DNS issues.  While you can manage to have a domain name tied to a dynamic IP, many blacklists include the IP ranges used by ISP for dynamic addresses.  Of course you need a domain name, and a DNS server too.  You might also want to consider a secondary MX record, in case your connection goes down.  You’ll also want to check that your ISP isn’t blocking port 25 outgoing, and having a valid reverse DNS is important too.

So you’ve followed the Ubuntu documentation and setup a mail server, great.  Assuming your IP address is “clean” (ie: not on a blacklist), then you can probably send email just fine.  Until you start hitting problems where spam filters have taken a dislike to your system – in my case it was Rogers (email provided by Yahoo) that treating my outgoing as spam.  One solution is to have the recipient add your email address to their address book so they do still get to see your email.  It may still get tagged as [Bulk] but it won’t get lost.  This isn’t a great solution for someone new you want to contact, or a friend who isn’t terribly technical.

It turns out there are some additional measures you can take on the email server side to add more trust.  There are three I’ve implemented:

• Sender Policy Framework (SPF)
• Domain Keys Identified Mail (DKIM)
• Domain Keys

All of them rely on the same basic ‘trick’ of adding a TXT record to your DNS information that serves to validate the email.  This works for the simple reason that spammers tend to use botnets made up of machines without valid DNS records.  SPF simply is a declaration that the IP address sending the email is allowed to send email for the specified domain.  DKIM is an updated version of DomainKeys, but both can be used concurrently and some systems only know one.  Both DKIM and DomainKeys have the email server sign the email with a secret (private) key, and the DNS record has a public key that will validate the signature.

After implementing all three, it turns out Yahoo was still tagging my email as spam.  Very frustrating.  One solution I did consider was to avoid the problem entirely and selectively smarthost email going to rogers.com (and yahoo.com, etc).  In the end, it turns out that Yahoo maintains their own blacklist of sorts and you can request to be removed.  To check this, you need access to a yahoo email account that you can send test messages to.  By examining the header you will see X-YahooFilteredBulk if your IP is on their blacklist, this appears to be independent of the status of your SPF/DKIM/DomainKeys authentication that should show as a pass.  The solution is to fill in the Yahoo form, and be persistent.  Much of the form will not apply but you do need to fill it in with something reasonable (and valid).  After a couple of exchanges over several days I was rewarded with this reply:

While we cannot fully exempt your mail server from our SpamGuard
technology, we have however, made appropriate changes to this IP address
in our database. This should help with delivering mail to the
appropriate Yahoo! folders.

Now email sent to yahoo.com is not tagged as spam or [Bulk] – I did a little victory dance once this happened.

The remainder of this post goes into some of the details of getting the three (SPF, DKIM, DomainKeys) implemented.

(...)
Read the rest of Earning Trust for Your Email Server (341 words)