Install specific chef version using omnibus


#1

Is it possible to install a particular version of chef using the
omnibus installer command?

curl -L http://www.opscode.com/chef/install.sh | sudo bash

I ask because one of the cookbooks that I use fails on 0.10.14 and I
would like to continue using 0.10.12 until the issue is sorted out.
I’ve been downloading the .deb packages directly and installing them,
but I like the simplicity of the above command.


#2

On Wednesday, September 12, 2012 at 8:34 AM, Jon-Erik Schneiderhan wrote:

Is it possible to install a particular version of chef using the
omnibus installer command?

curl -L http://www.opscode.com/chef/install.sh | sudo bash

The script takes a -v VERSION argument, but it won’t work with the curl | bash method, you have to download the script first and then run it.

Knife bootstrap should try to install the version you’re currently using for knife.

Or, you can visit the install Chef page ( http://www.opscode.com/chef/install/ ) and get the direct link to the package you want.


Daniel DeLeo


#3

On Wed, Sep 12, 2012 at 11:34 AM, Jon-Erik Schneiderhan
jschneiderhan@gmail.com wrote:

curl -L http://www.opscode.com/chef/install.sh | sudo bash

sudo true && curl -L https://www.opscode.com/chef/install.sh | sudo
bash -s – -v 10.12.0

The sudo true is to ensure you get asked the password immediately if
needed, otherwise the password prompt can be confusing.

-s explicitly tells bash to take input from stdin
– tells bash to stop interpreting arguments for itself
-v 10.12.0 as Dan mentions, tells install.sh what Chef version to download.

Unfortunately the API that serves these files doesn’t know about
versions of Chef before 10.12.0. You can find older Omnibus packages
in the old archive here:

https://opscode-full-stack.s3.amazonaws.com/

What bug are you seeing? Are you using 10.14.0 or 10.14.2?

Bryan


#4

Bryan,

Has Opscode put together a policy on retention of previous versions of
Chef within the Omnibus installer? I am a bit hesitant to use a script to
install a very critical part of my infrastructure without certainty that
the version I need will be there in the future. Older versions of Chef 10
are already missing from apt.opscode.com, but the use of debs allows
anyone to archive off versions they rely on to a local repository. That
goes away if you rely on a script to install Chef. While I’d like to
always run the current release of Chef, parts of my infrastructure still
run on Chef .9 and upgrading it tricky sometimes. Will there be a posted
lifecycle for each release?

Thanks,
Tim

On 9/12/12 8:57 AM, “Bryan McLellan” btm@loftninjas.org wrote:

On Wed, Sep 12, 2012 at 11:34 AM, Jon-Erik Schneiderhan
jschneiderhan@gmail.com wrote:

curl -L http://www.opscode.com/chef/install.sh | sudo bash

sudo true && curl -L https://www.opscode.com/chef/install.sh | sudo
bash -s – -v 10.12.0

The sudo true is to ensure you get asked the password immediately if
needed, otherwise the password prompt can be confusing.

-s explicitly tells bash to take input from stdin
– tells bash to stop interpreting arguments for itself
-v 10.12.0 as Dan mentions, tells install.sh what Chef version to
download.

Unfortunately the API that serves these files doesn’t know about
versions of Chef before 10.12.0. You can find older Omnibus packages
in the old archive here:

https://opscode-full-stack.s3.amazonaws.com/

What bug are you seeing? Are you using 10.14.0 or 10.14.2?

Bryan


#5

On Wed, Sep 12, 2012 at 1:35 PM, Tim Smith Tim.Smith@webtrends.com wrote:

Has Opscode put together a policy on retention of previous versions of
Chef within the Omnibus installer? I am a bit hesitant to use a script to
install a very critical part of my infrastructure without certainty that
the version I need will be there in the future. Older versions of Chef 10
are already missing from apt.opscode.com, but the use of debs allows
anyone to archive off versions they rely on to a local repository. That
goes away if you rely on a script to install Chef. While I’d like to
always run the current release of Chef, parts of my infrastructure still
run on Chef .9 and upgrading it tricky sometimes. Will there be a posted
lifecycle for each release?

Actually, Opscode doesn’t delete any of the old versions of any of the
packages; Omnibus, rubygems or the deb packages.

— Omnibus

Omnibus packages were beta until 10.12.0, when we announced Omnibus
shortly thereafter. This is why releases before 10.12.0 are not
included in the API endpoint for downloading.


If someone wants the Omnibus beta releases, they can grab them out of
the S3 bucket, they’re all still there:
https://opscode-full-stack.s3.amazonaws.com/

— Rubygems

The gems on rubygems.org go back to 0.7.10 released in September 2009.
For anyone alive way back then, you might recall that rubygems.org had
a lot of stability issues in the past and we had our own gem server,
from which you can still get old gems (its actually an S3 bucket now).

http://rubygems.org/gems/chef/versions

gem list '^chef’ -r -a --source http://gems.opscode.com

*** REMOTE GEMS ***

chef (10.14.2, 10.14.0, 10.12.0, 0.10.10, 0.10.8, 0.10.6, 0.10.4,
0.10.2, 0.10.0, 0.9.18, 0.9.16, 0.9.14, 0.9.12, 0.9.10, 0.9.8, 0.9.6,
0.9.4, 0.9.2, 0.9.0, 0.8.16, 0.8.14, 0.8.10, 0.8.8, 0.8.6, 0.8.4,
0.8.2, 0.7.16 ruby, 0.7.14 ruby, 0.7.12 ruby, 0.7.10 ruby, 0.7.8,
0.7.4, 0.7.2, 0.7.0, 0.6.2, 0.6.0, 0.5.6, 0.5.4, 0.5.2, 0.5.1)

— Debian packages

Debian archives are hard. Really they’re just a file hierarchy with
some special files and signing, which should be easy, but this has led
to lots of tools that do just enough. We’ve been using reprepro for
quite some time, which creates the indexes and signs them, but it
doesn’t support having more than one version of the same package in
the index it creates. Of course we use separate repositories for each
major release to allow folks to only get upgrades for their own
release if they’re not pinning or using a local repository for
software management. We discovered that originally reprepro cleaned up
older versions, but we figured out how to turn that off, and there are
multiple versions of debian packages stored there.

http://apt.opscode.com/pool/main/c/chef/

Bryan


#6

On Wednesday, September 12, 2012 at 10:35 AM, Tim Smith wrote:

Bryan,

Has Opscode put together a policy on retention of previous versions of
Chef within the Omnibus installer? I am a bit hesitant to use a script to
install a very critical part of my infrastructure without certainty that
the version I need will be there in the future. Older versions of Chef 10
are already missing from apt.opscode.com (http://apt.opscode.com), but the use of debs allows
anyone to archive off versions they rely on to a local repository. That
goes away if you rely on a script to install Chef. While I’d like to
always run the current release of Chef, parts of my infrastructure still
run on Chef .9 and upgrading it tricky sometimes. Will there be a posted
lifecycle for each release?

Thanks,
Tim

Just to be clear, the script is just a bit of magic to figure out which OS and CPU architecture you’re on, the installation is done via whatever package manager is appropriate for your system.

If you go to http://www.opscode.com/chef/install/ and click through the drop-down menus, you can get links to the actual packages, which you can archive as needed. If you want to automate this process for various OSes and architectures, you can grab the Location headers from the download URL (or just follow the redirect):

http://www.opscode.com/chef/download?v={version}&p={platform}&pv={platform_version}&m={machine}

As far as a retention policy, we haven’t decided anything yet, but it’s not our intention to force people to upgrade to versions they’re not ready for. Since the Omnibus packages are a new feature, we decided not to backport old versions of Chef, but this doesn’t imply that older versions will be purged.

HTH,


Daniel DeLeo


#7

Thank you so much for the reply! I was hoping there was a parameter I
could pass to specify the version - this is exactly what I was looking
for.

FYI - The bug I am seeing is detailed here
https://github.com/sensu/sensu-chef/issues/61 (Cannot find a resource
for assert_enclosing_directory_exists!)

On Wed, Sep 12, 2012 at 2:18 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, September 12, 2012 at 10:35 AM, Tim Smith wrote:

Bryan,

Has Opscode put together a policy on retention of previous versions of
Chef within the Omnibus installer? I am a bit hesitant to use a script to
install a very critical part of my infrastructure without certainty that
the version I need will be there in the future. Older versions of Chef 10
are already missing from apt.opscode.com, but the use of debs allows
anyone to archive off versions they rely on to a local repository. That
goes away if you rely on a script to install Chef. While I’d like to
always run the current release of Chef, parts of my infrastructure still
run on Chef .9 and upgrading it tricky sometimes. Will there be a posted
lifecycle for each release?

Thanks,
Tim

Just to be clear, the script is just a bit of magic to figure out which OS
and CPU architecture you’re on, the installation is done via whatever
package manager is appropriate for your system.

If you go to http://www.opscode.com/chef/install/ and click through the
drop-down menus, you can get links to the actual packages, which you can
archive as needed. If you want to automate this process for various OSes and
architectures, you can grab the Location headers from the download URL (or
just follow the redirect):

http://www.opscode.com/chef/download?v={version}&p={platform}&pv={platform_version}&m={machine}

As far as a retention policy, we haven’t decided anything yet, but it’s not
our intention to force people to upgrade to versions they’re not ready for.
Since the Omnibus packages are a new feature, we decided not to backport old
versions of Chef, but this doesn’t imply that older versions will be purged.

HTH,


Daniel DeLeo


#8

This is also being a problem for me as well while firing up new node on EC2.
How to specify the version when launching the new instance on ec2 via knife?


@millisami
~ Sachin Sagar Rai
Ruby on Rails Developer
http://tfm.com.np
http://nepalonrails.tumblr.com
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Thursday, September 13, 2012 at 1:04 AM, Jon-Erik Schneiderhan wrote:

Thank you so much for the reply! I was hoping there was a parameter I
could pass to specify the version - this is exactly what I was looking
for.

FYI - The bug I am seeing is detailed here
https://github.com/sensu/sensu-chef/issues/61 (Cannot find a resource
for assert_enclosing_directory_exists!)

