Rails on Windows XP (was Re: [Rails] Hosting multiple rails apps under mod_ruby)

[Sean O'Halpin]

>
>Does anyone have pointers for setting up FastCGI under Windows?
>
>Gavin

After many hours of banging my head against a wall, I found it
impossible to get FastCGI working with Apache 2.0 on XP Pro.
The CGI applications ran but no output ever got back to the browser.
I'd be very interested to hear from anyone who has got Rails working with 
FastCGI on XP.

However, I do have a workable setup which I present below.

I have a number of WEBrick servers running on their own ports with Apache 
providing
the virtual hosting. This works fine for my purposes (low hit volume, 
database intensive
intranet webapps) and delivers reasonable (if not screaming) performance.

This works out of the box with Apache on port 80 but you'll need a patch if 
you want
to have Apache itself running on a non-standard port
(see http://www.ohalpin.com/downloads/rails_patches.rb for one possibility).

= Setup

For development, I run Apache on localhost port 9000 and
for each application have a CGI virtual host
(for testing code changes on the fly - slow but bearable) and a WEBrick one
(for application testing and use - much better performance but requires 
restarts
for changes to controllers and libs).

The CGI and WEBrick virtual hosts for each application share the same code
and configuration but are separate from other Rails applications.

This is what I have in my C:\WINDOWS\system32\drivers\etc\hosts file
(for my Rails test bed blog app):

  127.0.0.1   blog.cgi
  127.0.0.1   blog.webrick

= Apache config

The relevant bits of Apache's httpd.conf look like this:

  LoadModule proxy_module modules/mod_proxy.so
  LoadModule proxy_http_module modules/mod_proxy_http.so

  # [snip]

  #
  # Turn off unrestricted proxying through this server
  #
  ProxyRequests Off
  #
  # Listen on port 9000
  #
  Listen 9000
  #
  # Use name-based virtual hosting.
  #
  NameVirtualHost *:9000
  #
  # Rails blog
  #
  # CGI host
  #
  <VirtualHost *:9000>
      ServerName      blog.cgi
      DocumentRoot    c:/web/blog2/public
      ErrorLog        c:/web/blog2/log/apache.log

      <Directory c:/web/blog2/public>
          Options +ExecCGI FollowSymLinks
          AllowOverride all
          Allow from all
          Order allow,deny
      </Directory>
  </VirtualHost>
  #
  # WEBrick host
  #
  <VirtualHost *:9000>
    ServerName        blog.webrick
    ErrorLog          c:/web/blog2/apache-vhost.log
    ProxyPass         /   http://127.0.0.1:3000/
    ProxyPassReverse  /   http://127.0.0.1:3000/

    <Location />
          Order allow,deny
          Allow from all
    </Location>
  </VirtualHost>

Obviously, you'd need to change the paths to suit your installation
and the WEBrick port (3000 in this case) to the particular port your
application WEBrick server is running on.

For port free urls, I just change the 9000 to 80.

= Sessions

You also need to make sure your application sessions are kept separate -
otherwise you'll get classes from different applications stored in the
same session which confuses Rails (not surprisingly).

For that I have the following in dispatch.rb (for WEBrick):

  Dispatcher::DEFAULT_SESSION_OPTIONS.update(
    {
    "database_manager" => CGI::Session::PStore,
    "prefix" => "rails_blog_webrick.",
    "session_path" => "/"
    })

and dispatch.cgi (for CGI):

  Dispatcher::DEFAULT_SESSION_OPTIONS.update(
    {
    "database_manager" => CGI::Session::PStore,
    "prefix" => "rails_blog_cgi.",
    "session_path" => "/"
    })

before the call to Dispatcher.dispatch. The prefix keeps the various 
applications separated.

You could also use the ActiveRecordStore if you don't mind hitting the 
database for
every access to sessions and sharing sessions between the CGI and WEBrick 
versions (which
doesn't cause a problem in my experience). This works as long as each 
application uses its own database.

However, the ActiveRecordStore needs a bit of work to handle multiple 
applications using
the same database (e.g. you could add an 'application' field to the 
configuration and table).

I haven't tested the DRb session store thoroughly yet so I can't offer any 
advice about it
though from my initial tests it appears that it too needs a bit of beefing 
up
to handle multiple applications cleanly.

I'm still in the development stage but I'm satisfied that this setup will
be more than adequate for the kind of applications I am building.

If like me you find that you can't get FastCGI to work, give the above a 
whirl
to see if it meets your needs.

Best of luck!

Sean O'Halpin

_________________________________________________________________
Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo