Greetings! We released ChefDK 0.10.0 today and it can be obtained from our downloads page. This release includes the following new/updated dependencies:
- InSpec version 0.9.2
- Kitchen InSpec version 0.9.0
- Knife Windows 1.1.1
- Chef Provisioning 1.5.0
- Chef Provisioning AWS 1.6.0
You can view the full release notes on Github, but I have copied them into here for friendliness.
The primary means of interfacing with InSpec is through its command line tool
inspec. The most important thing to note about the integration with the ChefDK right now is that the
inspec tool is not added to your PATH by default when installing the ChefDK. To use it you can either:
- EDIT: Someone pointed out to me after we published this post that if you run `chef shell-init` you do not need to prepend the `inspec` executable with `chef exec`. Thanks Adam!
Prepend all your
chef exec. For example, following their guide you would run
chef exec inspec exec test.rbto run local Inspec tests.
- Add the executable to your PATH manually. On linux/OSX systems this is located at
/opt/chefdk/embedded/binand on Windows it is located at
This path change is temporary – we plan to include
inspec in the PATH by default in future ChefDK releases.
Kitchen-InSpec is a new Test Kitchen verifier that uses InSpec. This verifier is only compatible with Test Kitchen version 1.4 or greater, and will only work with other Test Kitchen plugins that also use Test Kitchen 1.4. Some examples of drivers which use Test Kitchen 1.4 are the Vagrant plugin and EC2 plugin.
Knife Windows 1.0 Enhancements
This release of the ChefDK ships with Knife-Windows 1.1.1 and marks the first v1 release to be bundled with ChefDK. Full details of features included in both 1.0.0 and 1.1.0 can be found in the release notes here:
For those who make use of Knife-Windows in your day to day Chef development workflow, here are the breaking changes and highlights:
Negotiateis the default authentication protocol. Prior to this release, the default authentication protocol depended on the format of the
basicauthentication protocol would be assumed unless that option had the format
domain\user. To revert to the behavior of previous releases or otherwise force knife-windows to use a specific authentication protocol such as
basic, use the
- Default WinRM port depends on the transport. The default port is still 5985 for non-ssl connections, but now defaults to 5986 if you’re using ssl.
- Kerberos Keytab short option is now
-Tto fix a conflict with the
Making it easier to setup WinRM over SSL
Setting up WinRM communication over SSL can be far from straight forward. Certificates need to be configured on both ends, firewall rules must be added and a WinRM listener has to be created. This Knife-Windows release adds some new
knife commands to help automate these tasks:
knife windows cert generategenerates a certificate and related public key file for use in configuring a WinRM listener and validating communication
knife windows cert installinstalls a certificate such as one generated by the
cert generatesubcommand into the Windows certificate store
knife windows listener createcreates a WinRM SSL listener on a Windows system
Validating WinRM Configuration
A new subcommand:
knife wsman test verifies winrm functionality on a remote system.
New Bootstrap Options
--hintcreates Ohai hints on bootstrap
--bootstrap-install-commandallows an alternate command to be used to install Chef Client
--install-as-servicewill have Chef Client be installed as a Windows service on bootstrap
--msi\_urlprovides an alternate URL to the Chef Client installation package
Look mom, no validator! Thats right – as seen in the core chef client first, this is now possible in
knife windows bootstrap as well.
Proxy support for WinRM
knife winrm and
knife bootstrap windows winrm subcommands now honor the proxy server configured via the
http_proxy setting in knife.rb for WinRM traffic.
chef generate commands now default to using Berksfile instead of Policyfile
In ChefDK 0.9.0, we changed the default behavior of
chef generate cookbook to create Policyfiles instead of Berksfiles. Our training materials and tutorials were not updated to account for this change, so we’ve changed the behavior back. You can still generate cookbooks with Policyfiles by passing the
-P option to
chef generate cookbook.
Additionally, you can generate a Chef repo with appropriate directories for Policyfiles by running
chef generate repo -P.