On Wed, Sep 12, 2012 at 2:18 PM, Daniel DeLeo <dan@kallistec.com (mailto:dan@kallistec.com)> wrote:

On Wednesday, September 12, 2012 at 10:35 AM, Tim Smith wrote:

Bryan,

Has Opscode put together a policy on retention of previous versions of
Chef within the Omnibus installer? I am a bit hesitant to use a script to
install a very critical part of my infrastructure without certainty that
the version I need will be there in the future. Older versions of Chef 10
are already missing from apt.opscode.com (http://apt.opscode.com), but the use of debs allows
anyone to archive off versions they rely on to a local repository. That
goes away if you rely on a script to install Chef. While I’d like to
always run the current release of Chef, parts of my infrastructure still
run on Chef .9 and upgrading it tricky sometimes. Will there be a posted
lifecycle for each release?

Thanks,
Tim

Just to be clear, the script is just a bit of magic to figure out which OS
and CPU architecture you’re on, the installation is done via whatever
package manager is appropriate for your system.

If you go to http://www.opscode.com/chef/install/ and click through the
drop-down menus, you can get links to the actual packages, which you can
archive as needed. If you want to automate this process for various OSes and
architectures, you can grab the Location headers from the download URL (or
just follow the redirect):

http://www.opscode.com/chef/download?v={version}&p={platform}&pv={platform_version}&m={machine}

As far as a retention policy, we haven’t decided anything yet, but it’s not
our intention to force people to upgrade to versions they’re not ready for.
Since the Omnibus packages are a new feature, we decided not to backport old
versions of Chef, but this doesn’t imply that older versions will be purged.

HTH,


Daniel DeLeo


#9

Try using knife’s option: --bootstrap-version VERSION

On Sun, Sep 16, 2012 at 2:04 PM, Sachin Sagar Rai millisami@gmail.com wrote:

This is also being a problem for me as well while firing up new node on EC2.
How to specify the version when launching the new instance on ec2 via knife?


@millisami
~ Sachin Sagar Rai
Ruby on Rails Developer
http://tfm.com.np
http://nepalonrails.tumblr.com
Sent with Sparrow

On Thursday, September 13, 2012 at 1:04 AM, Jon-Erik Schneiderhan wrote:

Thank you so much for the reply! I was hoping there was a parameter I
could pass to specify the version - this is exactly what I was looking
for.

FYI - The bug I am seeing is detailed here
https://github.com/sensu/sensu-chef/issues/61 (Cannot find a resource
for assert_enclosing_directory_exists!)

