Spork Bomb

Outside the ordered universe is that amorphous blight of nethermost confusion which blasphemes and bubbles at the center of all infinity—the boundless daemon sultan Azathoth, whose name no lips dare speak aloud, and who gnaws hungrily in inconceivable, unlighted chambers beyond time and space amidst the muffled, maddening beating of vile drums and the thin monotonous whine of accursed flutes...

Azathoth lives! It feels good to be back on a sensible operating system. I built Azathoth for just under £500 (including postage), which I think is pretty good. As an aside, monitors are incredibly expensive, if the spare monitor living under my bed worked, I'd have saved myself over £100.

Azathoth will assimilate the functions of Cthulhu, but with the added memory and processor speed, I imagine I'll be using it for a bit more number crunching; perhaps F@h or something. I picked a microATX case for two reasons: save space in my room, and portability. When I go to university, I can fit the computer, keyboard, and mouse in a backpack. The monitor isn't so transportable, alas. This also means if I want to, say, take it to someone else's house, I can do with relative ease.

Hardware

Case:

Antec Minuet 350

Processor:

AMD Athlon II X2 (3GHz)

Motherboard:

Gigabyte GA-MA78LM-S2 (AM2+ socket)

Memory:

4GB Corsair TwinX DDR2 (1066Hz)

Monitor:

23" Digimate L-2362WD (1920x1080, HD 1080P)

Storage

Recycled HDD from Cthulhu; 250GB SATA

I also bought a slew of cables and other little bits and pieces.

Post-construction notes

There were a few issues upon booting up as, well, Arch expected to be on a laptop. However, despite having completely different hardware, the only thing to fail utterly was Xorg, and that was my fault. As soon as I removed my xorg.conf, it started up fine, at the screen's native resolution of 1920x1080 (incredible). I was pretty impressed with Arch's ability to handle massive hardware changes with so few complaints.

Whilst I was trapped in Windows-land, linux 2.6.33 was released to Archers through testing which, amongst other things I haven't really noticed yet (:P), works perfectly with early-start radeon KMS; do you know how amazing a 1920x1080 framebuffer appearing as soon as Arch starts to boot is? It's most amazing.

In addition to graphics being wonderful, this motherboard is pretty great, too. Support for up to 8GB of RAM and 12 USB ports should keep me happy for several years to come. The only thing I'm (slightly) worried about is USB 3.0, which could become pretty widespread over the next few years, possibly meaning I'd need to get a USB 3-capable motherboard to keep up with new peripherals. One thing I do miss from Cthulhu is the SD card reader, I've ordered a USB one, but until that arrives I'll be a bit stuck if I need to read any SD cards which, thankfully, isn't a very common occurrence.

Photos

My laptop, Cthulhu, is, alas, dreaming. In my laptop bag currently, not quite as grand as his sunken city of R'lyeh, but it'll have to do for now.

On Friday (February the 26th), there was a graphical glitch in the morning. After using it for a while, the screen flickered and distorted, and black vertical bars appeared on the screen. The laptop was then completely frozen (graphically, at least). So, I did the first thing that came to mind: leave it and see if it goes away.

Later in the day, the same thing happened again, again shortly after turning it on. This time, I tried it with an external monitor to see if it was a problem with the LCD, but unfortunately it wasn't. So I took it apart to see if anything was overheating, but there was barely any dust in it. I tried booting into different OSes, to check if it was a software problem but, alas, no. Every time I booted, it happened a little sooner.

And now it happens more or less immediately after booting, it's a hardware problem, and the graphics are built-in to the motherboard, so I'd need to get a new motherboard to fix it. In a great departure from tradition, I've opted to build myself a desktop rather than spend a fortune on a new laptop.

This new desktop rising from the ashes of Cthulhu, shall be named... Azathoth!

Greetings, legion of MPDDP users, there is another update! With it, MPDDP has been bumped to version 2.0.1, as the configuration file format is the same, so things will keep working, but the “update” keyword no longer does anything.

But why? I used that feature, how dare you deprive me of it!?

Well, allow me to explain…

