# Ruby, Chef, Omnibus and you!

**URL:** <https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297>\
**Category:** Chef Infra (archive)\
**Created:** [December 27, 2011, 7:13pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297 "2011-12-27T19:13:38Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Joshua\_Timberman](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/joshua_timberman/32/424_2.png) [@Joshua\_Timberman](https://discourse.chef.io/u/Joshua_Timberman)\
**Post date:** [December 27, 2011, 7:13pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/1 "2011-12-27T19:13:38Z")

</div>

Ohai!

I’d like to start a conversation and collect feedback about how Chef  
should manage Ruby at an OS/app level, in particular when Chef is  
installed using the “Omnibus” full stack installer[0]. Feedback  
collected will better help us in providing cookbooks that work with  
Ruby applications besides Chef.

The Omnibus full stack installation of Chef includes Ruby for Chef to  
use. This is convenient for Chef, but it means that the system  
(typically) will not have Ruby installed anywhere for other tools or  
applications. While you _can_ use the Ruby in the omnibus  
installation for your applications or other tools, we don’t recommend  
it as it may not match the version of Ruby that you need for your  
applications.

In the past, we assumed that the Ruby installed as a package or  
otherwise with “knife bootstrap” templates is used by Chef. For many  
use cases that works fine, however on certain platforms, the default  
version of Ruby that is available as a native OS package is an  
outdated version.

The Ruby community and the various platform distributors have  
different goals when it comes to getting Ruby installed on the system,  
and there are three main approaches. Each of these approaches has  
different implementation in Chef cookbooks, and indeed different  
cookbooks exist for each.

- Distribution packages
- Rvm
- rbenv & ruby-build

Each approach also has different pros and cons.

Distribution packages are very convenient, because typically all you  
need is “apt-get install ruby” or “yum install ruby” (or  
equivalent). Compiling source is not required, and all the benefits of  
using the local package manager are realized. However, they may be out  
of date for the needs of a particular application. They are also quite  
different between distributions when it comes to the default packages  
available in the base repositories, and in the past some have altered  
the way that Ruby (particularly RubyGems) works. Also, remaining  
"purely" in package management is difficult because not all the  
RubyGems you might want to use are packaged, which introduces another  
layer of complexity for managing systems and applications with  
Chef. In the past, we managed system packages of Ruby with the  
`ruby`[1] cookbook beyond what the “bootstrap” process did.

Rvm is a set of shell scripts that help install and manage different  
versions of Ruby and RubyGems. It’s flexibility and features have made  
it a very popular way to deploy and manage Ruby for  
applications. However, it does assume compiling Ruby versions from  
source. This is time consuming, and in some environments against  
security policy (no compilers on production machines). There are at  
least two cookbooks[3] for managing Rubies through Rvm with Chef.

Rbenv is a newer project that can be used to manage versions of  
Ruby. I personally have not used it, but some folks are switching from  
Rvm to Rbenv. Rbenv does not install Rubies itself, but it has a  
helper called `ruby-build` to assist[4]. There are a couple cookbooks  
for using Rbenv to manage Ruby with Chef[5].

What are you doing in your environment to manage Ruby? Are you using  
the same installation of Ruby with Chef _and_ your application? If you’re  
using the Omnibus full-stack installer, are you managing a separate  
Ruby for your applications?

[0]: [http://github.com/opscode/omnibus](http://github.com/opscode/omnibus) and [http://opscode.com/chef/install](http://opscode.com/chef/install)  
[1]: [http://community.opscode.com/cookbooks/ruby](http://community.opscode.com/cookbooks/ruby) and  
[http://tickets.opscode.com/browse/COOK-409](http://tickets.opscode.com/browse/COOK-409)  
[3]: [http://community.opscode.com/cookbooks/rvm](http://community.opscode.com/cookbooks/rvm) OR  
[https://github.com/fnichol/chef-rvm](https://github.com/fnichol/chef-rvm)  
[4]: [https://github.com/sstephenson/ruby-build](https://github.com/sstephenson/ruby-build)  
[5]: [http://community.opscode.com/cookbooks/rbenv](http://community.opscode.com/cookbooks/rbenv) OR  
[https://github.com/fnichol/chef-rbenv](https://github.com/fnichol/chef-rbenv)

–  
Opscode, Inc  
Joshua Timberman, Technical Program Manager  
IRC, Skype, Twitter, Github: jtimberman

---

<div class="post-metadata">

**Author:** ![Kyle\_Bader](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kyle_bader/32/626_2.png) [@Kyle\_Bader](https://discourse.chef.io/u/Kyle_Bader)\
**Post date:** [December 27, 2011, 8:06pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/2 "2011-12-27T20:06:53Z")

</div>

We use Debian packages almost exclusively. Often we have to roll our own  
for one reason or another but for us it's worth the time.  
On Dec 27, 2011 11:13 AM, "Joshua Timberman" [joshua@opscode.com](mailto:joshua@opscode.com) wrote:

> Ohai!
> 
> I'd like to start a conversation and collect feedback about how Chef  
> should manage Ruby at an OS/app level, in particular when Chef is  
> installed using the "Omnibus" full stack installer[0]. Feedback  
> collected will better help us in providing cookbooks that work with  
> Ruby applications besides Chef.
> 
> The Omnibus full stack installation of Chef includes Ruby for Chef to  
> use. This is convenient for Chef, but it means that the system  
> (typically) will not have Ruby installed anywhere for other tools or  
> applications. While you _can_ use the Ruby in the omnibus  
> installation for your applications or other tools, we don't recommend  
> it as it may not match the version of Ruby that you need for your  
> applications.
> 
> In the past, we assumed that the Ruby installed as a package or  
> otherwise with "knife bootstrap" templates is used by Chef. For many  
> use cases that works fine, however on certain platforms, the default  
> version of Ruby that is available as a native OS package is an  
> outdated version.
> 
> The Ruby community and the various platform distributors have  
> different goals when it comes to getting Ruby installed on the system,  
> and there are three main approaches. Each of these approaches has  
> different implementation in Chef cookbooks, and indeed different  
> cookbooks exist for each.
> 
> - Distribution packages
> - Rvm
> - rbenv & ruby-build
> 
> Each approach also has different pros and cons.
> 
> Distribution packages are very convenient, because typically all you  
> need is "apt-get install ruby" or "yum install ruby" (or  
> equivalent). Compiling source is not required, and all the benefits of  
> using the local package manager are realized. However, they may be out  
> of date for the needs of a particular application. They are also quite  
> different between distributions when it comes to the default packages  
> available in the base repositories, and in the past some have altered  
> the way that Ruby (particularly RubyGems) works. Also, remaining  
> "purely" in package management is difficult because not all the  
> RubyGems you might want to use are packaged, which introduces another  
> layer of complexity for managing systems and applications with  
> Chef. In the past, we managed system packages of Ruby with the  
> `ruby`[1] cookbook beyond what the "bootstrap" process did.
> 
> Rvm is a set of shell scripts that help install and manage different  
> versions of Ruby and RubyGems. It's flexibility and features have made  
> it a very popular way to deploy and manage Ruby for  
> applications. However, it does assume compiling Ruby versions from  
> source. This is time consuming, and in some environments against  
> security policy (no compilers on production machines). There are at  
> least two cookbooks[3] for managing Rubies through Rvm with Chef.
> 
> Rbenv is a newer project that can be used to manage versions of  
> Ruby. I personally have not used it, but some folks are switching from  
> Rvm to Rbenv. Rbenv does not install Rubies itself, but it has a  
> helper called `ruby-build` to assist[4]. There are a couple cookbooks  
> for using Rbenv to manage Ruby with Chef[5].
> 
> What are you doing in your environment to manage Ruby? Are you using  
> the same installation of Ruby with Chef _and_ your application? If you're  
> using the Omnibus full-stack installer, are you managing a separate  
> Ruby for your applications?
> 
> [0]: [GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms.](http://github.com/opscode/omnibus) and [http://opscode.com/chef/install](http://opscode.com/chef/install)  
> [1]: [http://community.opscode.com/cookbooks/ruby](http://community.opscode.com/cookbooks/ruby) and  
> [http://tickets.opscode.com/browse/COOK-409](http://tickets.opscode.com/browse/COOK-409)  
> [3]: [http://community.opscode.com/cookbooks/rvm](http://community.opscode.com/cookbooks/rvm) OR  
> [GitHub - sous-chefs/rvm: Development repository for the rvm cookbook](https://github.com/fnichol/chef-rvm)  
> [4]: [GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.](https://github.com/sstephenson/ruby-build)  
> [5]: [http://community.opscode.com/cookbooks/rbenv](http://community.opscode.com/cookbooks/rbenv) OR  
> [GitHub - sous-chefs/ruby\_rbenv: Development repository for the ruby\_rbenv cookbook](https://github.com/fnichol/chef-rbenv)
> 
> --  
> Opscode, Inc  
> Joshua Timberman, Technical Program Manager  
> IRC, Skype, Twitter, Github: jtimberman

---

<div class="post-metadata">

**Author:** ![Alex\_Soto](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/alex_soto/32/673_2.png) [@Alex\_Soto](https://discourse.chef.io/u/Alex_Soto)\
**Post date:** [December 27, 2011, 8:32pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/3 "2011-12-27T20:32:06Z")

</div>

I've tried using the rvm cookbook and was disappointed with it. I use rvm extensively in dev environment but as a server deployment solution I was confused with how it worked and ultimately punted on using it. Granted I spent very little time trying to figure it out, but I just ended up installing a single ruby version that I compile locally inside my bootstrap script.

However I would like to skip the compile and have different rubies and gemsets on a system.

A wish list in no particular order:

- a recipe that allows deploying a rails app that uses ruby enterprise (or some other version, separate from a 'system' ruby if desired)
- a ruby version that is used by the system for scripts with it's own gemset separate from whatever rails app is on that node.
- I'd like it so when you're in the rails application's home dir, the right ruby and gems are setup for running any rake tasks or launching the rails console. The gems are handled by bundler, but the ruby version 'should' be the same as passenger is using.
- have various rubies already compiled or packaged, ready for install so I can skip the compile step to cut down on node provisioning time

On Dec 27, 2011, at 11:13 AM, Joshua Timberman wrote:

> Ohai!
> 
> I'd like to start a conversation and collect feedback about how Chef  
> should manage Ruby at an OS/app level, in particular when Chef is  
> installed using the "Omnibus" full stack installer[0]. Feedback  
> collected will better help us in providing cookbooks that work with  
> Ruby applications besides Chef.
> 
> The Omnibus full stack installation of Chef includes Ruby for Chef to  
> use. This is convenient for Chef, but it means that the system  
> (typically) will not have Ruby installed anywhere for other tools or  
> applications. While you _can_ use the Ruby in the omnibus  
> installation for your applications or other tools, we don't recommend  
> it as it may not match the version of Ruby that you need for your  
> applications.
> 
> In the past, we assumed that the Ruby installed as a package or  
> otherwise with "knife bootstrap" templates is used by Chef. For many  
> use cases that works fine, however on certain platforms, the default  
> version of Ruby that is available as a native OS package is an  
> outdated version.
> 
> The Ruby community and the various platform distributors have  
> different goals when it comes to getting Ruby installed on the system,  
> and there are three main approaches. Each of these approaches has  
> different implementation in Chef cookbooks, and indeed different  
> cookbooks exist for each.
> 
> - Distribution packages
> - Rvm
> - rbenv & ruby-build
> 
> Each approach also has different pros and cons.
> 
> Distribution packages are very convenient, because typically all you  
> need is "apt-get install ruby" or "yum install ruby" (or  
> equivalent). Compiling source is not required, and all the benefits of  
> using the local package manager are realized. However, they may be out  
> of date for the needs of a particular application. They are also quite  
> different between distributions when it comes to the default packages  
> available in the base repositories, and in the past some have altered  
> the way that Ruby (particularly RubyGems) works. Also, remaining  
> "purely" in package management is difficult because not all the  
> RubyGems you might want to use are packaged, which introduces another  
> layer of complexity for managing systems and applications with  
> Chef. In the past, we managed system packages of Ruby with the  
> `ruby`[1] cookbook beyond what the "bootstrap" process did.
> 
> Rvm is a set of shell scripts that help install and manage different  
> versions of Ruby and RubyGems. It's flexibility and features have made  
> it a very popular way to deploy and manage Ruby for  
> applications. However, it does assume compiling Ruby versions from  
> source. This is time consuming, and in some environments against  
> security policy (no compilers on production machines). There are at  
> least two cookbooks[3] for managing Rubies through Rvm with Chef.
> 
> Rbenv is a newer project that can be used to manage versions of  
> Ruby. I personally have not used it, but some folks are switching from  
> Rvm to Rbenv. Rbenv does not install Rubies itself, but it has a  
> helper called `ruby-build` to assist[4]. There are a couple cookbooks  
> for using Rbenv to manage Ruby with Chef[5].
> 
> What are you doing in your environment to manage Ruby? Are you using  
> the same installation of Ruby with Chef _and_ your application? If you're  
> using the Omnibus full-stack installer, are you managing a separate  
> Ruby for your applications?
> 
> [0]: [GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms.](http://github.com/opscode/omnibus) and [http://opscode.com/chef/install](http://opscode.com/chef/install)  
> [1]: [http://community.opscode.com/cookbooks/ruby](http://community.opscode.com/cookbooks/ruby) and  
> [http://tickets.opscode.com/browse/COOK-409](http://tickets.opscode.com/browse/COOK-409)  
> [3]: [http://community.opscode.com/cookbooks/rvm](http://community.opscode.com/cookbooks/rvm) OR  
> [GitHub - sous-chefs/rvm: Development repository for the rvm cookbook](https://github.com/fnichol/chef-rvm)  
> [4]: [GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.](https://github.com/sstephenson/ruby-build)  
> [5]: [http://community.opscode.com/cookbooks/rbenv](http://community.opscode.com/cookbooks/rbenv) OR  
> [GitHub - sous-chefs/ruby\_rbenv: Development repository for the ruby\_rbenv cookbook](https://github.com/fnichol/chef-rbenv)
> 
> --  
> Opscode, Inc  
> Joshua Timberman, Technical Program Manager  
> IRC, Skype, Twitter, Github: jtimberman

---

<div class="post-metadata">

**Author:** ![Jesse\_Nelson](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_nelson/32/262_2.png) [@Jesse\_Nelson](https://discourse.chef.io/u/Jesse_Nelson)\
**Post date:** [December 28, 2011, 5:41am UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/4 "2011-12-28T05:41:17Z")

</div>

We package our own ruby on cent/rhel 4/5/6. We then use bundler to  
bundle chef up into an rpm that is self contained. This keeps chef and  
all its deps in ruby space away from the system and system gems. We  
do the same thing for other ruby tools/infra we deploy.

We originally tried packaging the ruby and all gems as rpm's but the  
management overhead for doing this was pretty heavy. As well as  
running into conflicting gem versions for some tools we had out in the  
wild. The new system requires usually just a bump of the chef version  
and an rpm rebuild.

my spec files for doing all this are in my repo:

> **[GitHub - spheromak/chef-bundled: specs and support for bundler based chef](https://github.com/spheromak/chef-bundled)**
>
> specs and support for bundler based chef . Contribute to spheromak/chef-bundled development by creating an account on GitHub.

On Tue, Dec 27, 2011 at 12:32 PM, Alex Soto [apsoto@gmail.com](mailto:apsoto@gmail.com) wrote:

> I've tried using the rvm cookbook and was disappointed with it. I use rvm extensively in dev environment but as a server deployment solution I was confused with how it worked and ultimately punted on using it. Granted I spent very little time trying to figure it out, but I just ended up installing a single ruby version that I compile locally inside my bootstrap script.
> 
> However I would like to skip the compile and have different rubies and gemsets on a system.
> 
> A wish list in no particular order:
> 
> - a recipe that allows deploying a rails app that uses ruby enterprise (or some other version, separate from a 'system' ruby if desired)
> - a ruby version that is used by the system for scripts with it's own gemset separate from whatever rails app is on that node.
> - I'd like it so when you're in the rails application's home dir, the right ruby and gems are setup for running any rake tasks or launching the rails console. The gems are handled by bundler, but the ruby version 'should' be the same as passenger is using.
> - have various rubies already compiled or packaged, ready for install so I can skip the compile step to cut down on node provisioning time
> 
> On Dec 27, 2011, at 11:13 AM, Joshua Timberman wrote:
> 
> > Ohai!
> > 
> > I'd like to start a conversation and collect feedback about how Chef  
> > should manage Ruby at an OS/app level, in particular when Chef is  
> > installed using the "Omnibus" full stack installer[0]. Feedback  
> > collected will better help us in providing cookbooks that work with  
> > Ruby applications besides Chef.
> > 
> > The Omnibus full stack installation of Chef includes Ruby for Chef to  
> > use. This is convenient for Chef, but it means that the system  
> > (typically) will not have Ruby installed anywhere for other tools or  
> > applications. While you _can_ use the Ruby in the omnibus  
> > installation for your applications or other tools, we don't recommend  
> > it as it may not match the version of Ruby that you need for your  
> > applications.
> > 
> > In the past, we assumed that the Ruby installed as a package or  
> > otherwise with "knife bootstrap" templates is used by Chef. For many  
> > use cases that works fine, however on certain platforms, the default  
> > version of Ruby that is available as a native OS package is an  
> > outdated version.
> > 
> > The Ruby community and the various platform distributors have  
> > different goals when it comes to getting Ruby installed on the system,  
> > and there are three main approaches. Each of these approaches has  
> > different implementation in Chef cookbooks, and indeed different  
> > cookbooks exist for each.
> > 
> > - Distribution packages
> > - Rvm
> > - rbenv & ruby-build
> > 
> > Each approach also has different pros and cons.
> > 
> > Distribution packages are very convenient, because typically all you  
> > need is "apt-get install ruby" or "yum install ruby" (or  
> > equivalent). Compiling source is not required, and all the benefits of  
> > using the local package manager are realized. However, they may be out  
> > of date for the needs of a particular application. They are also quite  
> > different between distributions when it comes to the default packages  
> > available in the base repositories, and in the past some have altered  
> > the way that Ruby (particularly RubyGems) works. Also, remaining  
> > "purely" in package management is difficult because not all the  
> > RubyGems you might want to use are packaged, which introduces another  
> > layer of complexity for managing systems and applications with  
> > Chef. In the past, we managed system packages of Ruby with the  
> > `ruby`[1] cookbook beyond what the "bootstrap" process did.
> > 
> > Rvm is a set of shell scripts that help install and manage different  
> > versions of Ruby and RubyGems. It's flexibility and features have made  
> > it a very popular way to deploy and manage Ruby for  
> > applications. However, it does assume compiling Ruby versions from  
> > source. This is time consuming, and in some environments against  
> > security policy (no compilers on production machines). There are at  
> > least two cookbooks[3] for managing Rubies through Rvm with Chef.
> > 
> > Rbenv is a newer project that can be used to manage versions of  
> > Ruby. I personally have not used it, but some folks are switching from  
> > Rvm to Rbenv. Rbenv does not install Rubies itself, but it has a  
> > helper called `ruby-build` to assist[4]. There are a couple cookbooks  
> > for using Rbenv to manage Ruby with Chef[5].
> > 
> > What are you doing in your environment to manage Ruby? Are you using  
> > the same installation of Ruby with Chef _and_ your application? If you're  
> > using the Omnibus full-stack installer, are you managing a separate  
> > Ruby for your applications?
> > 
> > [0]: [GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms.](http://github.com/opscode/omnibus) and [http://opscode.com/chef/install](http://opscode.com/chef/install)  
> > [1]: [http://community.opscode.com/cookbooks/ruby](http://community.opscode.com/cookbooks/ruby) and  
> > [http://tickets.opscode.com/browse/COOK-409](http://tickets.opscode.com/browse/COOK-409)  
> > [3]: [http://community.opscode.com/cookbooks/rvm](http://community.opscode.com/cookbooks/rvm) OR  
> > [GitHub - sous-chefs/rvm: Development repository for the rvm cookbook](https://github.com/fnichol/chef-rvm)  
> > [4]: [GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.](https://github.com/sstephenson/ruby-build)  
> > [5]: [http://community.opscode.com/cookbooks/rbenv](http://community.opscode.com/cookbooks/rbenv) OR  
> > [GitHub - sous-chefs/ruby\_rbenv: Development repository for the ruby\_rbenv cookbook](https://github.com/fnichol/chef-rbenv)
> > 
> > --  
> > Opscode, Inc  
> > Joshua Timberman, Technical Program Manager  
> > IRC, Skype, Twitter, Github: jtimberman

---

<div class="post-metadata">

**Author:** ![Ranjib\_Dey](https://avatars.discourse-cdn.com/v4/letter/r/8e8cbc/32.png) [@Ranjib\_Dey](https://discourse.chef.io/u/Ranjib_Dey)\
**Post date:** [December 28, 2011, 6:38am UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/5 "2011-12-28T06:38:22Z")

</div>

We use ruby1.8.7 from epel for most of the non ruby deployments (mostly  
j2ee apps), chef works fine with 1.8.7 , for RoR and related stacks we  
compile ruby from source straight on the servers(as part of the bootstrap  
process). Initially we had tried using the os packages but due to the  
outdated packages or the way ruby 1.9.2 is shipped (ruby19 binary?) or some  
gem dependencies (like passenger/nokogiri/mysql etc) we had to grab the  
headers and compile them on the servers later on anyway..so , now we  
install ruby from source, this has helped us developing a uniform way to  
manage ruby and gems across different systems.

In between i had tried rvm, it was a real pita, since it assumes you have a  
shell and does all the trick based on shell env manipulation, it fails on  
everywhere which does not involve a shell. We tried retrofitting  
the deployment strategies so that it uses an user with a shell , but it was  
too much patch work. rbenv requires less work in this approach

Till now we have never faced any issue with chef in terms of ruby versions,  
we always use bundler to manage and contain the gems related to  
apps/services, that way they never interfere with the system wide installed  
gems. In few rare occasions we had issues with bundler versions, so now I  
have specific cookbook for managing bundler.

We are looking forward with chef omnibus, but i have tried it out with few  
containers, and the experience was good. Going forward, it will be  
interesting to see how omnibus addresses other ruby installations (apart  
from the ships with itself) in the same server and how the behavior of  
gem\_package like resources are affected. But all these matters a lot more  
if servers are multi tenant (i.e. they are serving different ruby apps  
requiring different ruby versions/gems) or if compiler/header file  
installation are not feasible.

regards  
ranjib

On Wed, Dec 28, 2011 at 11:11 AM, Jesse Nelson [spheromak@gmail.com](mailto:spheromak@gmail.com) wrote:

> We package our own ruby on cent/rhel 4/5/6. We then use bundler to  
> bundle chef up into an rpm that is self contained. This keeps chef and  
> all its deps in ruby space away from the system and system gems. We  
> do the same thing for other ruby tools/infra we deploy.
> 
> We originally tried packaging the ruby and all gems as rpm's but the  
> management overhead for doing this was pretty heavy. As well as  
> running into conflicting gem versions for some tools we had out in the  
> wild. The new system requires usually just a bump of the chef version  
> and an rpm rebuild.
> 
> my spec files for doing all this are in my repo:  
> [GitHub - spheromak/chef-bundled: specs and support for bundler based chef](https://github.com/spheromak/chef-bundled)
> 
> On Tue, Dec 27, 2011 at 12:32 PM, Alex Soto [apsoto@gmail.com](mailto:apsoto@gmail.com) wrote:
> 
> > I've tried using the rvm cookbook and was disappointed with it. I use  
> > rvm extensively in dev environment but as a server deployment solution I  
> > was confused with how it worked and ultimately punted on using it. Granted  
> > I spent very little time trying to figure it out, but I just ended up  
> > installing a single ruby version that I compile locally inside my bootstrap  
> > script.
> > 
> > However I would like to skip the compile and have different rubies and  
> > gemsets on a system.
> > 
> > A wish list in no particular order:
> > 
> > - a recipe that allows deploying a rails app that uses ruby enterprise  
> > (or some other version, separate from a 'system' ruby if desired)
> > - a ruby version that is used by the system for scripts with it's own  
> > gemset separate from whatever rails app is on that node.
> > - I'd like it so when you're in the rails application's home dir, the  
> > right ruby and gems are setup for running any rake tasks or launching the  
> > rails console. The gems are handled by bundler, but the ruby version  
> > 'should' be the same as passenger is using.
> > - have various rubies already compiled or packaged, ready for install so  
> > I can skip the compile step to cut down on node provisioning time
> > 
> > On Dec 27, 2011, at 11:13 AM, Joshua Timberman wrote:
> > 
> > > Ohai!
> > > 
> > > I'd like to start a conversation and collect feedback about how Chef  
> > > should manage Ruby at an OS/app level, in particular when Chef is  
> > > installed using the "Omnibus" full stack installer[0]. Feedback  
> > > collected will better help us in providing cookbooks that work with  
> > > Ruby applications besides Chef.
> > > 
> > > The Omnibus full stack installation of Chef includes Ruby for Chef to  
> > > use. This is convenient for Chef, but it means that the system  
> > > (typically) will not have Ruby installed anywhere for other tools or  
> > > applications. While you _can_ use the Ruby in the omnibus  
> > > installation for your applications or other tools, we don't recommend  
> > > it as it may not match the version of Ruby that you need for your  
> > > applications.
> > > 
> > > In the past, we assumed that the Ruby installed as a package or  
> > > otherwise with "knife bootstrap" templates is used by Chef. For many  
> > > use cases that works fine, however on certain platforms, the default  
> > > version of Ruby that is available as a native OS package is an  
> > > outdated version.
> > > 
> > > The Ruby community and the various platform distributors have  
> > > different goals when it comes to getting Ruby installed on the system,  
> > > and there are three main approaches. Each of these approaches has  
> > > different implementation in Chef cookbooks, and indeed different  
> > > cookbooks exist for each.
> > > 
> > > - Distribution packages
> > > - Rvm
> > > - rbenv & ruby-build
> > > 
> > > Each approach also has different pros and cons.
> > > 
> > > Distribution packages are very convenient, because typically all you  
> > > need is "apt-get install ruby" or "yum install ruby" (or  
> > > equivalent). Compiling source is not required, and all the benefits of  
> > > using the local package manager are realized. However, they may be out  
> > > of date for the needs of a particular application. They are also quite  
> > > different between distributions when it comes to the default packages  
> > > available in the base repositories, and in the past some have altered  
> > > the way that Ruby (particularly RubyGems) works. Also, remaining  
> > > "purely" in package management is difficult because not all the  
> > > RubyGems you might want to use are packaged, which introduces another  
> > > layer of complexity for managing systems and applications with  
> > > Chef. In the past, we managed system packages of Ruby with the  
> > > `ruby`[1] cookbook beyond what the "bootstrap" process did.
> > > 
> > > Rvm is a set of shell scripts that help install and manage different  
> > > versions of Ruby and RubyGems. It's flexibility and features have made  
> > > it a very popular way to deploy and manage Ruby for  
> > > applications. However, it does assume compiling Ruby versions from  
> > > source. This is time consuming, and in some environments against  
> > > security policy (no compilers on production machines). There are at  
> > > least two cookbooks[3] for managing Rubies through Rvm with Chef.
> > > 
> > > Rbenv is a newer project that can be used to manage versions of  
> > > Ruby. I personally have not used it, but some folks are switching from  
> > > Rvm to Rbenv. Rbenv does not install Rubies itself, but it has a  
> > > helper called `ruby-build` to assist[4]. There are a couple cookbooks  
> > > for using Rbenv to manage Ruby with Chef[5].
> > > 
> > > What are you doing in your environment to manage Ruby? Are you using  
> > > the same installation of Ruby with Chef _and_ your application? If  
> > > you're  
> > > using the Omnibus full-stack installer, are you managing a separate  
> > > Ruby for your applications?
> > > 
> > > [0]: [GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms.](http://github.com/opscode/omnibus) and  
> > > [http://opscode.com/chef/install](http://opscode.com/chef/install)  
> > > [1]: [http://community.opscode.com/cookbooks/ruby](http://community.opscode.com/cookbooks/ruby) and  
> > > [http://tickets.opscode.com/browse/COOK-409](http://tickets.opscode.com/browse/COOK-409)  
> > > [3]: [http://community.opscode.com/cookbooks/rvm](http://community.opscode.com/cookbooks/rvm) OR  
> > > [GitHub - sous-chefs/rvm: Development repository for the rvm cookbook](https://github.com/fnichol/chef-rvm)  
> > > [4]: [GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.](https://github.com/sstephenson/ruby-build)  
> > > [5]: [http://community.opscode.com/cookbooks/rbenv](http://community.opscode.com/cookbooks/rbenv) OR  
> > > [GitHub - sous-chefs/ruby\_rbenv: Development repository for the ruby\_rbenv cookbook](https://github.com/fnichol/chef-rbenv)
> > > 
> > > --  
> > > Opscode, Inc  
> > > Joshua Timberman, Technical Program Manager  
> > > IRC, Skype, Twitter, Github: jtimberman

---

<div class="post-metadata">

**Author:** ![Burkholder\_Peter](https://avatars.discourse-cdn.com/v4/letter/b/ebca7d/32.png) [@Burkholder\_Peter](https://discourse.chef.io/u/Burkholder_Peter)\
**Post date:** [December 29, 2011, 3:41pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/6 "2011-12-29T15:41:13Z")

</div>

Hi Joshua,

I've tried the omnibus approach but I'm using the FrameOS build now because I need libselinux-ruby and I couldn't get that to build against the 1.9.1 Ruby in Omnibus. I like the idea of having Chef neatly walled off in a chef-full RPM, but it didn't suffice for me. (We're using RHEL5 as our platform).

Cheers,

Peter

> > On Dec 27, 2011, at 11:13 AM, Joshua Timberman wrote:
> > 
> > > Ohai!
> > > 
> > > I'd like to start a conversation and collect feedback about how Chef  
> > > should manage Ruby at an OS/app level, in particular when Chef is  
> > > installed using the "Omnibus" full stack installer[0]. Feedback  
> > > collected will better help us in providing cookbooks that work with  
> > > Ruby applications besides Chef.
> > > 
> > > The Omnibus full stack installation of Chef includes Ruby for Chef to  
> > > use. This is convenient for Chef, but it means that the system  
> > > (typically) will not have Ruby installed anywhere for other tools or  
> > > applications. While you _can_ use the Ruby in the omnibus  
> > > installation for your applications or other tools, we don't recommend  
> > > it as it may not match the version of Ruby that you need for your  
> > > applications.
> > > 
> > > In the past, we assumed that the Ruby installed as a package or  
> > > otherwise with "knife bootstrap" templates is used by Chef. For many  
> > > use cases that works fine, however on certain platforms, the default  
> > > version of Ruby that is available as a native OS package is an  
> > > outdated version.
> > > 
> > > The Ruby community and the various platform distributors have  
> > > different goals when it comes to getting Ruby installed on the system,  
> > > and there are three main approaches. Each of these approaches has  
> > > different implementation in Chef cookbooks, and indeed different  
> > > cookbooks exist for each.
> > > 
> > > - Distribution packages
> > > - Rvm
> > > - rbenv & ruby-build
> > > 
> > > Each approach also has different pros and cons.
> > > 
> > > Distribution packages are very convenient, because typically all you  
> > > need is "apt-get install ruby" or "yum install ruby" (or  
> > > equivalent). Compiling source is not required, and all the benefits of  
> > > using the local package manager are realized. However, they may be out  
> > > of date for the needs of a particular application. They are also quite  
> > > different between distributions when it comes to the default packages  
> > > available in the base repositories, and in the past some have altered  
> > > the way that Ruby (particularly RubyGems) works. Also, remaining  
> > > "purely" in package management is difficult because not all the  
> > > RubyGems you might want to use are packaged, which introduces another  
> > > layer of complexity for managing systems and applications with  
> > > Chef. In the past, we managed system packages of Ruby with the  
> > > `ruby`[1] cookbook beyond what the "bootstrap" process did.
> > > 
> > > Rvm is a set of shell scripts that help install and manage different  
> > > versions of Ruby and RubyGems. It's flexibility and features have made  
> > > it a very popular way to deploy and manage Ruby for  
> > > applications. However, it does assume compiling Ruby versions from  
> > > source. This is time consuming, and in some environments against  
> > > security policy (no compilers on production machines). There are at  
> > > least two cookbooks[3] for managing Rubies through Rvm with Chef.
> > > 
> > > Rbenv is a newer project that can be used to manage versions of  
> > > Ruby. I personally have not used it, but some folks are switching from  
> > > Rvm to Rbenv. Rbenv does not install Rubies itself, but it has a  
> > > helper called `ruby-build` to assist[4]. There are a couple cookbooks  
> > > for using Rbenv to manage Ruby with Chef[5].
> > > 
> > > What are you doing in your environment to manage Ruby? Are you using  
> > > the same installation of Ruby with Chef _and_ your application? If you're  
> > > using the Omnibus full-stack installer, are you managing a separate  
> > > Ruby for your applications?
> > > 
> > > [0]: [GitHub - chef/omnibus: Easily create full-stack installers for your project across a variety of platforms.](http://github.com/opscode/omnibus) and [http://opscode.com/chef/install](http://opscode.com/chef/install)  
> > > [1]: [http://community.opscode.com/cookbooks/ruby](http://community.opscode.com/cookbooks/ruby) and  
> > > [http://tickets.opscode.com/browse/COOK-409](http://tickets.opscode.com/browse/COOK-409)  
> > > [3]: [http://community.opscode.com/cookbooks/rvm](http://community.opscode.com/cookbooks/rvm) OR  
> > > [GitHub - sous-chefs/rvm: Development repository for the rvm cookbook](https://github.com/fnichol/chef-rvm)  
> > > [4]: [GitHub - rbenv/ruby-build: A tool to download, compile, and install Ruby on Unix-like systems.](https://github.com/sstephenson/ruby-build)  
> > > [5]: [http://community.opscode.com/cookbooks/rbenv](http://community.opscode.com/cookbooks/rbenv) OR  
> > > [GitHub - sous-chefs/ruby\_rbenv: Development repository for the ruby\_rbenv cookbook](https://github.com/fnichol/chef-rbenv)
> > > 
> > > --  
> > > Opscode, Inc  
> > > Joshua Timberman, Technical Program Manager  
> > > IRC, Skype, Twitter, Github: jtimberman

--  
Peter Burkholder | Sr. System Administrator (consultant)  
AARP | Digital Strategy & Operations | 601 E Street NW | Washington, DC 20049  
[pburkholder@aarp.org](mailto:pburkholder@aarp.org) | aim: peterbtech | w: 202-434-3530 | c: 202-344-7129  
For optimal efficiency, I check email at 2-hour intervals during the workday  
(except when on-call). Please use IM or phone to contact me for urgent matters

---

<div class="post-metadata">

**Author:** ![Erik\_Hollensbe](https://avatars.discourse-cdn.com/v4/letter/e/9de053/32.png) [@Erik\_Hollensbe](https://discourse.chef.io/u/Erik_Hollensbe)\
**Post date:** [December 29, 2011, 4:14pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/7 "2011-12-29T16:14:09Z")

</div>

On Dec 27, 2011, at 11:13 AM, Joshua Timberman wrote:

> Ohai!
> 
> I'd like to start a conversation and collect feedback about how Chef  
> should manage Ruby at an OS/app level, in particular when Chef is  
> installed using the "Omnibus" full stack installer[0]. Feedback  
> collected will better help us in providing cookbooks that work with  
> Ruby applications besides Chef.

We're actually building tooling out to do this, likely scheduled for release later this week to our developers and their testing environment -- chef 0.9 still, but I can describe how we're doing it. We have potentially unique deployment needs; where possible I'm detailing those as well, which might shed some light on our rationale and expose a few issues with chef in general.

We have a `ruby\_build' provider which performs builds of ruby which live in /opt/ruby, and a chef-only build of ruby in /opt/chef-ruby which is built on bootstrap and has compatible recipes to bootstrap legacy systems. There's a (very) small selector tool (ala rvm, but less needy -- see below) for shell users, but the important bit is the clear separation between the "chef ruby" and the "application rubies". The application rubies are linked into deployment dirs by application preference, which are then used by monit/cron/etc with bundler and all that fun stuff (we have about 15 rails applications deployed so this can get a little hairy). As a result, we're able to completely walk away from debian packages which have caused us grief in the past. I realize that may not be an acceptable solution for everyone.

Note that chef-client not living in /usr/bin, at least on 0.9 w/ 0.9-compatible opscode chef recipes, is very problematic so all our chef tooling is linked into /usr/bin from the recipe that installs our chef ruby. It's the /etc/init.d scripts that get copied from the gem that are the pain in particular.

I would like to advocate this approach, notably, the part where the ruby used by chef _is not used by anything else_. This avoids all sorts of issues (for example, our capistrano deployment system integrates with chef search for reasons I may not be able to discuss) with chef, shef, etc being a part of other ruby-related components on the system. If you could make this happen, I could literally remove about 200 lines of code. 🙂

As for rvm, it in particular doesn't work well for servers in my experience, see here: [smoking-chef/cookbooks/rvm at master · phillyrb/smoking-chef · GitHub](https://github.com/phillyrb/smoking-chef/tree/master/cookbooks/rvm) which is a series of (chef-solo) recipes based on other community versions I built out a while back -- I have had no end to the hell I unleashed with those recipes. Just having it on the boxes introduces all sorts of pathing/rvm-shell issues. rbenv seems to suffer a similar fate with its on-login requirements (but I haven't explored it as well). ruby-build OTOH should work fine and I will be exploring that as an alternative to the (very simple in implementation) provider guts for the cookbook described above.

I'm not sure if this helps for anything than to describe an alternative approach, but I figured I should chime in anyways. 🙂 I'm 'erikh' on irc if you want to discuss it further and am normally available on typical PST working hours.

-Erik

---

<div class="post-metadata">

**Author:** ![Joshua\_Timberman](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/joshua_timberman/32/424_2.png) [@Joshua\_Timberman](https://discourse.chef.io/u/Joshua_Timberman)\
**Post date:** [December 29, 2011, 6:37pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/8 "2011-12-29T18:37:49Z")

</div>

Ohai!

On Dec 29, 2011, at 8:41 AM, Burkholder, Peter wrote:

> I've tried the omnibus approach but I'm using the FrameOS build now because I need libselinux-ruby and I couldn't get that to build against the 1.9.1 Ruby in Omnibus. I like the idea of having Chef neatly walled off in a chef-full RPM, but it didn't suffice for me. (We're using RHEL5 as our platform).

Fwiw, you can append to the load path and load the selinux library after installing it as a package. I can't speak to how well this library will work with the Ruby version included in the Omnibus installation (ruby 1.9.2p180 as of now on my test system)

[root@centos6 ~]# rpm -qa | egrep "ruby|chef"  
chef-full-0.10.8-2.x86\_64  
[root@centos6 ~]# shef  
chef \> recipe  
chef:recipe \> package "libselinux-ruby"  
chef:recipe \> run\_chef  
[Wed, 28 Dec 2011 18:08:37 -0700] DEBUG: Processing package[libselinux-ruby] on [centos6.int.housepub.org](http://centos6.int.housepub.org)  
[Wed, 28 Dec 2011 18:08:37 -0700] INFO: Processing package[libselinux-ruby] action install ((irb#1) line 1)  
[Wed, 28 Dec 2011 18:08:42 -0700] DEBUG: package[libselinux-ruby] checking yum info for libselinux-ruby  
[Wed, 28 Dec 2011 18:08:42 -0700] DEBUG: package[libselinux-ruby] installed version: (none) candidate version: 2.0.94-5.2.el6  
[Wed, 28 Dec 2011 18:08:42 -0700] DEBUG: Executing yum -d0 -e0 -y install libselinux-ruby-2.0.94-5.2.el6  
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: ---- Begin output of yum -d0 -e0 -y install libselinux-ruby-2.0.94-5.2.el6 ----  
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: STDOUT:  
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: STDERR:  
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: ---- End output of yum -d0 -e0 -y install libselinux-ruby-2.0.94-5.2.el6 ----  
[Wed, 28 Dec 2011 18:08:51 -0700] DEBUG: Ran yum -d0 -e0 -y install libselinux-ruby-2.0.94-5.2.el6 returned 0  
[Wed, 28 Dec 2011 18:08:51 -0700] INFO: package[libselinux-ruby] installed version 2.0.94-5.2.el6  
=\> true  
chef:recipe \> $: \<\< "/usr/lib64/ruby/site\_ruby/1.8/x86\_64-linux/"  
=\> [OUTPUT TRUNCATED]  
chef:recipe \> require 'selinux'  
=\> true

I'll also update the relevant COOK ticket where this was discussed.

--  
Opscode, Inc  
Joshua Timberman, Technical Program Manager  
IRC, Skype, Twitter, Github: jtimberman

---

<div class="post-metadata">

**Author:** ![Andrea\_Campi](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/andrea_campi/32/514_2.png) [@Andrea\_Campi](https://discourse.chef.io/u/Andrea_Campi)\
**Post date:** [December 29, 2011, 10:23pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/9 "2011-12-29T22:23:55Z")

</div>

Joshua,

On Tue, Dec 27, 2011 at 8:13 PM, Joshua Timberman [joshua@opscode.com](mailto:joshua@opscode.com) wrote:

> Ohai!
> 
> I'd like to start a conversation and collect feedback about how Chef  
> should manage Ruby at an OS/app level, in particular when Chef is  
> installed using the "Omnibus" full stack installer[0]. Feedback  
> collected will better help us in providing cookbooks that work with  
> Ruby applications besides Chef.  
> ...  
> What are you doing in your environment to manage Ruby? Are you using  
> the same installation of Ruby with Chef _and_ your application? If you're  
> using the Omnibus full-stack installer, are you managing a separate  
> Ruby for your applications?

as you know well, we run FreeBSD on most of our servers. Some of them  
don't need ruby except for chef, or don't care about a specific  
version. On the others (mostly app servers running rails), we've had a  
mixed experience.  
Chef on ruby 1.8.7 is prone to crashing hard quite often; sometimes we  
have 2-3 crashes in a row on subsequent chef-client runs.  
Luckily, we only run 1.8 on a few legacy servers so that's not been a  
big issue; at least not big enough to look for a complicated solution.  
But that's a good example of something we are looking forward to solve  
once we standardize on Omnibus.

The scenario is pretty much the same with our customers: most of the  
ones who run Rails apps have already moved to 1.9 (or have been using  
JRuby), with a small number of legacy apps on 1.8.

We do love rvm on developer workstations, but we don't really care for  
the complexity of running it on production servers.  
Also, going forward we are focusing on CloudFoundry, which does a very  
good job letting each app use the version of ruby it wants, regardless  
of what the rest of the system runs.

So the bottom line for us is: as long as Omnibus works nicely, and we  
can have a way of installing a separate ruby 1.9 and gems for it, we  
don't really need a move involved solution.

Andrea

---

<div class="post-metadata">

**Author:** ![Burkholder\_Peter](https://avatars.discourse-cdn.com/v4/letter/b/ebca7d/32.png) [@Burkholder\_Peter](https://discourse.chef.io/u/Burkholder_Peter)\
**Post date:** [December 30, 2011, 4:05pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/10 "2011-12-30T16:05:21Z")

</div>

Hi,  
On Dec 29, 2011, at 1:37 PM, Joshua Timberman wrote:

> $: \<\< "/usr/lib64/ruby/site\_ruby/1.8/x86\_64-linux/"

but then.....

chef \> require 'selinux'  
=\> true  
chef \> Selinux.lgetfilecon("/etc/ntp.conf")  
TypeError: in method 'lgetfilecon', argument 1 of type 'char const \*'  
from (irb):3:in `lgetfilecon' from (irb):3 from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:73:in `block in start'  
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:72:in `catch' from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:72:in `start'  
from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/bin/shef:34:in `<top (required)>' from /opt/opscode/bin/shef:19:in `load'  
from /opt/opscode/bin/shef:19:in `'

So it loads, but it doesn't work. Hmmm.

-Peter

--  
Peter Burkholder | Sr. System Administrator (consultant)  
AARP | Digital Strategy & Operations | 601 E Street NW | Washington, DC 20049  
[pburkholder@aarp.org](mailto:pburkholder@aarp.org) | aim: peterbtech | w: 202-434-3530 | c: 202-344-7129  
For optimal efficiency, I check email at 2-hour intervals during the workday  
(except when on-call). Please use IM or phone to contact me for urgent matters

---

<div class="post-metadata">

**Author:** ![Joshua\_Timberman](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/joshua_timberman/32/424_2.png) [@Joshua\_Timberman](https://discourse.chef.io/u/Joshua_Timberman)\
**Post date:** [December 30, 2011, 10:23pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/11 "2011-12-30T22:23:35Z")

</div>

Hello!

On Dec 30, 2011, at 9:05 AM, Burkholder, Peter wrote:

> > $: \<\< "/usr/lib64/ruby/site\_ruby/1.8/x86\_64-linux/"
> 
> but then.....
> 
> chef \> require 'selinux'  
> =\> true  
> chef \> Selinux.lgetfilecon("/etc/ntp.conf")  
> TypeError: in method 'lgetfilecon', argument 1 of type 'char const \*'  
> from (irb):3:in `lgetfilecon' from (irb):3 from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:73:in `block in start'  
> from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:72:in `catch' from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/shef.rb:72:in `start'  
> from /opt/opscode/embedded/lib/ruby/gems/1.9.1/gems/chef-0.10.8/bin/shef:34:in `<top (required)>' from /opt/opscode/bin/shef:19:in `load'  
> from /opt/opscode/bin/shef:19:in `'
> 
> So it loads, but it doesn't work. Hmmm.

Ah, of course. The package compiled against the version of Ruby available in the distribution, since is a C extension, so in order to work with the Ruby in the Chef Full Stack installation, it needs to be recompiled with that version of Ruby (1.9.2p180). That's fine in many environments - to build C extension RubyGems on systems when installing the gem, but not in environments where C compiler and build toolchains are prohibited from servers by security policy.

--  
Opscode, Inc  
Joshua Timberman, Technical Program Manager  
IRC, Skype, Twitter, Github: jtimberman

---

<div class="post-metadata">

**Author:** ![Alex\_Howells](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/alex_howells/32/664_2.png) [@Alex\_Howells](https://discourse.chef.io/u/Alex_Howells)\
**Post date:** [December 31, 2011, 2:40am UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/12 "2011-12-31T02:40:26Z")

</div>

On 30 December 2011 22:23, Joshua Timberman [joshua@opscode.com](mailto:joshua@opscode.com) wrote:

> Ah, of course. The package compiled against the version of Ruby available in the distribution, since is a C extension, so in order to work with the Ruby in the Chef Full Stack installation, it needs to be recompiled with that version of Ruby (1.9.2p180). That's fine in many environments - to build C extension RubyGems on systems when installing the gem, but not in environments where C compiler and build toolchains are prohibited from servers by security policy.

If Omnibus is "The Future" then I'm guessing the Ruby which you ship  
inside it is going to have a _lot_ of stuff bolted on.

Is that something you've thought about and are okay with?

I'm generally a little concerned that Omnibus could be very divisive.  
Those who can use it and benefit, because their needs are simple, and  
those who are excluded because they want to use a technology (SELinux)  
which is not included and supported.

Whilst I appreciate you will never cater to all needs, and there is a  
core of 'power user' out there who will always do their own thing, the  
recommended route for deploying chef-client (which seems to be heading  
in an Omnibus direction) needs to cater for the masses, and that  
_does_ mean things like SELinux (amongst other things) will become  
increasingly important to support properly.

Cheers,  
-Alex

---

<div class="post-metadata">

**Author:** ![Alex\_Howells](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/alex_howells/32/664_2.png) [@Alex\_Howells](https://discourse.chef.io/u/Alex_Howells)\
**Post date:** [December 31, 2011, 2:41am UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/13 "2011-12-31T02:41:53Z")

</div>

On 31 December 2011 02:40, Alex Howells [lists@howells.me](mailto:lists@howells.me) wrote:

> On 30 December 2011 22:23, Joshua Timberman [joshua@opscode.com](mailto:joshua@opscode.com) wrote:
> 
> > Ah, of course. The package compiled against the version of Ruby available in the distribution, since is a C extension, so in order to work with the Ruby in the Chef Full Stack installation, it needs to be recompiled with that version of Ruby (1.9.2p180). That's fine in many environments - to build C extension RubyGems on systems when installing the gem, but not in environments where C compiler and build toolchains are prohibited from servers by security policy.
> 
> If Omnibus is "The Future" then I'm guessing the Ruby which you ship  
> inside it is going to have a _lot_ of stuff bolted on.
> 
> Is that something you've thought about and are okay with?

NB: This means instead of benefiting from the Ubuntu Security folks  
handling all the repackaging when a security bug comes out, you guys  
are assuming responsibility for patching your intepreter. No longer is  
it just chef-client bugs, now you have responsibility for the full  
stack you deployed via Omnibus...

---

<div class="post-metadata">

**Author:** ![Brad\_Knowles](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/brad_knowles/32/716_2.png) [@Brad\_Knowles](https://discourse.chef.io/u/Brad_Knowles)\
**Post date:** [December 31, 2011, 4:02am UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/14 "2011-12-31T04:02:14Z")

</div>

On Dec 30, 2011, at 8:40 PM, Alex Howells wrote:

> Whilst I appreciate you will never cater to all needs, and there is a  
> core of 'power user' out there who will always do their own thing, the  
> recommended route for deploying chef-client (which seems to be heading  
> in an Omnibus direction) needs to cater for the masses, and that  
> _does_ mean things like SELinux (amongst other things) will become  
> increasingly important to support properly.

I'm not convinced that SELinux is something that the "masses" deal with today, or that it is something they will be dealing with in the near future.

IMO, Chef has a long ways to go with regards to better supporting other OS platforms, even just other versions of Linux that are commonly used in the business community (e.g., RHEL/CentOS). Ideally, we would have both better support for other platforms AND support for SELinux, but in reality we have to face the facts that there will always be limits to the available resources.

Of course, the core code supports multiple platforms fine, but one of the biggest advantages that you're getting with Chef is the community cookbooks, and that's also their Achilles Heel with regards to support for platforms other than Ubuntu. That said, this kind of thing is entirely expected when you're talking about such a young product from such a young company, especially one that has such strong ties to the open source community. Given time, this problem would tend to largely resolve itself as the company grows, the customer list grows, and the community grows.

My biggest concern is the risk that we might all get put on the back burner so that they can focus on Windows. That's the biggest potential market with the biggest potential ROI, and I think it would be the most attractive to bean counters.

However, I also think it is also a huge risk that Microsoft might wipe them out with a single stroke -- or worse, buy them up and then kill support for all non-Microsoft OSes.

--  
Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com)  
SAGE Level IV, Chef Level 0.0.1

---

<div class="post-metadata">

**Author:** ![Tensibai](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tensibai/32/29_2.png) [@Tensibai](https://discourse.chef.io/u/Tensibai)\
**Post date:** [January 2, 2012, 1:26pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/15 "2012-01-02T13:26:55Z")

</div>

Le 31.12.2011 05:02, Brad Knowles a écrit :

> On Dec 30, 2011, at  
> 8:40 PM, Alex Howells wrote:
> 
> > Whilst I appreciate you will never  
> > cater to all needs, and there is a core of 'power user' out there who  
> > will always do their own thing, the recommended route for deploying  
> > chef-client (which seems to be heading in an Omnibus direction) needs to  
> > cater for the masses, and that _does_ mean things like SELinux (amongst  
> > other things) will become increasingly important to support properly.

> I'm not convinced that SELinux is something that the "masses" deal  
> with today, or that it is something they will be dealing with in the  
> near future.
> 
> I-- Brad Knowles SAGE Level IV, Chef Level 0.0.1

I've  
to agree that se-linux is not a widely used system in my experience  
(usaully disabled because causing more troubles than help to secure).

As a sysadmin I do prefer to ensure critical system parts are secured  
in an usual way than relying on se-linux which would need me to add one  
more rule to do a dumb thing touching system files.

I've a point of  
view which is: relying on se-linux and saying the box is secure is the  
same as thinking you'll be able to stop properly when driving at 200  
Km/h with an ABS on a rusty car. In brief: fix the car before adding it  
drive assists.

So if you really rely on SE-Linux and can't do an  
update path using chef, there's a problem in the way Se-Linux is  
configured.

Tensibai.

## Links:

[1]  
[mailto:bknowles@ihiji.com](mailto:bknowles@ihiji.com)

---

<div class="post-metadata">

**Author:** ![Tim\_Uckun](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/tim_uckun/32/751_2.png) [@Tim\_Uckun](https://discourse.chef.io/u/Tim_Uckun)\
**Post date:** [January 1, 2012, 12:28pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/16 "2012-01-01T12:28:00Z")

</div>

We use REE and usually install it via a custom written script. I tried  
using ruby build but it didn’t work with the latest version of ubuntu  
the last time I gave it a shot.

Looks like REE is about become history though so we will have to move  
on to something else either MRI or Jruby.

---

<div class="post-metadata">

**Author:** ![hani\_elabed](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/hani_elabed/32/772_2.png) [@hani\_elabed](https://discourse.chef.io/u/hani_elabed)\
**Post date:** [January 1, 2012, 7:18pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/17 "2012-01-01T19:18:03Z")

</div>

out of curiosity, where have you heard that REE is history ?  
I checked Phusion's web site, no mention of this...

Hani

On Sun, Jan 1, 2012 at 6:28 AM, Tim Uckun [timuckun@gmail.com](mailto:timuckun@gmail.com) wrote:

> We use REE and usually install it via a custom written script. I tried  
> using ruby build but it didn't work with the latest version of ubuntu  
> the last time I gave it a shot.
> 
> Looks like REE is about become history though so we will have to move  
> on to something else either MRI or Jruby.

---

<div class="post-metadata">

**Author:** ![Adam\_Jacob](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/adam_jacob/32/292_2.png) [@Adam\_Jacob](https://discourse.chef.io/u/Adam_Jacob)\
**Post date:** [January 1, 2012, 11:35pm UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/18 "2012-01-01T23:35:08Z")

</div>

The short answer: yes. Nothing about the omnibus approach make this harder, and the alternative is untenable today - target the lowest common denominator (rhel 4, honestly, for a while longer) for everyone.

For the vast majority of dependencies, having to keep track of security updates is already a born cost.

If we want to deliver a sane, viable experience on every platform, this is the way forward, in my opinion.

For the selinux case, building the selinux bindings on platforms that support them is trivial to do.

Adam

Sent from my iPhone

On Dec 30, 2011, at 6:40 PM, Alex Howells [lists@howells.me](mailto:lists@howells.me) wrote:

> On 30 December 2011 22:23, Joshua Timberman [joshua@opscode.com](mailto:joshua@opscode.com) wrote:
> 
> > Ah, of course. The package compiled against the version of Ruby available in the distribution, since is a C extension, so in order to work with the Ruby in the Chef Full Stack installation, it needs to be recompiled with that version of Ruby (1.9.2p180). That's fine in many environments - to build C extension RubyGems on systems when installing the gem, but not in environments where C compiler and build toolchains are prohibited from servers by security policy.
> 
> If Omnibus is "The Future" then I'm guessing the Ruby which you ship  
> inside it is going to have a _lot_ of stuff bolted on.
> 
> Is that something you've thought about and are okay with?
> 
> I'm generally a little concerned that Omnibus could be very divisive.  
> Those who can use it and benefit, because their needs are simple, and  
> those who are excluded because they want to use a technology (SELinux)  
> which is not included and supported.
> 
> Whilst I appreciate you will never cater to all needs, and there is a  
> core of 'power user' out there who will always do their own thing, the  
> recommended route for deploying chef-client (which seems to be heading  
> in an Omnibus direction) needs to cater for the masses, and that  
> _does_ mean things like SELinux (amongst other things) will become  
> increasingly important to support properly.
> 
> Cheers,  
> -Alex

---

<div class="post-metadata">

**Author:** ![Alex\_Kiernan](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/alex_kiernan/32/473_2.png) [@Alex\_Kiernan](https://discourse.chef.io/u/Alex_Kiernan)\
**Post date:** [January 2, 2012, 10:51am UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/19 "2012-01-02T10:51:17Z")

</div>

On Tue, Dec 27, 2011 at 7:13 PM, Joshua Timberman [joshua@opscode.com](mailto:joshua@opscode.com) wrote:

> What are you doing in your environment to manage Ruby? Are you using  
> the same installation of Ruby with Chef _and_ your application? If you're  
> using the Omnibus full-stack installer, are you managing a separate  
> Ruby for your applications?

Omnibus has been a complete god-send for us. We're stuck on  
RedHat/Oracle Linux 5.5, prior to omnibus whenever we rolled out a new  
chef client it was a week of intense pain as we tried to find some  
combination that worked whilst breaking workstations left right and  
centre (we're a combined development/operations team - we use  
chef-client on our workstations and CI, then chef-solo all the way  
through to production).

In the two days I worked between Christmas and New Year I updated  
everything to 0.10.8-2 and then for good measure rolled out a new chef  
server using the omnibus packages - compared to our last rollout of  
chef server (roughly a year ago - we were on 0.10.0) it was remarkably  
painless. We've got the omnibus build process off-pat inside mock now  
so I'm hoping to push it onto our Jenkins server some time in the near  
future.

We'd previously tried umpteen approaches to getting a good install:

- rvm
- third party repos
- build it everywhere
- probably some more I've forgotten!

We're principally a Java shop so for the most part we're not worried  
about any ruby on a box (other than for Chef) - for sysadmin stuff I  
tend to push additional gems into the omnibus ruby, but it's a klunky  
approach, if we were actually deploying something which was ruby I'd  
want a properly packaged (modern) ruby which I could use, but still  
separate from Chef.

--  
Alex Kiernan

---

<div class="post-metadata">

**Author:** ![Alex\_Kiernan](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/alex_kiernan/32/473_2.png) [@Alex\_Kiernan](https://discourse.chef.io/u/Alex_Kiernan)\
**Post date:** [January 2, 2012, 10:58am UTC](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297/20 "2012-01-02T10:58:13Z")

</div>

On Sat, Dec 31, 2011 at 4:02 AM, Brad Knowles [bknowles@ihiji.com](mailto:bknowles@ihiji.com) wrote:

> On Dec 30, 2011, at 8:40 PM, Alex Howells wrote:
> 
> > Whilst I appreciate you will never cater to all needs, and there is a  
> > core of 'power user' out there who will always do their own thing, the  
> > recommended route for deploying chef-client (which seems to be heading  
> > in an Omnibus direction) needs to cater for the masses, and that  
> > _does_ mean things like SELinux (amongst other things) will become  
> > increasingly important to support properly.
> 
> I'm not convinced that SELinux is something that the "masses" deal with today, or that it is something they will be dealing with in the near future.
> 
> IMO, Chef has a long ways to go with regards to better supporting other OS platforms, even just other versions of Linux that are commonly used in the business community (e.g., RHEL/CentOS). Ideally, we would have both better support for other platforms AND support for SELinux, but in reality we have to face the facts that there will always be limits to the available resources.
> 
> Of course, the core code supports multiple platforms fine, but one of the biggest advantages that you're getting with Chef is the community cookbooks, and that's also their Achilles Heel with regards to support for platforms other than Ubuntu. That said, this kind of thing is entirely expected when you're talking about such a young product from such a young company, especially one that has such strong ties to the open source community. Given time, this problem would tend to largely resolve itself as the company grows, the customer list grows, and the community grows.

We've mostly not found it too bad - maybe the cookbooks we're using  
are pretty mainstream. The biggest pain we've had recently is the  
changes in 0.10.4 (I think) which separated out all the RedHat clones

- we've a mix of RedHat and Oracle Enterprise Linux and having to pick  
through cookbooks to find the multiple if/case statements which check  
for redhat/fedora/scientific/centos and add in  
"enterpriseenterpriselinux" is pretty dull; some refactoring to have  
ohai report some kind of platform "flavour" would be helpful.

--  
Alex Kiernan

[Next page](https://discourse.chef.io/t/ruby-chef-omnibus-and-you/2297.md?page=2)