Ohai cookbook doesn't like the default relative solo_path

[jdsiegel]

When using knife-solo against a server with a normal account that has sudo, the ohai cookbook will converge successfully on the initial chef-solo run, but subsequent runs result in an error:

Errno::ENOENT
-------------
No such file or directory - ./chef-solo/solo.rb

<snip>

Relevant File Content:
----------------------
/home/vagrant/chef-solo/cookbooks/ohai/recipes/default.rb:

46:  # only reload ohai if new plugins were dropped off OR
47:  # node['ohai']['plugin_path'] does not exists in client.rb
48:  if reload_ohai ||
49>>   !(::IO.read(Chef::Config[:config_file]) =~ /Ohai::Config\[:plugin_path\]\s*<<\s*["']#{node['ohai']['plugin_path']}["']/)
50:  
51:    resource.run_action(:reload)
52:  end

This is due to chef-solo's config file being specified as ./chef-solo, which can't be found during the converge step.

Steps to replicate

This was tested using the master branch (SHA: 0b5c88a) against an Ubuntu 12.04 LTS server

1. Initialize a new repo
2. Add the nginx cookbook via Berkshelf or Librarian
3. Add a node with the run list "recipe[nginx]"
4. Load up a vagrant instance using a chef-less box and no provisioner
5. Ensure your knife.rb doesn't set a solo_path
6. knife solo bootstrap vagrant@server (this should pass)
7. knife solo cook vagrant@server (this should fail)

Workaround

The ohai cookbook is happy with an absolute path. Add the following line to your knife.rb file:

knife[:solo_path] = "~/chef-solo"

Changing the default solo_path from ./chef-solo to ~/chef-solo would address this, too.

[tmatilai]

I think a better approach would be to expand the path on the node. But all this will still probable change quite a bit before 0.3.0 is released. At least #199 has some ideas about it.

Anyway thanks for an excellent report! This has to be fixed of course.

[jdsiegel]

Awesome, I figured it was still in flux. :) Expanding the path would be nice, for sure. I'll keep an eye on #199 for discussion.

[matschaffer]

👍 for expanding the path when we run the command. And 👍 for bug reports with headers. Way to be @jdsiegel

[allaire]

Changing the path to "~/chef-solo" fixed it for me! Way more secure to run knife solo under a sudo user, any plans to highly suggest it in the README once all the quirks are sorted out? The necessity to use root user means you must at least have PermitRootLogin without-password in your SSH config, unless I'm wrong?

Thanks!

[matschaffer]

#199 is my latest attempt to fix this. Haven't quite settled on code that
both Teemu and I can agree on ;)

Thanks for the report. If you're up for some experimentation feel free to
give that branch a kick.

On Mar 2, 2013, at 15:44, Mathieu Allaire notifications@github.com wrote:

Changing the path to "~/chef-solo" fixed it for me! Way more secure to run
knife solo under a sudo user, any plans to highly suggest it in the README
once all the quirks are sorted out? The necessity to use root user means
you must at least have PermitRootLogin without-password in your SSH config,
unless I'm wrong?

Thanks!

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/212#issuecomment-14335342
.

[allaire]

Will do, thank you!

[algesten]

Changing the path to "~/chef-solo" fixed it for me!

Just to clarify, this means changing your local ~/.chef/knife.rb.

princess$ cat ~/.chef/knife.rb 
knife[:solo_path] = "~/chef-solo"

I had to create the file since it wasn't there for me.

[tmatilai]

@algesten You seem to have an earlier 0.3.0 prerelease, as the option name changed to knife[:provisioning_path] (or --provisioning-path from command line) in v0.3.0.pre3 (pre5 is the latest). The default is ~/chef-solo so you you don't even need to change it normally.

[algesten]

So did it change in pre3 or after?

princess$ gem list | grep knife-solo
knife-solo (0.3.0.pre3)

[tmatilai]

My quick search from the history hinted that it should have been changed in pre3. I haven't had enough coffee yet though, so I might be wrong. =)