Last Friday, the motherboard and CPU of my main Linux system died, and since it was a Pentium III, even the RAM and power supply were obsolete, so I ran off to the computer store to get the parts for a new one. My old system ran Red Hat 6.2 (very old), so upgrading was on my list anyway. This machine had been up for a year before it croaked.

I'd been grousing at Broadband Reports about poor performance of the hardware RAID in some Dell servers at a customer, so I figured I'd give a try at software RAID to learn the technology, as well as getting the reliability benefits on my own system.

So I fired up the ASUS P4P800-VM motherboard with 2.4GHz Celeron Pentium 4 with 1GB of RAM, installed RedHat 9 and started reconfiguring everything. RAID, nameserver, mailserver, migrating data, etc.

Though it was all working, it just felt slow so I decided to run some tests: building SpamAssassin took 2 minutes on the new box and 30 seconds on my Kenmore system (a 2GHz P4). Something wasn't right, and I figured it was the RAID.

After doing some digging, I broke the RAID1 mirrors to run with just the native partitions (though this wasn't easy: I haven't found any way to remove the misnamed "persistent-superblock"), but found that it made no real difference in time. Hmmm.

So maybe it's the Celeron: a "real" Pentium 4 has 512kbytes of cache, but a Celeron has only 128kb: could that make a difference? I swapped the CPUs between the new machine and kenmore: no difference.

After visiting the computer store to get a new motherboard, the guy - who was generally well informed - said that this used new Intel chipsets that might not have OS support yet - this could cause very slow disk I/O due to the lack of running with optimal DMA. I was using some new good Maxtor IDE drives with 8MB buffers, so I didn't think the drives themselves were causing the problems. Fair enough.

The ASUS website had no information or drivers, and the BIOS settings all looked more or less optimal. I dug into hdparm and DMA settings: everything looked OK as far as I could tell. hdparm -t /dev/hda showed more than 50 MB/sec of throughput, and running dd to and from the device showed numbers in those ranges. The disk didn't look like the problem, but it sure as hell wasn't obvious what was.

So maybe it's something in the kernel, but I have the distinct disadvantage of having never actually built a Linux kernel. I have studied the kernel for 20 years, read the source plenty, keep up with the news, have built other kernels, but have never had the need to build and run a Linux kernel myself.

At this point it was Sunday afternoon, and on the chance that I'd get no joy, I went to the local Micro Center to get a different one. I'd previously stopped in, but all the Pentium motherboards had the same chipset, so I passed, but I wasn't going to take a chance: I bought an Intel D865PERL motherboard (gotta love the model number) but left it unopened. It wasn't a slam-dunk that this would work any better.

Back to the kernel: it took more than two hours to build on this 2G system, and the resultant kernel didn't run any better. I had a feeling this was going to be a very long night, but then Jeremy showed up on Yahoo! IM from Korea, so I was able to ping him about this. It turns out that he had the same Intel motherboard and it worked great for him, so this made the choice easy for me.

So with "ASUS Outside" and "Intel Inside", the machine ran much faster. Whew. But while I'm doing this upgrade-fest it's time to really build my own kernel in a meaningful way: I downloaded 2.4.23-pre8 (with patches) from kernel.org and am now running a real live recent kernel (after 10 revisions to try things out).

I'm quite sure I'd have preferred to have received this education without spending three days, but I guess I'm better off. What a mess. Thanks to Jeremy for saving me at least a day.

Up next: re-install RAID1 and make a go at the 2.6 kernel. But maybe not this week :-)

Update - I've been asked several times if I ever got this resolved, and the answer is "no". I gave the Asus motherboard away and have never looked back.

I'll also note that the Intel motherboard has no onboard video, so it's not entirely a drop-in replacement for the Asus. This caught me by surprise, and at least one other person too. Check your "junk drawer" before doing the Asus-to-Intel swap.

I'm in the throes of rebuilding my main Linux box after the motherboard & CPU melted down, and it was the primary nameserver for my network. This means that the Win2000 box that I use as my main workstation has no DNS, so I have to point it to some other system. Though with Win2000 Microsoft has made it so that you don't have to reboot when changing the IP address, you do have to reboot after changing the namserver. This is exceptionally lame.

