*BSD vs Linux for Home Server

I have a few simple needs for my home server - it needs to be stable, functional on older hardware (P4 2GHz with 1 or 2 GB of RAM) and run a few simple applications:

• rtorrent (for... ahem... legitimate torrent requirements)
• irssi - the bestest IRC client (and the one I've spent ages getting a nice config file for)
• screen (for teh awesomeness!)
• SSH - for remote work, and for sshfs so I can rsync and backup data remotely
• and a bit of storage space - 100GB is nice
• nagios - monitoring work sites as required
• DHCP
• DNS

Currently I'm running Ubuntu 10.04.3 LTS on a P4 3GHz USDT HP that has a noisy fan in it and I'm going to migrate back to my Dell P4 2GHz box that I was running before. It has a slower processor, is quiet and reliable. It's also more power efficient than the current one. I've been considering getting my hands on an Atom powered box or the like with very low power requirements for home. After all this server really doesn't have to do a lot or work - it just needs to chug quietly away and provide the basic services I need. So why change?

Well several reasons I guess. Security is the big one. Reliability is the next one. A rolling distribution would be handy too - one with easy, in place, headless upgrades.

Most Linux variants will support the apps I listed, as will FreeBSD and DragonFly BSD, my two preferred BSD variants (even though I've had great success with OpenBSD on my Sun Blade - see earlier posts). I'm thinking FreeBSD may be the option to go with, so I'm playing with it under VMware Player at the moment. DragonFly's HAMMER files system is mighty attractive though, so I'm thinking very carefully about this choice. I'll keep notes on my adventure as it goes forward.

HTC Aria Review

After the unmitigated disaster that is the Motorola Backflip I have very fortunately managed to get my hands on the HTC Aria. Although this device is aimed at a mid market it's a wonderful little bit of kit. OK so first up the hardware.

The device itself is quite compact and fits in the palm with ease. I find that I can put it in the same case I had my e66 in without worry and it fits easily. The screen takes up the majority of the Aria with 4 capacitive buttons and a swipe mouse thing as well. Only a few external buttons - volume up/down and the lock/on/off switch. Under the black casing is a brightly coloured interior which is quite striking. The screen itself, which I read elsewhere as being not as bright as the OLED type screens is nonetheless bright and readable. I find it better than my iPhone 3GS to read. The keyboard works relatively well and the device is easy to use.

The built in HTC themes and widgets are superb and I've found that I don't need to add any extra widgets for a lot of the stuff I used on the Motorola.

DG834 resolved - v5 is where it's at

After much wrangling, I didn't get the Netcomm to work properly, the VPN was still no good and I was unable to get VOIP running across it. Fortunately I ran into an old buddy and he suggested using the v5 of the Netgear router. Lo and behold, it uses a Conexant chipset, not Broadcomm and I put two in, one at either end. Both have been very stable, no dropouts and the VPN works perfectly.

Following this small victory I then deployed one at home and it's working fantastically well. I've been hammering it too so it's all going along nicely and my VPN is working properly too.

While the Netcomm is undoubtedly a powerful device, the lack of configuration in the VPN side of things and the fact it won't send VOIP data properly are big strikes against it. I've redeployed one of these routers elsewhere and the user loves it so that's a win and no financial loss on my part.

The love affair with Netgear is renewed!

Things I'd like to see on the iPhone

The number one thing I'd like to see on the iPhone is to be able to turn push mail on and off according to time automatically. My venerable e66 had this - it would check my mail faithfully throughout the day between 8am and 6pm and then stop. It did wonders for the battery life and for my sleep patterns. If I inadvertantly forget to disable this when I go to bed, nagios wakes me up as it's monitoring failing servers or systems.

In fact, the ability to have auto on/off dependent on time is something that the iPhone could apply to a bunch more things too - like changes of ringtones etc. It's probably too hard to do for Apple so as my old dad says - wish in one hand and pee in the other and see which hand fills up the quickest!

The other thing I'd like is for a slightly more robust design, but hey - you can't have everything. My Motorola Backflip (MB300) is more rugged and seems to go pretty well.

Netcomm NB8WVPN and the Netgear DG834

After the woes I've experienced with the DG834 I cast about looking for a replacement device. It needed to be a decent ADSL 2+ router (with built in modem) and support site-to-site VPN tunnels - none of this VPN pass through garbage. After looking around a bit, I found the NB8WVPN from Netcomm which promises all sorts of things about how wonderful it is etc etc. So I purchased two and set them up at one of my problem sites - both ends. Now each of these sites has an Alcatel-Lucent phone system that use a VOIP link to put calls through to each other. Naturally this VOIP link has to go across a VPN.

With the VPN established between the two sites, I had some connectivity between them - that is, I could ping and browse the network etc but the phone systems couldn't talk to one another. The initial part of the VOIP signalling goes through, but the call itself doesn't. Remarkably frustrating I must say. After alterations to the phone systems (and I must add: the VOIP worked perfectly over the Netgear VPN) we got partial signalling through.

Eventually I put the stable Netgear back in and here's where it gets tricky. When I created the VPN between the NB8WVPN and the DG834 I had to make it quite basic. No Perfect Security or anything like that. Also, in the Advanced settings on the NB8, I had to change the settings to SHA-1 from it's original setting. Once this was all done I got a VPN back up! Yay! Before I performed jumps of joy, I tested it with my trusty sidekick. He could call me (from the Netgear side) but couldn't hear me and I couldn't call him from the NB8 side. The support on this is very sketchy out there. I was surprised by how little there is about these routers out there. I eventually upgraded the firmware on the NB8 and it's nearly time to test.

The good thing out of all this is, that the VPN was able to carry data like pings (ICMP) NetBIOS queries and various TCP streams like HTTP. It just doesn't seem to like the VOIP signalling. Additionally I found it very useful to disable the QoS on the Netcomm's. I tested the VOIP signalling by using two Linux notebooks with extra NIC's bridged and running Wireshark to see what was happening. I now need to go back to site and test it all.

Netgear DG834 woes

For quite some time I've used the Netgear DG834 as my router of choice, particularly as a low end router providing easy site-to-site VPN's. These little white routers will support up to 5 VPN tunnels and have proven themselves to be quite reliable under most circumstances.

Unfortunately, I think I've discovered the circumstances that these routers do not work well under. I have two sites under my management that have had no end of trouble with these routers. Here is the situation and the symptoms:

• both sites are ADSL2
• both sites have a single VPN connection to them as the responder
• both sites have appropriate ADSL2+ capable filters and short cables etc
• both sites drop their ADSL connection (not line sync) after 13 to 16 days and then fail to reconnect.
• A restart of the device (soft or hard) and the connection will stay up for anywhere between 5 and 16 minutes - whatever the time length is, it will always die after that time e.g. if it's 10 minutes, then it will lose connection every 10 minutes.
• both lines have been tested (and charged to the end user) by the carrier and the wholesaler and no line problems have been found. There are some very mild anomalies but nothing that should cause these sorts of issues
• both routers have the latest firmware, have been reset to default and still show the same errors.

Netgear have shown no willingness to engage with me on this issue. After calling them four times and speaking with four different 1st level techs I can't get them to acknowledge that the routers might have a problem. Mind you, it's only 2 routers out of 40+ that I have in place out in the real world. Replacing the routers with devices running different hardware results in a stable connection again so it's not the lines! Once everything has been eliminated as points of failure, the final location of the problem is the Netgear Router. So I've had to replace them and that's the subject of my next entry.

Tips and Tricks: Monitoring with NTOP and IFTOP

For monitoring networks I have an old GX260 Dell desktop in the small form factor. Packed into this little device are a couple of network cards, added on are a wireless NIC and an extra USB network device. The purpose? To slot this in between the router and the network and see what's going backwards and forwards - very useful in the situation where a client is hemorrhaging bandwidth and doesn't know why. I'm running Ubuntu 10.04 LTS on it and it behaves very well.

Two of the main tools I use are ntop and iftop. For those of you not familiar with them, ntop monitors a particular interface and creates some nice webpages to be checked by the user in order to see what's going on through the network. iftop is similar but real time and is available through a console - which is the real appeal for me.

The server in question has two internal NICs, both are 100MB cards and are scripted to come up as a transparent bridge - br0. Basically I monitor that bridge and use one of the other interfaces to see what the server is seeing. Here is the script I use (adapted from elsewhere) to bring the bridge up:

#!/bin/bash
PATH="/sbin:/usr/sbin:/usr/local/sbin";
slaveIfs="1 2 3 4 6 7 8 9 10";
cmd="$1";
[ -z "$cmd" ] && cmd="start";
case "$cmd" in
  start)
    brctl addbr br0;
    brctl stp br0 on;
    brctl addif br0 eth1;
    brctl addif br0 eth2;
    (ifdown eth1 1>/dev/null 2>&1;);
    (ifdown eth2 1>/dev/null 2>&1;);
    ifconfig eth1 0.0.0.0 up;
    ifconfig eth2 0.0.0.0 up;
    ifconfig br0 up ### Adapt to your needs.
    ;;
  stop)
    brctl delif br0 eth1;
    brctl delif br0 eth2;
    ifconfig br0 down;
    brctl delbr br0;
    #ifup eth0; ### Adapt to your needs.
    #ifup eth1; ### Adapt to your needs.
    ;;
  restart,reload)
    $0 stop;
    sleep 3;
    $0 start;
    ;;
