Changes:

0.1.0 / 2010-07-14

• 1 major enhancement

  • Birthday!

• http://bitbucket.org/krbullock/xpgrep

I quickly discovered that the REMOTE_USER environment variable, which for a CGI app would contain the username which was authenticated by Apache, doesn’t get passed via the proxying magic to Rails (when run via mongrel or the like). My Google-fu turned up this thread, which has a solution that sets an X-Forwarded-User header to the value of REMOTE_USER. That header gets passed on in the proxied request to the Rails app. Here’s the magic incantation:

RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule . - [E=RU:%1]
RequestHeader add X-Forwarded-User %{RU}e

It put me on the right track, but still wasn’t working. There’s two problems with the solution given there:

1. The RewriteRule only matches the root URL of the application (the . matches any single character). Back to regex class. It should read ^.*$, that is, match all URLs.

1. It uses mod_rewrite’s ‘lookahead’ to determine the final (post-rewriting) value of REMOTE_USER. I, however, am using this in a directory configuration context, which for esoteric implementation reasons doesn’t require lookahead—we can use the REMOTE_USER variable directly.

Here, then, is my final config, added before the rest of the normal Rails .htaccess rules:

RewriteCond %{REMOTE_USER} (.+)
RewriteRule ^.*$ - [E=RU:%1]
RequestHeader add X-Forwarded-User %{RU}e

Using the X-Forwarded-User header in Rails

The other thing that the aforementioned post didn’t tell me was how to use the forwarded header once Apache was forwarding it. Rails doesn’t do anything automatically with an X-Forwarded-User header; you have to get at it in your controllers through the request object. I added the following method to ApplicationController (and used helper_method to make it available to views):

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  def http_remote_user
    request.env['HTTP_REMOTE_USER'] || request.headers['X-Forwarded-User']
  end
  helper_method :http_remote_user
end

It checks first for the HTTP_REMOTE_USER environment variable, so that if you want to deploy your app differently you don’t need to change the code.

You could write a before_filter to enforce authentication, but I’ll leave that as an exercise for the reader. For this app, I need to know the authenticated username, but I don’t want the app to have anything more to do with authentication. The above does the job handily.

Changes:

2.1.0 / 2010-06-04

• 1 major enhancement

  • Add support for deploying with a patch queue. Useful e.g. for setting up a staging site with minor changes to the production configuration.

• http://hitsquad.rubyforge.org/vlad-hg/

• http://rubyforge.org/projects/hitsquad/

• http://bitbucket.org/krbullock/vlad-hg/

I think it still has some advantages over other solutions that have been posted:

• It completes long options (--trace, --execute-print, etc.).

• It falls back to completing filenames. I find this most useful for running just one set of tests, e.g.:

  $ rake test:units TEST=test/unit/
  bar_test.rb  foo_test.rb  helpers/

• It handles colons for namespaced tasks correctly, without resorting to setting COMP_WORDBREAKS globally.

• It doesn’t rely on an external script, which means it only has to fire up one Ruby interpreter (to run rake) instead of two (to run a Ruby completion script that runs rake).

It doesn’t cache the task list, so it still requires a call to rake --tasks on every <TAB>. I may add caching support later.

Here it is for your inspection and enjoyment:

LiveJournal peeps, I’m back.

Update 10 Oct 2009: Feed URLs are now redirected to their new locations.

Update: I’ve successfully built the mysql gem against MySQL installed via a 64-bit fink as described below. Here’s the incantation I used:

$ sudo env ARCHFLAGS="-arch x86_64" gem install mysql -- \
    --with-mysql-dir=/sw64

Updating Fink

Since I was upgrading from Leopard, I already had a 32-bit install in /sw. Following the upgrade instructions made what I already had work again. Updating my installed packages was another matter. Here’s the issues I ran into on a fink update-all, and how I solved them:

1. pango1-xft2-ft219 ran into some issues with missing .la files. The fix suggested on the fink-users list worked for me, although I can’t guarantee it won’t break something later.

2. boost1.35.nopython passes -Wno-long-double to GCC. The version of GCC in Snow Leopard doesn’t have that flag, and errors out if you try to use it. I fixed it by copying fink’s package info (boost1.35.info and boost1.35.patch) to the local/main package tree (/sw/fink/dists/local/main/finkinfo/), and fixing the patch to remove the -Wno-long-double option.

   The result is available on bitbucket. Just copy 32bit/boost1.35.* into the aforementioned local/main package tree on your fink install, run fink index, and then fink install boost1.35-nopython.

