Jul 162014
 

I’ve found the netatalk available in Wheezy (version 2.2.2) to be flakey for a while now. Even Jessie only has 2.2.5, while the latest from netatalk.sourceforge.net is 3.1.3. My specific problem was intermittently failing time machine backups from the Macs in my house. Netatalk helpfully includes directions on compiling netatalk from source on Wheezy here, but I don’t like to have all those dev packages on my fileserver, which means spinning up a build host, creating a deb, yada yada yada. Anyway, no point in going to all that bother and not sharing it.

First make sure you remove the old version: # apt-get remove –purge netatalk

Install the pre-requisites: # apt-get install libdbus-glib-1-2 libmysqlclient18 mysql-common libcrack2 avahi-daemon

Download this: netatalk_3.1.3-1_amd64.deb

And install it: # dpkg -i netatalk_3.1.3-1_amd64.deb

Netatalk v3 uses an entirely new config format, so you’ll have to recreate your config files (hence why we used –purge above). It’s actually way easier to configure now though, so don’t fret too much.

Big important note: I’m providing this purely as a convenience. I accept no liability and provide no guarantees. Use at your own risk.

 Posted by at 8:37 PM
Feb 142014
 

I recently turned up a new RAID array and plopped an XFS filesystem down on it. I didn’t bother setting any specific tunings when I created the filesystem. However I couldn’t for the life of me export any subdirectories from the volume over NFS. Local access was fine and I could export via netatalk and samba.

On the server I saw messages like this in the logs:

Feb 14 13:08:43 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.50:1003 for /mnt/music (/mnt/music)
Feb 14 13:08:57 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.50:1002 for /opt/music (/opt/music)
Feb 14 13:15:19 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:717 for /mnt/music (/mnt/music)
Feb 14 13:15:20 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:1001 for /mnt/music (/mnt/music)
Feb 14 13:15:22 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:1002 for /mnt/music (/mnt/music)
Feb 14 13:15:26 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:801 for /mnt/music (/mnt/music)
Feb 14 13:15:34 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:967 for /mnt/music (/mnt/music)
Feb 14 13:15:44 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:794 for /mnt/music (/mnt/music)
Feb 14 13:15:54 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:855 for /mnt/music (/mnt/music)
Feb 14 13:16:04 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:863 for /mnt/music (/mnt/music)
Feb 14 13:16:14 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:932 for /mnt/music (/mnt/music)
Feb 14 13:16:24 monolith rpc.mountd[3092]: authenticated mount request from 192.168.1.20:830 for /mnt/music (/mnt/music)

On the client I would get two different behaviours, depending on whether it was NFSv4 or NFSv3 that was being used. With NFSv4 it would mount the directory, but any attempt to read from it would give a ‘Stale NFS handle’ error:

root:~# mount -t nfs -v 192.168.1.10:/mnt/music /mnt/
mount.nfs: timeout set for Fri Feb 14 16:49:39 2014
mount.nfs: trying text-based options 'vers=4,addr=192.168.1.10,clientaddr=192.168.1.20'
root:~# ls /mnt/
ls: cannot open directory /mnt/: Stale NFS file handle

With NFSv3 it would just time out, although if I used the -v switch I could see that it was timing out because it was getting ‘Stale NFS handle’ errors during the attempt to mount the directory:

root:~# mount -t nfs -o nfsvers=3 -v 192.168.1.10:/mnt/music /mnt/
mount.nfs: timeout set for Fri Feb 14 16:51:29 2014
mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.1.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
<SNIP>
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.1.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.1.10 prog 100005 vers 3 prot UDP port 60925
mount.nfs: mount(2): Stale NFS file handle
mount.nfs: Connection timed out

After much frustrated googling I finally stumbled across the answer: inode64. By default NFS still exports 32bit inodes, and XFS by default uses 64bit inodes. There are a few workarounds that worked for me:

