codeblog code is freedom — patching my itch

Happy Holidays!

Or, as my firewall reported this morning:

Dec 25 04:39:18 firewall kernel: [1054241.000084] sd 2:0:0:0: [sda] ABORT operation started
...
Dec 25 04:40:10 firewall kernel: [1054292.072173] raid1: sdb2: redirecting sector 3490144 to another mirror


I guess I’m getting my firewall a new hard drive for Christmas. :)

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.

With the vrms meme raging on Planet Ubuntu, I noticed some people still have sun-java6 installed. I’ve been using openjdk-6 since Hardy, and everything I use works fine with it (e.g. Vuze, Catan, Eclipse, FreeMind, and even Facebook’s photo uploader thing). Given the Ubuntu Tech Board’s “remove sun-java6 from the archive” Agenda item, it’s possible sun-java6 (being redundant and orphaned) would go away in Ubuntu Karmic (sun-java5 is already gone because Sun will drop support for it in October, and sun-java6 is not far behind).

I’ve heard some noises about openjdk-6 not working for people, but I haven’t actually seen any direct technical evidence of something working in one and not the other. Seeing as Jaunty’s OpenJDK was certified by Sun, it would be very interesting to find failures, as this would indicate that Sun’s certifications are missing something.

Looking for examples of failures in Google, I couldn’t find anything with obvious test-cases that failed with openjdk-6. I suspect I’m just not trying hard enough, but I’m curious what other people have run into.

Test for yourself:

sudo apt-get purge sun-java6-jdk sun-java6-jre sun-java6-bin sun-java6-plugin
sudo apt-get install openjdk-6-jdk icedtea6-plugin

(Don’t forget to restart your browser.)

© 2009 – 2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.

I spent a while this morning hunting down the root cause of a 100% CPU MIMEDefang process. (Turned out to be one specific email triggering one of my custom SpamAssassin rules that seems to get processed really inefficiently.) I wasn’t able to find any documentation on how to debug where in MIMEDefang an email was getting stuck, and even jacking up the debugging output of my mimedefang-filter script seemed to imply it was happening late in the filtering process. After digging through mimedefang.pl, I found a “status reporting” subsystem and tracked it back out into configuration in /etc/default/mimedefang:

# Uncomment next line to have busy slaves send status updates to the
# multiplexor. NOTE: Consumes one extra file descriptor per slave, plus
# a bit of CPU time.
# MX_STATUS_UPDATES=yes


Turning this on, and then using “md-mx-ctrl busyslaves” (I command I didn’t know existed until today either) I got to see exactly where it was stuck:

3 B 13380 (Running SpamAssassin j951iX1t025805)


Now I’m having fun running md-mx-ctl with histo, barstatus, and load. :)

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.

Here are my notes on growing a KVM disk image’s root filesystem. I had a few 4G partitions that really needed to be bigger. This shows how to get a report on the sizes of the disk images, convert them to raw, work on the partition tables, grow the root filesystem, and rebuild the swap partition with the original UUID. With some work, it could probably become fully scripted, but since the partition layout may not always be the same from VM to VM, the “fdisk” step needs human interaction to delete and rebuild the partition table. Note that the method below also maintains the sparseness of the images.

# Look for files to change
for i in /vmware/*/*{vmdk,qcow2}; do qemu-img info $i; done
...

# Pick one...
cd dir...
ORIG=64bit-Ubuntu-7.10-desktop.vmdk
SIZE=8G


ORIG_TYPE=$(echo $ORIG | awk -F. '{print $NF}')
TARGET_TYPE="qcow2"
TARGET_BASE=$(basename "$ORIG" ."$ORIG_TYPE")
TARGET_RAW="$TARGET_BASE".raw
TARGET="$TARGET_BASE"."$TARGET_TYPE"

qemu-img convert -f "$ORIG_TYPE" "$ORIG" -O raw "$TARGET_RAW"

trunc "$TARGET_RAW" "$SIZE"

sudo kpartx -a "$TARGET_RAW"
SWAP_PART=$(for i in /dev/mapper/loop0p*; do sudo vol_id $i | \
    grep -q ^ID_FS_TYPE=swap && echo $i; done | head -n 1)
UUID=$(sudo vol_id "$SWAP_PART" | grep ^ID_FS_UUID= | cut -d= -f2)
sudo kpartx -d "$TARGET_RAW"

# use losetup otherwise fdisk doesn't know cylinder count
sudo losetup /dev/loop0 "$TARGET_RAW"
# FIXME: Need to automate fdisk (detect swap partition size, etc)
# I'm deleting the swap and growing the root partition, then re-adding swap
sudo fdisk /dev/loop0
sudo losetup -d /dev/loop0

sudo kpartx -a "$TARGET_RAW"
sudo e2fsck -f /dev/mapper/loop0p1
sudo resize2fs /dev/mapper/loop0p1
sudo mkswap -U "$UUID" "$SWAP_PART"
sudo kpartx -d "$TARGET_RAW"

qemu-img convert -f raw "$TARGET_RAW" -O "$TARGET_TYPE" "$TARGET"
rm "$TARGET_RAW"
# FIXME: change disk image path
sudo vi /etc/libvirt/qemu/THING
# FIXME: have the daemon notice the file change
sudo /etc/init.d/libvirt-bin restart
if [ "$ORIG" != "$TARGET" ]; then rm "$ORIG"; fi

The “trunc” command above is based on my network backups post, but is now a general script I use:

#!/usr/bin/perl
# Copyright (C) 2006-2008 Kees Cook <kees@outflux.net>, License: GPLv3
use strict;
use warnings;

my $filename = $ARGV[0];
die "Need valid size also\n" unless ($ARGV[1] =~ /^(\d+)([KMG])$/);
my $size       = $1 + 0;
my $multiplier = $2;

$size *= 1024 if $multiplier =~ /^[KMG]$/;
$size *= 1024 if $multiplier =~ /^[MG]$/;
$size *= 1024 if $multiplier =~ /^[G]$/;

#die "Not trunc'ing existing file\n" if (-e $filename);
die "$filename: $!\n" if (!open(FILE,">>$filename"));
die "seek: $!\n" if (!(seek(FILE,$size,0)));
die "truncate: $!\n" if (!(truncate(FILE,$size)));
die "close: $!\n" if (!(close(FILE)));

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.