Installing a 64-bit Fink

Next up was getting my gems, in particular RMagick, working with Snow Leopard’s shiny new 64-bit Ruby. Since it’s 64-bit, you can’t build gems against your 32-bit libraries installed through fink. But no matter—it turns out to be possible (even relatively easy) to set up two fink installs, one 32-bit and one 64-bit. Here’s how to do it:

1. Follow the instructions from the fink website to bootstrap a 64-bit install into /sw64, leaving the existing 32-bit install alone.

2. Skip adding . /sw64/bin/init.sh to your login scripts, leaving the 32-bit install as the default. Instead, when you want to use the 64-bit version, execute that line from the terminal. Now just that terminal window will default to 64-bit fink.

Once I’d done the above, it was just a matter of running fink install imagemagick, and then sudo gem install RMagick… oh, but wait, no.

See, RMagick is picky about the configure options you use to build ImageMagick; it doesn’t work with HDRI support enabled (whatever that is). Fink’s imagemagick package has it enabled by default, so I again took to customizing the Fink package info and putting it in the local/main repository (in this case at /sw64/fink/dists/local/main/finkinfo/), changing --enable-hdri to --disable-hdri. Once again, the result is available on bitbucket in 64bit/imagemagick*.

So once I’d finished that, I ran fink index and fink install imagemagick again, and the RMagick gem installed fine. Yay!

My next endeavor will be to try to install a 64-bit MySQL thru fink, but for now I’ve handled that by installing the MySQL 5.1 package from mysql.com.

Also note: I haven’t tested any X11 apps under fink64 yet. Not installing the fink64 xinitrc might break things horribly.

I’ve been playing with hg-git for the past couple weeks off-and-on (Abderrahim Kitouni’s fork—and so should you). Today I decided to try to use it to provide git mirrors of my projects. It took a bit of futzing around to figure out how to set it up, but as you can see above, it’s smooth like buttah. Here’s how I did it.

        <span id="more-1366"></span>

        <ol>

$ wget http://samba.org/~jelmer/dulwich/dulwich-0.3.3.tar.gz
$ tar xvzf dulwich-0.3.3.tar.gz
$ (cd dulwich-0.3.3 && sudo /usr/bin/python setup.py install)


$ wget -O hg-git.tar.gz http://bitbucket.org/abderrahim/hg-git/get/tip.gz
$ (cd /path/to/hgext && tar xvzf /path/to/download/hg-git.tar.gz)

[extensions]
hg_git = /path/to/hgext/hg-git

git@github.com:krbullock/vlad-merb.git

git+ssh://git@github.com/krbullock/vlad-merb.git

[paths]
github = git+ssh://git@github.com/krbullock/vlad-merb.git

$ hg push github

Boom. Done.

Description:

Merb support for Vlad. Prior to 2.0.0, Vlad included support to make vlad:start and vlad:stop work with Merb; this plugin adds Merb support back in, and makes it a bit more robust.

Changes:

2.0.0 / 2009-09-05

• 3 major enhancements

  • Birthday!

  • Bring Merb support up to speed with recent versions of Merb.

  • Add deploy variables to run Merb as another user, and to be able to use sudo.

If you’re not using either Git or Mercurial (hg) (or Bazaar or some other appropriate DVCS), you should be. I prefer hg, but I think git is generally fine. Scott Chacon, however, thinks that git is unquestionably better than hg, for three specific reasons I intend to counter here, with reference to Geoffrey Grosenbach’s recent post on the matter.

Update 2 Sep 2009: See this post by Steve Losh for more on the branching issue.

Update 2 Oct 2009: Scott Chacon is not an idiot (nor did I mean to even imply that he was!), and has demonstrated his not-idiotness by apologizing “for being a tool” (his words).

        <span id="more-1325"></span>

        <ol>

I don’t mean to say that hg is better than git. It has its weaknesses as well—but these aren’t them.

I’ve taken over development of Mercurial support for Vlad, and with the latest release (2.0.0), it’s been split out into a plugin (along with Perforce support, with more to come). So, to get Mercurial support back, just

$ gem install vlad-hg

and continue to use your existing deployment recipes.

We’ll likely be moving vlad-hg from its own lonely home into the hitsquad RubyForge project, so Vlad and all its plugins will be available from the same location. Stay tuned.