[Or "my quest for the ultimate home-brew storage array."] At my day job, we use a variety of storage solutions based on the type of data we’re hosting. Over the last year, we have started to deploy SuperMicro-based hardware with OpenSolaris and ZFS for storage of some classes of data. The systems we have built previously have not had any strict performance requirements, and were built with SuperMicro’s SC846E2 chassis, which supports 24 total SAS/SATA drives, with an integrated port multiplier in the backplane to support multipath to SAS drives. We’re building out a new system that we hope to be able to promote to tier-1 for some “less critical data”, so we wanted better drive density and more performance. We landed on the relatively new SuperMicro SC847 chassis, which supports 36 total 3.5″ drives (24 front and 12 rear) in a 4U enclosure. While researching this product, I didn’t find many reviews and detailed pictures of the chassis, so figured I’d take some pictures while building the system and post them for the benefit of anyone else interested in such a solution.

Updates:
[2010-05-19 Some observations on power consumption appended to the bottom of the post.]
[2010-05-20 Updated notes a bit to clarify that I am not doing multilane or SAS - thanks for reminding me to clarify that Mike.]

In the systems we’ve built so far, we’ve only deployed SATA drives since OpenSolaris can still get us decent performance with SSD for read and write cache. This means that in the 4U cases we’ve used with integrated port multipliers, we have only used one of the two SFF-8087 connectors on the backplane; this works fine, but limits the total throughput of all drives in the system to 4 3gbit/s channels (on this chassis, 6 drives would be on each 3gbit channel.) On our most recent build, we built it with the intention of using it both for “nearline”-class storage, and as a test platform to see if we can get the performance we need to store VM images. As part of this decision, we decided to go with a backplane that supports full throughput to each drive. We also decided to use SATA drives for the storage disks, versus 7200rpm SAS drives (which would support multilane, but with the backplane we’re using it doesn’t matter), or faster SAS disks (as the SSD caches should give us all the speed we need.) For redundancy, our plan is to use replication between appliances versus running multi-head stacked to the same storage shelves; for an example of a multi-head/multi-shelf setup, see this build by the local geek Mike Horwath of ipHouse.

When purchasing a SuperMicro chassis with a SAS backplane, there are a few things you should be aware of..

1. There are different models of the chassis that include different style backplanes:
• ‘A’ style (IE – SC847A) – This chassis includes backplanes that allow direct access to each drive (no port multipliers) via SFF-8087 connectors. In the SC847 case, the front backplane has 6 SFF-8087 connectors, and the rear backplane has 3 SFF-8087 connectors. This allows full bandwidth to every drive, and minimizes the number of cables as much as possible. Downside, of course, is that you need enough controllers to provide 9 SFF-8087 connectors!
• ‘TQ’ style – not available for the SC847 cases, but in the SC846 chassis an example part number would be ‘SC846TQ‘. This backplane provides an individual SATA connector for each drive — in other words, you will need 24 SATA cables, and 24 SATA ports to connect them to. This will be a bit of a mess cable-wise.. with the SFF-8087 option, I don’t know why anyone would still be interested in this – if you have a reason, please comment! This is quite a common option on the 2U chassis – it can actually be difficult to purchase a 2U barebones “SuperServer” that includes SFF-8087 connectors.
• ‘E1′ style (IE – SC847E1) – This chassis includes backplanes with integrated 3gbit/s port multipliers, without multipath support. Each backplane has one SFF-8087 connector, so you only need two SFF-8087 ports in a SC847E1 system. The downside is that you are limited to 3gbit/s per channel – so you’d have a total of 6 drives on each 3gbit/s channel for the front backplane, and 3 drives on each channel for the rear backplane. SuperMicro also has a ‘E16′ option (IE – SC847E16) which is upcoming, and supports SATA3/SAS2, for a total of 6gbit/s per channel.
• ‘E2′ style (IE – SC847E2) – Similar to the SC847E1, this includes a port multiplier on the backplane, but also supports multipath for SAS drives. Each backplane has two SFF-8087 connectors. Same caveats as the E1 apply. They also have a ‘E26′ version coming out soon (IE – SC847E26) which will include SAS2 (6gbit/s) multipliers.

I do wish that SuperMicro would offer a “best of both worlds” option – it would be great to be able to get a high amount of bandwidth to each drive, and also support multipath. Maybe something like a SAS2 backplane which only put two or three drives on each channel instead of six drives? If they did two drives per channel with a port multiplier, and supported multipath, it should be possible to get the same amount of total bandwidth to each drive (assuming active/active multipath), and still keep a reasonable number of total SFF-8087 connectors, plus support multipath with SAS drives, and get the bonus of controller redundancy. If anyone knows of an alternate vendor or of plans at SuperMicro to offer this, by all means, comment!

2. You can also choose the type of expansion slots you would like to support on the motherboard tray; you will need to match the tray to the type of motherboard that you purchase. Note that these are the same options available on their 2U chassis – the concept of the SC847 chassis essentially makes your motherboard choices the same as the 2U systems.
• ‘UB’ option (IE, SC847A-R1400UB) – this option supports SuperMicro’s proprietary UIO expansion cards. It uses a proprietary riser card to mount the cards horizontally, and will support 4 full-height cards and 3 low-profile cards in the SC847. They get the card density by mounting the components for one (or more) UIO cards on the opposite site of the PCB than you usually see – the connector itself is still PCI-E x8, but the bracket and components are all on the opposite side. I have not ordered a chassis that uses UIO recently, so I’m not sure if the sample part number would include riser cards or not. Note that you will need to purchase a SuperMicro board that supports UIO for this chassis.
• ‘LPB’ option (IE, SC847A-R1400LPB) – this option supports 7 low-profile expansion slots. If you do not have any need for full-height cards, this gives you the maximum number of high-speed slots. This is the option you will need to go with if you want to use a motherboard from a vendor other than SuperMicro.

For the system I’m building, we went with the following components:

• SuperMicro SC847A-R1400LPB chassis – 36-bay chassis with backplanes that offer direct access to each drive via SFF-8087 connectors. 7 low-profile expansion slots on the motherboard tray.
• SuperMicro X8DTH-6F motherboard – Intel 5520 chipset; supports Intel’s 5500- and 5600- series Xeon CPUs. Has an integrated LSI 2008 SAS2 controller, which supports 8 channels via two SFF-8087 ports. 7 PCI-E 2.0 x8 slots. 12 total memory slots. IPMI with KVMoIP integrated. Two Gig-E network ports based on Intel’s newest 82576 chipset. This board is great.. but what would make it perfect for me would be a version of the board that had 18 memory slots and 4 integrated Gig-E ports instead of two. Ah well, can’t have it all!
• 2x Intel E5620 Westmere processors
• 24gb DDR3 memory; PC3-10600, registered/ecc.
• 4x LSI 9211-8i PCI-E SAS-2 HBA – 2 SFF-8087 ports on each controller; same chipset (LSI 2008) as the onboard controllers. This gives me a total of 10 SFF-8087 SAS2 ports, which is one more than needed to supports all the drive bays. I should also note that we haven’t had any problems with the LSI2008-based controllers dropping offline with timeouts under OpenSolaris; with our other systems, we started with LSI 3081E-R controllers, and had no end of systems failing due to bug ID 6894775 in OpenSolaris, which as far as I’m able to tell has not yet been resolved. Swapping the controllers out with 9211-8i’s solved all the issues we were having.
• Variety of SuperMicro and 3ware SFF-8087 cables in various lengths to reach the ports on the backplanes from the controller locations.
• 2x Seagate 750gb SATA hard drives for boot disks.
• 18x Hitachi 2TB SATA hard drives for data disks.
• 2x Intel 32gb X25-E SATA-2 SSD’s; used in ZFS for a mirrored Zero Intent Log (ZIL); write cache. (Note: 2.5″ drives; needs a SuperMicro MCP-220-00043-0N adapter to mount in the hot-swap bays.)
• 1x Crucial RealSSD C300 128gb SSD; used in ZFS for a L2ARC read cache. (Also a 2.5″ drive; see note above.)

