Grab the new Oracle InstantClient libraries

The new Intel Mac versions are available from the Oracle downloads site. Install them in /Library/Oracle/. You can do side-by-side installations in folders with whatever names you want, since apps find them by using the $ORACLE_HOME environment variable (and it’s friends). I’ve got mine in /Library/Oracle/instantclient/10.2.0.4. Also make sure that you’ve got the files required to run sqlplus and the sdk. You can drop those in the same directory.

Oh, and don’t forget to copy over your tnsnames.ora file.

Symlink the libraries

In the directory where you’ve installed the instant client, run this:

ln -s libclntsh.dylib.10.1 libclntsh.dylib

Set the environment variables correctly

You’ll probably want to put these lines in your .bash_profile, but they also must be run (or source‘d) from the command line to take effect:

export ORACLE_HOME=/Library/Oracle/instantclient/10.2.0.4
export TNS_ADMIN=$ORACLE_HOME
export LD_LIBRARY_PATH=$ORACLE_HOME
export DYLD_LIBRARY_PATH=$ORACLE_HOME
export PATH=$PATH:$ORACLE_HOME

On to the next step, making Rails & Oracle play nice.

Getting Rails to talk to Oracle

First,

sudo gem install activerecord-oracle-adapter --source http://gems.rubyonrails.org

This installs the oracle adapter, which is how ActiveRecord deals with Oracle. It doesn’t, however, install the Ruby oci8 driver, which is how Ruby talks to Oracle. We’ll do that now.

Compile the ruby-oci8 library

Make sure you’ve got the Oracle Instant Client SDK installed in your Oracle Instant Client directory (/Library/Oracle/instantclient/10.2.0.4)

The most recent stable version of the oci8 library is 1.0.1. Download it and unpack the file in the finder: it should unzip into ~/Downloads/ruby-oci8-1.0.1.

Now we can finish configuring the environment before we compile the library.

cd ~/Downloads/ruby-oci8-1.0.0
export SQLPATH=$ORACLE_HOME
export RC_ARCHS=i386
ruby setup.rb config
make
sudo make install

These steps should cause some compiler output to scroll by. Pay attention if you run into any errors on the setup step; the error messages are reasonably helpful at pointing you towards any problems.

Test connectivity

At this point, we’re done. We’ve got the latest Oracle InstantClient, and we’ve installed the ruby-oci8 library. Now it’s a question of making sure that everything works as advertised:

ruby /usr/bin/irb

In the IRb console, type:

require 'oci8'

If the console returns true or [], you’re in business.

Configure your database.yml

The last step is to make your application use the Oracle connection. In your database.yml, use the following to make it work:

development:
adapter: oracle
database: your_instance_name
username: your_user_name
password: your_password

The database name comes straight out of your tnsnames.ora file. You don’t need to specify any other connection information in database.yml, since the tnsnames.ora file has everything you need.

Your application is now talking to Oracle, without Rosetta!

Fix the ruby_fat and ruby_ppc setup