On Wed, Sep 12, 2012 at 2:18 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, September 12, 2012 at 10:35 AM, Tim Smith wrote:

Bryan,

Has Opscode put together a policy on retention of previous versions of
Chef within the Omnibus installer? I am a bit hesitant to use a script to
install a very critical part of my infrastructure without certainty that
the version I need will be there in the future. Older versions of Chef 10
are already missing from apt.opscode.com, but the use of debs allows
anyone to archive off versions they rely on to a local repository. That
goes away if you rely on a script to install Chef. While I’d like to
always run the current release of Chef, parts of my infrastructure still
run on Chef .9 and upgrading it tricky sometimes. Will there be a posted
lifecycle for each release?

Thanks,
Tim

Just to be clear, the script is just a bit of magic to figure out which OS
and CPU architecture you’re on, the installation is done via whatever
package manager is appropriate for your system.

If you go to http://www.opscode.com/chef/install/ and click through the
drop-down menus, you can get links to the actual packages, which you can
archive as needed. If you want to automate this process for various OSes and
architectures, you can grab the Location headers from the download URL (or
just follow the redirect):

http://www.opscode.com/chef/download?v={version}&p={platform}&pv={platform_version}&m={machine}

As far as a retention policy, we haven’t decided anything yet, but it’s not
our intention to force people to upgrade to versions they’re not ready for.
Since the Omnibus packages are a new feature, we decided not to backport old
versions of Chef, but this doesn’t imply that older versions will be purged.

HTH,


Daniel DeLeo