We purchased the system from CDW, with our own customer-specific pricing. I’m not allowed to share what we paid, but for your reference, I’ve whipped up a shopping cart at Provantage with (essentially) the same components. There is no special pricing here; this is just the pricing that their web site listed as of May 8 2010 at 11:18am central time. Note: I have no affiliation with Provantage. I have ordered from them previously, and enjoyed their service, but cannot guarantee you will have a good experience there. The prices here may or may not be valid if you go to order. You may be able to get better pricing by talking to a customer service rep there. I also had to change a few components for parts that Provantage did not have available – namely some of the various lengths of SFF-8087 cables. I error’d on the side of ‘long’, so it should work, but I haven’t built a system with those exact cables, so can’t guarantee anything.

As you can see, the total price for this system came out at just under $8500, or $8717.14 shipped. Not bad at all for a high-performance storage array with 18 2tb data drives and the ability to add 13 more.

If we do decide that this is the route to go for our VM image storage, the config would be similar to above, with the following changes at minimum:

• More memory (probably 48gb) using 8gb modules to leave room for more expansion without having to replace modules.
• Switch from desktop HDDs to enterprise or nearline HDDs (6gb SAS if they are economical); probably also go with lower capacity drives, as our VMs would not require the same amount of total storage, and NexentaStor is priced by the terabyte of raw storage.
• Add more (either 4x or 6x total, still used in pairs of 2) X25-E’s for ZIL/SLOG, possibly also go with 64gb instead of 32gb. (More total drives should mean more total throughput for synchronous writes. If Seagate Pulsars are available, also consider those.
• Add additional RealSSD C300’s for cache drives; the more the better.
• Add additional network capacity in the form of PCI-E NIC cards – either 2x 4-port Gig-E or 2x 10-GigE. This will allow us to make better use of IPMP and LACP to both distribute our network load among our core switches and use more than 2gbit total bandwidth.

In any case, on to some pictures of the chassis and build.

Front of the chassis – 24 drive bays up front.

Rear of the chassis – 12 drive bays, and a tray for the motherboard above them. Also shows the air shroud to direct airflow over the CPUs; the only part of the chassis that feels cheap at all.. but it serves its purpose just fine.

System with the motherboard tray removed. Note that as far as the mounting is concern the tray is pretty much the same as a standard SuperMicro 2U system. You’ll need to order heatsinks, cards, etc that would work in a 2U.

View of the system from the back with the motherboard and four front fans removed. You can see a bit of the front backplane in the upper right; two of the SFF-8087 connectors are visible. All cable routing goes underneath the fans; there is plenty of room under the motherboard for cable slack. You can also see the connectors that the power supplies slide into on the upper left hand corner, and a pile of extra power cables that are unneeded for my configuration underneath that.

Another shot of the front backplane. You can see the five of the six SFF-8087 connectors (the other is on the right-hand side of the backplane which is not visible.) Also note the fans that I’ve removed to get better access to the backplane.

One of the power connectors that the fans slide into (white four-pin connector near the center of the picture); the SFF-8087 connector that is not visible in the picture above is highlighted in red.

Motherboard tray before installing the motherboard. This tray uses a different style screw system than I’ve seen before; instead of having threaded holes that you screw standoffs into, they have standoffs coming up off the bottom (one highlighted in blue), which you screw an adapter onto (highlighted in red) which the motherboard rests on and is secured to.

A partial view of the rear backplane on the system; also the bundle of extra power cables and the ribbon cable connected to the front panel.

Labels on one of the power supplies. This system includes a pair of ‘PWS-1K41P-1R’ power supplies, which output 1400W at 220V or 1100W at 120V.

Motherboard installed on tray, with the four LSI SAS HBAs in their boxes.

One of the two Intel E5620 ‘Westmere’ Xeon processors set in motherboard but not secured yet.

Both processors and 24gb of memory installed. No heatsinks yet.

Motherboard tray complete and ready to be installed in the system. Heatsinks and LSI controllers have been installed. Note the two SFF-8087 connectors integrated on the motherboard, and eight more on the four controllers.

Prep work on the rear backplane; the chassis shipped with the power cables pre-wired; I connected the SFF-8087 cable.

Motherboard tray installed back in the system; SFF-8087 cables connected to three of the four LSI controllers. I ended up moving one controller over for ease of cabling – notice the gap in the middle of the four controllers.

(Note: The pictures of the finished system below this point were taken on 5/7/2010; thanks to my coworker Colleen for letting me borrow her camera since I #natefail‘d to bring mine!)

The seven cooling fans to keep this system running nice and cool.

HBAs with all cables connected.

Finished system build with the top off. One power supply is slightly pulled out since I only have a single power cable plugged in.. if you have one cable plugged in but both power supplies installed, alas, the alarm buzzer is loud.

Front hard drive lights after system is finished – note that we don’t have every drive bay populated yet.

Rear drive lights while system is running.

The build-out on the system went fine for the most part; the only problem I ran into is that the motherboard did not have a BIOS installed which supported the relatively new Westmere processors. Fortunately I had a Nehalem E5520 I could borrow from another system to get the BIOS upgraded.. I wish the BIOS recovery procedure would work for unsupported processors, but ah well. I was pleased with the way the motherboard tray slides out; it makes it easy to get the cabling tucked underneath and routed so that they will not interfere with airflow. There also seems to be plenty of airflow to keep the 36 drives cooled.

I currently have NexentaStor 3.0 running on the system; we have not yet landed on what operating system we will run on this long-term.. but it will likely either be NexentaCore or NexentaStor. If we deploy this solution for our VM images (with some upgrades as mentioned above), we will almost certainly use NexentaStor and the VMDC plugin, but we’ll cross that bridge if we get there!

Here’s the disk configuration I have running at the moment with NexentaStor:

• ’syspool’: Mirrored ZFS zpool with 2×750gb Seagate drives.
• ‘NateVol1′: ZFS zpool with..
• 2 RaidZ3 arrays with 8 2TB disks each
• 2 2TB disks set as spares
• 2 36gb Intel X25-E SSDs as a mirrored log device
• 1 128gb Crucial RealSSD C300 as a cache device

..and the obligatory screenshot of the data volume config:

This nets 18T usable space, and would allow for a simultaneous failure of any three data disks before there is any risk of data loss. (Each of the sub-arrays in ‘NateVol1′ have 3 parity disks – so I could also lose 3 disks from each of the sub-arrays without any issues.)

Again, this system only has two Gig-E NICs at the moment.. I’ve done I/O tests with NFS across one NIC and iSCSI across the other NIC, and can max out the bandwidth on both cards simultaneously with multiple runs of Bonnie++ 1.96 without the system breaking a sweat. I like! I should also note that this is with both deduplication and compression enabled.

Another note – before putting this into production, I did some simple “amp clamp” power usage tests on the box, with one power supply unplugged. The other power supply was plugged into 120V. While idling, it consumed 3.3A, and while running multiple copies of Bonnie in the ZFS storage pool (with all active disks lighting up nicely), it consumed 4.1A. Not bad at all for the amount of disk in this machine! I’d estimate that if the 13 additional drive bays were occupied with 2TB disks, and all those disks were active, the machine would consume about 5.5A – maybe slightly more. When we racked it up at the data center (in one of our legacy racks that is still 120V), the power usage bumped up by 3.2A combined across the A+B power, which matches nicely with my clamped readings. I’m very impressed – under 500 watts while running full out.. wow.

I will update this post once we decide on a final configuration “for real” and put this into production, but so far I’d highly recommend this configuration! If you’ve used the SC847 chassis, I’d love to hear what you’ve thought. I’d also love to try out the 45-bay storage expansion version of this chassis at some point – talk about some dense storage! :)

Related posts:

1. Sun adds block-level deduplication to zfs
2. Sun’s Unified Storage 7210 – designed to disappoint?
3. new backplane in my drive array

I recently had the opportunity to set up a few Nehalem based servers at SoftLayer to replace some older hardware that we were using.. and these servers /rock/. The servers have the E5520 CPU’s, and kick the snot out of the E5430’s that they replaced. We were able to actually able to replace 6 dual-5430’s with 4 dual-5520’s, and lower our costs significantly (by about 25%) — which is nice!

However, I did run into one problem while installing Debian Lenny (5.0) on these systems. The problem is that the on-board Intel Gig-E adapters (PCI ID 8086:10c9) are not supported in the 2.6.26 kernel which Lenny ships with – d’oh! If you are not planning on using Xen on your system, you could install the 2.6.29 kernel from Unstable; however, in my case, I wanted to use Xen, and there is no Xen dom0 support in 2.6.29. I was able to overcome this by re-building Debian’s 2.6.26 kernel (rev 2.6.26-13) with the most recent version of the igb drivers from Intel’s web site.

If you have a similar server and don’t want to go through the same pain I did, read more for directions on how to do this!

Here are the steps to install, assuming that you’re using a KVM-IPMI interface that supports virtual media:

1) Install a base system using the ‘netinstall’ or first install disc from Debian. [amd64] [i386]

