Omnibus Client installer open beta


#1

We’ve been building and testing a Chef feature for a while now that we
call Omnibus.

Sometimes getting a good version of Ruby and the right libraries on a
system can be daunting and makes a difficult Chef install for
newcomers. Today I’d like to release the Omnibus Client for open beta.
This includes the latest version of the chef-client and everything you
need to run it.

Head over to http://www.opscode.com/chef/install where we have pull
down menus for the operating systems we’ve tested it on, and the
simple instructions for installing it.

You’ll find everything installed in /opt/opscode. If you’re on a
Redhat or Debian based Linux distribution that we detect, we wrap the
install in a deb or rpm so you can manage it with your package
management tools as well. Binaries are symlinked into /usr/bin for
convenience. You should remove any other versions of Chef you have
installed first, but you can leave any keys or configuration files
behind in /etc/chef and the Omnibus Client will pick them up.

There’s a little script included to help set up your configuration on
fresh hosts:

— Opscode Hosted Chef

Save a copy of your validation key in a file like ‘validation.pem’

sudo /opt/opscode/setup.sh -v validation.pem -o ORGANIZATION

— Open Source Chef Server

Save a copy of your validation key in a file like ‘validation.pem’

sudo /opt/opscode/setup.sh -v validation.pem -u http://chef.example.org

In both cases you’ll need to change the organization name or the URL.

One big caveat is that because we put everything Chef needs in
/opt/opscode/embedded, so the instance of Ruby that Chef uses will be
different than the instance installed on your system, particularly if
you don’t have a system ruby. Consequently, when you use the
"gem_package" resource inside a Chef recipe, this package will be
installed in the version of Rubygems that comes with Chef. This may
not be what you expect, but we can’t reliably guess where you Rubygems
installation is and if you have more than one, which you want us to
use. So we default to our own installation of Rubygems. Thus, if you
want a gem installed with gem_package to your system ruby gems you
need to provide the gem_binary attribute like this:

Install the rake binary for raking things on the system like a raker would.

gem_package “rake” do
gem_binary "/usr/bin/gem"
end

Install bundler to the system, any system

gem_package “bundler” do
gem_binary “gem” # System gem
version "1.0.15"
only_if (node[‘platform’] == ‘windows’ ? “where gem” : “which gem”)
end

We’ll be updating our own cookbooks to cope:
http://tickets.opscode.com/browse/COOK-744

Let us know how it goes, and what you you think. You can file bugs
against the Chef project on http://tickets.opscode.com, please add
"omnibus" as a label so we can find it. Be sure so specify what
version of the Omnibus Client you are using, which is the Chef version
but includes an Omnibus specific revision number like “0.10.8-2” would
be the second revision of the Omnibus build for Chef 0.10.8.

I’m still thinking about where and how to document changes. A wiki
page may suffice, but we may need a full blown JIRA project.


Bryan McLellan | opscode | technical program manager
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#2

I’ve used this on various version of Ubuntu and Red Hat (4 and 5) and I
think it’s awesome! I truly appreciate the ease of use it brings to client
installs.

Sascha

On Fri, Dec 16, 2011 at 4:22 PM, Bryan McLellan btm@opscode.com wrote:

We’ve been building and testing a Chef feature for a while now that we
call Omnibus.

Sometimes getting a good version of Ruby and the right libraries on a
system can be daunting and makes a difficult Chef install for
newcomers. Today I’d like to release the Omnibus Client for open beta.
This includes the latest version of the chef-client and everything you
need to run it.

Head over to http://www.opscode.com/chef/install where we have pull
down menus for the operating systems we’ve tested it on, and the
simple instructions for installing it.

You’ll find everything installed in /opt/opscode. If you’re on a
Redhat or Debian based Linux distribution that we detect, we wrap the
install in a deb or rpm so you can manage it with your package
management tools as well. Binaries are symlinked into /usr/bin for
convenience. You should remove any other versions of Chef you have
installed first, but you can leave any keys or configuration files
behind in /etc/chef and the Omnibus Client will pick them up.

There’s a little script included to help set up your configuration on
fresh hosts:

— Opscode Hosted Chef

Save a copy of your validation key in a file like ‘validation.pem’

sudo /opt/opscode/setup.sh -v validation.pem -o ORGANIZATION

— Open Source Chef Server

Save a copy of your validation key in a file like ‘validation.pem’

sudo /opt/opscode/setup.sh -v validation.pem -u http://chef.example.org

