The BFC Computing Weblog

For folks who are running the current development, or soon-to-be-just-released Fedora 11, you might find Firefox to be very crashy. It's not because it's the semi-controversial 3.5b4 version (which is excellent), it's because of a buggy library.

I'm running it with the Tree Style Tab and NoScript extensions, and can get a crash half the time when Session Restore is running, and almost all the time when I allow a site in NoScript.

If you run firefox from the console, so you get the debug messages, you'll see:

cairo-ft-font.c:554: _cairo_ft_unscaled_font_lock_face: Assertion `!unscaled->from_face' failed 

when the crash happens. I tracked this down through the Mozilla and Freedesktop bug systems to a problem with the Cairo graphics engine improperly disposing of fonts which it didn't own, for which a fix was incorporated last December. However, the version of Cairo shipping in Fedora 11 is older than that.

So, I applied the simple patch, fixed up the .spec, and put up some new RPM's for i386 and an SRPM for hackers and x86_64 users to build (rpmbuild --rebuild cairo-1.8.6-3.fc11.src.rpm).

I haven't tried cross-compiling from i386 to x86_64 before, and --target=x86_64 doesn't work, so if anybody can tell me how to do that short of learning mock, please leave a comment and I'll put up RPM's for that too.

The Redhat bug is here. Hopefully it gets accepted soon.

I recently had the power supply fail on my SOHO server, which was a mongrel of old parts, far too many USB cables, and was pretty darn slow. It was also very expensive to run, having a Pentium IV in it, the worst of Intel's line.

My goals for a new server were:

• quiet
• energy efficient
• virtualization support
• lots of storage
• easy to take backups offsite
• rackmount
• budget-friendly.

After poking around NewEgg for a while (I think I enjoy shopping there a bit too much) I came up with a list of parts (after reading many of the helpful reviews), and I have to say I couldn't be happier with the system.

It's almost inaudible, runs at about 105W under normal load, has seven hard drives in it, of various capacities, fits in my rack, has a hot-swap drive for off-site backups, and runs Fedora 10 like a charm. The case is especially nice to work inside, and is of higher quality than you'd expect for the price.

I'm acually using the 2.66GHz version of the Core2Duo, but they don't seem to make that anymore - 3.0GHz seems to be the low-end. It's worth noting here that most of the commercial server builders try to force you into the Xeon line with a rackmount server and those are both more expensive and more power hungry than the Core2Duo and Core2Quad lines. Get what you really need, keeping in mind that virtualizing multiple systems onto one is a huge energy win.

Additionally, I got a cooler from BestBuy (surprisingly their in-stock cooler is the nicest I've found) and used Arctic Silver 5 thermal compound to bond the CPU. Plus a bunch of SATA cables I have in a box (they seem to spontaneously generate in there). The whole package comes in under $1200 even if you have to buy every part. Compare at fifty percent more to purchase pre-assembled.

Here's the parts list:

• 1 x ARK 4U-500-CA Black 4U Rackmount Case - Retail
• 4 x Athena Power 6" SATA II Y cable Model CABLE-YSATA290 - Retail
• 1 x ASUS P5N7A-VM LGA 775 NVIDIA GeForce 9300/nForce 730i HDMI Micro ATX Intel Motherboard - Retail
• 1 x Rosewill RG430-2 430W 80Plus Certified,ATX12V v2.3/EPS12V v2.91, Active-PFC Power Supply, UL,FCC,CE,TUV,ROHS - Retail
• 1 x ICY DOCK MB671SK-BB Tray-less 3.5" SATA I & II Mobile Rack Removable Hard Drive Kit - Retail
• 1 x  Intel Core 2 Duo E8400 Wolfdale 3.0GHz 6MB L2 Cache LGA 775 65W Dual-Core Processor - Retail
• 2 x Kingston 4GB (2 x 2GB) 240-Pin DDR2 SDRAM DDR2 800 (PC2 6400) Dual Channel Kit Desktop Memory Model KVR800D2N5K2/4G - Retail
• 4 x Seagate Barracuda 7200.11 ST31500341AS 1.5TB 7200 RPM SATA 3.0Gb/s 3.5" Internal Hard Drive (bare drive) - OEM
• 2 x MASSCOOL FD08025B1M3/4 80mm Case Fan - Retail
• 1 x Antec 761345-75120-9 120mm Case Fan - Retail
• 1 x Rosewill RCR-IC001 40-in-1 USB 2.0 3.5" Internal Card Reader w/ USB port / Extra silver face plate - Retail
• 1 x LG 22X DVD±R DVD Burner with LightScribe Black SATA Model GH22LS30 - OEM
• 1 x SYBA SD-SA2PEX-2IR PCI Express SATA II Controller Card - Retail

The secondary SATA controller is only needed if you're going over the number of drives the motherboard supports, and likewise the power splitters. If you were buying all new 1.5TB drives you'd likely not need this. Obviously the memory card reader is only if you need it. But who wants a floppy drive anymore?

Happy building!

This is a neat enhancement to postfix for reducing spam by attacking its economics: making sure it speaks SMTP properly.

A spammer gets paid by the message delivered. So, it's in his interest to flood them out as quickly as possible. Because of this, they rarely implement mailers which negotiate the SMTP connection politely - they simply open the TCP connection and start sending.

When an SMTP client doesn't respect the proper-back-and forth postfix expects, it'll flag it as unauthorized 'pipelining' - for example when multiple messages are sent in succession, but which would otherwise be OK.

We can take advantage of this by forcing the issue, and increasing the odds a spammer will make this mistake by waiting just a second between establishing the TCP connection and telling the spammer we're ready to take mail. A loaded mail server may behave this way anyway, so it's not outside the norm and the resource consumption is minimal, but it attacks the economics of spamming.

In your main.cf file, you would add to smtpd_client_restrictions something like this:

          smtpd_client_restrictions =
                  permit_sasl_authenticated,
                  permit_mynetworks,
                  check_client_access hash:/etc/postfix/access-client,
                  sleep 1,
                  reject_unauth_pipelining
          
          

We accept all of our own users' connections (interactive ones, perhaps) right away, and if the sender is totally unknown to us, we wait for just a second. Then we reject any unauthorized pipelining. The log will show something like this:

May 6 10:49:00 mailhub postfix/smtpd[8965]: NOQUEUE: reject: RCPT from unknown[10.1.2.3]: 403 4.5.0 spamtarget@example.com: Recipient address rejected: Improper use of SMTP command pipelining

when the spammer attempts to just send.

It's worth noting that this method may not scale to very large installations, as those one second delays may be too much. But for the average-sized postfix install, it can make yet another dent in the spam deluge. Where it does consume 'too many' resources, one must weight the cost of computing resources vs. the time cost of dealing with yet another spam.

A Mac user might want to export his Keychain passwords and notes for several reasons - using a third-party password manager on Mac OS X, creating a time-resistant backup of passwords, printouts of passwords for the safe-deposit box or attorney, or switching to another operating system.

There's no easy way to do this. Keychain Access only allows you to export certificates, and Apple recommends backing up the Keychain database files, which accomplishes none of the above goals and promotes lock-in.

The keychain code is itself open source, but I couldn't find it compiled for another platform anywhere. I assume that enough of the OSX toolchain is required to make this infeasible, though likely not impossible. Still, it's not there.

Fortunately, I ran across an Applescript that uses Keychain Scripting to create a text file from a user's login Keychain. Unfortunately, it didn't do a bunch of things I thought were required for moving my passwords to a Linux machine, so here's the delta:

version 2009030201:

• handle all keychains
• handle all key types
• handle comments and descriptions
• handle errors
• trim dangling whitespace
• write to tab delimited format
• unlock all keychains first, so the mad tapping won't hit 'cancel'
• add username to filename
• replace carriage returns/newlines in text fields with spaces
• use unix line endings in output file

and some general code cleanup. I'm assuming the sample code is in the public domain and releasing this version under GPLv2+. Please improve this and comment here when you do or send changes back. If you own the original code and feel this is improperly licensed, let me know ASAP.

I've run this out of Script Editor - the advantage there is it's easy; the disadvantage is double-confirming every keychain access, one for Script Editor, one for Keychain Scripting. Terribly time consuming. I suspect if you compile this it'll eliminate the first half.

I've set this to open all the keychains first. Otherwise when hitting "allow, allow, allow" you might hit 'cancel' if it asks to unlock a keychain. If your keychain is big enough you might not get through the whole thing before the keychain unlock times out, so be careful.

Your minutes of tapping on the mouse button like a human waiting for a treat will be rewarded with a ~/Desktop/Passwords-yourusername file. It'll be easy to then process with other scripts, importable into databases or spreadsheets for further manipulation. I'll leave it up to you to be smart and not leave this password file sitting around in some unencrypted/unprotected location for any longer than absolutely necessary. If it gets stolen you're probably up a creek, right? So, be careful, only aim at what you intend to kill.

Download KeychainExport.

Here's a technology idea: combine a solid-state flash drive, a synchronization engine, advanced virtual memory techniques, and a portable hardware abstraction layer to create a portable computer state device.

The idea would be like this: you have a small hardware device that you bring with your anywhere. When you plug it into one of your computers, it would synchronize the filesystem states, restore memory images, and resume your computing environment the way you left it at the last location.

It's roughly equivalent to the idea of network computers, except you don't need the ubiquitous ultra-high-speed Internet that doesn't really exist (when wireless gigabit is pervasive, this would become passe).

Current reasons this can't work, using linux as the obvious OS to start with, include the lack of an abstract HAL (root drive, home drive, etc) and the lack of virtual-memory restore on a per-process basis. Lots of the other parts exist already.

Initial limitations would probably be a restriction to the same hardware architecture (x86, AMD64, ARM, etc), inability to deal with filesystem changes greater than the capacity of the SSD, and an inability to restore stateful network connections (an IP proxy might work around the last one).

One company has made an approach at this experience by running the environment directly on the portable device, but this forfeits local resources and demands power draws unachievable on an external bus (for simple connectivity). That approach may gain viability over time, though, but not yet.

Would you, gentle reader, use such a device?

I've been using streaming video solutions more, since we pared back our satellite TV package at home and have been saving the Netflix allotment for the kids.

But streaming performance has been lacking for me. I've frequently experienced [buffering] and [recalculating bandwidth] messages, and having streams just stop dead and freeze up.

I wondered if Comcast might be playing games, since they have a history of doing so and this competes with one of their other products, so I decided to check out Google's tools that measure this possibility. Comcast is clean.

But the tools did help me find the actual cause: my TCP buffer receive size was set too low. Their network diagnostic tool revealed that 80% of the time my system was responsible for causing the delay, and only 20% of the time was the network at fault. After rejecting many forum suggestions I found as bizarre, I came across a decent O'Reilly article, which linked to an LBNL site with this recommended setting (for Mac OS X):

          sysctl -w net.inet.tcp.win_scale_factor=8
          sysctl -w kern.ipc.maxsockbuf=16777216
          sysctl -w net.inet.tcp.sendspace=8388608
          sysctl -w net.inet.tcp.recvspace=8388608
          

This increases the send and receive buffers to 8MB each and adjusts the kernel ipc buffer to accommodate. The first line is obsolete as of at least 10.4.11, which my video streaming system is on.

The last three lines above are a good way to test, and for permanence, create a file, /etc/sysctl.conf , with just the parameters, like this:

          kern.ipc.maxsockbuf=16777216
          net.inet.tcp.sendspace=8388608
          net.inet.tcp.recvspace=8388608
          

After setting that, my videos are all streaming without errors and the Google test shows that now the network is my delay 80% of the time and my client side none.

Recent OSX (10.5.x) and Linux (2.6.17) have TCP buffer autotuning which might, in some cases, make the above unnecessary. The Linux version only sets 4MB buffers, though, which may or may not be enough depending on your bandwidth delay product. Some experimentation may be in order, look up the proper variables for your kernel version, the above is only tested on xnu 8.11.1.

Intel thoughtfully has some ISO images of their BIOS flash upgrades, so you don't need to worry about finding the right flash software for your operating system and then timidly hoping that all works OK. You burn the image to a CD and reboot, then it flashes for you (using a FreeDOS/ISOLINUX system).

However, if you have a SATA CD-ROM drive, the device driver in FreeDOS doesn't support that. There is a SATA-compatible FreeDOS driver, but rather than rebuild Intel's ISO, there's an easier solution - make the BIOS emulate an IDE drive.

Go into BIOS Setup (F2 at boot), then Advanced ... Drive Configuration, and set 'Configure SATA as' to 'IDE' (mine was AHCI) and ATA/IDE Mode to 'Legacy'.

Reboot, allow the flash to succeed, then switch your BIOS settings back.

There's nothing wrong with this method, but Intel should highlight it on their download page.

KDE 4.2 looks like it's finally the right version to get me to use Linux as my daily desktop. 4.5 has more goodness baked in, 4.1 was insufficient, but 4.2 looks 'just right'. I used to be a GNOME user, but with GNOME's track towards Microsoft API's (mono) for its centerpiece applications I've gone over to KDE, and with its recent switch to LGPL I couldn't be more optimistic about its future.

For those who like to run official '-stable' versions of everything in Fedora, stop here. It'll be in Fedora 11 in a few months. Go read the warnings at the kde-redhat and the tracking bug if you want to know all the theoretical risks involved.

But for those eager to get on with things, I'll distil down what I think is the minimal command set to install the '-testing' release of KDE 4.2:

cd /etc/yum.repos.d

sudo wget http://blog.bfccomputing.com/files/kde.repo

sudo rpm -Uhv http://download1.rpmfusion.org/free/fedora/releases/10/Everything/i386/os/rpmfusion-free-release-10-1.noarch.rpm

sudo yum -y groupupdate kde-desktop

sudo yum -y update

(answering Y to importing GPG keys)

log out, log back in. You should be good to go.

I started with a working KDE 4.1 install, which wasn't easy either. If you haven't gotten that far first, be sure to do so. I have this in my notes from trial and error getting all the correct packages installed:

yum -y install kdebase kdegames kdegraphics kdemultimedia kdenetwork kdepim kdeplasma-addons kdeutils kipi-plugins PyKDE4 digikam-libs ebook-tools-libs kdebase-libs kdegames-libs kdegraphics-libs kdemultimedia-libs kdenetwork-libs kdepim-libs libgadu system-config-printer kdeaccessibility kdeartwork kdebase-workspace system-switch-displaymanager

but it may not be comprehensive (leave notes, please). Run 'system-switch-displaymanager KDM' to get the correct display manager selected. If your logins never succeed there are more packages to install. Unfortunately anaconda doesn't give a working KDE install, even if you select it at install-time.

I got a National Cyber Alert System alert today about the Microsoft Internet Explorer security vulnerability, now that Microsoft has a patch out. The trouble is, everybody has known about this since last week, and anybody finding out about it today is already hopelessly in trouble.

There's nothing wrong with a notification, "hey, you should ensure this patch is applied," but that's not the purported purpose of the Cyber Alert System.

Thank goodness for the ISC which is group of volunteers doing a much better job than the large government bureaucracy charged with the task.

It used to be you could get a floppy disk for about a dollar. If you needed to give a colleague a document it was easy to do so with a floppy disk, and there was no point in returning it.

Today, it's easy to get a 1GB flash drive/card for $8 or so, but that's a bit beyond the point of just handing them out like candy and far too much capacity for simple document exchange.

Moore's Law says we ought to expect 512MB flash cards these days for about a dollar. Something like an SD card would be a perfect replacement for these cases where e-mail isn't the best solution, and surely manufacturing costs are such that a 3.5" floppy disk had a higher materials cost than a SD card, just in terms of plastic and metal.

Here's to finding a $10 10-pack of 512MB SD Cards at Staples sometime soon. Next up: very tiny pens to label them.