2) On a different machine, download the updated kernel image which you would like to use from my web site. Please only download the image(s) you intend to use to conserve bandwidth.

3) Create an ISO image that contains the kernel image you would like to use. On a Linux system, the following command would do the trick:

genisoimage -o ~/iso/nehalem-kernel-images.iso -J -R linux-image-[whatever]

4) Select the generated ISO image using the IPMI interface, and mount it on your guest. Then, install the new kernel with:

dpkg -i linux-image-[whatever]

5) Reboot, and you should be running the new kernel!

When I built these kernel images, I updated the subrelease to ‘999′ to try to ensure that future Debian updates would not overwrite them. I would recommend watching the Debian bug for this issue, and manually install the patched Debian kernel when it comes available.

Note: These kernels are provided with no warranty. I’ve provided the source I used to build the kernels so you can verify that they only contain the updated igb driver. If you have issues, feel free to comment, and I will try to help you out, but cannot guarantee anything. The kernels may or may not be updated to include security patches as they come available.

Related posts:

1. virtuozzo on nehalem systems at softlayer
2. debian on an inspiron 6000
3. How to compile Nvidia kernel modules on 2.6.20+ with paravirt_ops enabled

In my previous post, I discussed how to get automatic procmail integration working with Plesk, to let you set up procmailrc rules to sort mail into folders. At the end of the post, I mentioned that it would be nice to figure out how to get Plesk’s version of Ingo set up to generate the rules for us automatically. Well, turns out it’s pretty easy! Once you set up procmail (as described in my previous post), and make the changes after the break to your Ingo config, any filters that users define via Plesk’s Horde/Imp/Ingo implementation will become server-side rules automatically. It’s surprisingly easy, and extremely versatile! The one downside is that if you edit the procmailrc files by hand, and then save rules in Ingo, your changes will be overwritten.

First, you need to set a password for the ‘popuser’ user, and remove the user from ‘/etc/ftpusers’. This will allow Ingo to FTP into the system as that user, and update procmailrc entries.

Then, you need to edit the Ingo config. For some reason, Plesk 9’s Ingo package for Debian has config files in two locations:
/etc/psa/webmail/horde/ingo/backends.php
/etc/psa-horde/ingo/backends.php

I’m not sure which one actually gets used, so I created a symlink:

# rm -f /etc/psa-horde/ingo/backends.php
# ln -s /etc/psa/webmail/horde/ingo/backends.php /etc/psa-horde/ingo/backends.php


Then, we need to edit this file. There should be a default entry that looks like:

/* IMAP Example */
$backends['imap'] = array(
'driver' => 'null',
'preferred' => 'localhost',
'hordeauth' => true,
'params' => array(),
'script' => 'imap',
'scriptparams' => array()
);


That’s not going to do anything for us, so nuke it. Then, copy and paste the entry below:


$split = explode('@', Auth::getAuth());
$backends['procmail'] = array(
'driver' => 'vfs',
'preferred' => 'localhost',
'hordeauth' => 'false',
'params' => array(
'vfstype' => 'ftp',
'hostspec' => 'localhost',
'filename' => '/var/qmail/mailnames/'.$split[1].'/'.$split[0].'/.procmailrc',
'port' => 21,
'username' => 'popuser',
'password' => 'password'
),
'script' => 'procmail',
'scriptparams' => array(
'path_style' => 'maildir',
'variables' => array(
'MAILDIR' => '/var/qmail/mailnames/' . $split[1] . '/' . $split[0] . '/Maildir',
'DEFAULT' => '${MAILDIR}/'
)
)
);


Simply change the password entry to the password you set for popuser. Then, log out of webmail and back in, set up a filter, and it should have updated the procmailrc entry for you. It’s magic!

Again, if this is useful or if you have any questions, please leave me a comment!

Related posts:

1. Using Procmail with Plesk
2. per-user spamassassin preferences in ldap with mimedefang
3. using advanced routing to control traffic across your interfaces

For many years now, I’ve been maintaining a separate mail server, web server, and shell server. I’m getting busy these days, and just don’t have the time to dedicate to this maintenance. About a year and a half ago, I purchased a 30-domain Plesk license, which I am using for all the sites I host for friends and family, but I haven’t cut my own sites over to it yet. I’m finally getting to the point where I want to stop having to worry about all the VM’s, and thinking about moving my sites and e-mail over to Plesk. The one big downside for me is that Plesk, by default, does not support server-side mail sorting or filtering. I am on about 50 different mailing lists, etc, and really don’t want to have to deal with sorting out that e-mail by hand. So, I did a bit of searching, and found that there are ways of getting Plesk to use Procmail – here are a few blog posts that discuss the subject:

http://www.russwittmann.com/2007/07/14/server-side-mail-filtering-using-qmailprocmail-under-plesk/
http://rackerhacker.com/2007/11/27/sort-e-mail-in-plesk-with-procmail/

In my case, I am not using Plesk’s built-in spam filtering (instead, I’m fronting it with Maia Mailguard – if you are curious on how to get that working, comment, and I’ll write a post on it someday), so the spam part of this really doesn’t apply for me.. but the posts do describe how to get procmail working. The one big downside is that it isn’t done automatically — any time the account is updated via Plesk, the .qmail file will be overwritten, and you will need to edit it by hand to get things working again. One of the posts suggests making it immutable, but, well, that’s a pain in the rear too. ;)

I wrote a quick script that will run through this setup for you, and then set up Plesk’s event handlers to call this script after an account is created or updated. My system is Plesk 9.0.0 on Debian 64-bit, using Postfix as the MTA — even though it’s Postfix, Plesk calls a virtual mail delivery agent that still uses the .qmail files. If you are interested in how this works, read more!

Without further ado, here is the script that I am using to auto-update the .qmail and .procmailrc files. Save this as /usr/local/sbin/add-procmail-rules.pl, and then read through the comments and make any updates that are needed.

### — start of add-procmail-rules.pl ###

