Feeding The Multitudes with Unbuntu Linux Christian Edition

Photo by rbieber

I found a reference to the Ubuntu Linux Christian Edition site from the Unix and Linux Menagerie blog and just had to download it and try it out.

This is my stupid attempt at humor. Christian geeks will get it, I hope. I actually downloaded it because I’m interested in the filtering that comes as part of the distro.

Subversion and SSL Troubles

I decided to upgrade my home Subversion repository to version 1.4.3 as soon as it was released. Since then, my ViewVC application has ceased to work, getting a Python exception every time I try to execute it. Creating a small Python program that just imports the library (from svn import fs) gave me the following error:

ImportError: /usr/local/lib/libsvn_ra_dav-1.so.0: undefined symbol: SSL_load_error_strings

Thinking it was an SSL library problem, I upgraded SSL – a few times. I kept mucking with the options, rebuilding Subversion, only to get everything installed and get that same error:

ImportError: /usr/local/lib/libsvn_ra_dav-1.so.0: undefined symbol: SSL_load_error_strings

Over, and over and over again I repeated the process and got the same result. The absolute definition of insanity. This has been going on for a couple of months and I’ve been trying to address it in my spare time, as I’ve been pretty busy lately during the week and gone to the Relaxation Unit the last few weekends.

I googled my ass off to find the error, but to no avail. Finally today I ran across this thread that explained the problem. After going through my distribution directory for 1.4.4 (which I upgraded at the beginning of the month only to receive the same error) I realized that I hadn’t pulled down the Subversion dependencies tarball and rebuilt neon. So, basically I was using an old version of the neon libraries.

I finally settled on the configure statement listed here, after downloading and untarring the deps file:

./configure --with-ssl --with-apxs=/usr/local/apache2/bin/apxs 
            --with-apr=/usr/local/apache2 --with-apr-util=/usr/local/apache2 
            --enable-shared --with-libs=/usr/local/ssl

This uses the already installed apr libraries that I build with my Apache server, and ensures that the neon shared libraries are built. A quick configure/make/make install/make swig-py/make install-swig-py sequence later and my Python libraries were working fine.

I made it a point this time to document this on the Labs internal wiki, but thought I should throw this out here in public so that others can find it. Hope it helps save the weeks of frustration that I have been suffering for someone out there.

Happy building …

Subversion 1.4 Released

The Subversion team has released version 1.4 of its popular version control software. You can check out the release notes over at the official site get the the details, but here’s a summary of the changes, pulled directly from the aforementioned release notes:

  • svnsync, a new repository mirroring tool
  • Huge working-copy performance improvements
  • Support for BerkeleyDB 4.4 and its “auto recovery” feature
  • Size improvements to the binary delta algorithm
  • A handful of new command switches
  • Many improved APIs
  • More than 40 new bugfixes

I was going to post about this yesterday, but I wanted to make sure I had the software built and installed here at the Labs before throwing the link out there. The upgrade went relatively well. Since I still use Berkeley DB for some of the repositories here, I build my own software to minimize the amount of dumping / loading I have to do. Currently I am still running Berkely DB 4.2. Referencing this during the build allowed me to avoid some problems people have reported using pre-packaged distributions that upgrade Berkeley DB for you, rendering your repository useless. Building my own also allows me to get the software without waiting for the binary distributions to become available.

One note on the upgrade. I’ve been a little lax in upgrading my Apache server (also custom built) and was running version 2.0.48 or so. The new release requires an up to date version of the apr libraries, so this also forced me to upgrade Apache to 2.0.59. Overall, the upgrade was painless.

As mentioned above, this release also includes the svnsync tool, which is a repository mirroring tool. From what I’ve read so far, the destination mirror must remain read only – there is no synchronization between two duplicate repositories (at least from the limited reading material I’ve found around so far), so this release by no means invalidates the SVK tool. Nevertheless, the working copy improvements and the mirroring capability shows that the team is still on the right track.

Also noted in the release notes:

… the new working copy format allows the client to more quickly search a working copy, detect file modifications, manage property metadata, and deal with large files. The overall disk footprint is smaller as well, with fewer inodes being used. Additionally, a number of long standing bugs related to merging and copying have been fixed.

I’m going to reserve judgement on these improvements until I get the Solaris boxes at work upgraded. The working copies are really an Achilles heel on Solaris environments, where 20 or so developers use one machine to do all development. We’ve had a number of inode-maxouts over the last year or so. When I get these machines upgraded, I’ll post a follow up on the performance on Solaris.

One other enhancement I’m glad to see, the diff and merge commands now support a -c option which you can use to merge one revision between branches. This allows you to avoid using a revision range for a simple one revision merge. This should simplify things a bit …

Subversion is still, overall, the best version control tool I’ve worked with thus far (and I’ve worked with quite a few of them). Kudos to the team on the new release. I like what I see so far …

Creating a self signed SSL Certificate – A Brain Dead Script

I have an SSL instance running in the house so that I can access my home Subversion installation remotely. The certificate I generated for this site expired a few months ago and I have procrastinated regenerating it because I seemed to remember it was complicated and I didn’t want to spend the time.

Well, it winds up its not that bad. I found a great summary of the commands necessary in order to do it, and threw together a very quick script to string them all together in order to create SSL certificates for a general host name and figured I’d throw it up here.

I generalized it thinking that I could have two certificates for the virtual hosts I have running on my home server. Unless I’m looking at old information, however, it doesn’t seem that you can have different SSL certificates for virtual hosts running on the same IP address under Apache 2. If you can, and someone knows how to configure Apache to do so, please let me know.

Here’s the script I used to generate the self signed SSL certificates for the house. Super simple. Now I just have to remember to source the script ;).

# Cert4Host.sh - Generate SSL Certificates for a host name.


if [ -z "${HOSTNAME}" ]; then
echo "Usage : Cert4Host.sh HOSTNAME";

if [ ! -e pass.key ]; then
openssl genrsa -des3 -out pass.key 1024
echo "Key already exists ... skipping ..."

openssl rsa -in pass.key -out $HOSTNAME.key
openssl req -new -key $HOSTNAME.key -x509 -out $HOSTNAME.crt -days 999

sudo cp $HOSTNAME.key /usr/local/apache2/conf/ssl.key
sudo cp $HOSTNAME.crt /usr/local/apache2/conf/ssl.crt

Don’t forget to change your Apache SSL configuration to point to the new certificate and key (<hostname>.crt and <hostname>.key, respectively) and restart Apache.