I still want to be notified when new versions come out (via my daily upgrade script) so I can recompile it, so I updated the version as little as possible by adding an “a” to the end of it.  

In the source directory, I edited debian/changelog .  The first line said

ffmpeg (3:0.cvs20070307-5ubuntu7.3) hardy-security; urgency=low

The error message was “unable to get local issuer certificate.”  I thought, no big deal, there must be an easy way to get SOAP4R to find all the root CA certificates.  Unfortunately it took a while searching Google to find the right answer, so I’m posting it here to make it easier for the next person (which just might be me next week).

It turns out SOAP4R will read a file called “soap/property” in your ruby library path (which can usually be the directory your app is in).  You can place certain configuration options in this file to control how SOAP4R behaves.  In this case, I needed to add

client.protocol.http.ssl_config.ca_file=/etc/ssl/certs/ca-certificates.crt


This fixed the “unable to get local issuer certificate” error right away.

There was another problem though; it was complaining about the hostname not matching the certificate. Since I’m using a wildcard certificate, I assume this means OpenSSL doesn’t respect wildcard certificates. I grudgingly added this to soap/property file

client.protocol.http.ssl_config.verify_mode=OpenSSL::SSL::VERIFY_NONE

And it’s fine now.

After I started setting up SSL, I realized that I might run into trouble because Apache has always said you can’t combine NameVirtualHost and SSL. The reason for this is that the SSL session is established before the HTTP headers are sent. Since NameVirtualHost relies on the HTTP Host header, which is unavailable since it hasn’t yet been sent at the time SSL is being negotiated, Apache can only use a single SSL cert per combination of IP and port.

So my thought was this should technically not be a problem since both of my hostnames are under the same domain and I have that fancy wildcard certificate for both virtual hosts. I thought Apache just might be cool enough to send the first certificate it finds, but still respect the HTTP Host header and send the request to the right virtual host.

Guess what… Apache is indeed that cool. I now have x.stockpr.com and y.stockpr.com on the same IP and port with two different virtual hosts, sharing the same certificate.

Won’t exactly revolutionize web hosting, but it definitely made my day night go a little easier. (Of course if you read my last post, something else more than made up for it)

Google revealed that I’m not the first to run into this problem with an EC2 instance. Several posts said to install the Xen version of libc

apt-get install libc6-xen 

and do this:

echo "hwcap 0 nosegneg" > /etc/ld.so.conf.d/libc6-xen.conf; ldconfig

And then reboot.

This seems to have fixed it, but I’m wondering why this was either not included in the Ubuntu AMI I’m using or somehow got undone.

The first time I tried to bundle the volume I noticed it was taking a very long time.  I had incorrectly assumed that ec2-bundle-vol would automatically exclude any EBS volumes.  Instead, it only excludes a static list of directories, so I had to add the EBS volume (/mail) to the exclusion list.  

Here are the commands I used to bundle the volume:

ec2-bundle-vol -k /mnt/aws-config/pk-xxxxx.pem \
-c /mnt/aws-config/cert-xxxx.pem \
-u xxxx-xxxx-xxxx -d /mnt/bundle \
-p image-name-20080924
-e /mail

ec2-upload-bundle -b ae-ami \
-m /mnt/bundle/image-name-20080924.manifest.xml \
-a xxxx -s xxxx

ec2reg bucket-name/image-name-20080924.manifest.xml

The next step will be to figure out how to set up the AMI so it will have a swap partition when it boots up in a new instance.

Since I will need to grow the filesystem in the future, I am using LVM.  This also allows me to break up the logical volume into separate EBS volumes, which should increase random access performance.  

Right now for testing, I have a single LVM volume group and logical volume comprised of three “physical” EBS volumes of 100GB each. 

Although EBS’s snapshot command completes quickly and the snapshots are consistent as of the time the command is run (there is a pause in access to the filesystem while the snapshot starts), the use of multiple EBS volumes complicates matters.  In order to get a consistent snapshot, the whole filesystem needs to be stopped while a snapshot is begun on each of the underlying EBS volumes.  Conveniently XFS has a “freeze” command to flush the whole filesystem and prevent writes until it is unfrozen.

Here’s my current snapshot script:

#!/bin/bash

SNAP_CMD=/usr/local/ec2/bin/ec2-create-snapshot
MOUNT_POINT=/mail
export JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.06
export EC2_CERT=/mnt/aws-config/cert-XXXX.pem
export EC2_HOME=/usr/local/ec2
export EC2_PRIVATE_KEY=/mnt/aws-config/pk-XXXX.pem

vols=("vol-xxxx" "vol-xxxx" "vol-xxxx")
i=0
xfs_freeze -f $MOUNT_POINT

for vol in ${vols[@]}
do
        $SNAP_CMD $vol &
        pids[i]=$!
        let i+=1
done

for pid in ${pids[@]}
do
        wait $pid
done

xfs_freeze -u $MOUNT_POINT