#!/usr/bin/perl -w
#
# Plesk event handler script to use procmail for mail delivery instead of
# Plesk's default mail handler.
#
# By Nate Carlson
# http://www.natecarlson.com
use strict;
#
# Basic configuration, in case Parallels changes where Plesk stores stuff.
my($topdir) = "/var/qmail/mailnames";
my($qmailcfg) = ".qmail";
my($procmailcfg) = ".procmailrc";
my($maildir) = "Maildir";
#
# First, sleep for 5 seconds to make sure that Plesk has finished writing
# out it's configuration to the .qmail file
sleep(5);
#
# Grab the e-mail address from Plesk's NEW_MAILNAME variable, and split
# it into user/domain parts.
my($emailaddress) = $ENV{'NEW_MAILNAME'};
my($user,$domain) = split(/\@/, $emailaddress, 2);
#
# Verify that we were able to split NEW_MAILNAME into user/domain parts;
# die if not.
if(!$user || !$domain) {
print "NEW_MAILNAME was not valid!\n";
exit 1;
}
#
# Set the user directory; die if it does not exist.
my($userdir) = "$topdir/$domain/$user";
if ( ! -d "$userdir") {
print "User directory $userdir does not exist.";
exit 1;
}
#
# Make sure the qmail cfg file exists
if (! -f "$userdir/$qmailcfg") {
print "User does not have a dot-qmail file; exiting.";
exit 1;
}
#
# Read in old qmail cfg file
open(OLDQMAILCFG, "<$userdir/$qmailcfg");
my(@oldqmailcfg) = ;
close(OLDQMAILCFG);
#
# Rename the old file for a backup copy
rename "$userdir/$qmailcfg", "$userdir/$qmailcfg.old";
#
# Write out our custom .qmail file, only changing the deliverquota line
# to procmail.
open(QMAILCFG, ">$userdir/$qmailcfg");
#
my($oldline);
foreach $oldline (@oldqmailcfg) {
chomp($oldline);
if ($oldline =~ /deliverquota/) {
print QMAILCFG "| /usr/bin/procmail -m -o .procmailrc\n";
} else {
print QMAILCFG "$oldline\n";
}
}
close(QMAILCFG);
#
# If the procmail file does not already exist, write out a totally base
# config file. If you want to move tagged spam to a different folder,
# you will need to update this. If it already exists, leave it alone.
if (! -f "$userdir/$procmailcfg") {
open(PROCMAILCFG, ">$userdir/$procmailcfg");
print PROCMAILCFG "MAILDIR=$userdir/$maildir\n";
print PROCMAILCFG 'DEFAULT=${MAILDIR}/' . "\n";
close(PROCMAILCFG);
}
#
# Get the right ownership of these files
system("chown popuser:popuser $userdir/$qmailcfg $userdir/$qmailcfg.old $userdir/$procmailcfg");


2009/01/08 Update: The previous version of this script blew away whatever was in the file, which broke Plesk’s spam filtering and mail redirection features. I’ve changed the script above to a new version which directly replaces the local delivery agent with procmail, but leaves the rest of the .qmail file alone. This should be better.

Note that I am not accounting for people who want their end users to be able to update their .procmailrc files — this article assumes that the root user will be the one making updates. In my case, this works fine; however, at some point, I will probably investigate setting up Plesk’s hacked-up version of Ingo to update the .procmailrc files for individual users. That way, users could define filters via IMP Webmail, and have them automatically applied on the server side.

Update: I figured out how to make this work with Ingo. Check out my next post here.

If you have any questions or comments, or find this useful, please leave me a comment below!

Related posts:

1. Using Procmail with Plesk: rules via Ingo
2. per-user spamassassin preferences in ldap with mimedefang
3. if you manage routers and don’t have rancid, get it

RANCID, the “Really Awesome New Cisco confIg Differ” (nice backronym, eh?) is a program that periodically goes out and fetches the config files from your routers / switches / many other devices that it supports. If you manage any of these type of devices, and do not currently use RANCID, well, all I can say is.. do it!

Why am I bringing this up now? We had a switch failure at work lately, and somehow while replacing the failed component, the switch managed to wipe it’s configuration (how? no idea.) Without RANCID, we would have been trying to figure out at least 4-5 months of configuration from the last time that the file was copied off the switch. We do have a RANCID server, which was unfortunately behind the switch that failed.. but fortunately, the server was being backed up by our BackupPC server, so we were able to hop on the web interface and grab a day-old config file. Even if we hadn’t had the BackupPC server, however, it would have only been a 15-minute job to recable the RANCID server onto a different switch and grab the config file from there — much better than the multi-hour job to rebuild the config of the failed switch. However, this does tell me that it’s actually not a bad idea to set up a job to regularly sync your switch config files from your RANCID server to an off-site machine.

In short: RANCID rocks! Use it!

Related posts:

1. Sun adds block-level deduplication to zfs
2. Using Procmail with Plesk
3. annoying file sharing stuff with windows xp professional

If you try to compile the nvidia kernel module on 2.6.20 or higher kernels that have paravirt_ops enabled (like the Debian kernels), you will run into a problem – it’ll complain that a non-GPL compatible license is using the GPL-only code paravirt_ops. I finally found a workaround (other than building the kernel without paravirt ops) – thanks to this page, you can just modify your kbuild source to get things to work. Here’s a quote from that site:

Delete the following two lines (1197-1198) in file modpost.c:

if (!mod->gpl_compatible)
check_for_gpl_usage(exp->export, basename, exp->name);

I rebuilt the 2.6.21 linux-kbuild package for Debian with the above changes, and lo and behold, it works! Thanks!

Related posts:

1. Debian Lenny on Nehalem-based systems
2. debian on an inspiron 6000
3. DRBD accepted to mainline kernel for 2.6.33!

I’ve seen a wide gamut of those “control panel” things for hosting providers, and most of the ones I’ve looked at, I haven’t liked. They usually cost tons of money, use software I hate (ie, qmail), and do not integrate well with my preferred distribution (Debian). I ran across one today that seems to work pretty darn well — SysCP.

Advantages:

• Designed for Debian
• Open-source
• Uses “good” software (Apache, Postfix, Courier’s pop3 daemon, etc)
• Stores users in MySQL, so they are entirely virtualized
• Fairly easy-to-use web interface

Things I don’t like about it (right now):

• Only supports woody/sarge
• Only supports Apache version 1, and PHP version 4 (probably easily worked around)

So far, so good.. I will probably move my virtual hosting over to this platform eventually, with redundant MySQL servers and mail servers and such. Because it uses postfix and virtual MySQL mailboxes, it should also tie in very well with Maia Mailguard.

Related posts:

1. Debian Lenny on Nehalem-based systems
2. mosso – “the hosting cloud”?
3. full suspend/resume *finally* working on my inspiron 6000

Our printer (Epson Stylus Photo R200) died on us Monday night. I talked things over with Tiff, and we decided to go with an all-in-one printer, so she could do copying and such, too (she often could use that for work). One of my requirements was also to get a network-connected printer, so we don’t have to have a computer on to be able to print from one of the other PC’s in the house. We ended up picking up an HP Photosmart 3210, which seemed to be a decent mix of price and features. Price was $260 (at Best Buy), minus a $60 rebate, and a free $20 Best Buy gift card with the purchase. I also had $130 in Best Buy cards already, so it won’t be a very high out-of-pocket expense.

In any case, got the printer home, and plugged it into the network. It went through a self-initialization cycle, which took about 5 minutes. During this, I started the driver install under both Linux and Windows. For Windows, I just popped the CD in, and let it do it’s thing. For Linux, I used the HPLIP driver. Surprisingly (not my experience working with Epson printers under Linux), I had the HP printer fully working about 2 minutes after an “apt-get install hplip hpijs-ppds”. All I had to do was run “hp-makeuri “, plug the URI into cups, and it worked! It also automatically installed a scanner driver, so I can fire up Kooka and scan over the network.. surprisingly simple.

