HTTP(S)_PROXY env vars causing 504's connecting to WinRM about bosh-windows-stemcell-builder HOT 7 CLOSED

@sneal Sorry for the (four month...) delay. We have a story for finalizing our removal of the ruby requirement in the manual stemcell building process here: https://www.pivotaltracker.com/story/show/148743023.

I'll ping back once that's been delivered.

from bosh-windows-stemcell-builder.

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/141820559

The labels on this github issue will be updated when the story is started.

from bosh-windows-stemcell-builder.

@sneal We are trying to cache the gems for bundler under vendor/cache. Is that not working as expected? This should remove the need to reach to Rubygems.org. If that works as expected, would it be safe to always unset HTTP_PROXY and HTTPS_PROXY for packer to work?

from bosh-windows-stemcell-builder.

@sneal Can you set NO_PROXY for the IP Address ranges you don't want? Sounds like you are trying to use the proxy to hit WinRM on a server the proxy can't connect to because it is inside your network?

from bosh-windows-stemcell-builder.

@aminjam On a cleanly cloned repo when the script calls bundle install for the first time it'll attempt to fetch the gem index from Rubygems.org. This can easily be seen by setting an invalid proxy.

$ HTTP_PROXY=http://127.0.0.1:4545 HTTPS_PROXY=https://127.0.0.1:4545 bundle install
Fetching source index from https://rubygems.org/

Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Retrying fetcher due to error (3/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
Retrying fetcher due to error (4/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/Could not fetch specs from https://rubygems.org/

I think the customer encountered an error like this and then added the HTTP(S)_PROXY env vars. If you add the --local flag then bundler won't attempt to reach out to rubygems and will use the vendor/cache directory as intended.

$ HTTP_PROXY=http://127.0.0.1:4545 HTTPS_PROXY=https://127.0.0.1:4545 bundle install --local
Using rake 12.0.0
Using aws-sigv4 1.0.0
Using jmespath 1.3.1
Using diff-lcs 1.3
Using mini_portile2 2.1.0
Using rspec-support 3.5.0
Using rubyzip 1.2.1
Using timecop 0.8.1
Using bundler 1.13.6
Using aws-sdk-core 2.8.1
...

@pearcec The winrm connection issue with Packer is definitely caused by the HTTP(S)_PROXY env vars, which shouldn't need to be set if we're using the --local flag with bundler. Most users will likely run this from a Windows box without those env vars already set, so for most cases I think we'll be ok. The NO_PROXY env var could be useful for Packer in cases where customers have set the HTTP(S)_PROXY env vars previously. That's probably not very many.

In my opinion an improved solution would not require Ruby. Shipping a statically compiled golang executable for each platform would greatly simplify installation and configuration, especially on Windows which currently requires Ruby and the Ruby DevKit to be installed so native extensions (Nokogiri I'm looking at you) can be compiled.

from bosh-windows-stemcell-builder.

@sneal The story above is delivered, but as I'm rereading this thread I realize I misunderstood your issue.

The fix above removes the ruby dependency for a manual stemcell building process (as described here), but your issue here was specifically related to bundler requiring a proxy be configured and packer requiring one not be configured when trying to kick off an automated stemcell build in a walled-off corporate environment with a proxy for egress. More generally, you have concerns about our packer provisioners' dependency on ruby use of rake tasks for running and configuring packer, and the Ruby dependency on the host builder that rake introduces.

We have an epic to revisit and formalize our guidance for automated stemcell builds here, and we may choose to remove the broader Ruby dependency at that time, for a variety of reasons I'm sure you're familiar with. I'll post back if we have anything new to add there.

from bosh-windows-stemcell-builder.

Apologies once again for the delay in response for this. We've provided a structured way for using proxies. I'll close this issue for now, but please re-open if the issues persist.

from bosh-windows-stemcell-builder.