Linux

One of my chores this weekend was to reconfigure a server to convert the Mailman mailing list manager already installed to support virtual domains. I've been using this package ever since its early releases, but it's been several years since I've reviewed what's changed.

One of the greatest limitations of Mailman has been its "virtual domain" support. That's where a single server supports mailing lists that live under different domains, such as list1 [at] example1 [dot] com and list2 [at] example2 [dot] com.

Unfortunately, the virtual domain support hasn't improved recently.

Here is how Mailman supports virtual domains, at least when using the Postfix mail transport. When you want to setup a mailing list called listname, you create an alias file entry that says something like:

This takes incoming email messages sent to listname and feeds then into the Mailman system.

My media center PC is an ASUS bookshelf computer running Ubuntu Linux and KDE desktop. I use it primarily for music, running the Amarok music player.

Our house is pretty small and open. I can see the entire living room from my desk. I often play music on the media system while I'm working. The annoying bit is that I have to get up from my desk and walk over to the living room anytime I want to fiddle the controls.

I wish I had a good way to control the music from my desk. I've been puzzling over this for a whilte. I've tried various ways to control Amarok remotely and none were satisfactory. Then it dawned on me that I was missing the obvious: I didn't want to control just the media player but the whole desktop. I can do that using something like Virtual Network Computing (VNC).

In December, I made a RAID 1 network storage server by adding a cheap SATA controller and a couple of 500GB hard disks to chinacat. For the most part, it has worked great, but there is one hiccup.

First the good news: the network storage server is working every bit as well as I had hoped and everything that I'd hope to do is falling into place. All of our media files are now consolidated in one place. All of our desktop systems are (finally!) being backed up. Plus, there are all the other groovy benefits of having a shared storage server in the house.

I started the benchmark series because I was concerned with the performance of Linux software RAID. My test results suggested that performance would be acceptable. My real world results underscore that. For a while, I even moved my home directory off of the primary hard drive onto the slower RAID 1 device. I ended up moving it back not because of performance, but to build a more reliable backup architecture.

In a previous blog entry, I discussed strategies for snooping out wi-fi hogs. Unfortunately, when I went out to cast my net, the only fish pulled in was myself. It turns out the approach I described doesn't work on my laptop, an Inspiron 600m with Intel 2200BG wireless network controller (ipw2200 driver).

In a shared network technology such as wireless Ethernet, the network controller typically picks out just the packets addressed to it, ignoring everybody else's traffic. Some controllers can be placed into promiscuous mode. In this mode the controller accepts all packets, so a program can monitor all the traffic on the network.

The ipw2200 driver doesn't provide a simple promiscuous mode, so the solutions I described don't work.

I've found two workarounds.

First, I can switch the wireless Ethernet controller from "Managed" to "Monitor" mode with a command such as:

iwconfig eth1 mode Monitor

Then, I can launch a program such as Wireshark to monitor the traffic.

Today's Holidailies writing prompt is, "What is your favorite Linux distribution?" Seeing that I'm the person who contributed that prompt (albeit kind of in jest) I suppose I should answer it.

I don't have just one favorite Linux distribution. My favorite depends on the application.

For desktop systems, I am using the Kubuntu Linux distribution. It's a variant of the widely used Ubuntu Linux distribution. I like the Ubuntu family of distributions because of the robust development activity and the large number of applications available. I'm using Kubuntu on my main workstation chinacat, my laptop hepcat, and my living room media computer coldsnap. It's a good fit for all those situations.

My project last weekend was to build a Linux storage server for my network. Sunday, I discussed benchmarking SATA controllers under Linux. Yesterday, I discussed some considerations for using Linux software RAID. I explained why a mirrored disk drive array (RAID level 1) might best suit my needs, but I had concerns about the performance.

So, I thought I'd run some benchmarks to determine whether the mirrored configuration would be a good choice. Today, I'll discuss the results.

Here are my test conditions:

• SIIG SC-SAT212-S4 dual-port SATA controller
• two Seagate ST3500631NS 500GB SATA disk drives
• ASUS A8N-VM system board
• AMD Athlon 64 X2 3800+ (dual core 2.4GHz)
• Ubuntu 7.10 Linux
• bonnie++ disk benchmark program

Here is the procedure I used to run the tests:

My project last weekend was to build a Linux storage server for my network. Sunday, I discussed benchmarking SATA controllers under Linux, and my discovery that a cheap SATA controller actually performed a smidge better than the one built into my system board. The add-on controller gave me enough ports to proceed and build the RAID. Today, I discuss my considerations for building the RAID.

As I mentioned previously, I had a pair of server-grade Seagate ST3500631NS 500GB SATA disk drives to use. My goal was to build the storage server using the Linux software RAID capability.

