3

Using chef-solo on Chef12, I assume the /opt/chef/embedded/bin path is appended to the system PATH and various libraries such as openssl and makedepend work through that path.

Upgrading to Chef13 with the same chef-solo command, I get errors such as -

  * execute[generate ca.pem] action run

================================================================================
Error executing action `run` on resource 'execute[generate ca.pem]'
================================================================================

Errno::ENOENT
-------------
No such file or directory - openssl

Resource Declaration:
      command "openssl x509 -req -in hostname.csr -CA /path/to/ca.pem -CAkey /path/to/ca.key -CAcreateserial -out hostname.cer -days 512 -sha256"

The system information is -

------------------------
chef_version=13.6.4
platform=oracle
platform_version=7.4
ruby=ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux]
program_name=chef-solo worker: ppid=627;start=06:32:26;
executable=/opt/chef/bin/chef-solo

The current PATH right now only has /usr/bin and other system bin directories but not the /opt/chef/embedded/bin.

I looked into enforce_path_sanity but we don't use kitchen files.(Ref. - https://github.com/chef/chef/issues/3705 )

Any other way to force the chef-solo client to use the embedded library ?

Raamish Malik
  • 105
  • 10

1 Answers1

4

This behavior was changed in Chef Client 13. It's no longer the default to enforce path sanity. The reason for this is that setting the chef embedded bin directory as part of the path could cause an unexpected version of a binary to run if the user also has the same binary elsewhere.

There is a few ways you could proceed. You could install the openssl package (recommended), you could give the absolute path to the binary you need, or you could set enforce_path_sanity to true in your config file to revert this behavior to what you are familiar with (client.rb, solo.rb, or otherwise).

Brandon Miller
  • 4,695
  • 1
  • 20
  • 27
  • 1
    Or your recipe could install openssl via your OS packaging system, which is probably what you should do. – coderanger May 25 '18 at 14:06
  • I updated the answer to reflect that recommendation. It is likely the best path to moving forward. However, the question did specifically ask how to force `chef-solo` to use the old behavior. I think this answer addresses that question as well as presents the better path forward now. – Brandon Miller May 25 '18 at 14:14
  • Thank you for that detailed answer. I had indeed found out that code change but was worried why do we need to set it explicitly. As for the suggestion by @coderanger , I run the recipe's on a very light docker image using Jenkins and I can't afford to install too many libraries on it. If it is already a part of chef, I would prefer to use that to be more efficient. Thanks a lot for helping out though. – Raamish Malik May 28 '18 at 05:19
  • Using internal CLI tools (i.e. things only in embedded/bin/, not bin/) is not supported. When it breaks (and it will, eventually) you get to keep all the pieces. It's hard enough maintaining cross-platform installers for Chef, let alone the dozen other tools in there :) – coderanger May 28 '18 at 07:34