If you followed my previous instructions and went through all of the shenanigans with the ruby_ppc and ruby_fat versions and would like to undo them, it’s quite simple. Just remove the ruby_ppc files, and the symlinks to them (called ruby, and rename ruby_fat as ruby:

cd /usr/bin
sudo rm ruby
sudo rm ruby_ppc
sudo mv ruby_fat ruby
cd /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin
sudo rm ruby
sudo rm ruby_ppc
sudo mv ruby_fat ruby

Then, you should also remove the 2 management scripts:

sudo rm /usr/bin/ppc_ruby.sh
sudo rm /usr/bin/fat_ruby.sh

And that’s enough for the cleanup. From here you can start following the instructions beginning with getting the new Oracle libraries.

namespace :db do
  namespace :schema do
    desc "Create a db/schema.rb file"
    task :dump => :environment do
      require 'active_record/schema_dumper'
      puts "Creating schema:"
      File.open(ENV['SCHEMA'] || “db/schema.rb”, “w”) do |file|
        ActiveRecord::SchemaDumper.dump(ActiveRecord::Base.connection, file)
      end
    end
  end
end

This task as shown does exactly what the default rake task does, except for the puts line. Let’s just pretend that it’s a radically different and wonderful version that solves world hunger and raises your children. Now, if you drop this into a rakefile in your app’s lib/tasks directory, and then you run rake db:schema:dump --trace you’ll notice that the schema.rb file gets created twice. What the???

Check the docs

So I started poking around the Rake docs. Rake::Task.define_task does the following:

Define a task given args and an option block. If a rule with the given name already exists, the prerequisites and actions are added to the existing task. Returns the defined task.

Aha! So instead of overriding the existing task (monkeypatching it), I’m adding to it. That’s why the schema gets dumped twice. But what if I don’t want that? What to do if I want to replace the rake task with my new version?

Check the internets

About an hour of googling later, I finally came across a post from Matthew Bass explaining the solution to my problem:

Rake::TaskManager.class_eval do
  def remove_task(task_name)
    @tasks.delete(task_name.to_s)
  end
end

def remove_task(task_name)
  Rake.application.remove_task(task_name)
end

# Override existing test task to prevent integrations
# from being run unless specifically asked for
remove_task 'db:schema:dump'

# Now define db:schema:dump again, the way we did above

And that was it. It’s relatively straight-forward, but has a tendency to do strange things when rails gets updated. So you could abstract it into a plugin, with tests, but don’t forget to test it whenever you gem update rails.

Alternative solution

While I was googling I also ran into a very interesting post on alias_task_chain, a method that patches Rake tasks to work like more typical methods with alias_method_chain. If you were clever and wanted to spend the time, you could get a solution to the problem using this method.

But wouldn’t it be nice to have a single method call, that uses url_for syntax?

class Object
  def request(options = {})
    method = options.delete(:method) || :get
    options.reverse_merge!(:only_path => true)
    ENV['REQUEST_URI'] = app.url_for(options)
    ENV['REQUEST_METHOD'] = method.to_s
    Dispatcher.dispatch
  end
end

First we pull the method (:get, :post etc.) out, if it exists. By default we want it to be :get. Then we call url_for and have it only return the path, without any leading domain info. Next we populate the environmental variables and call the dispatcher. The return output will be the HTML your app renders.

To make the trick universally accessible on your development box, put the above code in ~/.irbrc:

Then, fire up the console to your favorite rails app, and call:

>> request(:controller => 'my_controller', :action => 'the_action')

You should see the HTML output scroll by.

Updated (12/11/07): The ruby-oci8 library just went to full 1.0.0 release. I’ve updated that section to reflect the new file names.

Updated (5/5/08): The oracle adapter installation has been on-again-off-again with successive Rails releases, but there’s an easy fix for it. I’ve updated the relevant section.

At my new job, I’m using Ruby on Rails to connect to multiple databases — multiple Oracle (10g) instances, as well as MySQL and FileMaker. There’s a lot of challenges to doing this, so I’m going to post some of the less obvious solutions as they come up.

The first challenge I had was to get RoR to talk to Oracle. There isn’t a lot of information about this online, because the people who tend to use Oracle are not the people who tend to use open source software like Rails.

Upgrade Rails to version 2.0

To start out, I wanted to use the most recent release candidate of Rails: version 1.99. I figured that I might as well upgrade before writing my first application, so that the codebase is all Rails 2.0 and up. Leopard comes with both Ruby and Rails, and upgrading is actually very easy:

sudo gem install rails --source http://gems.rubyonrails.org

Then enter “y” at each prompt, to install all of the dependencies. That’s it! Check yourself with

rails –v

You should see Rails 1.99.0 or Rails 2.0.

Getting Rails to talk to Oracle

Now,

sudo gem install activerecord-oracle-adapter --source http://gems.rubyonrails.org

This installs the oracle adapter. It doesn’t, however, install the Ruby oci8 driver. We’ll do that now.

Make sure you’ve got the Oracle Instant Client SDK installed in your Oracle Instant Client directory (/Library/Oracle/instantclient/10.1.0.3)

There’s a problem on new Intel Macs with this library. Oracle hasn’t seen fit to release an Intel version of the library in the past year and a half, and that’s going to cause problems since the Ruby binary is going to run as Intel-native, but the Instant Client will run under Rosetta. To solve this, we have to make a PPC version of the Ruby binary.

Make PPC and fat versions of Ruby

This is easier than it sounds. We don’t have to recompile, since the Ruby binary in /user/bin is fat. You can check this:

file `which ruby`

This should show you a PPC and a i386 version:

/usr/bin/ruby_fat: Mach-O universal binary with 2 architectures
/usr/bin/ruby_fat (for architecture ppc7400):	Mach-O executable ppc
/usr/bin/ruby_fat (for architecture i386):	Mach-O executable i386

All we have to do is extract the PPC version as a standalone binary, and trick the system into using that only. It will make our Ruby slower, but it will get Ruby to talk to Oracle, so I’m willing to take the performance hit. It’s so fast on the Intel Macs anyway, unless your Rails apps are doing massive amounts of processing, you probably won’t notice.

We’ll use ditto to extract the PPC version:

sudo ditto -arch ppc7400 /usr/bin/ruby /usr/bin/ruby_ppc
sudo mv /usr/bin/ruby /usr/bin/ruby_fat

Now we’ve got two versions of the Ruby binary — the original fat version, and a PPC only version.

There’s a catch here, though: we actually have two copies of the ruby binary on our system. The second binary is a part of the Ruby Framework, and that’s the binary that’s used by irb, rake and other very useful Rails helpers, so let’s fix this one too:

sudo ditto -arch ppc7400 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_ppc
sudo mv /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_fat

Now we’ll need a facility for switching between the fat and PPC only binaries. Create /usr/bin/ppc_ruby.sh:

#!/bin/bash
ln -fs /usr/bin/ruby_ppc /usr/bin/ruby
ln -fs /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_ppc /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Create /usr/bin/fat_ruby.sh:

#!/bin/bash
ln -fs /usr/bin/ruby_fat /usr/bin/ruby
ln -fs /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby_fat /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Now, make them both executable:

sudo chmod 0711 /usr/bin/ppc_ruby.sh
sudo chmod 0711 /usr/bin/fat_ruby.sh

Run ruby_ppc.sh to switch to using the PPC version:

sudo /usr/bin/ppc_ruby.sh

Verify this worked:

file `which ruby`

This should return /usr/bin/ruby: Mach-O executable PPC.

We’re getting closer. Now we need the ruby-oci8 library.

Compile the ruby-oci8 library

The most recent stable version of the oci8 library is 1.0.0. Download it and unpack the file in the finder: it should unzip into ~/Downloads/ruby-oci8-1.0.0.

Before we can compile this library, we have to fool the system into making it PPC only, or it’s not going to work. With your favorite text editor, edit /usr/lib/ruby/1.8/universal-darwin9.0/rbconfig.rb. Comment out line 17 ('-arch ppc -arch i386' and replace it with '-arch ppc'. Save your changes. Leave the file open in your text editor, because we’ll come back to it.

Now we can finish configuring the environment before we compile the library.

cd ~/Downloads/ruby-oci8-1.0.0
export DYLD_LIBRARY_PATH=/Library/Oracle/instantclient/10.1.0.3
export SQLPATH=/Library/Oracle/instantclient/10.1.0.3
ruby setup.rb config
make
sudo make install

Now you can go back to your text editor and restore line 17, save your changes and exit.

Test connectivity

At this point, we’re done. We’ve fooled our system into running a PPC version of Ruby under Rosetta, and we’ve installed the ruby-oci8 library. Now it’s a question of making sure that it works:

ruby /usr/bin/irb

In the IRb console, type:

require 'oci8'

If the console returns true, you’re in business.

Configure your database.yml

The last step is to make your application use the Oracle connection. In your database.yml, use the following to make it work:

development:
adapter: oracle
database: your_instance_name
username: your_user_name
password: your_password

The database name comes straight out of your /Library/Oracle/instantclient/10.1.0.3/network/admin/tnsnames.ora file. You don’t need to specify any other connection information in database.yml, since the tnsnames.ora file has everything you need.

Your application is now talking to Oracle!

sudo gem install rails --source http://gems.rubyonrails.org

Then, enter “y” at each prompt, to install all of the dependencies. That’s it! Check yourself with:

rails -v

Right now it will show Rails 1.99.0 which is the current release candidate. When rails goes fully 2.0, the same instructions should work to get the full release installed.

And don’t forget, you can always rake rails:freeze to lock a Rails app to a particular version of Rails by copying all of the Rails libraries into the /vendor directory.

Happy coding!

Most recently, I wanted to code this algorithm:

If on the current page
  show <a href="blah1">link 1</a>
else
  show <a href="blah2>link 2</a>

Rails has, of course, the nifty link_to_unless_current, but all that does is show the text of the link:

If on the current page
  show link
else
  show <a href="blah">link</a>

That’s not quite what I’m looking for. But when I was looking up link_to_unless_current in the docs, I realized that there IS an else condition on link_to_unless_current. The function takes a block as its last parameter, and that’s what gives you the “else.”

This code, in a view:

<%= link_to_unless_current('Link text', my_url) { 'Alternate text' } %>

produces this algorithmic result:

If on the current page
  show Alternate text
else
  show <a href="my_url">Link text</a>

Mission accomplished.

My current job is really the first time I’ve had to use Windows regularly since Windows for Workgroups 3.11. That’s way back in 1995 when Windows 95 was still vaporware, much like Vista is now. Isn’t it already 3 years overdue? Anyway, that’s not relevant to this discussion.

I’ve had many discussions with people over the years about the old Mac vs. Windows debate. I’m no rabid Mac advocate: it’s not the best solution for all people at all times. Hardcore Windows users frequently complain that on the Mac there is no Registry, that you can’t really configure hardware devices etc. I would argue that on the Mac you don’t have to. It’s convention over configuration.

When I first started using a Mac, I had many of the same misgivings. Where were the menus with the bazillion options to choose from? Why couldn’t I regulate every little detail of the interface? As I used my Mac more, I realized that I didn’t have to. The configuration options I wanted were absent, but the need for them was absent as well. And I say the MacOS is better off for it, because it lowers the barrier to entry.

I frequently think about interface design in terms of my mom. I know, a lot of people do this, but it works. My mom has fought with Windows for years: it doesn’t do things the way she wants. What she doesn’t realize is that she probably can make it work the way she wants it to, if only she knew how. And therein lies the problem. It’s too complicated to get Windows configured just so, and so most users end up just living with it. Why should a $300 piece of software just be “lived with?”

The MacOS takes a different approach. It comes with a working configuration that is easier to use than what you get with Windows, and with fewer options. This means that the application and system interface isn’t cluttered with 1001 widgets all of which let you configure system, and so all you see are the features you want access to. This seems to be the goal of the UI revisions in “Office 12,” but they still don’t seem to have figured it out. Too many options mean that most of them just don’t get used.

If the system has good conventions, or default options, then you don’t have to spend your time fighting with it, and it generally does 95% of the tasks that 95% of users need done without any hassle. This is true of the Mac OS, and it’s true of RoR. The main difference is that the RoR folks have made their goal explicit.

Accomplishing 95% of what I want to do easily: that’s design elegance.

</epiphany>

But now I need to serve Rails as well. Getting Apache to do RoR with fcgi can be a hassle, and it’s apparently slow as well, so I decided to switch to lighttpd, or lighty as it’s called.

For development purposes, using the standard script/server is a no-brainer; however I want a “production” environment as well. One that can serve Rails, and legacy PHP, and do SSL for authentication, while talking to MySQL. I discovered that lighty can do all of these things, but how?

I looked around, and once you get to the deployment phase of RoR, there isn’t a lot of good information on the web, especially for smaller set-ups like mine; essentially, I’m almost the only person who hits my web server, as it houses some personal productivity stuff just for me that most other people don’t find interesting. That and my photo collection for friends to browse.

So I looked and looked, and found a lot of disjointed bits and bobs, but I didn’t find a good how-to for non-unix geeks. But, given the ease of use of lighty, I’ve put one together. Enjoy!

Requirements

1. Tiger (OSX 10.4)
2. XCode 2.0 or newer and developer’s tools
3. Patience and a nice snack while waiting for compiling to happen

Building Ruby, Gems, RoR, FastCGI, PCRE

Go to Dan Benjamin’s excellent instructions to do all of these things, and follow them well. However, stop when you get to the lighttpd instructions, because we’re going to make a change. Do this instead of what he says:

curl -O http://lighttpd.net/download/lighttpd-1.4.11.tar.gz
tar xzvf lighttpd-1.4.11.tar.gz
cd lighttpd-1.4.11
./configure --prefix=/usr/local --with-pcre=/usr/local --with-openssl
make
sudo make install
cd ..

The only difference is the addition of –with-openssl to the configuration, which will compile lighttpd with SSL (v2 and v3) support.

Building MySQL

You can choose to build MySQL according to the HiveLogic instructions, or you can use the MySQL 5.0 packages from the dolphin’s mouth, so to speak, and avoid the compile time. This works for version 4.1 as well. I’ve tried both versions with the setup described here, and both work.

Don’t forget to install the MySQL native bindings (again, from the HiveLogic instructions) as well.

But, I’ve already got this stuff working!

Chances are, you’ve already got a full setup that works, because you saw the HiveLogic instructions long before I ever wrote this page. If that’s the case, then all you need to do is follow my lighttpd compile instructions, which will over-write the pre-existing lighttpd version, with no ill effects.

Building PHP

First, download the PHP 5.1.2 full source code, and unpack the tarball by double-clicking it in the finder. I would recommend moving the unpacked “php-5.1.2″ folder to the same folder where you downloaded all of the source code from the hivelogic instructions.

Second, open a terminal, and execute the following commands:

./configure --enable-fastcgi --enable-discard-path --enable-force-redirect --with-zlib --with-xml --with-mysql=/usr/local/mysql --prefix=/usr/local/php5-fcgi --disable-cli --enable-memory-limit --with-layout=GNU --with-regex=php
make
sudo make install

When this is done, you’ll have a working cgi-fcgi version of PHP. We’ll hook this up to lighttpd in a minute, when we get to the lighty configuration files.

SSL

Before we start configuring lighty, we’ve got to get an SSL certificate. If you’re creating your own, you can follow the instructions from the lighty web site:

openssl req -new -x509 -keyout host.pem -out host.pem -days 365 -nodes

If you already have a certificate that’s a .crt and a .key file, you have to make them snuggle up into a single .pem file:

cat host.key host.crt > host.pem

Both of these methods result in a single .pem file, usually named “host.pem” where “host” is the name of the server you’re using the certificate for. This file can be stored anywhere you want on your system, since the lighty configuration takes an explicit path to it.

Configuring lighttpd

Now the more difficult part: we get to configure lighty. I’ll present the config files one chunk at a time, explaining what the various commands do. I’ve chosen to store mine in /etc/lighttpd/ to mimic how Apache stores its files (/etc/httpd/). Any path will do, just change the references to that directory in the coming intsructions.

First, we’ll set up 2 top-level files, which are both quite simple. They set up two nearly identical configurations for the lighty daemon, that run side-by-side. The first scans port 80, and serves http requests. Let’s call this file lighttpd.conf.

include "lighttpd_shared.conf"

server.port = 80

server.errorlog    = "/etc/lighttpd/lighttpd.error.log"
accesslog.filename = "/etc/lighttpd/lighttpd.access.log"

The first line causes lighty to parse the main configuration file, which we’ll go through below. The next line binds lighty to port 80, the default for http, and then we assign error log files.

We do something very similar for the other top-level file, the one that configures the SSL daemon. I’ve called mine lighttpd_ssl.conf.

include "lighttpd_shared.conf"

server.port = 443

server.errorlog    = "/etc/lighttpd/lighttpd_ssl.error.log"
accesslog.filename = "/etc/lighttpd/lighttpd_ssl.access.log"

ssl.engine         = "enable"
ssl.pemfile        = "/etc/lighttpd/host.pem"

In this case, we’ve bound the daemon to port 443, the default for secure connections. We’ve specified log files, and then enabled the SSL engine and specified the path to the .pem file.

By the way, the log files must exist before you run the daemon, and have the right permissions. To do this, simply touch the files, assign them to “www” and set the permissions:

cd /etc/lighttpd
touch lighttpd.error.log
touch lighttpd.access.log
touch lighttpd_ssl.error.log
touch lighttpd_ssl.access.log
sudo chown www *.log
sudo chmod 0666 *log

Now, on to the meat of the matter. Both of our top-level files parse the lighttpd_shared.conf file, so that both daemons run in parallel and do the same things. This means that all pages in our web server can be served with a regular or a secure connection. Here’s the meat:

server.modules = ( "mod_rewrite",
                   "mod_access",
                   "mod_fastcgi",
                   "mod_userdir",
                   "mod_accesslog" )

# Main folder containing web documents
server.document-root = "path/to/main/"

# Allow http://www.domain.com/~username/ style requests
userdir.basepath = "/Users/"
userdir.path = "Sites"
userdir.include-user = ("username") # only allow requests for this user (optional)

# If no file is specified, what to look for?
index-file.names = ( "index.html", "index.htm", "index.php" )

# Required event handler for OS X
server.event-handler = "freebsd-kqueue"

# Run the server under the user-name "www" for security purposes
# To bind to port 80, the server must be called by root user, but we don't want
# the server to have free run of the box, so it runs as "www"
server.username = "www"
server.groupname = "www"

# Set up the appropriate MIME type mappings
mimetype.assign             = (
  ".pdf"          =>      "application/pdf",
  ".sig"          =>      "application/pgp-signature",
  ".spl"          =>      "application/futuresplash",
  ".class"        =>      "application/octet-stream",
  ".ps"           =>      "application/postscript",
  ".torrent"      =>      "application/x-bittorrent",
  ".dvi"          =>      "application/x-dvi",
  ".gz"           =>      "application/x-gzip",
  ".pac"          =>      "application/x-ns-proxy-autoconfig",
  ".swf"          =>      "application/x-shockwave-flash",
  ".tar.gz"       =>      "application/x-tgz",
  ".tgz"          =>      "application/x-tgz",
  ".tar"          =>      "application/x-tar",
  ".zip"          =>      "application/zip",
  ".mp3"          =>      "audio/mpeg",
  ".m3u"          =>      "audio/x-mpegurl",
  ".wma"          =>      "audio/x-ms-wma",
  ".wax"          =>      "audio/x-ms-wax",
  ".ogg"          =>      "application/ogg",
  ".wav"          =>      "audio/x-wav",
  ".gif"          =>      "image/gif",
  ".jpg"          =>      "image/jpeg",
  ".jpeg"         =>      "image/jpeg",
  ".png"          =>      "image/png",
  ".xbm"          =>      "image/x-xbitmap",
  ".xpm"          =>      "image/x-xpixmap",
  ".xwd"          =>      "image/x-xwindowdump",
  ".css"          =>      "text/css",
  ".html"         =>      "text/html",
  ".htm"          =>      "text/html",
  ".js"           =>      "text/javascript",
  ".asc"          =>      "text/plain",
  ".c"            =>      "text/plain",
  ".cpp"          =>      "text/plain",
  ".log"          =>      "text/plain",
  ".conf"         =>      "text/plain",
  ".text"         =>      "text/plain",
  ".txt"          =>      "text/plain",
  ".dtd"          =>      "text/xml",
  ".xml"          =>      "text/xml",
  ".mpeg"         =>      "video/mpeg",
  ".mpg"          =>      "video/mpeg",
  ".mov"          =>      "video/quicktime",
  ".qt"           =>      "video/quicktime",
  ".avi"          =>      "video/x-msvideo",
  ".asf"          =>      "video/x-ms-asf",
  ".asx"          =>      "video/x-ms-asf",
  ".wmv"          =>      "video/x-ms-wmv",
  ".bz2"          =>      "application/x-bzip",
  ".tbz"          =>      "application/x-bzip-compressed-tar",
  ".tar.bz2"      =>      "application/x-bzip-compressed-tar"
 )

# Don't server these files statically, for security
static-file.exclude-extensions = ( ".fcgi", ".php", ".rb", "~", ".inc", ".pl", ".yml" )

# Use mod_access to deny direct access to files ending in ~ or .inc; these are usually
# code or backup files
url.access-deny             = ( "~", ".inc" )

# Disable auto-generated directory listings, for security
dir-listing.activate        = "disable"

# Disable range requests for PDF files
$HTTP["url"] =~ “\.pdf$” {
  server.range-requests = “disable”
}

# Set up a fastcgi server for PHP
fastcgi.server = ( “.php” => ((
                     “bin-path” => “/usr/local/php5-fcgi/bin/php”, # path to php binary
                     “socket” => “/tmp/php.socket”,
                 )))

# Now create virtual subdomains for each rails app we want; myrailsapp.domain.com
# Repeat the following block for each rails app, and for each one
# replace “myrailsapp” with the name of your application
# This sets up separate fcgi processes for each application

$HTTP["host"] =~ “^myrailsapp\.” {
     var.myrailsapp = “/path/to/rails/app”
     server.document-root = var. myrailsapp + “/public”
     server.error-handler-404 = “/dispatch.fcgi”
     fastcgi.server = ( “.fcgi” =>
                     ( “localhost” =>
                         ( “bin-environment” => (”RAILS_ENV” => “production”),
                           “bin-path” => var. myrailsapp + “/public/dispatch.fcgi”,
                            “socket” => “/tmp/myrailsapp.fcgi.socket”
                         )
                      )
                 )
}

You can tweak the fastcgi performance by using the lighttpd instructions for directives such as “min-procs” and “max-procs” but that’s up to you.

Lighty at startup

Wouldn’t it be nice if lighty launched at startup, and we didn’t have to worry about it? How about if it relaunched whenever it crashed? That would be even better. Save the following to /Library/LaunchDaemons/net.lighttpd.plist and watch the magic happen, thanks to froehle:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>net.lighttpd</string>
	<key>OnDemand</key>
	<false />
	<key>Program</key>
	<string>/usr/local/sbin/lighttpd</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/sbin/lighttpd</string>
		<string>-f/path/to/lighttpd.conf</string>
		<string>-D</string>
	</array>
</dict>
</plist>

Oh, wait, before the magic, there’s one more (/Library/LaunchDaemons/net.lighttpd_ssl.plist):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>net.lighttpd_ssl</string>
	<key>OnDemand</key>
	<false />
	<key>Program</key>
	<string>/usr/local/sbin/lighttpd</string>
	<key>ProgramArguments</key>
	<array>
		<string>/usr/local/sbin/lighttpd</string>
		<string>-f/path/to/lighttpd_ssl.conf</string>
		<string>-D</string>
	</array>
</dict>
</plist>

Of course, if you’ve installed the lighttpd binary someplace other than /usr/local/sbin then you should change those 2 lines in each .plist file, and you should specify the path to your .conf files properly.

Graceful restarts

Wouldn’t it be super-nice if we could issue graceful restart commands? It’s actually very easy in Tiger (10.4) since launchd monitors apps it has started, and re-opens them if they’ve quit or crashed. That means that all we have to do is cause a graceful shutdown, and launchd will take care of the restart for us. Put the following in /usr/local/sbin/ in a file called “lighttpdctl” (named after apachectl) with the appropriate path to your config files:

#!/bin/sh
sudo killall -9 lighttpd

Make it executable by doing this:

chmod u+x /usr/local/sbin/lighttpdctl

Now, from anywhere (since /usr/local/sbin is in our path), you can call lighttpdctl to do a graceful restart. Note, if you’re running a port 3000-bound script/server development instance of lighty, it will also quit.

We’re done

Well, almost. You now have to restart your machine to have launchd do its thing. If you issue the kill command to lighttpd and the configuration is bad (for whatever reason), and lighty bails on startup, launchd will no longer monitor the process. This means that when you’re mucking around, there’s a lot of sudo lighttpd -f/etc/lighttpd/lighttpd.conf -D from the prompt until you’ve got it working, followed by a restart. I’m pretty sure that there’s a better way to do the config debugging, but I’m not 1337 enough with FreeBSD and launchd-speak to do it any better. If somebody out there knows, please post it in the comments.

Enjoy!

script/server

trick for development to be fantastically useful. It’s quick to use, the server itself is fast, and it’s everything I could want. That is, until it’s time to go in to production mode. I’ve been running Apache, using OSX’s built-in build, but I’m considering switching my whole setup over to lighty because of the funkiness of Apache and Ruby’s fcgi. So I tried it. Building lighty was really easy. Getting lighty to then serve my static pages was also very easy. Then I tried getting it to serve my ruby apps, and that’s where the problems hit.

It turns out that my one big config problem was this: “url.rewrite” does not work inside a $HTTP["url"] matching block. So, for example consider this case, where I want to rewrite URL’s intended for my rails app which has 2 controllers, admin and view:

$HTTP["url"] =~ “^/input_path/” {
  url.rewrite-once (”/(admin|view)/(.*)” => “/some/other/path/$1/$2″)
}

If the incoming URL matches “/input_path/” then lighty starts processing the code inside the braces, but the url.rewrite-once fails to act. Instead, the server will invariably look for files inside /input_path/ and serve up a 404.

The proper way to do this sort of work with lighty is to have the regex do all the work:

url.rewrite-once ("^/input_path/(admin|view)/(.*)" => "some/other/path/$1/$2")

This isn’t documented anywhere on the lighty web site, but there is a message on the lighty mailing list that points out the problem.

I have to say, other than this hitch, I’ve been very impressed with the speed and ease of configuration that lighty offers. Once I get PHP to work with it, I’ll be a happy camper.

I recently had a rather interesting problem, however. My first teaching project was a little app to generate a bookmarks page, and it allows me to categorize bookmarks. Relatively straightforward, right? Well, I got the code to handle logging in, the categories, subcategories and bookmarks done just fine with no hitches, but then I wanted to test out caching.

In development.rb I set caching to true, and then enable page caching on my “view” controller &emdash; the one that is not behind the login and simply outputs the bookmarks list. I reload the page, and presto, the index.html page magically appears in my app’s public folder. “Sweet,” I think. I then edit one of the pieces of bookmark data, and my sweeper class kicks in, logs that it is expiring the page, and then expires the page.

  def expire_view(model)
    model.logger.info("Expiring the cached index")
    expire_page(:controller => "view", :action => "index")
  end

Except that the page doesn’t actually expire. What the f*@#!?!

After several days of poking around, trying action caching instead, and a few posts to various forums, I figured out what the problem was. I had reconfigured my routes.rb to essentially point all bogus URL’s to the view::index action, which was the page being cached. After I changed routes.rb back, the page started expiring. I’m guessing that :caches_page and expire_page() only work when there are single URL’s pointing to the page being cached. Has anybody else had a similar experience?