On the Windows box, on the other hand, the install took about 20 minutes total – 10 minutes of installing, 2-3 minutes for a reboot, and about 5-10 more minutes of installing after the reboot. The software works fine, but still, that took forever!

I’m glad to see that HP’s doing some serious work on getting better support for their printers in Linux. I think I’ll be pretty happy with this printer – the output is pretty nice, and it is *fast*.

Related posts:

1. tethering a sprint pcs sanyo 4900 via usb with linux
2. wireless sniffing under linux
3. debian on an inspiron 6000

As those of you who use Xen on the i386 arch know, the libc6 stuff can be rather annoying. The Debian libc6 developers have finally released a test glibc that includes xen compatibility — no more moving /lib/tls out of the way and losing performance!

You can grab the packages from:
http://people.debian.org/~aurel32/xen/

Hopefully these will be mainline soon.

Related posts:

1. debian on an inspiron 6000
2. Debian Lenny on Nehalem-based systems

With the current version of the Linux kernel (2.6.15), some patches, and ATI’s fglrx driver version 8.20.8, software suspend/resume *finally* works, with full accelerated graphics support. Woohoo! Uptime on my laptop is now 6 days, and that involves many trips between home and work, and many suspend/resumes.

If you’d like a copy of the scripts I’m using to get suspend working properly, let me know. I can either suspend with a FN-ESC, or by running a script (usually the method I use if I want to shut down the network card and restart it when I resume.)

Related posts:

1. debian on an inspiron 6000
2. new resume format
3. finally, a “control panel” that i kind of like!

Tim (one of my co-workers) and I have been messing around with mt-daapd for the last couple days, and I gotta say, the software *rocks*!

For those of you not familiar with DAAP, it’s the protocol that Apple uses for iTunes’s music operations over the network. mt-daapd is an open-source product that runs on Linux, and lets you set up an iTunes server. The current stable version is pretty nifty, but if you’re willing to go bleeding edge, you get lots of sweet features, like the ability to set up smart playlists via the web interface, and the ability to transcode pretty much any audio format on the fly, so iTunes can play ogg vorbis files over the network. If you’d like to try out mt-daapd’s current CVS version, I’ve got Debian packages built for it – give me a holler.

It’s also fairly trivial to set up a SSH tunnel to a remote iTunes server, and share that iTunes share on your local network.. assuming that you have a Linux box with mDNSResponder set up, at least. It’s pretty simple – just set up your SSH connection:

ssh username@remote-linux-box -N -f -L *:3690:ip-of-itunes-or-mt-daapd-server:3689

Then, in your /etc/mdns/mDNSResponder.conf file:

“Nate’s Music at Home” _daap._tcp. local. 3690

With this, I can easily stream music from my mt-daapd server at home to any box running iTunes on my subnet at work.

Like I said, teh cool!

Related posts:

1. full suspend/resume *finally* working on my inspiron 6000
2. new favorite music player for linux
3. some notes about monitoring systems

[This page originally lived at http://www.natecarlson.com/linux/advanced-routing-in-out.php. I am working on migrating all content over to WordPress, which is why this post exists. This document is mostly up-to-date; please leave a comment with any changes!]

One of my tasks at work has been to set up Nagios to monitor all of our critical services. In the process of setting this up, I’ve ran into a very interesting issue related to the way Linux does ARP with a “strange” routing table. This article details what the problem I ran into was, and what I did to resolve it with Advanced Routing.

Last modified: 11/21/2005 Nate Carlson

As an aside, this article could also be very useful for people who have two separate ISP’s, with a separate IP range from each ISP. The gist of what I end up doing is setting up source routes to guarantee that traffic will go back out the proper interface, which can be necessary to get the expected behavior out of your network.

First of all, I need to explain a bit about our network layout. For each of our public-facing boxes, we have two network interfaces – “front” and “back”. Let’s call the front interface eth0, and the back interface eth1. Front is used to serve actual data to the world, and back is supposed to be used for management purposes. Assume that 10.100.0.0/16 is our front network, and 10.101.0.0/16 is our back network. Our routing table looks something like this:

Destination	Gateway		Genmask		Flags Metric Ref    Use Iface
10.0.0.0	10.101.0.254	255.255.255.0   UG    0      0        0 eth1
10.101.0.0	0.0.0.0		255.255.0.0     U     0      0        0 eth1
10.100.0.0	0.0.0.0		255.255.0.0     U     0      0        0 eth0
0.0.0.0		10.100.0.1	0.0.0.0         UG    0      0        0 eth0

10.100.0.254 and 10.101.0.254 are the uplink “internal” routers; 10.100.0.1 is the load balancer that these boxes are behind. 10.0.0.0/24 is a management network at our main office, which is where the Nagios server is located that monitors this box. Let’s say that the local IP’s on this box are 10.100.0.100 and 10.101.0.100.

On the Nagios server, I am only monitoring 10.100.0.100 (front) network at this point. I should probably be monitoring both, but hadn’t set that up yet; this is rather fortunate, as if I was monitoring both interfaces, I wouldn’t see the strange behavior. What is this behavior, you ask? In times of low load (IE, no traffic going to/from the box besides the Nagios monitoring), the box would occasionally become unreachable. I could verify this by trying to ping it’s address on the 10.100.0.0 network – I wasn’t able to reach it. However, the second I ping the 10.101.0.0 interface, the 10.100.0.0 interface becomes reachable again. I worked with the network guy on and off for a few weeks to try to figure out what was causing this behavior, and finally we figured out that it’s the way that the Linux kernel sends ARP requests. What happens is that the ARP entry for 10.101.0.254 times out on the Linux box (because of the lack of traffic), and it tries to re-resolve it. However, since the address we’re trying to connect to from the Nagios is in the 10.100.0.0 network, the Linux box sends an arp entry out the eth1 interface that looks like:

“Who has 10.101.0.254? Tell 10.100.0.100″

The Cisco router we’re using denies this request, as the IP asking for the ARP entry is not part of the network it’s asking for. In the ARP debug logs on the Cisco, we got an error like:

“IP ARP req filtered src 10.100.0.100 , dst 10.101.0.254 wrong cable, interface “

So, what can we do to get around this problem? I can see three solutions, any of which would work:
1) Add a static ARP entry for the router on the Linux box
2) Set up advanced routing on the Linux box, so traffic will go back out the same interface it came in
3) Figure out a way to get the router to answer the filtered ARP requests, and/or mangle the ARP request with iptables to “appear” to come from the right IP.

I really didn’t like either #1 or #3, so I went with #2. Here’s what the rules I added end up looking like:

## Table 100 – Traffic in/out of eth0, front
$ ip route add table 100 10.0.0.0/24 via 10.100.0.254 dev eth0
$ ip route add table 100 default via 10.100.0.1 dev eth0

## Table 101 – Traffic in/out of eth1, back
$ ip route add table 101 10.0.0.0/24 via 10.101.0.254 dev eth1

## Main table; default routes. Default to using the “back” interface for comms to HQ.
$ ip route add table main 10.0.0.0/24 via 10.101.0.254 dev eth1

$ ip route add table main 172.16.4.0/24 via 10.19.0.254 dev eth1

## Make our traffic follow these rules
$ ip rule add from 10.100.0.0/16 lookup 100
$ ip rule add from 10.101.0.0/16 lookup 101

With these rules in place, everything’s working great – traffic’s flowing in and out of the interfaces, as expected. Now, when the box tries to reply to traffic that hit it at 10.100.0.100, it will go back out the eth0 interface, and ARP for 10.100.0.254, which works just fine. All by the wonders of source routing.

If you have any comments on this document, please feel free to drop me an e-mail at: natecars@natecarlson.com

Related posts:

1. advanced routing in linux to force traffic to interfaces
2. wireless sniffing under linux
3. mt-daapd is teh cool

