From: Thomas Fini Hansen <beast@...>
Date: 2004-03-13T23:19:55+09:00
Subject: Re: convincing a webhost to support ruby

On Fri, Mar 12, 2004 at 11:41:47AM +0900, David Garamond wrote:
> Mark Hubbart wrote:
> >They are a large webhost, with a decent-sized server farm. So they would 
> >probably be wanting to roll it out on all of them, or none of them. 
> >Also, they use the debian packages when possible.

Yeah. We're not big but I prefer debs too. And preferbly from stable,
but something like backports.org can be acceptable.

At our place, getting Ruby on your site would probably involve calling
us, expressing said wish, getting invited down for cofffee (or a beer
perhaps), getting 'checked out' and if you seem like a dencent guy, me
adding da magick to the httpd.conf.

You would probably have an easier time getting a date with the boss'
daughter. 

> If they run a shared hosting environment (where a single Apache daemon 
> is used by all users on the same machine), then fastcgi is probably the 
> easier path. I don't know how mod_ruby can be secured in a shared 
> environment, but last time I checked mod_perl can't (meaning it can't be 
> configured to prevent a user to poke inside Apache and do dangerous things).

In our configuration, everything is owned by www-data, and it's ProFTP
that takes care of the logins. No ssh access, 99.9% of our customers
barely handle FTP as it is. PHP is locked up with safemode and
open_basedir. There is no user accounts.

Now, I've been pondering how we could offer Ruby. I'd happily spend a
couple of hours setting it up if it could convince just one customer
to use Ruby. But as much as mod_ruby makes the coder in me wet his
pant, as much it scares the living daylights out of the paranoid
sysadmin.

I was thinking that it must be possible to make another version of the
Apache::ERubyRun class, that redefines File.open and friends (to
simulate openbase_dir, and whatever else needs to be locked down), and
drops to a higher $SAFE, before loading the script. Perhaps wrapping
the script in its own module to avoid clashing (OK, I admit to not
quite know what I'm talking about here, but I remember that rbot runs
its plugins in an annonymous module).

Ideas people? I was thinking about mailing some of the ISPs that offer
Ruby to hear how they did, but if it's all based on Apache 2 and using
it's ability to run as mutiple users, it's not an option yet.

How about FastCGI? If there's not seperate local users, would it
change anything?

-- 
Thomas
beast@system-tnt.dk