1) Export the root of the filesystem and not subdirectories. If you’re in a high trust environment this might be a reasonable solution. However you might not want to export everything on your filesystem, in which case you should look at option 2.

2) You can also manually set the fsid option for each exported subdirectory like this:

/mnt/music 192.168.1.0/24(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,fsid=1)
/mnt/pictures 192.168.1.0/24(rw,async,wdelay,insecure,no_root_squash,no_subtree_check,fsid=2)

I’ve tested both of the above with the following clients: Ubuntu 13.10, FreeBSD 9.2, and Mac OS X 10.9. I don’t actually have any older clients to test with at the moment.

 Posted by at 4:55 PM
Nov 032013
 

I wanted a new system to run as my router, so I set out to find a small system with at least three gigabit NICs. I settled on a Jetway NF9H-525 (also referenced as a NF9HQL-525), which is a mini-ITX board geared for networking applications with four onboard gigabit NICs and a dual core atom 1.8Ghz processor.  I also purchased an LGX MC500 case, two gigabytes of RAM, and pulled a drive out of a recently retired laptop. Bottom line: everything worked great and I would recommend it.

The board has four onboard realtek gigabit NICs (RTL8111/8168B) which use the re driver. They’re not the beloved Intel em NICs, but they’ll do. Especially for the types of applications this board is likely to be used for – like my home networking. Same deal with the intel atom processor. The system can be a bit louder than I would have really liked, but the fan speed stepping does work so it’s only loud when it’s under a bit of load.

I’m not going to bother including any build notes, mostly because I didn’t encounter any gotchas or oddities during the installation or configuration of the system. I read reports online that the NICs require a recent version of FreeBSD, but I didn’t have any issues with 9.2-RELEASE.

Oct 312012
 

For the second time now I’ve had an Asus EN9600GT catch fire on me. The first time was a few years ago when I first built my media centre. At the time the media centre was on but wasn’t actually doing anything, when suddenly there was a loud pop and flames shooting out the back of the computer. I RMA’d the device, which is a needlessly painful process with Asus, and installed the replacement.

This evening I was logged into the media centre from another computer and running an update on it (I run MythTV). Suddenly, progress seems to stop. I turn on the TV, and there’s nothing there. I try to power cycle the media centre to no effect. Finally I pull out the computer and pull off the cover – nothing is happening. I pull the power cord, give it half a minute, plug it back in and try again. Fire.

The burned component

The burned component

The first one was far more spectacular than this one. But regardless, I certainly don’t need the extra expense and hassle of having to rebuild or replace my media centre right now.

 Posted by at 10:48 PM
May 142012
 

I’ve been struggling with a pair of issues with forked-daapd recently. I’ve managed to fix one of them for the time being. In particular, with recent versions of iTunes forked-daapd was dropping out after about 5 minutes of audio. I found the issue in the bug tracker on github, and found that some people has taken some stabs at patching the problem. One of them actually succeeded (though no one appeared to be able to post a working .deb).

I used the guide How to: Recompiling / Rebuild Debian / Ubuntu Linux Binary Source File Packages and the patch listed in this comment to sort out the problem. On Debian Testing here are the steps to follow to recreate the solution:

# apt-get install build-essential fakeroot dpkg-dev
# cd /usr/src/
# apt-get source forked-daapd
# apt-get build-dep forked-daapd
# dpkg-source -x forked-daapd_0.19gcd-2.dsc
# cd forked-daapd-0.19gcd/src/
# cp httpd_daap.c httpd_daap.c.bak
# wget https://raw.github.com/kekiefer/forked-daapd/77dc0fd2f466a02b86582ed2c5f97ea6e444f2ac/src/httpd_daap.c
# cd ..
# dpkg-buildpackage -rfakeroot -b
# cd /usr/src
# dpkg -i forked-daapd_0.19gcd-2_amd64.deb

You’re just recompiling the regular debian package but with an updated httpd_daap.c source file. You can also just download the .deb here.

 Posted by at 7:48 PM