Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 3 down vote favorite

I have a CentOS 6 server that is in production and actually is hosting a few sites. I should now install Redmine which runs on Ruby. The remi/ephel repository gives me Ruby 1.8.7 but I would like to use the newest version (1.9). The problem is that I should compile and install it myself downloading the sources and all the other dev-packages required to make the gems works, for example mysql-devel for the mysql2 adapter. Is a bad practice to install dev-packages in a production machine? Can the security be compromised? Should I stick with the default packages provided by the repositories?

share|improve this question

4 Answers

up vote 3 down vote accepted

It would be better to stay in the package management system from the vendor.

That said, if you require a more recent version of a piece of software, at least try to use packages instead of installing via make; make build.

For Ruby 1.9.3, someone has make a spec file:

https://github.com/imeyer/ruby-1.9.3-rpm

You should be able to use this to make RPMs for Ruby 1.9.3, and install that way. If nothing else, it will make updates easier (i.e., rpm -Uhv ruby-1.9.3 instead of make; make install). You will still be responsible for generating new Ruby 1.9 packages for yourself as updates come out, of course.

In general, there is a hierarchy of preference for installing software.

  1. Software provided by the vendor repositories. In this case, you will use the nice, friendly management system to install and update packages maintained by the vendor (e.g., yum, apt-get).

  2. Software provided through third party repositories. There should be a mini-hierarchy here, where you have highly reputable repositories (e.g., EPEL for CentOS) to ones that are less so (e.g., some guy's PPA on Ubuntu; I'm not saying that people are trying to install trojans through PPAs, more that this is typically something provided by someone who may not be maintaining the packages, or who may not be looking for compatibility issues).

  3. Software installed via packages that you build yourself. This is where the spec file mentioned earlier will fall. You will wrap the build process in your distro's package system, so installations and upgrades are easy (e.g., rpm -e, rather than hunting through /usr/local for cryptically named files). You will take on the responsibility of building new packages as updates come up.

  4. Software installed without package management. This is the classic wget software.tgz ; tar xzvf software.tgz ; cd software ; ./configure ; make ; make install. Generally, you will spew files all over /usr/local; it may be hard to get information about the software (i.e., you can simply run rpm -q or rpm -ql), and it will be hard to remove. This should be a last resort.

I think somewhere around 3 is the rvm method mentioned by Alex. It's not really in system packages, but there is a framework surrounding the Ruby installation. With Ruby, in an RVM context, the gems associated with that particular Ruby will be installed via gem install and managed in a particular framework, also, albeit not the OS's package management system.

share|improve this answer
as I said commenting other replies I'm having a lot of trouble testing the default packages provided by the vendor on the virtual machine because I get a lot of errors saying to install dev packages to compile native extensions. Until now i had to install mysql-devel, ruby-devel, gcc, gcc-c++. All things that basically I had to install on the other virtual machine where I installed ruby from sources. Should I look for RVM or should I build RPM myself? I don't plan to run more than redmine on the server, so I don't need to have multiple versions of ruby installed ready to switch – Stefano Aug 21 '12 at 12:32
Hmm. Some of the packages you mentioned, gcc, etc., would be required to build the RPM and extensions, anyway. ruby-devel should pop out of the RPM build process with the spec file (if you look at github.com/imeyer/ruby-1.9.3-rpm/blob/master/ruby19.spec you can see what packages will be generated by the spec file from ruby source). You will need all those packages anyway if you're going to build gems, whether you go the rpmbuild route or use RVM. I think you should use the spec file, because you aren't going to use more than one Ruby. You should handle the gems via "gem install". – cjc Aug 21 '12 at 13:06
the problem is that gem install for example for json requires gcc and for thin requires gcc-c++. I need to install these dev packages anyway. Also for mysql gem, I need to install the mysql-devel – Stefano Aug 21 '12 at 13:10
Right. You need -devel packages to build things, whether you're compiling RPMs or doing "gem install". You can build RPMs for the gems, also, but there's not much benefit over running "gem install". You will need to install build dependencies regardless. – cjc Aug 21 '12 at 13:12
ok so basically what's the difference beetween building the RPM or build from source? In any case I need the dev packages, the only difference if I understood correctly is that RPM let me use yum install – Stefano Aug 21 '12 at 13:14
show 6 more comments
up vote 3 down vote

Unless you have a requirement to use the later version then sticking with the 'official' version is generally considered to be a 'good thing'. Security patches are backported to the official packages and you can take advantage of the package manager's update and dependency resolution.

Once you step outside of the above things can get quite messy.

share|improve this answer
using the official version of ruby on CentOS 6 is giving me a lot of trouble in the virtual machine. For example the package doesn't include itself the gems and when I try to install them I get a compilation error saying that I must have ruby-dev and gcc compiler to build native gem extensions like the json gem. It seems that building the ruby myself is easier that using the default packages – Stefano Aug 21 '12 at 12:19
up vote 3 down vote

This is a matter of opinion, however I never directly install packages from source on a production machine. It makes applying security updates down the road much more difficult. I'm paranoid about a potential compromise down the road.

My leaning is to use inbuilt packages where possible and track down additional RPMs from outside sources if necessary. If I can't find a version that I need I build the package into a RPM myself on a dev box and deploy that new RPM to production. Not elegant but functional.

share|improve this answer
I tried to install in a virtual machine the builtin package provided by the default repository of CentOS. The version of ruby is 1.8.7. However, I first had to install the rubygems package manually because it didn't had it alredy builtin and I'm now trying to install the default gems but I have a compilation error saying that to build the json gem I must have ruby-dev and the gcc compiler. Basically, installing manually all the ruby is easier than using the default packages – Stefano Aug 21 '12 at 12:17
up vote 2 down vote

I always use RVM to create and manage Ruby environments, RVM seems to be the preferred way to install Ruby for many Rubyists. Packages provided by Debian and CentOS maintainers are just not up to speed. Also, RVM is capable of creating isolated virtual environments just like Python's virtualenv.

share|improve this answer
is RVM suitable for production servers? I would install only the minimum things required to run what I need – Stefano Aug 21 '12 at 11:52
In my opinion RVM is the only way to manage any Ruby environment including production ones (and yes, I do use it in production) currently. And I believe this situation will unlikely change (based on my experience with Java packaging). – Alex Aug 21 '12 at 12:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.