At work, I had an interesting problem where boxes would just seem to stop responding to ping packets for awhile on one interface, until you ping the other interface on the box. It turned out to be a problem with the way that Linux sends ARP requests when you’ve got routing set up across two interfaces. I decided to use Linux’s advanced routing features to fix this problem for our case. Basically, I just end up forcing traffic onto the interface for the IP address that the box was reached on – if you hit the box on it’s front-facing IP, the traffic will go back out the front side; if you hit the rear-facing IP, the traffic will go out the rear interface. Figuring this info could be useful for other people, I’ve written a quick article about how to set it up:

http://www.natecarlson.com/linux/advanced-routing-in-out.php

This is also useful if you have two separate ISP’s with different address ranges, and want to make sure the traffic goes back out the proper interface. Hope you find it useful!

Related posts:

1. using advanced routing to control traffic across your interfaces
2. tethering a sprint pcs sanyo 4900 via usb with linux
3. wireless sniffing under linux

[This page originally lived at http://www.natecarlson.com/linux/mimedefang-ldap-prefs.php. I am working on migrating all content over to WordPress, which is why this post exists. This document is mostly up-to-date; please leave a comment with any changes!]

This document describes how to set up my patches for Mimedefang which allow you to store per-user preferences for SpamAssassin in LDAP. If you run into any problems, please drop me an e-mail at ipsec@natecarlson.com

First of all, let’s go over some background info on Mimedefang, in case you’re not familiar with it. Mimedefang is a program that ties into Sendmail using the Milter API. It allows you to do basically whatever type of filtering you’d like in Perl. It has built-in ties to SpamAssasin, virus scanners, and many other useful programs. More information is available at the web site.

Note that the authors of Mimedefang do offer a commercial program called Can-It Pro! that integrates per-user preferences, per-user bayesian filters, and many other nice features with a slick web front-end. This is available from Roaring Penguin, at http://www.roaringpenguin.com. If you’d like per-user everything, with a nice management interface, check it out! My previous employer is also a Can-It reseller; if you’d like more information, their site is at http://www.real-time.com.

One of the weaknesses in Mimedefang’s ties to SpamAssassin are that there isn’t any good way to implement per-user preferences and such. SpamAssassin 3.0 and above has support for storing the preferences in LDAP or MySQL, so I figured it was time to try to figure out a method of having per-user preferences. Since my users are already in LDAP, it seemed to make sense to store the preferences in LDAP, so that’s the approach I took. This code should be easily adaptable to store preferences in MySQL instead, though.

Note that this code does not seem to work if enable Mimedefang’s embedded perl interpretor.

Now, to the code!

Contents:
Download patch, rebuild Mimedefang
Configure SpamAssassin for LDAP preferences
Configure Slapd for LDAP preferences
Configure your mimedefang-filter to use LDAP
Add SpamAssassin Attributes, and test!
My TODO List

Download patch, rebuild Mimedefang

My patch to enable LDAP in Mimedefang is available from:
http://www.natecarlson.com/downloads/mimedefang/mimedefang-sa-prefs-ldap.patch

You’ll need to apply this to the root of the Mimedefang source, and rebuild and reinstall Mimedefang. The patch will also probably apply to /usr/bin/mimedefang.pl, but I haven’t tested that. If you’re a Debian Testing user, I have a deb package available at:

http://www.natecarlson.com/downloads/mimedefang/mimedefang_2.51-2.nc.1_i386.deb

This package is based on Debian’s Mimedefang 2.51-2 package.

Configure SpamAssassin for LDAP preferences

You’ll need to configure SpamAssassin to use LDAP as your preference container. I personally put the configuration in /etc/mail/spamassassin/prefs-ldap.cf. Here’s what I use:

user_scores_dsn ldap://ldap.server/dc=example,dc=com?spamassassin?sub?uid=__USERNAME__
user_scores_ldap_username cn=binduser,dc=example,dc=com
user_scores_ldap_password bindpw

You’ll need to create a user to bind to the LDAP server as, along with a password. I haven’t managed to convince SpamAssassin to do an anonymous bind yet; if you do figure this out, please let me know. This example will search for an entry with the attribute ‘uid’ equal to the username (passed from Mimedefang in the filter section below). Edit as needed.

Configure Slapd for LDAP preferences
You’ll also need to set up the schema for your LDAP server to support the SpamAssassin tag. Based on the sample documentation with SpamAssassin, I edited ‘/etc/ldap/schema/inetorgperson.schema’, and added the following:

spamassassin
see http://SpamAssassin.org/ .
attributetype ( 2.16.840.1.113730.3.1.220
NAME 'spamassassin'
DESC 'SpamAssassin user preferences settings'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

You’ll also need to add ‘$ spamassassin’ to the end of the ‘MAY’ entry at the end of the file. Once you’ve added these entries, restart slapd, and make sure you don’t get any errors.

Configure your mimedefang-filter to use LDAP

The next step is to configure your mimedefang-filter to use the new code.

My patch to the example config file is available from:
http://www.natecarlson.com/downloads/mimedefang/mimedefang-ldap-filter.patch

This should be pretty self-explanitory. Search for XXXXX’s for things you need to fill in (LDAP server and base). My example code will search the ldap server for the first recipient, as ‘mail=mail@domain’ and for just ‘mail=@domain’. You’ll likely want to replace the get_username_ldap subroutine altogether, depending on your needs. Be sure to test your config with ‘mimedefang.pl -test’, and then reload your config.

Add SpamAssassin Attributes, and test!

Once you’ve got all of the above set up, you should be set to go. First thing you’ll want to do is add some SpamAssassin preferences to the LDAP database. You want to add an attribute of ’spamassassin’ with a value of ’sa_config_option config_value’. For example, to whitelist mail from ‘user@example.com’ to your user named ‘nate’ in LDAP, you’d add the attribute ’spamassassin’ with a value of ‘whitelist_from user@example.com’ to the ‘nate’ user. Then, send a mail through, and see if it worked!

My TODO List

• Write a web-based interface to modify user’s SpamAssassin entries
• Write better documentation, with more details
• Add support for MySQL preferences
• Document using Bayes in MySQL for individual users (it works, just have to config it)
• Lots more, I’m sure!

Related posts:

1. Using Procmail with Plesk: rules via Ingo
2. Using Procmail with Plesk
3. debian on an inspiron 6000

[This page originally lived at http://www.natecarlson.com/linux/sanyo-4900.php. I am working on migrating all content over to WordPress, which is why this post exists. The original post is ancient, but most of the comments still apply to modern phones and 3G plans.]

This document describes how to connect a Linux box to Sprint’s “Vision” (3G) network using a Sanyo SCP-4900 and the PCS Connection Kit USB cable.

$Id: sanyo-4900.php,v 1.17 2005/09/21 15:54:10 natecars Exp $

Background:
**NOTE**: I have not had my Sprint phone in over a year; I am now using T-Mobile’s wireless data service when I need it. It’s slower, but I like T-Mobile’s phones better. Sprint does also now state that you are not supposed to use your Vision service with a laptop unless you pay laptop prices, or they will cut you off. YMMV. People who have Sprint phones do tell me that the below still seems to work.

In my ever-lasting search for high speed wireless internet access, I decided to try out Sprint PCS’s new Vision service. They recently dropped their prices. For $40/mo, I’m getting 300 anytime minutes, free long distance, and unlimited ‘high speed’ (56-144k) data (this is the Vision service). The best part is that the data service is simple to get working with Linux – all you need is the proper USB drivers, and the knowledge to set up a PPP connection. The phone’s cost varies from free to $150 (depending on what deal you get). Sprint used to sell the data cable (with Windows software) for $69.99, but it’s no longer available from them. You can get it from Sanyo directly for $29.99, from https://store.sanyousa.com/osb/itemdetails.cfm/ID/74. Radio Shack and various other stores also carry the cable. I’ve also used the setup instructions below with a Samsumg A500 phone and the proper USB cable, which worked fine.

NOTE: There are conflicting reports to what exactly Sprint means by ‘unlimited vision’. Apparently, they have told some people that the unlimited vision is for phone use only, and does not apply when you’re using the phone with the USB cable. The USB cable solution was actually recommended to me by an employee at a Sprint store to start with, and I checked with two other Sprint reps that it was acceptable use before purchasing. I can also confirm that I have not been charged for any Vision usage, beyond the standard $10/mo, even though I have been using it via the USB cable. But to protect yourself, be sure to check with your Sprint rep, and make sure that this use is acceptable before doing it. If you end up getting billed for the usage, don’t say I didn’t warn you!

Some other sites that have information on Sprint PCS equipment with Linux:
http://www.tummy.com/articles/laptops/merlin-c201/

First Step: Make sure your kernel has the right options
To use the PCS phone, you’ll need to have USB support for the USB card in your computer, and support for USB ACM devices (CONFIG_USB_ACM). The kernel included with recent versions of both Debian and RedHat includes everything you need. Also make sure you have hotplugging enabled, so that the modules will be loaded automatically.

Second Step: Plug in the phone, and watch the drivers load
All you need to do is plug in your phone, and all the drivers should be loaded automatically. Note that I have had a few cases where I needed to reset the phone to get the USB interface to show up. When I plug my phone in, I see the following:

Nov 5 19:35:29 knight kernel: hub.c: new USB device 00:07.2-1, assigned address 2
Nov 5 19:35:29 knight kernel: usb.c: USB device 2 (vend/prod 0×474/0×701) is not claimed by any active driver.
Nov 5 19:35:33 knight /etc/hotplug/usb.agent: Setup acm for USB product 474/701/0
Nov 5 19:35:33 knight kernel: usb.c: registered new driver acm
Nov 5 19:35:33 knight kernel: ttyACM0: USB ACM device
Nov 5 19:35:33 knight kernel: acm.c: v0.21:USB Abstract Control Model driver for USB modems and ISDN adapters

Third Step: Create a dialup connection
Now that you’ve got an ACM device, you just need to create a dialup connection. Note that the ACM device name may vary – just search through /dev for the proper device. On my (default) Debian install, it’s /dev/ttyACM0. On RedHat 7.3, it’s /dev/input/ttyACM0. Once you’ve found that, the number to dial to get a connection to the Vision network is ‘#777′ (which is #PPP on the keypad). So, use whatever method you prefer to create a dialer that will dial #777. On my Debian box, I’m using the standard ‘pon’ scripts. Here are the config files I use:

/etc/ppp/peers/sprint:

# You usually need this if there is no PAP authentication
noauth
# The chat script (be sure to edit that file, too!)
connect "/usr/sbin/chat -v -f /etc/chatscripts/sprint"
# Set up routing to go through this PPP link
defaultroute
# Use remote DNS
usepeerdns
# Default modem
/dev/ttyACM0
# Connect at high speed
230400
local
novj

/etc/chatscripts/sprint:

TIMEOUT         5
ABORT           '\nBUSY\r'
ABORT           '\nERROR\r'
ABORT           '\nNO ANSWER\r'
ABORT           '\nNO CARRIER\r'
ABORT           '\nNO DIALTONE\r'
ABORT           '\nRINGING\r\n\r\nRINGING\r'
''              \rAT
TIMEOUT         12
OK              ATD#777
TIMEOUT         22
CONNECT         ""

So, I run the command ‘pon sprint’ (if you’re on RedHat, try running ‘pppd call sprint’), wait a few seconds, and then start surfing. If you have problems with the above script not working, please try the script below (Thanks to Matthew Brichacek for the info):

TIMEOUT         5
ABORT           '\nBUSY\r'
ABORT           '\nERROR\r'
ABORT           '\nNO ANSWER\r'
ABORT           '\nNO CARRIER\r'
ABORT           '\nNO DIALTONE\r'
ABORT           '\nRINGING\r\n\r\nRINGING\r'
''              \rAT
TIMEOUT         12
OK		"ATZ"
OK		"ATE0V1"
OK		"AT+IFC=2,2"
OK              ATD#777
TIMEOUT         22
CONNECT         ""

Here in Minneapolis, I generally get ping times of 300-500ms, and download speeds of 7-12kbytes/sec. Not bad at all, considering it’s a connection I can take with me everywhere I go! Note that Sprint also gives you a (dynamic) public IP address, where the rest of the wireless phone connections I’ve tried have been NAT translated. This service works beautifully with FreeS/WAN as a VPN Client. Well, hope this has been helpful.. good luck getting your connection up!

If you have any comments on this document, please feel free to drop me an e-mail at: natecars@natecarlson.com. The contents of this page are freely distributable, as long as a link is provided to this page.

Related posts:

1. infrared between a sony vaio pcg-f390 and a nokia 8290 phone
2. Types of VPN available on Linux
3. wireless sniffing under linux

[This page originally lived at http://www.natecarlson.com/linux/inspiron6000.php. I am working on migrating all content over to WordPress, which is why this post exists. Most of the comments on this post are waaay out of date.. if you still have an Inspiron 6000, any modern distribution should take care of you.]

This document contains some rough notes on what I needed to do to get Linux running smoothly on my Inspiron 6000.

Last modified: 9/13/05 Nate Carlson

I recently purchased a Dell Inspiron 6000, and of course am running Linux on it. The notebook has some “bleeding edge” hardware in it, so there is still some tweaking required to make things work properly.

First of all, some notes on installation. With Debian’s sarge rc3 installer, I had to use the 2.4 kernel, as the 2.6 kernel would not detect the CD-ROM. (The CD-ROM on this laptop is an ATAPI drive on a PIIX SATA bridge, and the SATA driver included with the 2.6 kernel does not support ATAPI-over-SATA.) When installing with 2.4, disk access will be s-l-o-w, because the 2.4 kernel does not support DMA with the chipset. Besides having to use a 2.4 kernel, you can install as usual.

After installation, you’ll want to upgrade to a 2.6 kernel. At first, whenever I enabled the ATAPI feature in the SATA driver, any heavy disk i/o would hang the system. I ran into a web site on the Inspiron 9300 that that has a patch to fix this behavior. You can grab the patch from:

http://www.rtr.ca/dell_i9300/

The patch on this site also includes patches to properly support the touchpad, which is very nice!.

If you have an Intel ipw2200 card, you will also want to install the wireless drivers. The driver is availabile in the ‘ipw2200-source’ package on Debian. Follow the directions to build and install; remember to grab the firmware image per the direction’s instructions.

My 6000 has an ATI Radeon X300 PCI-E video card. To get acceleration on this card, you will want the fglrx drivers from ATI. There are Debian packages for these drivers available from:

http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html

Again, just follow the directions to install. I am using Xorg from Ubuntu, so I used the Xorg packages.

If you have the Bluetooth module, installation is trivial – just make sure you have the Bluetooth USB drivers in your kernel, and it should work. The Bluetooth card shows up as a standard USB dongle.

Well, that’s it for now – I will try to organize this document better and include some more information at a later date. Hope it helps!

If you have any comments on this document, please feel free to drop me an e-mail at: natecars@natecarlson.com

Related posts:

1. full suspend/resume *finally* working on my inspiron 6000
2. Debian Lenny on Nehalem-based systems
3. wireless sniffing under linux

[This page originally lived at http://www.natecarlson.com/linux/wireless-sniff.php. I am working on migrating all content over to WordPress, which is why this post exists. Most of the comments on this post are waaay out of date.. but the concepts are similar.]

This document describes how I got sniffing of 802.11b wireless networks working with my Linux box and a Prism2 wireless card.
Last modified: 10/01/01 Nate Carlson

Background:

We’ve been playing around with wireless networking at work, and one of the things I’ve been wanting to do is learn how to sniff networks for wireless packets, just to see what I can get. Hard part is all I have to work with for wireless cards are PrismII and Aironet cards, and the NetStumbler (for Windows) software only supports Orinoco. Of course, since I do the rest of my work in Linux anyways, I wanted to be able to sniff under Linux. So, I did some research, and it turns out that everything you need to do the sniffing is indeed available for Linux; it just hasn’t been well documented. So, here’s my attempt to document it! :)

First Step: Compile required PCMCIA packages

First step is to set up the PCMCIA stuff properly. You will need the following:

Standard PCMCIA Card Services package (you probably already have this)
Linux WLAN Package (provides full support for PrismII cards)
Patch to WLAN drivers to enable monitoring of packets (same patch you need for airsnort; this patch is integrated into linux-wlan-ng-0.1.10!)

Prismdump (dumps the packets from the wireless network into a PCAP file
CVS version of PCAP and TCPDUMP (current versions do not support 802.11b packets; CVS does)
Newest version of Ethereal (not strictly needed, but it lets you break down the packets for viewing

Download all the above packages, and compile and install according to the included directions (yeah, I might write a cheat sheet here eventually.) Make sure that you apply the patch to the linux-wlan package before compiling it (obvious). Note that depending what kind of PrismII card you have, you may need to modify the PCMCIA configuration to bind it to the PrismII card.

Second Step: Put the card into monitor mode, and sniff some packets

To put the card into monitor mode (note: this WILL make the network card unusable for normal traffic!), run the following command:

wlanctl-ng wlan0 lnxreq_wlansniff channel=N enable=true

Generally, you’ll want to sniff on Channel 6 (it’s the default, and most people don’t change the default), but you may want to play with other channels, too. To stop sniffing, run the same thing, except enable=false.

Once you have the card in sniffing mode, you can use prismdump to dump some packets out into a pcap-format file. This is really simple; just run:

prismdump > sniff.out

I generally also run airsnort’s capture with the ‘-c’ flag while I am doing this; that way, I can see how many packets have gone through. This file will grow, quick. Once it starts growing, it means you have some data!

Final Step: Analyze the packets!

Well, now that you have some packets saved to disk, I suppose you want to view them, huh? If all you want is the ESSID, and you don’t care about anything else, you can just dump the packets with tcpdump:

tcpdump -X -x -r sniff.out

Here is a sniff of one of my boxes doing a probe for AP’s:

11:38:09.496277 Probe Request (thisisessid) [ 11.0 Mbit]
0x0000   000b 7468 6973 6973 6573 7369 6401 0482        ..thisisessid..
0x0010   040b 16ff ffff ff                              .......

In the above, it’s easy to spot the essid: ‘thisisessid’. Not much else that’s very useful in this packet.

Here’s a Beacon packet from my AP at home:

03:33:58.788488 Beacon (abcdefghijkl) [ 11.0 Mbit] ESS CH: 6 , PRIVACY
0x0000   9a81 d49c 7700 0000 5000 1500 000c 7465        ....w...P.....ab
0x0010   6368 6e69 6361 6c69 7479 0104 8284 0b16        cdefghijkl......
0x0020   0301 0605 0400 0200 00ff ffff ff               .............

As you can see, Privacy (WEP) is invoked in this case, and the essid is ‘abcdefghijkl’. Fairly simple.

For even more information, such as the mac address, etc, you can load these packets into Ethereal by clicking File->Open, and loading the file. Note that for encrypted packets, I had to turn off the ‘Enable MAC name resolution’, ‘Enable network name resolution’, and ‘Enable transport name resolution’ options. Once you load up Ethereal, you can anaylze these packets just like any other packet — beyond what I want to document right now. :)

But, that’s the basics, I may add more details later.

If you have any comments on this document, please feel free to drop me an e-mail at: natecars@natecarlson.com

UPDATE: Sniffing networks on an AiroNet card

If you have an AiroNet card, it’s possible to sniff packets if you have a kernel > 2.4.7 and the CVS versions of libpcap and tcpdump. To do this:

# echo 'Mode: rfmon' > /proc/driver/aironet/eth0/Config
# tcpdump -i eth0 -w 

..and then load the file into Ethereal as usual.

Related posts:

1. tethering a sprint pcs sanyo 4900 via usb with linux
2. debian on an inspiron 6000
3. per-user spamassassin preferences in ldap with mimedefang

[This page originally lived at http://www.natecarlson.com/linux/vaio-infrared.php. I am working on migrating all content over to WordPress, which is why this post exists. This is ancient, and probably no longer applies.]

This document describes how I got infrared working between my Sony VAIO PCG-F390 and my Nokia 8290 GSM Phone.
Last modified: 9/13/01 Nate Carlson

Background:
I’ve always wanted wireless internet, but didn’t want to pay the insane rates for Ricochet, etc. I finally ended up picking up a Nokia 8290 phone, which has an integrated modem that you can access over the infrared port. Set up under Windows was fairly simple (just download the ircomm updates, and away it goes), but I had some trouble getting it working under Linux. My two main problems were the broken serial port that the laptop sets up for the port, and then I had problems with latency that were caused by the kernel parameters I was using. I hope this document will make a similar set up easier for you. :)

First Step: Compile options into the kernel

I used the following options with kernel version 2.4.9-ac8:

CONFIG_IRDA=m
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
CONFIG_IRDA_ULTRA=y
CONFIG_IRDA_OPTIONS=y
CONFIG_IRDA_CACHE_LAST_LSAP=y

CONFIG_IRDA_FAST_RR=y
CONFIG_IRDA_DEBUG=y
CONFIG_IRTTY_SIR=m
CONFIG_IRPORT_SIR=m
CONFIG_NSC_FIR=m

Just make sure you have these options configured, and build as usual. Note that the CONFIG_IRDA_FAST_RR is very important; without it, you get extremely high latency on the link! I was getting ~5000ms pings over PPP once I brought the link up before I added that option; now I get around 1000.

Second Step: Set up the module config

pre-install nsc-ircc /bin/setserial /dev/ttyS2 irq 0 port 0 uart none
alias irda0 nsc-ircc
options nsc-ircc dongle_id=0×09 io=0×3e8 irq=10 dma=0

The setserial command disables the (broken) serial port for infrared that the notebook enables by default. If you don’t disable it, things aren’t going to work.

Third Step: Activate the Infrared Subsystem
Before you can activate the infrared devices under Linux, you will need to create the character devices (ie, serial ports) that you will use to connect to you infrared device. You only need to do this once. To create it:

# mknod /dev/ircomm0 c 161 0

# mknod /dev/ircomm1 c 161 1

If you need more than two serial devices, just increment the minor number.

Once you have the character devices ready, you’re ready to bring up the link. To do this, run:

# irattach irda0 -s 1

Once you have run this command, you should be able to snoop the traffic on the infrared port by using irdadump. You will always see traffic from your own computer, and if you have a device activated and in the line of sight, you should be able to see packets coming from that device.

Last Step: Use the port!

Once you see traffic from the other devices, you’re ready to go! Just point your favorite terminal program or ppp dialer to /dev/ircomm0, and you’re set. If you are using this to access your Nokia phone, you may also find applications such as ‘gnokii’ and the gsmutils package useful; they allow you to back up your phonebook, and do other interesting operations like that.

If you have any comments on this document, please feel free to drop me an e-mail at: natecars@natecarlson.com

Related posts:

1. tethering a sprint pcs sanyo 4900 via usb with linux
2. Bust your phone? Need a temp replacement quick? AT&T customer? You’re in luck!
3. wireless sniffing under linux