Convincing a webhost to support ruby

ruby-talk
1

Hi all,
I’ve been putting together an argument to convince my webhost to
support ruby and eruby on their servers. Right now, they have ruby
1.6.7 installed, with no extras (ie., no mod_ruby, eruby, irb,
anything).

Based on past threads here, I’m thinking that FastCGI is the way to go.
So I’m planning on suggesting that they:

  • Update Ruby to the latest stable version (which, iirc, includes eruby)
  • Install mod_fastcgi

My arguments for this would be:

  • installing mod_fastcgi would benefit all customers, perlers,
    pythoners, etc.
  • updating Ruby would fix any bugs, while still retaining compatibility.
  • They could be put on a list of recommended ruby-supporting
    webservers, potentially getting more customers.

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.

Any thoughts? Should I suggest mod_ruby instead? How
stable/accepted/easy to maintain is fastcgi? Pros/cons I didn’t think
of? :slight_smile:

Thanks, Mark

2

Con:

Debian packages aren’t the fastest to reflect stable releases. Your hosting
provider may only wish to use Debian stable packages. Hence Debian still
installs Ruby 1.6.7 and Perl 5.6.

Good Luck,

Zach

···

-----Original Message-----
From: Mark Hubbart [mailto:discord@mac.com]
Sent: Thursday, March 11, 2004 5:44 PM
To: ruby-talk ML
Subject: convincing a webhost to support ruby

Hi all,
I’ve been putting together an argument to convince my webhost to
support ruby and eruby on their servers. Right now, they have ruby
1.6.7 installed, with no extras (ie., no mod_ruby, eruby, irb,
anything).

Based on past threads here, I’m thinking that FastCGI is the way to go.
So I’m planning on suggesting that they:

  • Update Ruby to the latest stable version (which, iirc, includes eruby)
  • Install mod_fastcgi

My arguments for this would be:

  • installing mod_fastcgi would benefit all customers, perlers,
    pythoners, etc.
  • updating Ruby would fix any bugs, while still retaining compatibility.
  • They could be put on a list of recommended ruby-supporting
    webservers, potentially getting more customers.

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.

Any thoughts? Should I suggest mod_ruby instead? How
stable/accepted/easy to maintain is fastcgi? Pros/cons I didn’t think
of? :slight_smile:

Thanks, Mark

3

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.

Any thoughts? Should I suggest mod_ruby instead? How
stable/accepted/easy to maintain is fastcgi? Pros/cons I didn’t think
of? :slight_smile:

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).

OTOH, FastCGI scripts can easily be ‘wrapped’ using the FastcgiSuexec
mechanism.

···

–
dave

4

Mark Hubbart wrote:

  • updating Ruby would fix any bugs, while still retaining compatibility.

Of course, you can always build Ruby yourself under your HOME (that is,
if they allow you access to gcc). Even if they don’t, you can upload the
binaries.

···

–
dave

5

Hello David,

Friday, March 12, 2004, 3:43:13 AM, you wrote:

Mark Hubbart wrote:

- updating Ruby would fix any bugs, while still retaining compatibility.

Of course, you can always build Ruby yourself under your HOME (that is,
if they allow you access to gcc). Even if they don't, you can upload the
binaries.

Most hosting companies don't allow the execution of external programs.
For example i can't even start "ls".

···

--
Best regards,
Lothar mailto:mailinglists@scriptolutions.com

6

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?

···

On Fri, Mar 12, 2004 at 11:41:47AM +0900, David Garamond wrote:

–
Thomas
beast@system-tnt.dk

7

Lothar wrote:

Most hosting companies don’t allow the execution of external programs.
For example i can’t even start “ls”.

Please define Most. I apologize for the tyrannical charades of your
hosting provider. I rejoice in the ease and freedom of mine.

Zach

···

-----Original Message-----
From: Lothar Scholz [mailto:mailinglists@scriptolutions.com]
Sent: Thursday, March 11, 2004 10:49 PM
To: ruby-talk ML; lists@zara.6.isreserved.com
Cc: ruby-talk ML
Subject: Re: convincing a webhost to support ruby

Hello David,

Friday, March 12, 2004, 3:43:13 AM, you wrote:

Mark Hubbart wrote:

  • updating Ruby would fix any bugs, while still retaining compatibility.

Of course, you can always build Ruby yourself under your HOME (that is,
if they allow you access to gcc). Even if they don’t, you can upload the
binaries.

Most hosting companies don’t allow the execution of external programs.
For example i can’t even start “ls”.

–
Best regards,
Lothar mailto:mailinglists@scriptolutions.com

Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004

8

!!! yikes. I can ssh in, build software, and run it; the understanding
being that if they notice I’m putting to much of a load on the server,
they’ll kill me off :slight_smile: So nice -n20 is my friend.

Building it myself in my HOME is a possibility. But AFAIK, there’s no
way of running eruby as a standard cgi script. So I would also have to
install and run webrick or somesuch in my home. I would really rather
not have to do that.

–Mark

···

On Mar 11, 2004, at 7:48 PM, Lothar Scholz wrote:

Hello David,

Friday, March 12, 2004, 3:43:13 AM, you wrote:

Mark Hubbart wrote:

  • updating Ruby would fix any bugs, while still retaining
    compatibility.

Of course, you can always build Ruby yourself under your HOME
(that is,
if they allow you access to gcc). Even if they don’t, you can
upload the
binaries.

Most hosting companies don’t allow the execution of external programs.
For example i can’t even start “ls”.

9

Lothar Scholz wrote:

> Of course, you can always build Ruby yourself under your HOME (that is,
> if they allow you access to gcc). Even if they don't, you can upload the
> binaries.