esac;

It resides in /etc/init.d and is called (imaginatively) bridge.sh and then has appropriate symlinks to rc2.d.

NTOP
NTOP is reasonably easy to configure on Ubuntu and is quite straightforward to get going - point it at http://localhost:3000 and set your username/password and off you go.

A tip to remember is that in the /etc/default/ntop it's a good idea to uncomment GETOPT="" and change it to read (if your network was 192.168.0.0/24):

GETOPT="--local-subnet=192.168.0.0/24"

and restart NTOP. Why is this important I hear you ask? Well on the br0 interface there is no IP assigned to it so NTOP doesn't automatically figure out what the local network is. By assigning this you can set it up to get proper info on local-remote, remote-remote and local-local traffic. Then leave it to run and see what it tells you.

IFTOP
Ah iftop is such a nice little bit of software. apt-get install it and then run it from the console with iftop -i br0 and it will tell you all sorts of things - data going from here to there and the level of bandwidth being used. I fancy pants it up a bit by creating a shell script and then launching it from there. iftop will use .iftoprc by default and if there isn't one will simply launch with it's own defaults. Here is the shell script I use (again I have adapted this from someone else):

#!/bin/sh

# customisable settings
LOCALNET="192.168.0.0/24"
IFACE="br0" # the bridged interface
CONF="/etc/iftoprc"

/usr/sbin/iftop -p -n -N -i $IFACE -F $LOCALNET -c $CONF

where /etc/iftoprc looks like this:

dns-resolution: yes
port-resolution: yes
show-bars: yes
promiscuous: no
port-display: source-only
#hide-source: yes
#hide-destination: yes
use-bytes: yes
sort: 2s
#line-display: one-line-both
show-totals: yes

Most of these are self-explanatory and I believe you should examine them more closely if you are looking to deploy it. Suffice to say, it gives me the info I want and I'm happy with that setup. So I hope that gives you some food for thought and you can take some of this away with you when you're trying to find out what the hell is chewing up all your bandwidth and download limit!