Run Rails 3 Apps on Passenger

Update: Make sure you update Rubygems using sudo gem update –system.

Whilst I’ve been learning more about Rails 3, I’ve been using the built in rails server to run my code. Today I tried to run my Rails 3 app through Passenger on Apache, and immediately hit an error page:

uninitialized constant Rack::Runtime

It turns out that Passenger notices Rails’ new config.ru file, causing it to run as a Rack application. This requires a slight change in the app’s VirtualHost entry. The RailsEnv setting now becomes RackEnv:

# /etc/apache2/apache2.conf
# RailsEnv development
RackEnv development

But that wasn’t all. My development machine was still running Passenger 2.2.7, which wouldn’t support Rails 3. To ensure a clean slate, I removed the old versions of Passenger and installed the latest build (2.2.11 at the time of writing). Once installed, I ran the standard Passenger installation script and updated apache2.conf:

$ sudo gem update --system
$ sudo gem uninstall passenger
  # Remove all versions of Passenger
$ sudo gem install passenger
$ sudo passenger-install-apache2-module
# /etc/apache2/apache2.conf
# Passenger mod_rails
# NOTE: Your paths may be different. Use the config generated by Passenger's install script)
LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.11/ext/apache2/mod_passenger.so
PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.11
PassengerRuby /usr/bin/ruby1.8
 
RailsEnv development
RackEnv development

After a quick restart of Apache, Passenger kicked in and my new Rails 3 app was up and running!

References

Changed Permalinks and More Blog Tweaks

I’m really liking Jekyll as a blog engine, and have been tweaking a few things on the site. One big change is permalinks. To follow Jekyll’s preferred convention, I’ve switched my post’s permalinks from /blog/YYYY/MM/DD to just /YYYY/MM/DD. Thanks to Apache’s mod_rewrite, old links will still work, but I find mod_rewrite rules a bit of a dark art. So, for convenience and future reference, here are the rules I’ve used:

# .htaccess
RewriteBase /
# Don't redirect if URL is a real file
RewriteCond %{REQUEST_URI} !-f
# Redirect requests for /blog/some/page.html to /some/page.html
RewriteCond %{REQUEST_URI}% ^/blog(.*)
RewriteRule blog/(.*) http://chrisblunt.com/$1 [R=301,NC,L]
 
# Redirect requests for /feed to Feedburner
RewriteCond %{REQUEST_URI}% ^/feed/?(.*)
RewriteRule ^(.*) http://feeds.feedburner.com/chrisblunt [R=301,NC,L]

For now, the changed permalink structure means that Disqus comments are not available. I’ve contacted Disqus about this though, and hope to move those comments to the new format soon.

In the meantime, everything else seems to be running smoothly on Jekyll. I’ve tweaked my site’s design back to a fairly minimal theme – influenced by other Jekyll sites that I’ve seen.

I’ve kept deployments simple too; rather than using git hooks, I use a Rakefile and rsync combination based on this post. The Rakefile lets me use a fork of Jekyll to compile and upload the site with a simple call to rake deploy:

# /Rakefile
def jekyll(opts = "", path = "../jekyll/bin/")
  sh "rm -rf _site"
  sh path + "jekyll " + opts
end
 
def rsync(options = {})
  options = {
    :domain => 'servername',
    :deploy_to => 'filesystem path',
    :port => ssh_port,
    :user => 'ssh_username'
  }.update(options)
 
  sh "rsync -rtz -e 'ssh -p #{options[:port]}' _site/ #{options[:user]}@#{options[:domain]}:#{options[:deploy_to]}/"
end
 
desc "Perform a jekyll rebuild of the site"
task :build do
  jekyll
  Rake::Task["sitemap:build"].invoke
end
 
desc "Serve on Localhost with port 4000"
task :local do
  jekyll("--server --auto --limit-posts 5")
end
 
desc "Rebuild and Deploy to Live"
task :deploy => :build do
  rsync
  Rake::Task["sitemap:ping"].invoke
end
 
desc "Deploy the currently cached build to Live"
task :cached do
  rsync
  Rake::Task["sitemap:ping"].invoke
end
 
