Chef-client on Windows always use the default value rather than what I configured in client.rb

Chef Infra (archive)
1

I’m trying to bootstrap a node. I can’t use knife to bootstrap for governance concerns. what I did is:

  1. Install chef client chef-client-14.1.12-1-x64.msi
  2. configure c:\chef\client.rb
chef_server_url  'https://*************************/org-name' 
validation_client_name 'org-name-validator'
validation_key	'c:\chef\org-name-validator.pem'
node_name 'HOSTNAME'
current_dir = File.dirname(__FILE__)
log_level                :info
log_location             STDOUT
  1. Run chef-client command.
    The same process works well on Linux. But on Windows, it came back with below error messages:
PS C:\Chef> chef-client.bat
Starting Chef Client, version 14.1.12e[0m
Creating a new client identity for HOSTNAME using the validator key.e[0m
[2018-06-01T03:16:20+00:00] WARN: Failed to read the private key C:\chef\validation.pem: #<Errno::ENOENT: No such file or directory @ rb_sysopen - C:\chef\validation.pem>
[2018-06-01T03:16:20+00:00] WARN: Failed to read the private key C:\chef\validation.pem: #<Errno::ENOENT: No such file or directory @ rb_sysopen - C:\chef\validation.pem>

Apparently, the configuration parameter “validation_key” in client.rb didn’t work. chef-client is looking for the default validator key
I’ve tried to change the name of the validator key file name to validation.pem. the chef-client was then trying to look for chef server at localhost.
Tried it on multiple systems including one fresh built windows server 2016. same error. Must be some configuration I missed. Anyone can help?

2

This feels consistent with c:\chef\client.rb being encoded incorrectly. Can you check it’s an ANSI or UTF-8 formatted file, and not UTF-16 LE. You would get the latter if you used PowerShell’s default settings to pipe content into the file. I also see that your c:\chef folder is named c:\Chef - whilst I’m not aware of any issues with this, I would recommend keeping it lower case in case of any incompatible tooling further down the line.

Stuart.

3

Thanks Stuart. Turned out to be the encoding issue.