supporting RoR

[pig...@gmail.com]

Hi guys, right now we offer all of our users a public_html directory
for webpages.
They update their public_html over kerberized nfs or ftp.

Some users want fancier webpages so we offer PHP+MySql, and we let
them
do this and have them make the updates via WEBDAV (all the files are
owned
by nobody).

I am wondering if anyone is offering and supporting RoR webpages and
what mechanisms
they use for this? It seems to me that the person editing the
websites is involved
with starting and stopping the webservers themselves so they would
need shell access
to the system, and would really have the ability to bargle a lot of
things up.

I would like to offer RoR to our population of users (right now most
people are happy with
PHP + mysql), but I am not sure what the best strategy to do this is.

I am curious to hear what others might be doing in this area, or if
anyone has good ideas for strategies.

[John Nunemaker]

Rails isn't really made for a shared environment, which is what you
seem to be describing. You'd probably want to do it on a case by case
basis.

[Jason Garber]

We don't let users run their own RoR apps, but with our setup, we probably could.  We use mod_fcgid for FastCGI dispatching and it works great.  It took us a little while in 2006 to tweak the module's settings so it ramps up fast enough to meet increasing load but doesn't overload the server, i/o, etc. but now it's been running great for over a year.  We restart Rails apps by doing a "pkill #{application_name}/current/public/dispatch.fcgi" and you could easily build an app to do that on behalf of your users without giving them shell access.

If you wanted to use svn and capistrano, though, you'd have to give them shell and perhaps even sudo capabilities.

Jason Garber

Web and New Media Coordinator

Eastern Mennonite University

(540) 432-4198

[Chas Grundy]

I can't imagine trying to support a Rails environment without allowing
shell access. At the least, you have svn and capistrano. Those are so
ingrained in the Rails community that you would be hard-pressed to
satisfy a RoR developer's needs without them. But then there are the
myriad custom setups that Rails developers use - custom gems, vendor/
rails symlinking, alternate server configurations, etc.

The best environments I've found are VPS type of setups; let the user
do whatever they want on their slice and provide the tools and support
to make the server management part of it easier. You certainly don't
need to offer it across the board - just to the folks that request it.
Or outsource that service: EngineYard, Slicehost, Railsmachine, etc.
all offer varying levels of this service.

Chas Grundy

[Brian Hogan]

Well, at the University of Wisconsin-Eau Claire, we don't let people deploy Rails apps. We support Rails though, and we offer it as an option for development projects. All of our internal development has moved to Rails, but external development (not done by our office) tends to prefer PHP. Several have done Rails apps, and so we work with htem to show them how to write tests, how to do code coverage, etc.  They check in to a repository we have access to, so we can periodically check out their projects and provide support.

Ultimately, though, we move the apps to production. The nice thing about Rails is that they can develop on their own machines. They don't need to push to Apache just to review their changes.

If anyone wants more info on how we do business at UW-Eau Claire, let me know!

-Brian

[Patrick Berry]

I'm just finishing up the process of setting up a shared application deployment server.  We're going to support perl (not mod_perl though), PHP 5, Tomcat 5.5, and Rails 2.  We're using RHEL 5 with Apache 2.2, so mod_proxy_balancer will come in handy for the Rails applications.

We're also doing in with a VMWare image.

Shell access is made easier because we're using pam_ldap for auth.

We're also making use of ACLs to ease permission problems with multiple developers.

Of course, nobody has used it yet...so they might all hate it. ;-)

Pat

CSU, Chico