Most hosting companies don't allow the execution of external programs.
For example i can't even start "ls".

Aw, that really sucks... Where do you hosted anyway? :slight_smile:

···

--
dave

10

Check Dmitry Borodaenko's Personal Hacks Collection

I basically keep Woody backport of Samizdat’s dependencies there, but if
you need something else (DFSG-free), let me know.

On a related note, I’m sure it would be interesting for Ruby Web apps
developers to learn about most usual restrictions that ISPs impose, so
that we could make sure that our programs operate in less friendly
environments.

···

On Sat, Mar 13, 2004 at 11:19:55PM +0900, Thomas Fini Hansen 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.

–
Dmitry Borodaenko

11

Hello David,

Friday, March 12, 2004, 11:05:44 AM, you wrote:

Lothar Scholz wrote:

> Of course, you can always build Ruby yourself under your HOME (that is,
> if they allow you access to gcc). Even if they don't, you can upload the
> binaries.

Most hosting companies don't allow the execution of external programs.
For example i can't even start "ls".

Aw, that really sucks... Where do you hosted anyway? :slight_smile:

But i'm not sure that this is a bad thing. I looked at all the other 30
virtual domains that are hosted on the server and i'm not sure if
there is another person i would trust when it comes to the use of command
line tools or installing their own complex systems.

And i'm getting really afraid when i think what they would do with a
database that supports stored procedure calls.

···

--
Best regards,
Lothar mailto:mailinglists@scriptolutions.com

12

Building it myself in my HOME is a possibility. But AFAIK, there’s no
way of running eruby as a standard cgi script. So I would also have to
install and run webrick or somesuch in my home. I would really rather
not have to do that.

–Mark

I was able to run eruby no problem as a standard CGI. Is there any
reason why you believe it might be a problem ?

If one would like to try ruby with a normal host and they have a linux
box, I would recommend just building it on the local machine and
uploading it to the cgi-bin of the webhost. At least for me, I’ve had
no problems when I taken this approach.

-Daniel

13

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.

Check Dmitry Borodaenko's Personal Hacks Collection

So I finally got round to trying it out, and I was plesantly surprised
that it coexist nicely with 1.6.

I basically keep Woody backport of Samizdat’s dependencies there, but if
you need something else (DFSG-free), let me know.

How about eRuby? mod_ruby used to depend on that, and I’d think that
many upgrading might be using it. That’s what broke for me. I tried
doing a quick backport of eruby and liberuby, but that went horribly
wrong for some reason. Apache would just hang connections using eRuby.

On a related note, I’m sure it would be interesting for Ruby Web apps
developers to learn about most usual restrictions that ISPs impose, so
that we could make sure that our programs operate in less friendly
environments.

Well, that thread kinda died, didn’t it? I still want to investigate
this further, but I’ve been quite busy.

The thread about a Safe module looks interesting in this regard.

···

On Mon, Mar 22, 2004 at 08:04:19PM +0900, Dmitry Borodaenko wrote:

On Sat, Mar 13, 2004 at 11:19:55PM +0900, Thomas Fini Hansen wrote:

–
Thomas
beast@system-tnt.dk

14

Building it myself in my HOME is a possibility. But AFAIK, there’s no
way of running eruby as a standard cgi script. So I would also have to
install and run webrick or somesuch in my home. I would really rather
not have to do that.

–Mark

I was able to run eruby no problem as a standard CGI. Is there any
reason why you believe it might be a problem ?

Really? Could you share the general setup? For me, naming it
script.cgi, adding a shebang line and making it executable didn’t work.
It would send the shebang line before I could send headers, so it
always failed. And that’s the only way I knew… But I’m probably just
ignorant :slight_smile:

If one would like to try ruby with a normal host and they have a linux
box, I would recommend just building it on the local machine and
uploading it to the cgi-bin of the webhost. At least for me, I’ve had
no problems when I taken this approach.

well, it would have to be compiled on their box. Theirs is i386-linux,
mine is powerpc-darwin (yeah, a mac), so… :slight_smile:

–Mark

···

On Mar 12, 2004, at 6:14 AM, Daniel Cremer wrote:

15

Mark Hubbart discord@mac.com wrote in message news:2BF2FE4C-7458-11D8-9C17-000502FDD5CC@mac.com…

Building it myself in my HOME is a possibility. But AFAIK, there’s no
way of running eruby as a standard cgi script. So I would also have to
install and run webrick or somesuch in my home. I would really rather
not have to do that.

–Mark

I was able to run eruby no problem as a standard CGI. Is there any
reason why you believe it might be a problem ?

Really? Could you share the general setup? For me, naming it
script.cgi, adding a shebang line and making it executable didn’t work.
It would send the shebang line before I could send headers, so it
always failed. And that’s the only way I knew… But I’m probably just
ignorant :slight_smile:

Not ignorant at all I hope, that’s how I set it up :). Sounds like
either the host intentionally prevents it from working, or it’s
actually never running because there’s a mistake in the path to eruby
after the shebang. If eruby is running it shouldn’t be sending the
shebang.

If one would like to try ruby with a normal host and they have a linux
box, I would recommend just building it on the local machine and
uploading it to the cgi-bin of the webhost. At least for me, I’ve had
no problems when I taken this approach.

well, it would have to be compiled on their box. Theirs is i386-linux,
mine is powerpc-darwin (yeah, a mac), so… :slight_smile:

yeah, I can see the problem there :).
I just wonder if a lot of new people to ruby would like to run eruby
at an existing host and just haven’t thought of trying to run it as
cgi. I’ll try testing it some more and add a page to the wiki.

-Daniel

···

On Mar 12, 2004, at 6:14 AM, Daniel Cremer wrote: