Open Sourcery

More as a reminder to myself for when I need this again, but I’m sure everyone needs this at least once.

Having screwed up my kernel configs for my VirtualBox Gentoo image, I needed a serial console to catch the boot messages scrolling past in order to see if all the required hardware was being loaded by the kernel. I’ve never done this on a physical machine before but I am converted now and will acquire a USB to serial port converter in the near future…

Using this article as a base you need to do the following:

1. Enable serial ports for your virtual machine
2. Select “Host Pipe”
3. Enter /tmp/vboxconsole as the filename
4. Use netcat to read the console: nc -U /tmp/vboxconsole

When booting you need to amend your grub boot line to have the following at the end:

console=ttyS0,38400

Making it look something like this:

kernel=/kernel-2.6.30-r6 root=/dev/sda3 console=ttyS0,38400

Proceed to boot and look at netcat to see the entire boot output scroll past without disappearing into thin air when the kernel panics.

Man, I love virtualization. I tested this on Mac OS X 10.5 with VirtualBox 3.0.6, but it should work on any *nix platform. Some more Gentoo serial console madness can be found on the old Gentoo Wiki.

UPDATE 2009-04022: Ruby Enterprise Edition 20090421 released a couple of hours after the original post. Now includes the OpenSSL patch from Gentoo’s Portage.

UPDATE: The upcoming release of Ruby Enterprise Edition might include the suggested patch, if we get enough +1’s on the list. Test and go vote!

Keeping your gentoo up to date almost means sacrificing Ruby Enterprise Edition because it doesn’t compile against OpenSSL 0.9.8i or later. This isn’t the fault of the Phusion guys, it comes from upstream Ruby.

Gentoo’s portage contains some patches for compiling stock Ruby 1.8.6 with later versions of OpenSSL, backported from Ruby 1.8.7. This patch also applies cleanly to Ruby Enterprise Edition 20090201, and here is how to do it from inside your unpacked Ruby Enterprise Edition tarball.


$ cd source
$ patch -p3 < /usr/portage/dev-lang/ruby/files/ruby-1.8.6-openssl.patch
$ cd ..
$ sudo ./installer


This keeps your OpenSSL library up to date, and keeps Ruby Enterprise Edition happy.

As part of the PowerDNS on Rails project, and improving our own DNS infrastructure, I sat out today to configure 4 new DNS servers around the world. This will move a lot of our DNS traffic out of South Africa, while keeping some servers locally on the main networks (Internet Solutions & SAIX).

I rolled out MySQL replication with SSL enabled, you can Google for some good howto’s on the topic and I’ll give some posts below. Basically we have secure replication, and each DNS server is isolated in case of a disaster.

The gotcha then?

The MySQL docs, and some other howto’s indicate you should set the SSL client certificate details in your my.cnf file, under the [client] section. It makes sense, the slave is a client of the master. Appears not so with Gentoo’s mysql-5.0.60-r1 ebuild. It appears even less so with PowerDNS, who rightfully reads the my.cnf file as client.

Cause and effect

PowerDNS now tries to connect to the slave using the SSL details specified in the [client] section of the my.cnf file. This breaks, since you probably never configured your MySQL slave to have PowerDNS connect via SSL.

Secondly, it appears MySQL blatantly ignores the settings when used with replication, and you actually need to specify the client certificates in the CHANGE MASTER TO statement.

Aftermath

Nothing serious, was quick to piece together what was going on. Now I’ll have double digit DNS servers scattered around the globe near pearing point, with SSL encryption for the replication data. Brilliant, that really is resillient DNS!

More reading

• MySQL Manual – Using SSL for secure connections
• MySQL Manual – Setting up replication using SSL
• Be your own CA – Not MySQL specific
• MySQL Replication with SSL
  
• MySQL Replication with SSL

Hope this prevents any future missery for someone else.

Strange days we live in, especially when our browsers trip of bugs in encryption libraries on the servers… David Smalley neatly pointed out how upgrading OpenSSL to at least 0.9.8h solves the cryptic Firefox 3 SSL errors we’ve been seeing on some our sites.

Secure Connection Failed An error occurred during a connection to xyz-abe.com SSL received an unexpected Change Cipher Spec record. (Error code: ssl_error_rx_unexpected_change_cipher)

Currently the package in question is still masked in gentoo, so upgrade as follows:

# echo ‘=dev-libs/openssl-0.9.8h-r1′ >> /etc/portage/package.unmask
# emerge -av openssl

Once done, follow the instruction given by portage to rebuild the packages still using the old versions of OpenSSL.

Thanks David