Question: Working with proxies about kitchen-puppet HOT 3 CLOSED

in the logs you should see the puppet command that is being run
Going to invoke puppet apply with: xxxxxxxxxxxxxxxxxxxxxx
also try running with debug.
kitchen converge myserver-platform -l debug
you could try with a different driver ie kitchen-ec2 or vagrant and see if the hhps-proxy works then it might be something with docker (not saying the bug is in docker but maybe proxies don't work in the same way as you have a extra server layer).

from kitchen-puppet.

Tried Vagrant. Not so much an issue with EC2 as that runs outside our proxy. Get the same issue with Vagrant.

I have some changes that helps run the provision phase, at least for me, but I am not sure if it is something we should really need in general: https://github.com/peterabbott/kitchen-puppet/tree/feature/http_proxy_changes

The issue I now see is trying to get past the firewall to install Chef. The method #{sudo('sh')} /tmp/install.sh fails because the script does not know how to get the proxy.

With the changes above the only way I can get a successful run is with require_chef_for_busser: false and setting the verifier to name: dummy. Still need to workout solution for the verify stage.

At home all this works fine, it is just our "wonderful" corporate proxy that is not only inflexible but also decides to rewrite ssl certs :(

from kitchen-puppet.

A different solution that allows me to install chef is to add this to the platform (in this case kitchen-docker) provision phase:

  provision_command:
        - echo "export httpx_proxy=<%= ENV['http_proxy'] %>" | tee -a /etc/profile.d/proxy.sh
        - echo "export https_proxy=<%= ENV['http_proxy'] %>" | tee -a /etc/profile.d/proxy.sh

that gets me Chef but it fails on the install of busser and the plugins because of the SSL cert verification.

Again that is my environment issue so I'll close this

from kitchen-puppet.