Chef is one of the most powerful open source tools for automated configuration management. Little known, however, is that Chef also supports Windows. Like Puppet, Chef [1] extends classic configuration scripts to include a context. Whereas Puppet works with tree configurations, those created using Chef take the form of cookbooks. These are scripts that describe the resources you want to create. The Chef run time processes the resources linearly and applies any changes that are not in place on the target system. This approach offers advantages compared with transactions implemented in Puppet, because the process is easier to understand: Graph theory is not necessary to understand the operation flow.

Getting Started with Chef

Chef offers Chef Solo, a standalone version of the system configurator, but I will not be using it in the following steps. Instead, I will be relying on a classic client/server configuration. For the remainder of this article, I use VMware Workstation as the basis; however, you could also use VirtualBox. Start by setting up an Ubuntu-based virtual machine (VM). The Chef server is only available on Unix-style operating systems; the download page [2] offers a choice between 64-bit versions for Red Hat Enterprise and Ubuntu. After downloading the 500MB DEB file, install it in the usual way from the Ubuntu Software Center and acknowledge any errors relating to the package quality.

To reconfigure the server, use the command:

sudo chef-server-ctl reconfigure

This procedure can take a few minutes. After completing the work, a message telling you Chef Client finished , or something of that ilk, then appears. Now you have to create the user and organization – they are essential for managing the configuration data:

sudo chef-server-ctl user-create admin tam hanna tamhan@tamoggemon.com <My password> -f admin.pem
sudo chef-server-ctl org-create tmgn "tamoggemon holding" --association_user admin -f orgValidator.pem

The Chef server is limited to distributing configuration data. The config files are actually created on the workstations (which can be co-hosted along with the server). Chef provides a default configuration that you can download with the following Git command:

git clone https://github.com/chef/chef-repo.git

Chef supports the ability to create configuration files through the Chef Development Kit. Download the respective DEB file and install it from the Software Center. Check for success with the command chef verify.

The server and workstation only communicate if they both use the same key. Copy the two PEM files into chef-repo downloaded from GitHub (/.chef subdirectory) and then open the /chef-repo/.chef/knife.rb file (Listing 1). Some commands for testing the connection between client and server follow. The current Chef (version 12) comes with more stringent certificate testing than its predecessor. It is evident here that the server name called in knife.rb doesn't match the output value from hostname, which was used to create the certificate. You can remedy this by changing the hostname – don't forget to reconfigure the server afterward using sudo <hostname> <IP address>. Now only the input from knife ssl fetch and knife-client list is missing. The second command returns the list of clients connected to the server – at the moment it's only the workstation.

current_dir = File.dirname(__FILE__)
log_level      :info
log_location   STDOUT
node_name      "admin"
client_key     "#{current_dir}/admin.pem"
validation_client_name "tmgn-validator"
validation_key         "#{current_dir}/orgValidator.pem"
chef_server_url        "https:/// organizations/tmgn"
cache_type     'BasicFile'
cache_options( :path => "#{ENV['HOME']} /.chef/checksums" )
cookbook_path  ["#{current_dir} /../cookbooks"]

Setting Up the Chef Client for Windows

On the client side, I decided to use Windows 8.1 and create another VM, which will – by and large – keep its plain vanilla state after the installation. Download the Chef client in the next step; it will run as of Windows 7.

Be sure also to install the Chef Client PowerShell Wrappers. Chef generates the files necessary on the client workstation after entering the knife command:

knife configure client ./
Creating client configuration
Writing client.rb
Writing validation.pem

Copy the client.rb and validation.pem to the C:\chef directory. Because Windows doesn't natively understand the SSL certificate generated by Ubuntu Server, you need to disable verification by editing client.rb:

log_level :info
log_location STDOUT
chef_server_url 'https://192.168.121.129/ organizations/tmgn'
validation_client_name 'tmgn-validator'
ssl_verify_mode :verify_none
node_name 'ChefSlave1'

Windows workstations have the unpleasant property of changing the hostname from time to time. The Chef server trips over this, because it uses the hostname to identify its clients. The property node_name lets you work around this problem in an elegant way.

Entering chef-client at the Windows command line familiarizes the client with its new working conditions. Successful registration of the client can be verified on the workstation by entering knife client list. The output shows your Windows machine under its hostname in the list.

Another tip: If you want to use Chef to manage large computer networks, you should automate the client deployment based on one of the methods featured in the Chef docs [3].

Automated Windows Configuration

As a first exercise, you want to provide your client with a recipe that influences the system configuration. Recipes and cookbooks are created using the knife tool configured on the workstation:

knife cookbook create adminbook

The recipes subfolder contains a file named default.rb. This is a blank recipe that serves as a template for your own configurations. Adapt this as shown in Listing 2.

# Cookbook Name::    adminbook
# Recipe::    default
#
# Copyright 2015,    YOUR_COMPANY_NAME
#
# All rights reserved - Do Not Redistribute
#
registry_key "HKLM\\Software\\MyApp\\MyConfig" do
    values [{
       :name => "NewRegistryKeyValue",
       :type => :dword,
       :data => 0,
    }]
    action :create
    recursive true
end
windows_service "BITS" do
    action :configure_startup
    startup_type :manual
end

Chef recipes consist of a sequence of resources, whose states are fully described. The file from Listing 2 declares a registry key and a Windows service. The key is generated, and the service launches after the script terminates. The knife administration tool is used to upload the newly created cookbook:

knife cookbook upload adminbook
export EDITOR=pico
knife node edit ChefSlave1

Entering node edit opens Pico. To enable the new cookbook, customize the run_list data structure as in Listing 3, then go to the client and run the chef-client command on it. This is quite a useful test, because the output from the process is sent directly to the command line.

{
    "name": "ChefSlave1",
    "chef_environment": "_default",
    "normal": {
      "tags": [
      ]
},
"run_list": [
            "recipe[adminbook]"
            ]

The first pass will fail because enabling a service requires administrative privileges. This can be solved by using an admin command line – further iterations of Chef will report that work has been done (Listing 4).

C:\Windows\system32>chef-client
Starting Chef Client, version 12.4.0
[2015-06-29T11:17:24-07:00] INFO: *** Chef 12.4.0 ***
[2015-06-29T11:17:24-07:00] INFO: Chef-client pid: 3160
Chef Client finished, 0/2 resources updated in 18.855305 seconds

Chef offers a few dozen resources, which you can extend using cookbooks. The resource overview provided in the Chef docs [4] offers a list of modules included out of the box and presents some practical examples and links to more information.