I needed to deploy a different node specific license file to our windows hosts so I wrote a cookbook_file resource that looked something like this:

cookbook_file 'C:\\Program Files (x86)\\vendor\\node.license'

And using the file-specificity overhaul I expected to be able to create a directory for each host under our-cookbook/files/host-NODENAME/our.license and have that be the file for that specific node.

our-cookbook $ tree files/host-nodes*
└── node.license
└── node.license
└── node.license
└── node.license

It took me a while to understand my failed assumptions.

NODENAME isn’t the same as FQDN

It usually is, but on windows ec2 instances they often differ.

Ec2Config service is configured by default on many windows AMIs to reset computer name on next boot which results in new machines geting renamed to ip-IP_INHEX where IP_INHEX is the hex representation of the internal ip.

$ knife winrm -m $IP 'ohai' | grep fqdn   "fqdn": "ip-0A7106AB",

When we bootstrap an ec2 ami and give it an ec2 instance name and nodename for chef, the fdqn/hostname is often left as the default:

$ knife search node *:$NODE_NAME
1 items found

Node Name:   $NODE_NAME
Environment: OURENV
FQDN:        ip-0A7106AB
Platform:    windows 6.3.9600

The fix for getting our license files into place based on the chef nodename was to add a source parameter to our resource based on the node.name

cookbook_file 'C:\\Program Files (x86)\\vendor\\node.license'' do
  # normally this is host-#{node['fdqn']} and on aws/windows than ip-HEXNUMBR
  source "host-#{node.name}/node.license'"