WinRM ConnectTimeoutError when using AWS

Chef-EC2-Windows-WinRM-Issue.md

Issue

knife winrm ConnectTimeoutError when using AWS (Chef Automate) and EC2

Workstation: MacOS 10.12.4
chef Development Kit Version: 1.5.0
chef-client version: 12.21.2
delivery version: master (17c1b0fed9be4c70f69091a6d21a4cbf0df60a23)
berks version: 5.6.4
kitchen version: 1.16.0
inspec version: 1.25.1

What I use

I've created a new Chef Automate (OpsWorks). I've created a cookbook and uploaded to server. Started a new EC2 Windows 2012 R2. Remote access to ec2 and allow Firewall. The EC2 instance is in my private subnet.

So now I add the EC2 as a node. This works great. It appears in Chef Automate portal. knife bootstrap windows winrm 172.31.x.yyy --winrm-user Administrator --winrm-password 'mysecret' --node-name test-windows-1 --run-list 'role[web]'

However. Now I manually try to make an update

knife winrm 'role:web' chef-client --winrm-user Administrator --winrm-password 'mysecret' --attribute cloud.public_hostname
ERROR: HTTPClient::ConnectTimeoutError: execution expired

also tried with

knife winrm 'name:test-windows-1' chef-client --winrm-user Administrator --winrm-password 'mysecret' --attribute cloud.public_hostname
ERROR: HTTPClient::ConnectTimeoutError: execution expired

Looking at the ec2 instance I can't see any new tags or other stuff. Don't know if cloud.public_hostname should be added as a tag?

Hi @fbacker,

Thanks for providing the clear explanation of what you tried. For this module, we specify that your node needs a public IP address. We do this for simplicity (in other words, to avoid all the variations and forks that come otherwise.)

That said, what you did was perfectly valid. I don't have a live environment in front of me to verify, but here are some thoughts on things you can try and experiment with.

1. Simply omit the --attribute cloud.public_hostname part. The default attribute is ipaddress, which I believe already refers to your node's IP address on the private network. (This works only because your workstation is on the same subnet.)

2. I don't have a screenshot handy, but from the Chef Automate web interface, you can drill down into your node's details (start by clicking the Nodes tab.) From there, you can find all of your node's attributes. Try to find one that contains your node's IP address and specify that attribute for the --attribute flag.

3. Specify your node's IP address from knife winrm rather than using search. Here's the syntax:

$ knife winrm 172.31.x.yyy chef-client --winrm-user Administrator --winrm-password 'mysecret' --manual-list

This is a good option to experiment with, just remember that you wouldn't get the benefit of running the command on multiple nodes simultaneously.

4. Define the cloud.public_hostname node attribute like you suggest. I believe knife node edit will let you do that. In the example in the docs, you can add your node attribute to the automatic section.

"automatic": {
  "cloud": {
    "public_hostname": "172.31.x.yyy"
  }
 },

This might be an interesting exercise to try, but in practice I might avoid doing this because semantically, cloud.public_hostname isn't your node's public IP address.

---

I'd love to hear what you find. Happy to try to help more if you get stuck.

We have VPN for AWS, third party hosting and the office.
We always use VPN to the office before accessing any servers. That's making everything 'private ip' when working.
Also the AWS and custom hosting talks internal so Chef Automate uses private ip (not all servers are public faced).

Here's my findings :)

Suggestion 1:

$ knife winrm 'role:web' chef-client --winrm-user Administrator --winrm-password 'mysecret'
ERROR: Network Error: getaddrinfo: nodename nor servname provided, or not known (WIN-OOL5EK0FIOF:5985)
Check your knife configuration and network settings

Suggestion 2:

$ knife winrm 'role:web' chef-client --winrm-user Administrator --winrm-password 'mysecret' --attribute 172.31.3.96
FATAL: 2 nodes found, but does not have the required attribute (172.31.3.96) to establish the connection. Try setting another attribute to open the connection using --attribute.

$ knife winrm 'name:test-windows-2' chef-client --winrm-user Administrator --winrm-password 'mysecret' --attribute 172.31.3.96
FATAL: 1 node found, but does not have the required attribute (172.31.3.96) to establish the connection. Try setting another attribute to open the connection using --attribute.

Suggestion 3: Works

$ knife winrm 172.31.3.96 chef-client --winrm-user Administrator --winrm-password 'mysecret' --manual-list
172.31.3.96 [2017-06-29T06:48:45+00:00] INFO: *** Chef 12.21.1 ***
172.31.3.96 [2017-06-29T06:48:45+00:00] INFO: Platform: x64-mingw32

Suggestion 4:

Node not updated, skipping node save
Would be better to be able to use private_hostname maybe if these features are looked into.