blog@insidesystems.net

Like a lot of other consultancies, we’re excited about Ruby on Rails. It provides a very nice framework to write clean, well-tested code in a great language. But hosting a production rails site isn’t quite as simple.

In a previous article I wrote about a possible way to run darcs on the FreeBSD/AMD64 platform.

Sadly, it didn’t work. It nearly worked, but it did not. It’s possible the fix was simple, but I don’t know a single line of Haskell, so I didn’t bother trying.

What I did try, was the FreeBSD Linuxulator.

Edit: This approach seemed tenable, but the resulting executable failed in some circumstances. We suggest you use the method in this article instead.

We recently moved to the AMD64 platform on FreeBSD, and for the most part it has been fantastic. The machines are screaming fast, and almost every piece of software we use has been supported.

Everything except darcs and ghc, which are i386 only on the FreeBSD platform.

We didn’t want to run a standard (dynamic) 32-bit binary, because then we would end up having to manage 32-bit version of the curl, readline and gmp libraries, in parallel with their 64-bit brothers. It seemed like a disaster waiting to happen at upgrade time.

If you’ve done a source upgrade on FreeBSD, you probably saw the following after you did your post-installworld “make delete-old”.

make delete-old
>>> Removing old files (only deletes safe to delete libs)
>>> Old files removed
>>> Removing old directories
>>> Old directories removed
To remove old libraries run 'make delete-old-libs'.

But why would you want to remove the old libraries? You know enough about Unix to know that doing so can break dependencies, and that it is often hard to figure out what all depended on a particular object.

Well, I wanted to because I don’t like having obviously outdated and unmaintained code sitting on my systems.

In today’s increasingly electronic commercial environment, one of the most common scenarios confronting businesses is the transport and processing of files. A typical scenario might be the following:

• At the end of the day, connect to a vendor FTP site and download a couple of files
• Decrypt them using GPG
• Process each line and import the information into a local reporting database
• Construct a subset of the information into a new format
• Encrypt the new files with a different key and e-mail them to a client
• Upload yet another format of the information to a website for client download

Of course, none of these tasks are particularly difficult, it’s just a matter of creating a simple shell script tossing it in the crontab. This is usually where things start to go progressively downhill and reality starts to assert itself. Strata can help fend off ugliness, but first lets explore why it’s necessary.

Ever been in a situation where you had one, maybe two T1 lines and it just wasn’t quite enough bandwidth? Ever thought it would it be really nice if you could just get a cheap DSL or cable account (or two) to offload some of the unexciting web and mail traffic and not have to go through the hassle of restructuring the network or even rebooting a running machine? Through the magic of OpenBSD and PF, it’s pretty easy.