In both cases you’ll need to change the organization name or the URL.

One big caveat is that because we put everything Chef needs in
/opt/opscode/embedded, so the instance of Ruby that Chef uses will be
different than the instance installed on your system, particularly if
you don’t have a system ruby. Consequently, when you use the
"gem_package" resource inside a Chef recipe, this package will be
installed in the version of Rubygems that comes with Chef. This may
not be what you expect, but we can’t reliably guess where you Rubygems
installation is and if you have more than one, which you want us to
use. So we default to our own installation of Rubygems. Thus, if you
want a gem installed with gem_package to your system ruby gems you
need to provide the gem_binary attribute like this:

Install the rake binary for raking things on the system like a raker

would.
gem_package “rake” do
gem_binary "/usr/bin/gem"
end

Install bundler to the system, any system

gem_package “bundler” do
gem_binary “gem” # System gem
version "1.0.15"
only_if (node[‘platform’] == ‘windows’ ? “where gem” : “which gem”)
end

We’ll be updating our own cookbooks to cope:
http://tickets.opscode.com/browse/COOK-744

Let us know how it goes, and what you you think. You can file bugs
against the Chef project on http://tickets.opscode.com, please add
"omnibus" as a label so we can find it. Be sure so specify what
version of the Omnibus Client you are using, which is the Chef version
but includes an Omnibus specific revision number like “0.10.8-2” would
be the second revision of the Omnibus build for Chef 0.10.8.

I’m still thinking about where and how to document changes. A wiki
page may suffice, but we may need a full blown JIRA project.


Bryan McLellan | opscode | technical program manager
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org


#3

On Fri, Dec 16, 2011 at 11:22 PM, Bryan McLellan btm@opscode.com wrote:

We’ve been building and testing a Chef feature for a while now that we
call Omnibus.

Sometimes getting a good version of Ruby and the right libraries on a
system can be daunting and makes a difficult Chef install for
newcomers. Today I’d like to release the Omnibus Client for open beta.
This includes the latest version of the chef-client and everything you
need to run it.

Head over to http://www.opscode.com/chef/install where we have pull
down menus for the operating systems we’ve tested it on, and the
simple instructions for installing it.

There’s something I don’t quite get: what’s the point of having the pull down?

At the end of the day, it just shows instructions for either
Unix-derivatives or Windows—wouldn’t a radio box work just as well?

Andrea


#4

On Sat, Dec 17, 2011 at 10:42 AM, Andrea Campi
andrea.campi@zephirworks.com wrote:

There’s something I don’t quite get: what’s the point of having the pull down?

At the end of the day, it just shows instructions for either
Unix-derivatives or Windows—wouldn’t a radio box work just as well?

The web page has been through a couple redesigns for various reasons.
I would say it never really got a proper design.

The original idea is that the instructions could vary based on the
operating system and version. For instance, Ubuntu systems should run
through “| sudo bash” whereas debian users are more likely to be root
and the command should just “| bash”. Also the instructions originally
used wget, which isn’t everywhere by default so some were switched to
use curl. Is curl everywhere? I’m not sure.

These items still need work, and I really wanted comments on this page
before we fully released, so I just shipped what I had been given
already. There’s definitely work to be done on that page.

Bryan


#5

Hi,
On Dec 16, 2011, at 8:32 PM, Sascha Bates wrote:

I’ve used this on various version of Ubuntu and Red Hat (4 and 5) and I think it’s awesome! I truly appreciate the ease of use it brings to client installs.

Sascha
So, how do I move forward getting this to our RedHat EL4 boxes (since I can’t drop off the roof just yet). I only see RHEL5/6 as supported.

Thanks,

Peter

Peter Burkholder | Sr. System Administrator (consultant)
AARP | Digital Strategy & Operations | 601 E Street NW | Washington, DC 20049
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


#6

I did it in June so my memory is sketchy. But I believe I downloaded an
OS-agnostic version (like a .tgz set) and installed from the command line.
I also think I had to work some bugs fixes into it, but I don’t think it
was related to RH4 - just an early version of the omnibus.

The client I was at elected to compile their own ruby on RH4 instead of
using the omnibus at that time, but I did get it working.

You can read the install.sh and see the URL where the omnibus is coming
from:

url=“http://s3.amazonaws.com/opscode-full-stack/$platform-$platform_version-$machine/$filename

This page has an xml listing of all the packages:
http://s3.amazonaws.com/opscode-full-stack

