On Thu, April 3, 2014 03:38, Filip Bartmann wrote:

  I'm interested in ruby and I try the ruby193 SCL and I want to run Ruby on Rails with Apache, so I'm searching mod_passenger for this ruby SCL version, but I found, that this package is not in this SCL. Are any other possibilities to run Ruby on Rails with Apache or why is mod_passenger not in this SCL?   Thanks, Filip Bartmann

When last I looked (~6-9 months ago) mod_passenger had to be built via the Rubygem install process. It also had issues with respect to SELinux that as far as I know remain unresolved. I know that Dan Walsh was working hard with the Phusion team to deal with this but it seemed to me at that time that both sides were considerably distant from an agreement with Phusion at one point basically telling RedHat to fork their project and call it something else.

Whether or not this is the reason that the Software Collection does not have an rpm for mod_passenger I cannot say.

However, given that support for 1.9.3 ends next January and that Ruby is already at 2.1.1 I suggest that perhaps you are better off building your own Ruby from source and packaging it as a custom rpm. I provided a working spec file and somewhat detailed instructions for building Ruby-1.9.3 at http://byrnejb.wordpress.com/2013/01/30/building-ruby-1-9-3-for-centos-6-3/. You can trivially modify this for 2.1.0 (skip 2.1.1 which has a problem with objects inheriting from Hash - a big problem if you are employing Rails) to build your own package and then use Rubygems to install mod-passenger. You can also package mod_passenger as an rpm should you desire. I do not bother with repackaging gems, although perhaps I should so as to avoid loading development packages on production servers.

Alternatively, you can use a Ruby version manager instead of using the system Ruby. On the use of rbenv or rvm I have mixed feelings. Both ruby version managers offer a valuable work-around for environments where system admin is not under the direction of the development team. For production deployments I found that there were other issues which made selection of rvm or rbenv problematic, notably in the deploy process itself and in the brittleness that resulted. I concluded after several incidents involving rvm deploys (not the fault of rvm by the way) that a package managed system really needs to remain a package managed system for ease and efficiency in maintenance.

Of course, if you are deploying to a shared hosting arrangement where the production environment is not under your control then rvm or something much like it is unavoidable. But in that case you are only responsible for maintaining your own small part of the system and so your maintenance requirements are far more circumscribed.