Tales From The Geek Side

I’ve been a bit disappointed with the performance of my system for a while. I run an sd11g5 from shuttle which is a Pentium M based machine. I run it diskless. I read the NFS howto and decided to try increasing the rsize and wsize parameters when mounting my filesystems. Normally when I boot my PC I start it up and walk away. I have gdm configured to automatically log me in (it’s a home machine, don’t give me crap about security). I wanted to watch the kernel output today to see if anything different happened with the rsize and wsize options set at 32768. I saw something which really surprised me. I saw a 100 Mbps link negotiation. I should have been getting a 1000 Mbps link. I know that I used to.

After rebooting the switch a few times and verifying that it wasn’t the switch I headed back to my PC. I did some googling and then it dawned on me – it could be the cable. I wired my entire house with cat6 cable but I didn’t worry about having cat6 for patch cables (although most are because I’ve made them from the 60 feet of spare cable that I have). Sure enough I saw only 6 wires terminated on the patch cable I’ve been using for a VERY long time. Gigabit ethernet requires all 8 wires. I think, to keep myself sane, I should throw out that patch cable (but I won’t because I’m cheap and because I have a couple 100 Mpbs devices on my network).

My machine is performing much better than it has for quite some time. I don’t know how much of an effect the rsize/wsize tuning made because I’m sure the speed increase from 100 Mbps to 1000 Mbps far overshadows a block size improvement. Still, I’m curious so at some point I will probably remove the rsize/wsize parameters and see if the machine is noticably slower.

For a long time I’ve had OpenVPN on my todo list. My wife’s primary computer is a laptop running Debian and it would be nice to VPN into the home wired subnet from the home wireless subnet.

For my router I have a LinkSys WRT54G. On this I’m running OpenWRT. I’ve “broken the bridge” between the wireless interface and the wired interface so I have a separate subnet for my wireless network. I did this primarily because I didn’t want to expose my NFS exports to a wireless network using WEP. I don’t have any WPA capable devices but even if I did I still prefer having a separate subnet for the wireless devices.

On the other hand I WOULD like to have access to the NFS exports as well as Myth TV in a secure fashion. I looked into running openswan on OpenWRT (white russian release) but didn’t have any luck. After doing more research I decided that OpenVPN makes more sense for my situation anyhow. I don’t want to run a computationally intensive app on the WRT54G. I can run OpenVPN on more powerful machines in my network.

I installed OpenVPN on my file server using apt-get. I wanted a simple way to get up and running and finally settled on reading the Open VPN 2.0 Howto. Of course I wasted a bunch of time trying to do shortcuts but in the end I had to read that document. Not only did I have to read it but I had to read it carefully.

I wanted to setup the VPN server to support multiple clients even though I’ll likely only use one client. There is a slight chance that I might issue client keys to friends that bring their laptops over but it’s unlikely. Either way it’s better to learn the “right way” of doing things.

The basic steps for setting up the server are:

1. Create a Certificate Authority. This sounds complicated but it’s not because a script comes with OpenVPN to create it for you. The Certificate Authority, which everyone likes to abbreviate with CA, is a file.
2. Build Diffie Helman parameters for the server.
3. Create a server key signed by the Certificate Authority created in step 1.
4. Create client keys signed by the Certificate Authority created in step 1.

To create the Certificate Authority (based on my Debian system):

$ cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/keys
$ cd /etc/openvpn/keys
$ $EDITOR vars
$ source vars
$ ./clean-all
$ ./build-ca

To build the Diffie Hellman parameters:

$ ./build-dh

To create a server key

$ ./build-key-server

To create client keys

$ ./build-key

Next you need to copy the default server.conf file and make a few modifications. On Debian the default server config file is located in /usr/share/doc/openvpn/examples/sample-config-files/serv.conf.gz. Uncompress the file and place it in /etc/openvpn. Some of the changes you may need to make are:

• dropping of priviledges – this should be turned on
• paths to the various key files

The OpenVPN init script will find all of the config file in /etc/openvpn and load each of them. Initially you will probably want to run the server directly for easy viewing of output (e.g. `#openvpn server.conf`). If you have trouble you main get extra insight by increasing ‘verb’ setting in the config file.

In my next post about OpenVPN I’ll discuss my network configuration and the steps required to get routing working correctly.

