Proxy settings from Workstation not copied to target node

[tyler-ball]

Description

In corporate environments where both the Workstation and target node (web1 in this case, the example from Learn Chef) are locked down the user needs to specify http_proxy, https_proxy and no_proxy settings to achieve connectivity. This works well enough on the Workstation to download chef client but then the remote chef-client run fails because the web1 machine does not have the same proxy settings.

Chef Apply Version

chef-run-0.1.119 but this also affects master

Platform Version

The docker container from Learn Chef

Replication Case

1. Restrict internet access from Workstation machine
2. Set up a proxy that has available internet access. In my case I setup a local squid proxy listening on 8088
3. Restrict internet access from web1 machine but allow that machine access to the proxy
4. Export http_proxy="localhost:8088" or whatever proxy settings are required then run chef-run web1 recipe.rb

Client Output

root@ptet47qyjoxs:~# chef-run web1 recipe.rb
[✔] [web1] Connected.
[✔] [web1] Successfully installed Chef client version 14.7.17
[✖] [web1] Failed to converge target.
 
CHEFCCR002
 
The converge of the remote host failed for the
following reason:
 
  Expected process to exit with [0], but received '100'
 
If you are not able to resolve this issue, please contact Chef support
at [email protected]

Stacktrace

It looks like it’s having hard time running resources. Inside the recipe it started failing on “package figlet” line.

cat recipe.rb
apt_update
package 'figlet'
directory '/tmp'
execute 'write_hello_world' do
    command 'figlet Hello World! > /tmp/hello.txt'
    not_if { File.exist?('/tmp/hello.txt') }
end

[tyler-ball]

I was able to help the customer fix the issue by having them manually set their proxy settings on the web1 machine. In action/converge_target.rb where we create the target config I had them manually add the proxy settings, like so:

      workstation_rb = <<~EOM
        local_mode true
        color false
        cache_path "#{cache_path}"
        chef_repo_path "#{cache_path}"
        require_relative "reporter"
        reporter = ChefRun::Reporter.new
        report_handlers << reporter
        exception_handlers << reporter
        http_proxy “corporate.com:8888”
        http_proxy “corporate.com:8888"
      EOM

I propose we either:

1. Always export any proxy settings from the workstation to the target, maybe with a configuration to disable this
2. Allow them to specify target node proxy settings in ~/.chef-workstation/config.toml
3. Some combination of these

[marcparadise]

Always export any proxy settings from the workstation to the target, maybe with a configuration to disable this

I like this as an option but not a default behavior - things will get harder to track down if we discretely push out proxy settings invalid for the node(s).

Allow them to specify target node proxy settings in ~/.chef-workstation/config.toml

I initially liked this, but thinking through my response above has me less sure. How common would it be that customers will have different proxy config for different nodes (regional, etc)?

If that's a corner case, then I'd be 👍 on adding it as config.

Otherwise - would it be more consistent to provide something like remote_http_proxy as an additional environment variable (consistency with http_proxy env), or as a CLI flag (consistent with other target-affecting options)?

I'm leaning towards the new env var for consistency with other proxy settings.

[jeremydumet]

Hi @tyler-ball, I am running into the same problem and I am also behind a corporate proxy. However, when I connect to the try-chef_web1_1 container in a bash session I am not able to find the action/converge_target.rb file you've mentioned. Can you please give more details on how you've proceed? I am a beginner to Chef. Thank you!

[tyler-ball]

@jeremydumet I typically use a find command to find it. On Linux it would be find /opt/chef-workstation -name converge_target.rb -type f

[jeremydumet]

Thank you!