My performance needs were modest. My home network is primarily wireless. Even if I do go wired, which is my eventual plan, it doesn't take a lot of disk performance to keep an Ethernet connection filled up.

Therefore, my priorities, in order, were: reliability, cost, and performance as a distant last.

As quick review, Redundant Array of Inexpensive Disks (RAID) is a technique for arranging multiple hard disk drives for either increased performance, increased reliability, or a combination of both.

My project for the weekend was to build a Linux storage server for my network.

I picked up a pair of ST3500631NS (server-grade 500GB SATA) disk drives from Newegg at a very good price ($119 apiece). I want to add them to chinacat, my main workstation, preferably in a redundant mirror.

Unfortunately, when I opened the computer case I discovered my system board only had two SATA ports. I needed one port for my system disk, two more for the new drives. For some reason I had thought my system had four ports, but it didn't. I was coming up short.

So it was time for plan B. I decided to try adding more SATA ports with an add-in controller card.

I picked up an inexpensive SATA controller at Fry's for $40, a SIIG SC-SAT212-S4. This is a PCI card with two internal SATA ports.

I debated between this card and a more expensive alternative. I was concerned that the bottom-of-the-line card would result in lower disk performance and higher CPU overhead. I decided to give this card a shot. I could run some benchmark tests and return it if it proved unsuitable.

Some time back I upgraded hepcat, a Dell Inspiron 600m laptop, from Ubuntu Dapper to Ubuntu Feisty, skipping over the Ubuntu Execrable release. I've been pleased with how Feisty runs on my laptop with one exception: I didn't understand the big deal about NetworkManager. Seems like DoNothingManager might be a better name.

Then based on a comment I saw over at the Ubuntu Forums site, I edited the /etc/group and manually added myself to the netdev group. (Also powerdev for good measure.)

Once I did, I was amazed. The NetworkManager is awesome. Not only does it make it easy to lock onto and log into the wireless network of your choice, it even switches over to the wired network when you dock. This facility runs rings around the Windows network managers I've seen.

I don't know if this group file change is documented anywhere, but it's really important. Without it you could be missing out on one of the best parts of the Feisty upgrade.

For the past couple weeks, I've been running Ubuntu Feisty Fawn, the version of Ubuntu Linux scheduled for release next month. Actually, I'm running Kubuntu—the flavor with a KDE desktop. So, just mentally add the "K" throughout this post.

Earlier this month, the hard drive on my primary workstation chinacat developed some bad blocks in critical areas. I replaced the drive and bravely decided to go ahead and load the pre-release version of Ubuntu. Fortunately, it's been remarkably robust. The system has been in heavy use I've only found a few minor bugs—which is remarkable for pre-beta software. The Ubuntu developers have responded quickly to my bug reports.

I've been impressed at how robust the Feisty applications and controls seem to be. Especially the desktop and system adminstration. One of the most difficult Linux administrative chores is adding printers. It can be bad enough just trying to add a simple printer hanging off a USB. My situation is even more difficult. I've got a couple of printers on a dedicated server, I want to use the lpd protocol to connect to the server, and I want to provide two queues for each device (one that processes the printing and one that provides a raw device). The GUI administration tool handled all this with ease.

I'm beginning to think the Ubuntu project may have taken a bad turn a year ago and Feisty represents a turn to recovery. A year ago, Ubuntu Dapper Drake was issued as a Long Term Support (LTS) release. They promised this release would have a longer lifetime, with full patch and security bugfix support through 2009, instead of the usual 18 months.

I realize that in retrospect there were two problems with this LTS release. First, LTS targets data centers more than desktops. One signficant part of this release was enhanced server support. This all sounds great, but it's not the Ubuntu sweet spot. If I want a robust, stable server, I'm going to choose Debian or Red Hat Linux, not Ubuntu. I understand that the Dapper release was an attempt to address that, but I think that's a poor choice. Ubuntu shines on the desktop, and given limited resources, maybe Ubuntu leaders should focus there instead of trying to be all things to all applications. I fear that the LTS effort may have been a distraction from providing a good desktop release.

The second problem is that it took a lot of work to get this LTS release out. Ubuntu normally runs on a six month release cycle. The Dapper release was slipped two months to get it all together. The next release, Edgy Eft, was done on a compressed four month schedule. Maybe that's why the Edgy release sucked so bad.

Every system that I upgraded to Edgy had significant problems. My workstation chinacat could not sync my calendar and contacts to my Samsung SPH-i500 PalmOS phone. My media computer coldsnap lost its wireless, and I had to build the network driver from source. The only Ubuntu computer I had that didn't have problems with Edgy Eft was my laptop hepcat—and that's because given the serial catastrophes of Edgy, I left it at Dapper.

All these problems had me concerned about the future of Ubuntu. Thanks to the promising results of Ubuntu Feisty Fawn, I'm a believer again.