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.
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
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
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.0The 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
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
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
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
Method assert_enclosing_directory_exists! has been removed from Chef 10.14.0 · Issue #61 · sensu/sensu-chef · GitHub (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,
TimJust 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
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
Method assert_enclosing_directory_exists! has been removed from Chef 10.14.0 · Issue #61 · sensu/sensu-chef · GitHub (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,
TimJust 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
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 SparrowOn 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
Method assert_enclosing_directory_exists! has been removed from Chef 10.14.0 · Issue #61 · sensu/sensu-chef · GitHub (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,
TimJust 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