[CentOS] ruby193 SCL and mod_passenger

James B. Byrne byrnejb at harte-lyne.ca
Thu Apr 3 14:40:12 UTC 2014


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.


-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB at Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3




More information about the CentOS mailing list