I’m pretty sure I just grabbed one of the existing red hat installs
for 5.x and was able to get it to work. I was pretty excited when I
managed, but truthfully I can’t remember if I did anything special.

Sorry to be so not-helpful :slight_smile:

Sascha

On Sat, Dec 17, 2011 at 10:05 AM, Burkholder, Peter PBurkholder@aarp.orgwrote:

Hi,
On Dec 16, 2011, at 8:32 PM, Sascha Bates wrote:

I’ve used this on various version of Ubuntu and Red Hat (4 and 5) and I
think it’s awesome! I truly appreciate the ease of use it brings to client
installs.

Sascha
So, how do I move forward getting this to our RedHat EL4 boxes (since I
can’t drop off the roof just yet). I only see RHEL5/6 as supported.

Thanks,

Peter

Peter Burkholder | Sr. System Administrator (consultant)
AARP | Digital Strategy & Operations | 601 E Street NW | Washington, DC
20049
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


#7

Like Sascha hints, the install.sh is just a script that determines what
distribution, version and arch you’re on, then grabs the appropriate
tarball (or deb or rpm) from S3.

I don’t know about getting it working on RHEL 4. We have separate build
servers for 5.x and 6.x because of system level differences. Ive never
tried to get 4.x to work.

If something needs to be changed we could try to do so if it was clear what
it was.

Bryan
On Dec 17, 2011 11:06 AM, “Burkholder, Peter” PBurkholder@aarp.org wrote:

Hi,
On Dec 16, 2011, at 8:32 PM, Sascha Bates wrote:

I’ve used this on various version of Ubuntu and Red Hat (4 and 5) and I
think it’s awesome! I truly appreciate the ease of use it brings to client
installs.

Sascha
So, how do I move forward getting this to our RedHat EL4 boxes (since I
can’t drop off the roof just yet). I only see RHEL5/6 as supported.

Thanks,

Peter

Peter Burkholder | Sr. System Administrator (consultant)
AARP | Digital Strategy & Operations | 601 E Street NW | Washington, DC
20049
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


#8

I have 3 remaining RHEL 4 boxes under Chef management. I should have
that down to 1 remaining RHEL 4 box by end of year. I will however,
share my experience running it on RHEL4.

As far as I know RHEL 4 has never been a supported platform for Chef.
Some of the problems you’ll encounter will be the package provider
defaulting to yum. While the actual package manager is up2date, and
there is no up2date package provider for Chef. So if you do choose to
use it on RHEL 4, then you’ll need to add the EPEL repo for the 4.x
release. You’ll need a yum package at the least. Can’t remember if I
got a yum RHEL4 package from EPEL, or Dag Wieers’ repo. I just have an
empty yum.conf on RHEL4, so that yum won’t return an error code if Chef
does happen to call it. I do avoid managing packages on RHEL4.
Instead, I manage resources like users, flat config files, and template.

The other hurdle you may encounter is getting a recent Ruby, and Gem
binary, on RHEL4. I believe our remaining RHEL4 systems had Chef
installed by RVM (http://rvm.beginrescueend.com). I can’t say for
certain if this was a manual process, or if I used my scripted
installer. You can find the source code for that scripted installer,
here: https://github.com/atomic-penguin/chef-fat-installer. It should
work out of the box on RHEL4, but it may not. However, you could modify
it to run up2date commands, or at the least, derive a manual
installation process from the code. Using RVM to bootstrap Chef is
probably frowned on, at least now that we have Omnibus. If you want to
use Chef to manage resources on RHEL4 there honestly are not a lot of
well tested options to get Ruby and Gem on your RHEL4 system, in this case.

I hope that helps. In summary, if you can get a Ruby and Gem supported
by Chef on the RHEL4 box, installing by rubygems is the easiest route
(http://wiki.opscode.com/display/chef/Installing+Chef+Client+on+Other+Operating+Systems).

On 12/17/2011 11:05 AM, Burkholder, Peter wrote:

Hi,
On Dec 16, 2011, at 8:32 PM, Sascha Bates wrote:

I’ve used this on various version of Ubuntu and Red Hat (4 and 5) and I think it’s awesome! I truly appreciate the ease of use it brings to client installs.

Sascha
So, how do I move forward getting this to our RedHat EL4 boxes (since I can’t drop off the roof just yet). I only see RHEL5/6 as supported.

Thanks,

Peter

Peter Burkholder | Sr. System Administrator (consultant)
AARP | Digital Strategy& Operations | 601 E Street NW | Washington, DC 20049
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