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