The “update” keyword was, really, not very good. It worked by telling MPDDP to enable a silly behaviour whereby it reloaded the configuration and rules every so many minutes. This produces unnecessary disk accessing (albeit not much of that), and CPU load when querying MPD for tracks and figuring out which ones we can use (which can be a lot, MPDDP 2 isn't terribly efficient yet). All in all, it was a Bad Thing. But it was the only way to notice changes in configuration without restarting MPDDP 2, which is very slow depending on how many rules you have enabled.

Depending on how many rules you have enabled? I thought it depended on how many rules you had!

Well, yes, it did. That's the second thing I have changed. MPDDP 2 will now only figure out what tracks are allowed for the allowed rules, not all of them. This speeds up starting MPDDP 2 massively. Anyway, back to signals…

…fast forward to today, when I'm skimming through wikipedia and end up on the article for POSIX signals. I then learn that dd prints progress information when sent SIGUSR1 (yes, I too was amazed) and a thought hit me: why can't I do the same with MPDDP 2? So, off to the Python documentation for signals I went and now MPDDP 2 has some nice new behaviour:

• SIGUSR1 tells MPDDP 2 to reload the configuration but not the rules.
• SIGUSR2 tells MPDDP 2 to reload the rules but not the configuration.

Individually, you can use them for things like changing the length of the playlist, with SIGUSR1, and editing the conditions of a rule, with SIGUSR2. Together, you can change which rules are active.

I think this is a very elegant solution. We've gone from checking continuously to see if something has happened, to waiting to be notified that something has happened. After editing the config file, it's only a little extra effort to send MPDDP 2 the appropriate signal(s), and you're not getting unrequired disk/CPU usage every few minutes just in case you changed something.

I discovered this wonderful thing yesterday, nbd is, simply, a way of sharing block devices over a network. I currently have my server rsyncing to a backup HDD attached to my laptop.

NBD comes in two parts, the client and the server. The server sits on the host machine, listens for NBD network requests, and translates them into standard filesystem calls. The client sits on the client machine and is used to control the nbd kernel module. It's remarkably simple to share a device, for example:

# On the server:
nbd-server $port /dev/sdb1

# On the client:
modprobe nbd
nbd-client $ip $port /dev/nbd0

And voila, /dev/sdb1 on the server is now accessable on the client as /dev/nbd0. I used this method to partition my new HDD over the network using gparted, unfortunately parted gives an error message after every change complaining that the kernel hasn't re-read the partition table, so you can only do one thing at a time. I should really learn how to use parted properly…

I wrote a helper script to share devices between my laptop and server:

function nbd()
{
    device=""
    port=2000
    host=""

    if [[ -z "$3" ]]; then
        if ifconfig wlan0 &>/dev/null; then # On my laptop
            host=eihort
        else                                # Not on my laptop
            host=192.168.1.64
        fi
    else
        host=$3
    fi

    # Allow specifying a device file, name, label, or UUID.
    if [[ -e "$2" ]]; then
        device=$2
    elif [[ -e "/dev/$2" ]]; then
        device="/dev/$2"
    elif [[ -e "/dev/disk/by-label/$2" ]]; then
        device="/dev/disk/by-label/$2"
    elif [[ -e "/dev/disk/by-uuid/$2" ]]; then
        device="/dev/disk/by-uuid/$2"
    else
        echo "Unknown device '$2'" 1>&2
        return 1
    fi

    if [[ "$1" == "share" ]]; then
        sudo nbd-server $port $device
    elif [[ "$1" == "gain" ]]; then
        sudo nbd-client $host $port $device
    elif [[ "$1" == "free" ]]; then
        sudo nbd-client -d $device
    else
        echo "Unknown method '$1'." 1>&2
        return 2
    fi
}

So, with a simple nbd share M2HDb and nbd gain nbd0, I can share my backup device :)

I've been having some problems with the old(ish) 80GB HDD I've been using with my server—it developed bad sectors which made any disk-related operation (even (un)mounting partitions on different physical devices, for some reason) incredibly slow. I'm not exaggerating when I say that rebooting took about 45 minutes to an hour. Also, the bad sectors caused loads of error output to be logged and, as I thought a 5GB root partition would be more than enough, that quickly filled causing more problems…

So, yesterday I ordered a 160GB 2.5" SATA HDD, and it arrived today. I barely used any of the 80GB one, so I'm not sure what I'll do with 160GB… It took me about six hours to migrate from the old HDD to the new. If it wasn't so slow on (un)mounting, it'd have taken me about an hour, needless to say, today has been very frustrating.

…but, dear gods! I can't believe how much that HDD was slowing things down! I only really noticed it in mounting and doing large read/writes, but the whole thing is just so much faster! Of course, some of that will be due to changing to a SATA HDD from an old ATA one, and perhaps from using ext4 on most of the partitions instead of JFS, but the difference is really amazing. Things I had attributed to a limitation of my network speed—such as copying large numbers of files back and forth—now soar along. It's incredible really.

With a large disk, I decided to split up the whole into many partitions, so it's less likely for, say misbehaving log files, to grind the system to a halt. Also, I wanted to play with ext4, I've used JFS as my filesystem of choice for so long now I don't remember my initial reasons for doing so, but when I did settle on it, ext4 hadn't entered the mix so JFS might not be the best for me any more… But, I couldn't bring myself to fully leave JFS behind, so I settled on this partitioning scheme:

• /boot: 128MiB, ext2
• /: 15GiB, ext4
• /home: 15GiB, ext4
• /usr: 15GiB, ext4
• /var: 15GiB, ext4
• /srv: 100GiB, JFS

Of course, /srv isn't really 100GiB, but you know what I mean. The remaining space after 60ish GiB had been used for other things.

A short while ago I was looking at the Arch wiki article for installing a system with software RAID and LVM, it looks pretty simple. I've always imagined RAID and LVM as incredibly complex beasts only understandable by server admins. But, well, I am a server admin (albeit for a server with about three users), and it didn't seem too complex. So, at some point in the future when I have money and time to waste, I'll consider getting another two HDDs and setting up RAID 5 or something. I'll probably be on a new motherboard before then, though, as the one I'm using at the moment has only two SATA ports (and one PCI port, which is likely to be a more imminent limitation).

I have designs to, by the end of the year, have transformed my server into a much more powerful beast. Watch this space…