OpenBSD Journal

RubyOnRails + FastCGI in OpenBSD 4.0 Apache-chroot

Contributed by deanna on from the httpd_flags = "" dept.

Darrin Chandler wrote in to tell us about his tutorial on setting up Ruby On Rails with FastCGI in an OpenBSD chroot apache environment:

If you've ever moved anything into chroot before, then you probably feel confident that you could get Rails done in a couple of minutes. I thought I could, and I was wrong! However, after much head scratching, Googling, and poring over the same log files about a thousand times I have succeeded. The good news is that if you know the steps then you can make it all work in just a few minutes after all.

(Comments are closed)

Comments

  1. By martin (217.13.255.38) martin@bzero.se on

    Nice. An alternative to moving stuff into the chroot though, would be to use the chrooted apache to proxy to a mongrel instance listening on localhost, as described on http://mongrel.rubyforge.org/docs/apache.html. That page talks about apache 2, but I guess it can be done equally well in apache 1.3.

    Comments

    1. By Darrin Chandler (70.57.100.37) dwchandler@stilyagin.com on

      > Nice. An alternative to moving stuff into the chroot though, would be to use the chrooted apache to proxy to a mongrel instance listening on localhost, as described on http://mongrel.rubyforge.org/docs/apache.html. That page talks about apache 2, but I guess it can be done equally well in apache 1.3.

      There's been some mongrel activity on the ports list, so this might be easier in the future...

  2. By Pierre-Yves Ritschard (193.252.148.11) pyr@spootnik.org on

    FastCGI servers can be started standalone and even chrooted in their own jail. This would prevent you from installing all the libraries needed by ruby in the apache jail, an external FastCGI server can be accessed through a unix or internet socket using the FastCGIExternalServer directive in apache.conf once mod_fastcgi is loaded.

    Comments

    1. By Darrin Chandler (70.57.100.37) dwchandler@stilyagin.com on

      > FastCGI servers can be started standalone and even chrooted in their own jail. This would prevent you from installing all the libraries needed by ruby in the apache jail, an external FastCGI server can be accessed through a unix or internet socket using the FastCGIExternalServer directive in apache.conf once mod_fastcgi is loaded.

      Nice!

      I was very interested in keeping everything in chroot and my primary goal was to provide Ruby to more than one app, so this seemed the most straightforward way.

      But doing an external FCGI in its own chroot sounds promising as well, and if I get something working nicely with that I may extend the article. (Since it's part of our BUG site it's a work in progress.)

    2. By Anonymous Coward (74.115.21.120) on

      > FastCGI servers can be started standalone and even chrooted in their own jail. This would prevent you from installing all the libraries needed by ruby in the apache jail, an external FastCGI server can be accessed through a unix or internet socket using the FastCGIExternalServer directive in apache.conf once mod_fastcgi is loaded.

      This doesn't really work for ruby on rails though. It relies on apache to spawn more processes to handle load. It doesn't have any multi-threading or anything to handle concurrency on its own.

      Comments

      1. By Pierre-Yves Ritschard (88.138.189.74) pyr@spootnik.org on

        > > FastCGI servers can be started standalone and even chrooted in their own jail. This would prevent you from installing all the libraries needed by ruby in the apache jail, an external FastCGI server can be accessed through a unix or internet socket using the FastCGIExternalServer directive in apache.conf once mod_fastcgi is loaded.
        >
        > This doesn't really work for ruby on rails though. It relies on apache to spawn more processes to handle load. It doesn't have any multi-threading or anything to handle concurrency on its own.

        Exactly, ruby doesn't provide a ProcHandler but writing a simple one isn't that hard and sample code can easily be found. I should have mentionned that this method of running RoR needs a lot more work.

  3. By vsy (70.95.32.79) on

    Amazing! This is EXACTLY what I've been trying to get to work for the past couple of weeks (with 3.9 and 4.0). Even following these instructions to the letter and massive amounts of googling didn't help me. (fcgi processes kept dying once the chrooted environment started up) Can't wait to try out this out...

  4. By David Chisnall (137.44.2.39) on

    On the subject of FastCGI, does anyone know when the PHP package is going to get a fastcgi flavour? It would be very useful for those of us that use Lighttpd instead of Apache. I believe a patch was submitted a few months ago, but it doesn't seem to have appeared.

    Comments

    1. By Jedi/Sector One (82.224.188.215) on http://forum.manucure.info

      > On the subject of FastCGI, does anyone know when the PHP package is going to get a fastcgi flavour? It would be very useful for those of us that use Lighttpd instead of Apache. I believe a patch was submitted a few months ago, but it doesn't seem to have appeared.

      I use Lighttpd with PHP/FastCGI on OpenBSD for about one year without any issue.

      Here's the current port I use :
      ftp://ftp.fr.pureftpd.org/OpenBSD/misc/ports/php5-with-fastcgi-openbsd-4.0-current.tar.gz


  5. By daddy2times (134.174.91.98) on

    First, thanks for this. I have several small rails apps that I want to deploy on OpenBSD.

    Second, I hope I'm not asking the obvious--and I did spend about an hour or so in vain last night searching for an answer:

    What is the reason for the rubygems and various rails-related gem package ports and packages? Is it for convenience, or are these packages heavily patched by the ports team?

    Why not just `sudo pkg_add ruby`, download rubygems-0.9.0.tgz, untar/gunzip, `sudo ruby setup.rb`, then `sudo gem install rails --include-dependencies`?

    Am I missing something critical here?

    Thanks!

    Comments

    1. By Anonymous Coward (74.12.78.83) on

      >
      > What is the reason for the rubygems and various rails-related gem package ports and packages? Is it for convenience, or are these packages heavily patched by the ports team?
      >
      > Why not just `sudo pkg_add ruby`, download rubygems-0.9.0.tgz, untar/gunzip, `sudo ruby setup.rb`, then `sudo gem install rails --include-dependencies`?
      >
      > Am I missing something critical here?
      >

      Probably the same reason why there are so many Perl ports/packages: to make the pkg_* tools aware of them so they're easier to manage. Anything added via CPAN does not show up in pkg_info.

    2. By Jedi/Sector One (82.224.188.215) on http://forum.manucure.info

      > First, thanks for this. I have several small rails apps that I want to deploy on OpenBSD.
      >
      > Second, I hope I'm not asking the obvious--and I did spend about an hour or so in vain last night searching for an answer:
      >
      > What is the reason for the rubygems and various rails-related gem package ports and packages? Is it for convenience, or are these packages heavily patched by the ports team?
      >
      > Why not just `sudo pkg_add ruby`, download rubygems-0.9.0.tgz, untar/gunzip, `sudo ruby setup.rb`, then `sudo gem install rails --include-dependencies`?
      >
      > Am I missing something critical here?
      >
      > Thanks!

      Well, that way, ports can properly install the right dependencies, including specific versions.

      But indeed, this is a bit lousy. Because not every packages is available and most packages are outdated. The same thing applies to CPAN, PEAR and gems. So to be fair I do exactly like you do: install the minimal packages, then use CPAN/PEAR/gem to install the rest and to keep it up to date.

  6. By Anonymous Coward (172.191.237.130) on

    I spent several hours last night futzing with a chrooted lighttpd connecting to a fastcgi program written in C. I figured out the library/ldconfig bit on my own, but am stuck on a particular error (not at that workstation now, will copy-paste later).

    The vast majority of the Google results for FastCGI seem to be PHP/Ruby oriented. I've been keeping a log of the steps required to get things to work for later publication on the web. Does anyone know of any writeups for an OpenBSD-specific non-PHP/Ruby fastcgi?

    Comments

    1. By Pierre-Yves Ritschard (193.252.148.11) pyr@spootnik.org on

      > I spent several hours last night futzing with a chrooted lighttpd connecting to a fastcgi program written in C. I figured out the library/ldconfig bit on my own, but am stuck on a particular error (not at that workstation now, will copy-paste later).
      >
      > The vast majority of the Google results for FastCGI seem to be PHP/Ruby oriented. I've been keeping a log of the steps required to get things to work for later publication on the web. Does anyone know of any writeups for an OpenBSD-specific non-PHP/Ruby fastcgi?


      You could start by looking at the documentation for the perl module included with www/fastcgi. Everything you need to have a small external server is in there.
      www/py-jonpy has the same kind of features but for python.

      Writing a FastCGI server in C without any libraries is a bit painful, I'd use the provided module for a quick project.

      Comments

      1. By Anonymous Coward (172.191.1.101) on

        I will probably end up using Perl, but I wanted to get the process down with a simple program first. Under advice from irc.freenode.net/#lighttpd, I pkg_delete'd the OpenBSD lighttpd pkg, I downloaded and installed 1.4.13 from lighttpd.net but the problem remains.

        Only one of the spawned fcgi procs ever gets used to handle web requests. Other requests sit and wait for the previous request in the queue to finish. I was under the assumption that the whole point of this was to roundrobin requests to the spawned fcgis. This behaviour happens when using either domain or tcp/ip sockets, and using either spawn-fcgi launched fcgis or having lighttpd do it (using bin-path).

        I'll stop article-hijacking now. :P

  7. By Anonymous Coward (130.220.79.178) on

    Ok, so what was the hard bit to get going?
    This looks like a standard jail setup to me - copy libs to chroot (following the output of ldd), copy or generate an ld.so.hints, tweak httpd.conf.

    Are there any dlopen()ed libs that made this tough?

    Comments

    1. By Darrin Chandler (70.57.100.37) dwchandler@stilyagin.com on

      > Ok, so what was the hard bit to get going?
      > This looks like a standard jail setup to me - copy libs to chroot (following the output of ldd), copy or generate an ld.so.hints, tweak httpd.conf.
      >
      > Are there any dlopen()ed libs that made this tough?

      I left out all the parts where I was stumped. ;) I thought about writing a narrative, but really I just wanted to get the steps down.

      The ldd stuff is easy, but that won't get you very far with Rails. Once you're in Ruby-land you're relying on Ruby's "stack dump" which can be less than informative.

      Ruby will give the same error if it can't find a *.rb file, or if it did find it but that file relies on a missing *.so and it won't load, etc. So the dependancies are all that obvious. Or at least they weren't obvious to me.

      There's no magic in the steps I gave, and nothing clever. But trying to get it working I came across roadblocks and a lot of web pages that gave only some of the puzzle, or were flat wrong.

      Comments

      1. By grg (122.49.141.212) on

        I've always found ktrace(1) to be useful for non ldd stuff. 
        $ ktrace /bin/ls /* >/dev/null
$ kdump |grep "open(" -A1
 29681 ls       CALL  open(0x3c000663,0,0)
 29681 ls       NAMI  "."
 29681 ls       CALL  open(0x87fa7000,0x4,0x1)
 29681 ls       NAMI  "/altroot"
 29681 ls       CALL  open(0x87fa7000,0x4,0x87fbf000)
 29681 ls       NAMI  "/altroot"
 29681 ls       CALL  open(0x87fa7000,0x4,0x8b359000)
 29681 ls       NAMI  "/bin"
 29681 ls       CALL  open(0x87fa7000,0x4,0x3fc)
 29681 ls       NAMI  "/dev"
 29681 ls       CALL  open(0x87fa7000,0x4,0x3fc)
 29681 ls       NAMI  "/etc"
 29681 ls       CALL  open(0x87fa7000,0x4,0x3fc)
 29681 ls       NAMI  "/home"
 29681 ls       CALL  open(0x87fa7000,0x4,0x7ec82000)
 29681 ls       NAMI  "/home"
 .
 .

        Comments

        1. By grg (122.49.141.212) on

          hmmm... perhaps grepping for NAMI would be better.

  8. By Anonymous Coward (85.194.225.225) on

    Fine but,

    OpenBSD and Ruby = no unicode support:(

    Comments

    1. By Jonathan Rockway (66.92.134.156) jon@jrock.us on http://blog.jrock.us/

      > Fine but,
      >
      > OpenBSD and Ruby = no unicode support:(

      Maybe you would prefer Perl and Catalyst instead?

      Incidentally, I have an article about running Catalyst with a chroot httpd here:

      http://www.catalystframework.org/calendar/2006/4

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]