But it turns out that it's possible to get around this by making the change in Network Properties, then stopping and starting the "DNS Client" service. Once can do this either from the control panel or by going to a command prompt and typing

C> net stop "dns client"
C> net start "dns client"

This is unbelievably lame of Microsoft. There are enough areas in Windows that legitimately require a reboot (as in: "inherent in the current design for whatever reason", not "impossible to fix") that they really ought to go out of their way to avoiding requiring reboots when it's not really necessary.

This could be done automatically with a mutex or a Registry Change Event.

Duh.

Quite a few projects of various kinds have offered prizes for those who have found and/or fixed bugs (in 1998 I got a check for $4 from Bjarne Stroustrup for finding some bugs in his C++ book). I believe that Donald Knuth has done this with his books for years.

I've run across a new twist: it's The SCO Code Bounty Hunt, which offers a reward for anybody who can prove that SCO code has made its way into Linux.

And with the way that SCO has acted of late, I'd call code from SCO "a bug" :-)

I donated $25 to the project. Why don't you?

For a long time I've had IPSec VPN tunnels established to customer networks so I could do my routine maintenance securely, but one of my configurations is perhaps a little non-standard: one of my customers is my backup MX (email) handler, but I route mail from him to me through the VPN. This comes into play when my primary DSL circuit goes down and I revert to my backup circuit: because my customer's mailserver knows to go through the tunnel, it doesn't know anything about external IP addresses, and I get all my mail more or less immediately.

Tech Tip: Routing a backup email server through a VPN tunnel

For the same project that led to my winprinfo tool I had to dig extensively into the Win32 Forms API found on NT, Win2k and XP: it seems that there is an unfortunate interaction between the Microsoft/Adobe PSCRIPT5 printer driver and the forms database that causes media sizes (Letter, A4. etc.) to mysteriously become unavailable to printers. It took a long time to figure out, but I eventually got a handle on it, and from this came a Tech Tip and another tool.

• Tech Tip: Managing Win32 Printserver "Forms"
  
• Tool: winforms
  

This information is only even mildly interesting to print driver or PPD developers - it won't be useful to anybody else. (though Jeremy might find it helps him get some sleep in Japan) :-)

I recently received an unexpected award: in October I was named a Microsoft MVP (Most Valuable Professional) for Windows Security. This was apparently in recognition for my work in the Broadband Reports Security Forum, where I've been hanging out since spring 2001.

Awardees get some Microsoft swag (certificate, lapel pin, backback, etc.), a bit of software, but no money :-) I'm told that the MVP-only technical gatherings are excellent.

I did nothing to lobby or ask for this, but I'm happy to accept. Even though I have a long-time UNIX background, I've been a Win32 developer for more than 10 years and really enjoy the platform.

I suspect I'm one of the few Microsoft MVPs with "unix" in his email address <grin>

Like most responsible admins, I've been running around upgrading OpenSSH on all the systems I administer, installing 3.7.1p2 everywhere. In the process I ran into a "surprise": when PAM is disabled, "locked" accounts are now disabled even for pubkey attempts.

On most systems I administer, I don't allow password auth for anybody, the user accounts are locked, and the only way to get in is via pubkey authentication. This change constituted a "surprise".

Commenting out the source to disable this behavior looked easy enough, but I thought it really belonged as a first-class option in the sshd_config file: hence this patch. The new DenyLockedAccounts keyword takes "yes" or "no" values, and in the absence of this option, it defaults to the previous behavior of "yes". I, of course, have set it to "no" on my systems, and it's been working fine for me.

openssh-denylocked-patch.txt

Part of my work is building Windows print drivers, and it won't come as a surprise to anybody that there's a lot of stuff to attend to. There is an interface from the printspooler to the driver that must be accomodated, but also the view of the driver from the application that enters into play too. Knowing how an application views a printer can help tune the driver (this includes getting a PostScript PPD working correctly).

So, I created a Win32 command-line tool that opens a Windows printer from the application side and queries all the stuff we are able to ask for. The output is quite voluminous, and it's not always obvious just how to read it all unless one is comfortable in "driver space". But it's a start.

Sample output for an HP4200 LaserJet can be seen here.

Unixwiz.net tool: winprinfo