Closed epu closed 5 years ago
Comparing imported windows base boxes to make sure they are identical, to try and rule out broken powershell/winrm versions between environments. They are using the same base windows box. On windows, I am also able to cd to the test kitchen's temp dir for the machine (.kitchen/kitchen-vagrant/node-name) and do a vagrant winrm -c 'setx http_proxy "http//192.168.0.1:8123" /M'
and it returns success.
I'm sorry, I have very little knowledge with Windows nowadays. So I have no idea how to move forwards with this issue...
Can confirm that proxyconf 1.5.2 with vagrant 1.8.1 works on a Windows 10 host with Windows 2008R2 guest
@rlaveycal I'll try again over here, thanks.
No further problems have been reported about this issue. Please re-open with ways to reproduce if this is still an issue.
With vagrant-proxyconf version 1.5.0, installed into vagrant 1.7.2 on a windows host, during a test-kitchen 'kitchen create' of a windows guest, when the communicator for a windows guest is set to winrm, and the windows guest is using an http/https proxy, the SETX commands for configuring environment variables fail with non-zero exit code.
Ran into this during a chef test-kitchen converge, windows7 guest, windows7 host. Proxying is working ok on linux guests over ssh communicator in the same setup. On my windows guest/yosemite 10.10.3 host, the SETX commands execute ok. This is the part that's confusing me: I would expect windows host/windows guest to also work, or osx host/windows guest to also fail.
This is with matching chefdk 0.6 installs on windows/mac hosts, running test-kitchen 1.4.0 with vagrant-proxyconf plugin installed.
Is the machine.communicate.sudo() call acting differently on osx than it is on windows?