namespace :sitemap do
  desc "Rebuild the sitemap.xml using gen_sitemap.rb"
  task :build do
    generate_sitemap_bin = File.dirname(__FILE__) + "/_tools/gen_sitemap.rb"
    cmd = "cd _site && ruby #{generate_sitemap_bin} '.' > sitemap.xml"
    `#{cmd}`
  end
 
  desc 'Notify Google of the new sitemap'
  task :ping do
    require 'net/http'
    require 'uri'
    Net::HTTP.get(
        'www.google.com',
        '/webmasters/tools/ping?sitemap=' +
        URI.escape('http://chrisblunt.com/sitemap.xml')
    )
  end
end

Overall everything feels a lot lighter and easier to manage, and vim now sits at the heart of my blog workflow. This is great as I find it hard work to use any other text editor since learning vim. Static HTML means the site is served quickly as well, and I feel safe in the knowledge that my data is stored in a git repository rather than a single database.

One caveat is that the site can’t include external dynamic content; at least not without some Javascript. I figure, though, that there are plenty of ways to follow my Twitter ramblings or photostreams and so on without adding distraction to the site.

So hopefully the transition is complete. Once the Disqus comments are linked, I’ll be able to get back to writing some content to fill the blog! There’s plenty to write about, with the recent release of Rails 3 beta, and my upcoming travels. I’ll also document more about Amberleaf‘s development, post more Rails tips as I learn, and discuss a new mobile app for Android I’m starting.

Are you using Jekyll or something similar to power your site? How have you found the transition if you’ve switched from bigger engines like WordPress or Mephisto?

PHP: Fixing Mismatched Canaries – How to Remove suhosin from Debian/Ubuntu Packages

30 August 2009: Will’s comment notes that Debian Squeeze now has an updated php5-suhosin package that may fix the problem I discuss below.

Having recently moved our development environment at work to a stock Debian 5 machine, some of our PHP code was throwing the following strange error in the apache (not the PHP) error log:

canary mismatch on efree() - heap overflow detected ...

After some research, it turns out this somewhat strange error is caused by the suhosin patch that is compiled into Debian’s default PHP5 package. In my case, it was some calls to mssql_query were throwing the error in Apache.

Updating the php.ini file to switch suhosin into simulation mode (as suggested by the documentation) didn’t have any effect, so I set about recompiling PHP5 into a new deb package without the suhosin patch.

This was the best tutorial I found for recompiling the deb. I’ve recreated the instructions below:

Create a working folder somewhere on your machine:

$ mkdir ~/packages
$ cd ~/packages

Install the Debian development packages

$ sudo apt-get install devscripts
$ sudo apt-get install gcc debhelper fakeroot
$ apt-get source php5
$ sudo apt-get build-dep php5

These lines will install the development helper scripts, and download the source files for PHP5 and its dependencies.

Remove references to the suhosin patch

$ cd php5-x.y # This will depend on the version of PHP
$ rm debian/patches/suhosin.patch

You now need to remove the instruction to include suhosin in the compiled package. I’ve used vim, but you can use any text editor.

$ sudo vim debian/patches/series

Once open, remove the line referencing suhosin.patch

Increment the package version
Incrementing the version will ensure that your custom package is installed by apt-get. You can use the debchange script to achieve this. You should avoid mentioning suhosin in the version name, and instead append a custom version string, e.g:

$ debchange -v 5.2.6-1debian.5.0~custom1 # 5.2.6 was my distro's default version. Again, change to match the default php version for your distrubution

Your text editor will open, and you should update the changelog to mention that you have removed the suhosin patch.

Compile and Build the Package

$ debuild

The build took a while on my machine, so now’s a great time to grab a brew.

Once finished, you should have a set of debs ready to install in the parent folder (../php5…).

$ dpkg -i php5-x.y.z.deb php5-common-x.y.z.deb php5-sybase-x.y.z.deb
# Include any additional packages you use, e.g. php-pear
php5 php5-common php5-sybase (the PHP5 MSSQL connector package)

The build process also creates a libapache2-mod-php5 package which I had to install to use the custom of build of PHP5 through Apache using dpkg:

$ dpkg -i libapache2-mod-php5-x.y.z # Use the new PHP5 in Apache2

Via: Original Instructional Post[http://ambitonline.com/]