At the time I was working from home, using a VPN tunnel to the office, connected to a Telekom V-DSL with a buggy Speedport Router. Hence my first suspect was a DNS issue and, indeed, the setps descibed here fixed the problem.

Anyone familiar with my recent Telekom issues understands why DNS was the obvious pick (there might be a comprehensive rant about that subject if I ever feel like talking about that experience).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import os, sys, subprocess

def check_version (output):
    packages = output.split("\n")
    # get rid of the suspicious additional last element (a single "\n")
    for p in packages[:-1]:
        info = p.split()
        if info[1] == "<":
            # cron will take care of sending the mail from here
            print p

null = open(os.devnull)
try:
    subprocess.check_call(["portsnap", "fetch"], stdout=null)
    subprocess.check_call(["portsnap", "update"], stdout=null)
    check_version(subprocess.check_output(["pkg_version", "-v"]))
except subprocess.CalledProcessError as e:
    print "*** ERROR ***"
    print e.output
null.close()

Which always returned none although I was sure there was an outdated package installed on the system, plus the script worked perfectly when run interactively (not from cron). After fiddling around a lot with environment and path settings in crontab, I decided to get the actual output of the 2 portsnap commands. This eventually provided the clue … portsnap fetch is not supossed to be run from cron and actually checks for that! A quick look in the according man page revealed the secret:

1

$ portsnap cron

which waits between 1 and 60 minutes before actually fetching the updates. So the final solution is now broken down in two parts (providing even basic privilege separation).

A crontab entry (root):

1

0 1 * * * /usr/sbin/portsnap cron > /dev/null && /usr/sbin/portsnap update > /dev/null

and a checker script (user):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

import subprocess

def check_version (output):
    """
    checks the output of 'pkg_version -v' for outdated packages
    """
    packages = output.split("\n")
    # get rid of the suspicious additional last element (a single "\n")
    for p in packages[:-1]:
        info = p.split()
        if info[1] == "<":
            # cron will take care of sending the mail from here
            print p

try:
    check_version(subprocess.check_output(["pkg_version", "-v"]))
except subprocess.CalledProcessError as e:
    print "*** ERROR ***"
    print e.output

In my opinion a classical case of RTFM … and yes, I know, all of the above can be condensed and my exception handler is exceptionally bad.

The Ubuntu Server distribution that has been running this server broke … again. Only a couple of months after I did a clean install, I dared to upgrade the system from 11.04 to 11.10, or at least I tried …

… unfortunately the machine turned out to be unreachable after the upgrade. So I had to physically log into my server just to find out the network was down, although the configuration didn’t change during the upgrade. A little debugging and a couple of reboots later, the network still wouldn’t start automatically - yet another incident in a series of Linux fails over the last year or so. Kubuntu desktop starts shipping version 4 and by that turns unusable. After switching to Ubuntu (and thereby Gnome), I had a sort-of working desktop system for a couple of months (I never liked Gnome, but it seriously was the better choice at the time). Then Ubuntu decides to drop Gnome in favour of something called “Unity”. An intersting approach, maybe a great choice on a netbook, but nothing more than a study on desktop concepts. After trying differnt flavours of Linux Mint and re-checking the current status of Kubuntu I’m now stuck with a broken Ubuntu for my Linux work, a Linux that is good enough to sshfs to my projects and do the actual desktop work on my MacBook.

Equipped with a great deal of frustration, not so much about the Linux kernel but the crappy userland and bad decisions made by distributors, I decided to step back a couple of years and install FreeBSD. Back in the days as a student I fiddled around with a couple of BSD flavours and had, among other things, an OpenBSD firewall and a FreeBSD file server. Eventually I decided against BSD back then, because I was experimenting with those systems a lot, mainly installing and uninstalling packages the whole day. This is something the ports collection, BSD’s preferred way of dealing with software packages, is not exactly helpful with. On the other hand, now I was looking for something well defined with as little maintenance as possible, so FreeBSD seemed like a natural choice.

The current system is running:

• FreeBSD 8.2-RELEASE
• lighttpd
• Octopress
• No MySQL (PostgreSQL, …)
• No PHP

And here’s a list of things I like about the new setup:

• Installation of a base system leaves with just that, a base systems
• Output of ps aux fits on a single screen (including 8 lines getty)
• Output of netstat fits on a single screen
• Config files are where the package’s documentation claims they are
• Searching the web for a technical issues turns up actual results (not 30+ hits to forums filled with people complaining about their Linux not behaving like Windows)
• Updating the systems doesn’t require a reboot twice a week because a new kernel shipped
• many more little details that just make me happy :-)