Last night I upgraded my custom built 2.6.17 kernel to the Debian built 2.6.18 kernel.  I had to do this because I run XFS and I was getting directory corruption.  This is a known bug in 2.6.17 that I covered in a previous post.

The most critical role of my file server is that of a MythTV backend.  I have a PC HDTV-3000 card and a PVR-150 card for DTV and analog tuners.  After repairing my corrupted file systems and installing the Debian provided ivtv-modules-2.6.18 package I found that I couldn’t tune my analog stations anymore.   In fact I found that the backend was crashing whenever I tried to view the tuner status in the information section from any frontend in the house.  It turns out the problem was that my drivers are loading in a different order now.  My PVR 150 card used to be /dev/video0 but has become /dev/video1 (or vice-versa).  A quick change in mythtv-setup fixed the problem and now I’m off and running again.

I was very happy to discover that Debian provides ivtv binary packages now.  I do not have to build any software for my backend machine now!  For the frontend I still have to build lirc-modules but I can live with.

I’ve always been annoyed that mythtv-setup is a GUI application.  It’s a tool to configure the backend.  The backend doesn’t need a GUI.  I would really prefer to edit a text file.  Oh well, you can’t have everything (for free!).

It seems that very few people comprehend how powerful C and C++’s sizeof operator really is. People insist on using sizeof on typenames. Folks, you don’t have to do that!

Typical code:

struct foo *f = malloc(sizeof(struct foo));

The way it should be written:

struct foo *f = malloc(sizeof(*f));

As you can see in the example above you can even dereference a pointer to get the correct size. What about dynamically allocating an array? That’s elegantly written like this:

int *array = malloc(sizeof(array[0]) * 44);

Using variables instead of types with sizeof is simply more robust. If you change the type of a variable you do not need to change your use of sizeof in anyway.

Generally speaking sizeof operates strictly at compile time. That means that anything that the compiler knows the size of will work with the sizeof operator. With C99 there is at least one case that I know of where sizeof is actually dynamic. In C99 you can declare “dynamic” arrays.

int dyn(int numElements) { int dynArray[ numElements]; int x = sizeof(dynArray); }

The example above will not compile in C++ and in most C compiler unless the C compiler supports C99. In the example above there is no way for the compiler to know the size of dynArray at compile time because numElements isn’t known until execution of the function. Regardless, with a C99 compliant compiler the code above will produce correct results.

So go forth and use sizeof on variable names, not on type names!

* Sorry about the crappy formatting. I’m battling the rich editor built into wordpress.

On my MythTV backend machine I run XFS file systems. Not too long ago I updated the system in an effort to finally start using the HDTV tuner card that I purchased a year prior. At that time the ivtv drivers for my PVR 150 tuner card required kernel 2.6.17 so I merrily built 2.6.17 and life has been good.

I’ve recently been testing a SATA controller card. The onboard SATA on my motherboard has a firmware bug that causes disk corruption when copying large data sets between drives. It’s an Abit NFS-7s that I bought used. I could upgrade the BIOS to fix this bug but I’m afraid to! My wife and I use MythTV nearly every day and we’d both be upset to go without it. I’m afraid that the BIOS upgrade process would fail and I’d be forced to buy a new motherboard when I really don’t want to. Also this machine acts as an NFS root for my desktop machine and my Myth frontend machine.

The XFS bug came to my attention while testing a SATA card to correct the firmware bug mentioned above. I have two 300G drives and I use rsnapshot to keep incremental backups. Because of the firmware bug I wasn’t able to do this and my spare 300G drive has sat idle for quite some time. My backups have been to a smaller IDE drive. To test the SATA card I’ve been using the spare 300G drive as the backup disk. With the onboard controller I found corrupted file systems very quickly. With the new controller I thought I was free from corruption until I ran xfs_check on the backup partition.

xfs_check found a handful of problems with directories. Googling I found this page from SGI that describes the bug. The bug exists in 2.6.17 and was fixed in 2.6.17.7.

I built a new 2.6.17.14 kernel to correct the XFS problem and I’ll hopefully run xfs_repair this evening on all of my file systems. Version 0.3 of the excellent System Rescue CD includes xfsprogs new enough to handle the problem. This bug bit me because I was using XFS and because 2.6.17 was required for the PVR 150 card.

Edit: I think I’ll probably use the 2.6.18 kernel from Debian. I also see that Debian has an ivtv-modules-2.6.18-4-686 package as well which should be perfect. I’d much rather use stuff from Debian than build things myself.