I am working on a basic Rails stack with Berkshelf that I would like to
present at http://wrocloverb.com/ if things work out. Basically, my goal
is to have a:
berks install
vagrant up
and get a running Rails stack that would be easy to customize (e.g.
switching the database like MySQL, Postgres, Mongo, Arangodb, ... )
Then, I removed some cookbook dependencies by applying Berkshelf.
So far, my setup is now:
But since the stack above uses rbenv (which I think is interesting for
testing different VM baseboxes), I am running into a gem problem.
The first provisioning works fine, however I am running into a dependency
problem, that I don't understand how to solve:
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:224:in run_application' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in loop'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in run_application' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application.rb:72:in run'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/chef-solo:25
/opt/ruby/bin/chef-solo:19:in `load'
/opt/ruby/bin/chef-solo:19
[2013-02-25T10:59:43+00:00] FATAL: Chef::Exceptions:
package[curl-dev] (nginx::passenger line 38) had an error:
Chef::Exceptions: No version specified, and no candidate version
available for curl-dev
I think the problem is related to rbenv/ruby build setup, since the next
provisioning will not find the chef-solo gem anymore.
Any help or feedback what I could do, would be great!
I had a similar problem before, but with RVM instead of rbenv.
The problem was that I had switched the ruby to the RVM one, and my VM had chef installed on its own ruby.
Fletcher Nichol's RVM cookbook [0] (the one I'm using) works around the problem with a 'vagrant' recipe [1] which I add to my Vagrant VMs run_list and point to chef-client's executable. You might be able to use that as a starting point.
A workaround that might work is to add the chef gem to the rbenv managed ruby on the first conversion.
On Monday, February 25, 2013 at 08:02, Patrick Mulder wrote:
Hello,
I am working on a basic Rails stack with Berkshelf that I would like to present at http://wrocloverb.com/ if things work out. Basically, my goal is to have a:
berks install
vagrant up
and get a running Rails stack that would be easy to customize (e.g. switching the database like MySQL, Postgres, Mongo, Arangodb, ... )
But since the stack above uses rbenv (which I think is interesting for testing different VM baseboxes), I am running into a gem problem.
The first provisioning works fine, however I am running into a dependency problem, that I don't understand how to solve:
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:224:in run_application' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in loop'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in run_application' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application.rb:72:in run'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/chef-solo:25
/opt/ruby/bin/chef-solo:19:in `load'
/opt/ruby/bin/chef-solo:19
[2013-02-25T10:59:43+00:00] FATAL: Chef::Exceptions: package[curl-dev] (nginx::passenger line 38) had an error: Chef::Exceptions: No version specified, and no candidate version available for curl-dev
I think the problem is related to rbenv/ruby build setup, since the next provisioning will not find the chef-solo gem anymore.
Any help or feedback what I could do, would be great!
I see the vagrant recipe as part of RVM and rbenv. Still I am having two
problems, after this commit:
Sp:
chef-solo gem is still out of the scope (= running vagrant provision the
next time ends with (whether or not I include the chef gem in node.json)
[default] Running provisioner: Vagrant::Provisioners::ChefSolo...
The chef binary (either chef-solo or chef-client) was not found on
the VM and is required for chef provisioning. Please verify that chef
is installed and that the binary is available on the PATH.
in the first run, I get stuck with the same error as previously:
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in loop' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in run_application'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application.rb:72:in run' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/chef-solo:25 /opt/ruby/bin/chef-solo:19:in load'
/opt/ruby/bin/chef-solo:19
[2013-02-25T14:38:18+00:00] FATAL: Chef::Exceptions:
package[curl-dev] (nginx::passenger line 38) had an error:
Chef::Exceptions: No version specified, and no candidate version
available for curl-dev
I had a similar problem before, but with RVM instead of rbenv.
The problem was that I had switched the ruby to the RVM one, and my VM had
chef installed on its own ruby.
Fletcher Nichol's RVM cookbook [0] (the one I'm using) works around the
problem with a 'vagrant' recipe [1] which I add to my Vagrant VMs run_list
and point to chef-client's executable. You might be able to use that as a
starting point.
A workaround that might work is to add the chef gem to the rbenv managed
ruby on the first conversion.
On Monday, February 25, 2013 at 08:02, Patrick Mulder wrote:
Hello,
I am working on a basic Rails stack with Berkshelf that I would like to
present at http://wrocloverb.com/ if things work out. Basically, my goal
is to have a:
berks install
vagrant up
and get a running Rails stack that would be easy to customize (e.g.
switching the database like MySQL, Postgres, Mongo, Arangodb, ... )
But since the stack above uses rbenv (which I think is interesting for
testing different VM baseboxes), I am running into a gem problem.
The first provisioning works fine, however I am running into a dependency
problem, that I don't understand how to solve:
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:224:in run_application' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in loop'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in run_application' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application.rb:72:in run'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/chef-solo:25
/opt/ruby/bin/chef-solo:19:in `load'
/opt/ruby/bin/chef-solo:19
[2013-02-25T10:59:43+00:00] FATAL: Chef::Exceptions:
package[curl-dev] (nginx::passenger line 38) had an error:
Chef::Exceptions: No version specified, and no candidate version
available for curl-dev
I think the problem is related to rbenv/ruby build setup, since the next
provisioning will not find the chef-solo gem anymore.
Any help or feedback what I could do, would be great!
Try setting attributes to tell rvm::vagrant where to find the executables for chef-client and chef-solo. I have these lines on one of the attributes file:
The curl-dev issue might be the case of outdated repository information. This has bitten me a few times. Try one of these two solutions (I'm assuming a Debian/Ubuntu VM here, adapt if that's not the case, but the concept remains):
Add a dependency on the 'apt' cookbook, and make sure to 'include_recipe "apt::default"' before installing packages; or
Add a shell provisioner on the Vagrantfile before the Chef one, like so:
config.vm.provision :shell, :inline => 'aptitude update'
Either solution will update the package cache before attempting to install a package. I usually go with the second one, as this is an issue that's specific to the VM having been just booted. I run apt::default on my base role so that the cache is always up-to-date.
cassiano
On Monday, February 25, 2013 at 11:40, Patrick Mulder wrote:
Thanks, Cassiano!
I see the vagrant recipe as part of RVM and rbenv. Still I am having two problems, after this commit:
chef-solo gem is still out of the scope (= running vagrant provision the next time ends with (whether or not I include the chef gem in node.json)
[default] Running provisioner: Vagrant::Provisioners::ChefSolo...
The chef binary (either chef-solo or chef-client) was not found on
the VM and is required for chef provisioning. Please verify that chef
is installed and that the binary is available on the PATH.
in the first run, I get stuck with the same error as previously:
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in loop' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in run_application'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application.rb:72:in run' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/chef-solo:25 /opt/ruby/bin/chef-solo:19:in load'
/opt/ruby/bin/chef-solo:19
[2013-02-25T14:38:18+00:00] FATAL: Chef::Exceptions: package[curl-dev] (nginx::passenger line 38) had an error: Chef::Exceptions: No version specified, and no candidate version available for curl-dev
I had a similar problem before, but with RVM instead of rbenv.
The problem was that I had switched the ruby to the RVM one, and my VM had chef installed on its own ruby.
Fletcher Nichol's RVM cookbook [0] (the one I'm using) works around the problem with a 'vagrant' recipe [1] which I add to my Vagrant VMs run_list and point to chef-client's executable. You might be able to use that as a starting point.
A workaround that might work is to add the chef gem to the rbenv managed ruby on the first conversion.
On Monday, February 25, 2013 at 08:02, Patrick Mulder wrote:
Hello,
I am working on a basic Rails stack with Berkshelf that I would like to present at http://wrocloverb.com/ if things work out. Basically, my goal is to have a:
berks install
vagrant up
and get a running Rails stack that would be easy to customize (e.g. switching the database like MySQL, Postgres, Mongo, Arangodb, ... )
But since the stack above uses rbenv (which I think is interesting for testing different VM baseboxes), I am running into a gem problem.
The first provisioning works fine, however I am running into a dependency problem, that I don't understand how to solve:
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:224:in run_application' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in loop'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application/solo.rb:216:in run_application' /opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/../lib/chef/application.rb:72:in run'
/opt/ruby/lib/ruby/gems/1.8/gems/chef-10.18.2/bin/chef-solo:25
/opt/ruby/bin/chef-solo:19:in `load'
/opt/ruby/bin/chef-solo:19
[2013-02-25T10:59:43+00:00] FATAL: Chef::Exceptions: package[curl-dev] (nginx::passenger line 38) had an error: Chef::Exceptions: No version specified, and no candidate version available for curl-dev
I think the problem is related to rbenv/ruby build setup, since the next provisioning will not find the chef-solo gem anymore.
Any help or feedback what I could do, would be great!
Try setting attributes to tell rvm::vagrant where to find the
executables for chef-client and chef-solo. I have these lines on one of the
attributes file:
Try setting attributes to tell rvm::vagrant where to find the
executables for chef-client and chef-solo. I have these lines on one of the
attributes file:
The curl-dev issue might be the case of outdated repository
information. This has bitten me a few times.
Thanks Cassiano!
Problem 2. can be solved as you suggested.
Still fighting a bit with 1. but I saw a pull-request which might be
related to the same problem:
Ok, I found the problem to be the sudo cookbook together with the rbenv/rvm
cookbooks; the conversion will fail, if the rvm/rbenv cookbook is used
together with:
package[curl-dev] (nginx::passenger line 38) had an error: Chef::Exceptions: