the birdhouse in my soul

When setting up backups over SSH (e.g. rsnapshot with rsync over SSH), it's important to know that the default SSH cipher isn't necessarily the fastest one. In this case, the CPU-based encryption is the performance bottleneck, and making it faster means getting faster backups. A test (copying a 440 MB file between a fast Xeon CPU (fast=no bottleneck there) and an Atom based NAS) shows that the arcfour family of ciphers are clearly the fastest in this setup: cipher real time user time bandwidth arcfour 0m9.639s 0m7.423s 45.7 MB/s arcfour128 0m9.751s 0m7.483s 45.1 MB/s arcfour256 0m9.856s 0m7.764s 44.7 MB/s blowfish-cbc 0m13.093s 0m10.909s 33.6 MB/s aes128-cbc 0m22.565s 0m20.129s 19.5 MB/s aes128-ctr 0m25.400s 0m22.951s 17.3 MB/s aes192-ctr 0m28.047s 0m25.771s 15.7 MB/s 3des-cbc 0m51.067s 0m48.018s 8.6 MB/s The default configuration of openssh uses aes128-ctr, so changing the cipher to arcfour gets me a 2.5-fold increase in bandwidth here ! Use the "Ciph...

At a customer, a Linux workstation suddenly refused to open HTTPS sites. Verified recent package versions of both browser (konqueror) and libraries (kde, openssl), everything looked good, but it didn't work. This blogpost serves as documentation for the fact that checking new software isn't enough, because in this case removing old openssl compatibility libraries solved the problem. The kio_http helper is not linked with openssl directly, and for some reason it must have tried to open one of the old openssl versions that were also installed. After erasing all versions between 0.9.5a and 0.9.6b, keeping the current 0.9.8e, konqueror had no problems opening https sites anymore.

(An update of an older post: now with vSphere 4.1 info. Further updated in 2011 with vSphere 5 info.) Your Linux runs on a VMware VM, but which ESX version is it ? You can see for yourself (as already explained in an earlier post on this blog). Run "dmidecode" and look at lines 10, 11 and 12. The list has been updated with current info: ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes ESX 4 - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes ESX 4U1 - BIOS Release Date: 09/22/2009 - Address 0xEA550 - Size 88752 bytes ESX 4.1 - BIOS Release Date: 10/13/2009 - Address 0xEA2E0 - Size 89376 bytes ESX 5 - BIOS Release Date: 01/07/2011 - Address 0xE72C0 - Size 101696 bytes

Your Linux runs on a VMware VM, but which ESX version is it ? You can see for yourself (as already explained in an earlier post on this blog). Run "dmidecode" and look at lines 10, 11 and 12. The list has been updated with current info: ESX 2.5 - BIOS Release Date: 04/21/2004 - Address 0xE8480 - Size 97152 bytes ESX 3.0 - BIOS Release Date: 04/17/2006 - Address 0xE7C70 - Size 99216 bytes ESX 3.5 - BIOS Release Date: 01/30/2008 - Address 0xE7910 - Size 100080 bytes ESX 4 - BIOS Release Date: 08/15/2008 - Address 0xEA6C0 - Size 88384 bytes ESX 4U1 - BIOS Release Date: 09/22/2009 - Address 0xEA550 - Size 88752 bytes

In the aftermath of the previous post, I ended up monitoring the progress of several huge pvmove and md RAID1 resync operations. Running "vmstat 1" however only shows pvmove block I/O activity, but not md RAID1 resyncing. Fortunately, "dstat -d" shows the reads and writes of both pvmove and md RAID1 resync. ("-d" is automatically included in "dstat -a" by the way.) N.B. This only affects block I/O measurements, you'll still see the impact on interrupts and CPU statistics in vmstat.

When the SATA standard was introduced in PCs, I'd read that the electrical connections of both the data and the power connector had been designed with hotplug in mind. But just as with many hotplug-able technologies, I never actually tried it (hotplug PCI, anyone ?). Until now, that is. Job at hand: replace the software-mirrored SATA drives in high-end Dell workstations with bigger ones. Without losing the data, of course. A perfect opportunity to test how Linux handles SATA hotplug ! Actually, adding the drive was a breeze, Linux automatically detects the drive, and I could sfdisk, and mdadm --add. Next step was hot-removing the old drives: mdadm --fail and mdadm --remove, then physically unplug the drives. I didn't expect it to be so easy, to be honest. Great technology !

Are you still using Red Hat Enterprise Linux 2.1, or CentOS 2.1 ? Then this news is of great importance to you: planned End-Of-Life for these products is approaching ! After May 2009, there will be no more security updates for RHEL 2.1, nor support from Red Hat. It's not really news , as the lifecycle of RHEL products has always been clearly announced and published . If you missed all that, this is the time to start planning an upgrade. Your Red Hat subscription gives you the right to use the newer versions of RHEL, so upgrading is all you need to do. Need help planning an upgrade to RHEL 3, 4 or 5 ? I can recommend some experienced consultants ! ;-)