Chapter 10. Community and the Chef-Client Cookbook

In this chapter we’ll be talking about the Chef community and community cookbooks. The Chef community site provides access to great Chef resources, including cookbooks, knife plug-ins, and the ability to connect to amazing people who create wonderful things built on Chef.

Before we get started, make sure you are running Chef Server and the node you created in Chapter 9. We’ll be making heavy use of the knife command line tool in this chapter, and it requires a Chef Server setup to function.

Using Community Cookbooks

Although we’ve been writing all the cookbooks and recipes we’ve used so far in this book, so you can learn Chef coding, there is an easier way. There are hundreds of freely available prewritten Chef cookbooks to install and configure a variety of commonly used services and applications in production environments. For instance, there are cookbooks to help you set up Apache, Nginx, and IIS web servers and MySQL, PostgreSQL, Microsoft SQL Server, and Oracle databases. There are cookbooks to support the deployment of apps written in Java, Ruby, Python, PHP, node.js, and much, much more!

You can browse and download these community cookbooks from Chef Software’s Chef Supermarket community hub, and from a variety of other locations including GitHub. Some of these cookbooks were created and are maintained by Chef Software, but the majority are developed by Chef users. In general, as with any third-party software, you should always independently verify the behavior and flexibility of a community cookbook in an isolated environment before using it in production.

TIP

Always verify that the cookbook’s license is suitable for your organization!

WHAT IS A COMMUNITY COOKBOOK?

A community cookbook is a tarball (.tar.gz) package of the cookbook structure discussed Chapter 7. It is packaged in this manner for easy cross-platform distribution. At its core, a community cookbook is exactly the same as an internally authored cookbook.

The best place to find free community cookbooks is the Chef Supermarket. This site is a Ruby on Rails application hosted and maintained by Chef Software where you can share, contribute, download, use, rate, and review community cookbooks. Chef Supermarket is akin to rubygems.org, cpan.org, and other focused distribution sites. You can log in to Chef Supermarket using the same credentials as your Hosted Enterprise Chef account. Once you have logged in, you will be able to comment on and follow cookbooks of interest and contribute your own cookbooks to the community.

NOTE

You do not need to log in to the Chef Marketplace to download or use its community cookbooks.

The Chef Supermarket lets you search for cookbooks by name or description as shown in Figure 10-1.

Chef Supermarket will query cookbook names, descriptions, platforms, categories, and other metadata. You can even sort results by most downloaded or most followed. Take time exploring to find the best cookbooks for you.

If you do not find the cookbook you are looking for at Chef Supermarket, your next obvious bet is a good old-fashioned Internet search. Chef Supermarket is not the sole authority on cookbooks; GitHub also has good cookbooks, such as Fletcher Nichol’s rvm cookbook.

Figure 10-1. Search for free cookbooks on the Chef Supermarket site

Chef-Client Cookbook

One community cookbook you should be aware of is the chef-client cookbook. Go ahead and search for it now at Chef Supermarket. Figure 10-2 shows the search results you should get for chef-client.

Figure 10-2. Chef-client cookbook entry at Chef Supermarket

The arrows in Figure 10-2 point out the most important components on the page when a cookbook is displayed in the Chef Supermarket. Front and center (well, actually, a little to the left) is a rendered version of theREADME.md file. Well-written README files, like the one in the chef-client cookbook, tell you what problem the cookbook is trying to solve, plus how to use the cookbook.

On the right are two big buttons, View Source and Download Cookbook. The View Source button will take you to the cookbook source code. (Usually it’s some link on the GitHub source hosting service.) From there you can inspect the cookbook more closely. Finally there is the Download Cookbook button, which lets you download a tarball containing the cookbook source.

The chef-client cookbook is a popular cookbook because it makes two things easy:

1. Configuring chef-client to run as a service or a cron job
2. Deleting the validation.pem file

Because one of the design goals for Chef Server is scalability, the server tries to offload as much processing as it can onto the nodes. So by default, the node is responsible for scheduling and initiating a chef-client run and performing all the related processing, not Chef Server. Chef Server itself is really just a dumb artifact repository for cookbooks and other associated metadata about your infrastructure.

When you bootstrap a node with knife in order to install chef-client, as we did in Bootstrap the Node with Knife, the bootstrap process does not configure chef-client to download any cookbook updates or perform Chef runs at regular intervals. You’ll definitely want to configure all your nodes to do this on a regular basis, say, every 15 to 30 minutes. The chef-client cookbook makes it easy to configure chef-client to run as a service or a cron job.

Also, it’s important to delete the validation.pem file after the first Chef run. With Enterprise Chef, this file is called <organization-validator>.pem by default. With Open Source Chef Server, the file is called validation.pemby default. To explain why deleting the validation.pem file is important, we need to provide a quick explanation of how requests by nodes are verified by Chef Server.

Chef Server requires that every request chef-client makes to the server be authenticated using a clientpublic/private key pair. Every node has its own special public/private key pair. You have already seen this because users have their own special public/private key pair as well—you needed to download the <username.pem> file to configure knife to make requests against Chef Server. The <username>.pem file you downloaded contains the private portion of the key pair. The public portion of this key is stored on Chef Server, and the key is used to authenticate you as a valid Chef Server user.

Similarly, there is a .pem for each node that runs chef-client containing a private key. We’ll call this client.pem for the sake of discussion. Figure 10-3 presents an overview of how this key is used to verify that requests come from a node. In this example, Node A has a private key, which is a unique client.pem file that lives on the node. When the client.pem file was created, an associated public key was generated and stored on the Chef server. Node A signs all HTTP requests it makes to Chef Server with its private key. When Chef Server receives a request, it verifies that the signature is from Node A by using Node A’s public key to ensure it is a legitimate request from Node A.

Figure 10-3. How Chef Server verifies a request from a node

When you run chef-client for the first time, there is a problem—you don’t have a client.pem file for your node yet, and a corresponding public key for the node does not exist on the Chef server. To solve this bootstrapping issue, a node uses a company-wide, well-known key when it generates the request to register the node as a client. That’s what the validation.pem key is for. The validation.pem is an organization-wide private key used specifically to sign the request to register a new node with Chef Server on the first chef-client run.

Chef Server performs a validation of a signature using the validator.pem similar to the one it performs with the client.pem. During the bootstrap process, the validator.pem is created with the name /etc/chef/validation.pem on the node.

Although the /etc/chef/validation.pem is secured with root privileges, it’s a good idea to delete it once the node has a proper client key to run chef-client. Anyone who obtains the /etc/chef/validation.pem file can create new nodes. Once the node has a client key, it no longer needs the /etc/chef/validation.pem. It’s a good idea to leave the /etc/chef/validation.pem key on the node only during the time it actually needs to create a client public/private key pair for itself and send its client public key to Chef Server.

You can verify that the validation.pem file is still present on the node you bootstrapped in Chapter 9. Make sure the chef-repo/cookbooks/node directory is the current working directory by running one of the following commands. If the parent of your chef-repo tree is not $HOME, change the command to reflect the correct parent.

Linux/Mac OS X:

$ cd $HOME/chef-repo/cookbooks/node

Windows Command Prompt:

> cd %USERPROFILE%\chef-repo\cookbooks\node

Windows PowerShell:

> cd $HOME\chef-repo\cookbooks\node

Use kitchen login to ssh into the node, as follows. Check the contents of the directory with /etc/chef/validation.pem. Note that it is still there. Then make sure you exit back out to your host prompt:

$ kitchen login
Last login: Thu Aug 14 20:14:59 2014 from 192.168.33.1
Welcome to your Packer-built virtual machine.
[vagrant@default-centos65 ~]$ ls /etc/chef
client.pem  client.rb  first-boot.json  validation.pem
[vagrant@default-centos65 ~]$ exit
logout
Connection to 127.0.0.1 closed.

We’ll talk more about the use of the chef-client recipe later, in Chef-Client Recipes. First, we need to talk about the knife cookbook site plugin.

Knife Cookbook Site Plugin

While the Chef Supermarket’s Download Cookbook link is very helpful, you still need to upload the cookbook source to your Chef Server in order to use it in production. Also, although a website is great for discovery, you’ll find yourself wanting to use a command-line tool for day-to-day community cookbook management because it is faster. All recent versions of both the Chef Client and the Chef Development Kit ship with a cookbook site plugin for knife designed to enable command-line interaction with the Chef Supermarket.

Let’s walk you through the most commonly use subcommands now. Feel free to type them in if you like. Make sure your current working directory is the chef-repo from Chapter 9. Assuming that the chef-repo is located in your home directory, run one of the following commands, depending on your platform. Change the root path to suit where you created chef-repo.

Linux/Mac OS X:

$ cd $HOME/chef-repo

Windows Command Prompt:

> cd %USERPROFILE%\chef-repo

Windows PowerShell:

> cd $HOME\chef-repo

Search for Community Cookbooks Using Knife Cookbook Site

You can use the knife cookbook site search command to search the Chef Supermarket for cookbooks. You will need to specify a search string as a parameter. knife cookbook site will search the following fields in the cookbook metadata at Chef Supermarket:

• name
• URL
• description
• maintainer

The knife cookbook site plugin will perform simple substring matching using your search string. Try it now with a chef-client query:

$ knife cookbook site search chef-client
chef:
  cookbook:             http://cookbooks.opscode.com/api/v1/cookbooks/chef
  cookbook_description: Installs and configures Chef for chef-client and
  chef-server
  cookbook_maintainer:  chef
  cookbook_name:        chef
chef-client:
  cookbook:             http://cookbooks.opscode.com/api/v1/cookbooks/
  chef-client
  cookbook_description: Manages client.rb configuration and chef-client service
  cookbook_maintainer:  chef
  cookbook_name:        chef-client
...

There’s also a related knife cookbook site show command to display more detailed information about a cookbook, when you can provide a cookbook name. Try it now for the chef-client cookbook:

$ knife cookbook site show chef-client
average_rating:
category:       Other
created_at:     2010-12-16T23:00:45.000Z
deprecated:     false
description:    Manages client.rb configuration and chef-client service
external_url:   http://github.com/opscode-cookbooks/chef-client
latest_version: http://cookbooks.opscode.com/api/v1/cookbooks/chef-client
                /versions/3.7.0
maintainer:     chef
...
name:           chef-client
updated_at:     2014-08-13T17:18:54.109Z
...

Manage Chef Supermarket Cookbooks on Your Chef Server Using Knife Cookbook Site

Although the search/show capabilities of knife cookbook site are helpful, you’ll use this plugin most often to download cookbooks from Chef Supermarket and upload community cookbooks to your local Chef Server. In order to download a cookbook from Chef Supermarket and upload it to your Chef Server, you must perform three steps:

1. Download the cookbook using knife cookbook site download.
2. Extract the cookbook package with tar.
3. Upload the cookbook using knife cookbook upload.
4. Repeat steps 1-3 for any cookbook dependencies.

Let’s go through this process now for the chef-client cookbook. Download the chef-client with knife cookbook site download as follows:

$ knife cookbook site download chef-client 3.7.0
Downloading chef-client from the cookbooks site at version 3.7.0 to
/Users/misheska/learningchef/chef-repo/chef-client-3.7.0.tar.gz
Cookbook saved: /Users/misheska/learningchef/chef-repo/chef-client-3.7.0.tar.gz

NOTE

I’ve specified the version in all these commands because cookbooks change frequently, even though you don’t have to specify a version to get the very latest cookbook.

The downloaded cookbook package is a .tar.gz file (a gzip-compressed .tar file). You’ll need to extract it with the tar command. Use the -C option to make sure the cookbook is extracted as chef-repo/cookbooks/chef-client. You’ll want to store all downloaded cookbooks in chef-repo/cookbooks. Use the tar command to extract the archive.

Linux/Mac OS X:

$ tar xvf chef-client*.tar.gz -C cookbooks/
x chef-client/README.md
x chef-client/CHANGELOG.md
x chef-client/metadata.json
x chef-client/metadata.rb
x chef-client/attributes/default.rb
x chef-client/files/default
x chef-client/files/default/tests
...

Windows:

$ bash tar xvf .\chef-client-3.7.0.tar.gz -C cookbooks
x chef-client/README.md
x chef-client/CHANGELOG.md
x chef-client/metadata.json
x chef-client/metadata.rb
x chef-client/attributes/default.rb
x chef-client/files/default
x chef-client/files/default/tests
...

NOTE

The tar program provided with Chef on Windows does not correctly expand filenames that include wildcards, such as chef-client*.tar.gz. On Windows, the easiest workaround is to provide the full file name. Thankfully, all the Windows shell programs support tab-completion. So you need only type in the first few letters of chef-client-3.7.0.tar.gz, then hit the Tab key and the shell should expand to use the full filename.

Unfortunately, if you try to upload the chef-client cookbook to your Chef Server right now, you’ll get an error that resembles the following:

$ knife cookbook upload chef-client —cookbook-path cookbooks
Uploading chef-client  [3.7.0]
ERROR: Cookbook chef-client depends on cookbooks which are not currently
ERROR: being uploaded and cannot be found on the server.
ERROR: The missing cookbook(s) are: 'cron' version '>= 1.2.0', 'logrotate'
version '>= 1.2.0'

If you recall when we introduced include_recipe in Include_Recipe cookbooks can contain a chain of references to other cookbooks. These references are called dependencies, and are noted in the metadata.rb of a cookbook using the depends statement. If you take a look at the metadata.rb file for the chef-clientcookbook, you’ll see that it resembles the following:

name              'chef-client'
maintainer        'Opscode, Inc.'
maintainer_email  'cookbooks@opscode.com'
license           'Apache 2.0'
description       'Manages client.rb configuration and chef-client service'
long_description  IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version           '3.7.0'
...
depends 'cron', '>= 1.2.0'
depends 'logrotate', '>= 1.2.0'

There are depends statements at the bottom of the metadata.rb file that state chef-client is dependent on thecron and logrotate cookbooks. Exactly the two cookbooks mentioned in the error message! This is where you will need to repeat the knife cookbook site > un-tar > knife cookbook upload cycle for any cookbook dependencies.

So, download these two additional cookbooks with the knife cookbook site command, like so:

$ knife cookbook site download cron 1.4.0
$ knife cookbook site download logrotate 1.6.0

Extract them to chef-repo/cookbooks/ using the tar command, like you did for the chef-client cookbook.

Linux/Mac OS X:

$ tar xvf cron*.tar.gz -C cookbooks/
$ tar xvf logrotate*.tar.gz -C cookbooks/

Windows:

$ tar xvf cron-1.4.0.tar.gz -C cookbooks
$ tar xvf logrotate-1.6.0.tar.gz -C cookbooks

Finally, upload all the cookbooks, cron, logrotate, and chef-client, using knife cookbook upload, taking care to upload chef-client after its dependencies:

$ knife cookbook upload cron --cookbook-path cookbooks
Uploading cron         [1.4.0]
Uploaded 1 cookbook.
$ knife cookbook upload logrotate --cookbook-path cookbooks
Uploading logrotate      [1.6.0]
Uploaded 1 cookbook.
$ knife cookbook upload chef-client --cookbook-path cookbooks
Uploading chef-client    [3.7.0]
Uploaded 1 cookbook.

Chef-Client Recipes

Now let’s perform a Chef run adding two recipes to the run-list we touched on in Chef-Client Cookbook:

1. chef-client::default recipe—Configures chef-client to run as a service
2. chef-client::delete_validation recipe—Deletes the /etc/chef/validation.pem file

Use knife node run_list add to add the chef-client::delete_validation recipe to the node’s run list. For all knife command lines, recipes are referenced in a run list in the form "recipe[<cookbook>::<recipe>]"; for example, "recipe[chef-client::delete_validation]".

Run the following knife node run_list add command to add "recipe[chef-client::delete_validation]" to the node-centos65.vagrantup.com node’s run list that we bootstrapped in Chapter 9:

$ knife node run_list add node-centos65.vagrantup.com \
"recipe[chef-client::delete_validation]"
node-centos65.vagrantup.com:
  run_list: recipe[chef-client::delete_validation]

NOTE

If you need a reminder of what the node name is, run the following command:

$ knife node list
node-centos65.vagrantup.com

Also add the chef-client::default recipe to the run list. Note that you can use a shorthand notation using just the cookbook name, when you want to use the default recipe. Run the following command now:

$ knife node run_list add node-centos65.vagrantup.com "recipe[chef-client]"
node-centos65.vagrantup.com:
  run_list:
    recipe[chef-client::delete_validation]
    recipe[chef-client]

Both the chef-client::delete_validation and chef-client::default recipes have been added to the node’s run list, and will be processed in the order provided.

NOTE

You can add more than one recipe at a time to a run list—just separate the recipe names with commas:

$ knife node run_list add <node> \
"recipe[<cookbook>::<recipe>],recipe[<cookbook>::<recipe>]"

Make sure the chef-repo/cookbooks/node directory is the current working directory, by running one of the following commands. If the parent of your chef-repo tree is not $HOME, change the command to reflect the correct parent.

Linux/Mac OS X:

$ cd $HOME/chef-repo/cookbooks/node

Windows Command Prompt:

> cd %USERPROFILE%\chef-repo\cookbooks\node

Windows PowerShell:

> cd $HOME\chef-repo\cookbooks\node

Perform an initial chef-client run by using kitchen login to ssh into the node, and then run sudo chef-client as follows:

$ kitchen login
Last login: Sat Jul 26 01:17:10 2014 from 192.168.33.1
Welcome to your Packer-built virtual machine.
[vagrant@node-centos65 ~]$ sudo chef-client
...
  * service[chef-client] action enable
    - enable service service[chef-client]

  * service[chef-client] action start
    - start service service[chef-client]

  * service[chef-client] action restart
    - restart service service[chef-client]


Running handlers:
Running handlers complete

Chef Client finished, 10/11 resources updated in 8.137774709 seconds

While you are still on the node, verify that the validation.pem was deleted and that the chef-client is now running as a daemon:

[vagrant@node-centos65 ~]$ ls /etc/chef
client.pem  client.rb  first-boot.json
[vagrant@node-centos65 ~]$ ps awux | grep chef-client
root      2184  0.0  7.9 217180 40152 ?        Sl   21:52
0:00 /opt/chef/embedded/bin/ruby /usr/bin/chef-client -d -c
/etc/chef/client.rb -L /var/log/chef/client.log -P /var/run/chef/client.pid
-i 1800 -s 300

Return back to the host prompt now:

[vagrant@node-centos65 ~]$ exit

Configure Knife to Use a Production SSL Setup

In Chapter 6, we mentioned the SSL warning you get running chef-client on the node when HTTPS connections are not validated. Before we end this chapter, let’s go over how you would configure SSL in a production environment.

On the node, SSL verification is controlled through settings in the file /etc/chef/client.rb, the file that configures chef-client. You can enable this setting by setting attributes in the chef-client cookbook. Nearly everything in the chef-client cookbook is controllable through attributes.

COOKBOOKS SHOULD CHANGE BEHAVIOR BASED ON ATTRIBUTES

Well-written cookbooks change behavior based on attributes. Ideally, you shouldn’t have to modify the contents of a cookbook to accommodate your needs.

Look at the attributes directory for things you can override to change the behavior of a cookbook. Well-written cookbook also have sane defaults, and a README.md file to describe how the attributes influence cookbook behavior.

SSL setups can be quite complex to set up. So it is recommended that you first validate the setup with knife on your development workstation, before trying to configure your nodes to use verified SSL connections. Let’s do that now. We’ll use a simple setup that makes use of the self-signed certificate that was generated when you installed Chef Server in Chapter 9.

You will need to make sure that Chef Server is configured to use a certificate you intend to be used to verify communication over HTTPS. By default, Chef Server automatically generates a self-signed certificate during the installation. If you want to use the self-signed certificate, everything is already set up for you. In this exercise, we’ll use the self-signed certificate.

NOTE

Refer to the Chef documentation for more information on how to configure ChefServer with a certificate authority-verified certificate.

Also, a Chef community member, Mislav Marohnić, wrote an excellent blog post on troubleshooting Chef Server SSL issues and published a set of scripts to help troubleshoot connection issues.

Once the certificate is configured on Chef Server, run knife ssl check on your development workstation to find out what you need to do next. You should see output similar to the following:

$ knife ssl check
Connecting to host 192.168.33.34:443
ERROR: The SSL certificate of 192.168.33.34 could not be verified
Certificate issuer data: /C=US/ST=WA/L=Seattle/O=YouCorp/OU=Operations/CN
=default-centos65.vagrantup.com/emailAddress=you@example.com

Configuration Info:

OpenSSL Configuration:
* Version: OpenSSL 1.0.1h 5 Jun 2014
* Certificate file: /opt/chefdk/embedded/ssl/cert.pem
* Certificate directory: /opt/chefdk/embedded/ssl/certs
Chef SSL Configuration:
* ssl_ca_path: nil
* ssl_ca_file: nil
* trusted_certs_dir:
"/Users/misheska/learningchef/chef-repo/.chef/trusted_certs"

TO FIX THIS ERROR:

If the server you are connecting to uses a self-signed certificate, you must
configure chef to trust that server's certificate.

By default, the certificate is stored in the following location on the host
where your chef-server runs:

  /var/opt/chef-server/nginx/ca/SERVER_HOSTNAME.crt

Copy that file to your trusted_certs_dir (currently:
/Users/misheska/learningchef/chef-repo/.chef/trusted_certs)
using SSH/SCP or some other secure method, then re-run this command to confirm
that the server's certificate is now trusted.

The knife ssl check command says that you need to copy the certificate to your trusted_certs_dir. Run the command knife ssl fetch to automatically download the certificate and place it in your trusted_certs_dir:

$ knife ssl fetch
WARNING: Certificates from 192.168.33.34 will be fetched and placed in your
trusted_cert directory
(/Users/misheska/learningchef/chef-repo/.chef/trusted_certs).

Knife has no means to verify these are the correct certificates. You should
verify the authenticity of these certificates after downloading.

Adding certificate for default-centos65.vagrantup.com in /Users/misheska
/learningchef/chef-repo/.chef/trusted_certs/default-centos65_vagrantup_com.crt

Run knife ssl check one final time, and it should verify successfully. If not, double-check to make sure the local hosts entry is correct, and that the hostname matched the expected name/IP when you ran knife ssl check in the previous step:

$ knife ssl check
Connecting to host default-centos65.vagrantup.com:443
Successfully verified certificates from `default-centos65.vagrantup.com'

Configure Chef-Client to Use a Production SSL Setup

The chef-client cookbook includes a recipe chef-client::config, which can be used to automatically generate the /etc/chef/client.rb config file with the SSL settings we need. In this way you can automate the configuration of SSL on your nodes.

Log in to the node and check the /etc/chef/client.rb file. The client.rb file was created to configure chef-clientsettings when you ran knife bootstrap on the node. Notice that it resembles the following. Make sure you log back out to the exist prompt when you are done.

$ kitchen login
Last login: Sat Aug 16 09:06:12 2014 from 10.0.2.2
Welcome to your Packer-built virtual machine.
[vagrant@node-centos65 ~]$ cat /etc/chef/client.rb
log_location     STDOUT
chef_server_url
"https://default-centos65.vagrantup.com/organizations/learningchef"
validation_client_name "learningchef-validator"
# Using default node name (fqdn)

[vagrant@node-centos65 ~]$ exit
logout
Connection to 127.0.0.1 closed.

In order to enable verification of the SSL certificate on the server, we need to add the following setting to /etc/chef/client.rb (the default setting is :verify_none):

ssl_verify_mode :verify_peer

To enable this setting and have the chef-client::config recipe generate the appropriate configuration setting, we need to set the following attribute:

node.default['chef_client']['config']['ssl_verify_mode'] = ':verify_peer'

We’ll do this by using Chef Server’s management site. Once you log in, click on the Nodes tab, then click on the Edit link for node-centos65.vagrantup.com as shown in Figure 10-4.

Figure 10-4. Node actions

The node editing page will be displayed. We’ll be using the node attributes portion of the page at the bottom, as shown in Figure 10-5.

Click on the source tab for attributes. Enter in the text as shown in Figure 10-6. This is the attribute setting node.default['chef_client']['config']['ssl_verify_mode'] = ':verify_peer' in JSON format. If you are reading this book in electronic format, feel free to copy and paste the following text into the json edit box:

{
  "chef_client": {
    "config": {
      "ssl_verify_mode": ":verify_peer"
    }
  }
}

Once you are done typing in the attribute value, click on the Load JSON from Source icon in the editing pane as shown in Figure 10-7. This will update the attribute setting in the json tree on the left. Then click on the Save Node button. If there is no syntax error, you should see this message: The node was updated successfully.

Figure 10-5. Edit node attributes web tool

NOTE

You can also edit node attributes on the command line with the knife node edit command.

Figure 10-6. Set node.default['chef_client']['config'][’ssl_verify_mode'] = ':verify_peer’

On the command line, verify that the attribute was set back in your chef-repo directory. Use the knife node show --attribute command to display the chef_client.ssl_verify_mode attribute for the node, as follows:

$ knife node list
node-centos65.vagrantup.com
$ knife node show --attribute "chef_client.config.ssl_verify_mode" \
node-centos65.vagrantup.com
node-centos65.vagrantup.com:
  chef_client.config.ssl_verify_mode: :verify_peer

If the output does not match exactly, make sure that you remembered to click on the Save Node button. It is easy to forget because it’s at the bottom of the page outside the editing window. Also make sure that you remembered to click on the Load JSON from Source button, and make sure the json tree rendered on the left matches the figure exactly.

Because we are using a self-signed certificate, we need to set one more attribute setting. We need to tell the SSL library on the node that we trust the self-signed server certificate. In production, you’d do this by writing a recipe that adds the custom certificate to the certificate store. If you are using OpenSSL on your node, you will need to copy the certificate to the SSL_CERT_DIR, the directory where trusted certificates are stored, and run c_rehashto register the self-signed certificate.

Figure 10-7. Click on the icon to update the attribute setting in the json tree, then click on Save Node

In our test setup, we simulate this with the synchronized folder we set up for the node that we configured in Chapter 9. The synchronized folder makes the certificate we have in chef-repo/.chef/trusted_certs locally on our host available on the node. This directory was set up when you ran knife ssl fetch.

Go back to the Chef Server web interface, and add the ssl_ca_file attribute to the node. Copy and paste the following JSON source:

{
  "chef_client": {
    "config": {
      "ssl_verify_mode": ":verify_peer",
      "ssl_ca_file":
      "/chef-repo/.chef/trusted_certs/default-centos65_vagrantup_com.crt"
    }
  }
}

Double-check to make sure the settings for chef_client.config.ssl_verify_mode and chef_client.config.ssl_ca_file are correct by checking them with knife node show --attributeas follows. Make sure these settings match exactly, and the /chef-repo/.chef/trusted_certs/default-centos65_vagrantup_com.crt is synced to your node before going further:

$ knife node show --attribute "chef_client.config.ssl_verify_mode" \
node-centos65.vagrantup.com
node-centos65.vagrantup.com:
  chef_client.config.ssl_verify_mode: :verify_peer
$ knife node show --attribute "chef_client.config.ssl_ca_file" \
node-centos65.vagrantup.com
node-centos65.vagrantup.com:
  chef_client.config.ssl_ca_file: /chef-repo/.chef/trusted_certs/
  default-centos65_vagrantup_com.crt
$ kitchen login
Last login: Sat Aug 16 10:29:58 2014 from 10.0.2.2
Welcome to your Packer-built virtual machine.
[vagrant@node-centos65 ~]$ ls /chef-repo/.chef/trusted_certs
default-centos65_vagrantup_com.crt
[vagrant@node-centos65 ~]$ exit
logout
Connection to 127.0.0.1 closed.

Once you have verified all the settings are correct, add the chef-client::config recipe to your node’s run list:

$ knife node run_list add node-centos65.vagrantup.com \
"recipe[chef-client::config]"
node-centos65.vagrantup.com:
  run_list:
    recipe[chef-client::delete_validation]
    recipe[chef-client]
    recipe[chef-client::config]

Then log in to the node and perform a Chef run. Because you added the chef-client::config recipe to your run list, Chef will make sure that the /etc/chef/client.rb matches the settings corresponding to the attributes you set on the node. You’ll get the SSL warning one more time as chef-client hasn’t yet applied your SSL verification settings:

$ kitchen login node-centos65
$ sudo chef-client
[2014-08-16T10:45:52-07:00] WARN:
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SSL validation of HTTPS requests is disabled. HTTPS connections are still
encrypted, but chef is not able to detect forged replies or man in the middle
attacks.
...
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Starting Chef Client, version 11.14.2
resolving cookbooks for run list: ["chef-client::delete_validation",
"chef-client", "chef-client::config"]
Synchronizing Cookbooks:
  - cron
  - chef-client
  - logrotate
Compiling Cookbooks...
...
Converging 17 resources
Recipe: chef-client::delete_validation
  * file[/etc/chef/validation.pem] action delete (up to date)
Recipe: chef-client::init_service
  * directory[/var/run/chef] action create (up to date)
  * directory[/var/cache/chef] action create (up to date)
  * directory[/var/lib/chef] action create (up to date)
  * directory[/var/log/chef] action create (up to date)
  * directory[/etc/chef] action create (up to date)
  * template[/etc/init.d/chef-client] action create (up to date)
  * template[/etc/sysconfig/chef-client] action create (up to date)
  * service[chef-client] action enable (up to date)
  * service[chef-client] action start (up to date)
Recipe: chef-client::config
  * directory[/var/run/chef] action create (up to date)
  * directory[/var/cache/chef] action create (up to date)
  * directory[/var/lib/chef] action create (up to date)
  * directory[/var/log/chef] action create (up to date)
  * directory[/etc/chef] action create (up to date)
  * template[/etc/chef/client.rb] action create
    - update content in file /etc/chef/client.rb from 6d6918 to 934e27
    --- /etc/chef/client.rb    2014-08-16 10:45:47.725998848 -0700
    +++ /tmp/chef-rendered-template20140816-5689-wqon53 2014-08-16 10:45:54
    .766997307 -0700
    @@ -1,5 +1,7 @@
     chef_server_url "https://default-centos65.vagrantup.com/organizations
     /learningchef"
     validation_client_name "learningchef-validator"
    +ssl_verify_mode :verify_peer
    +ssl_ca_file "/chef-repo/.chef/trusted_certs/
    default-centos65_vagrantup_com.crt"
     # Using default node name (fqdn)


  * ruby_block[reload_client_config] action create
    - execute the ruby block reload_client_config
  * directory[/etc/chef/client.d] action create (up to date)
  * ruby_block[reload_client_config] action nothing (skipped due to action :nothing)

Running handlers:
Running handlers complete
Chef Client finished, 2/18 resources updated in 2.654285226 seconds

Now, if you run chef-client one more time, finally there is no more SSL warning:

$ sudo chef-client
Starting Chef Client, version 11.14.2
resolving cookbooks for run list: ["chef-client::delete_validation",
"chef-client", "chef-client::config"]
Synchronizing Cookbooks:
  - cron
  - logrotate
  - chef-client
Compiling Cookbooks...
...
Converging 17 resources
Recipe: chef-client::delete_validation
  * file[/etc/chef/validation.pem] action delete (up to date)
Recipe: chef-client::init_service
  * directory[/var/run/chef] action create (up to date)
  * directory[/var/cache/chef] action create (up to date)
  * directory[/var/lib/chef] action create (up to date)
  * directory[/var/log/chef] action create (up to date)
  * directory[/etc/chef] action create (up to date)
  * template[/etc/init.d/chef-client] action create (up to date)
  * template[/etc/sysconfig/chef-client] action create (up to date)
  * service[chef-client] action enable (up to date)
  * service[chef-client] action start (up to date)
Recipe: chef-client::config
  * directory[/var/run/chef] action create (up to date)
  * directory[/var/cache/chef] action create (up to date)
  * directory[/var/lib/chef] action create (up to date)
  * directory[/var/log/chef] action create (up to date)
  * directory[/etc/chef] action create (up to date)
  * template[/etc/chef/client.rb] action create (up to date)
  * directory[/etc/chef/client.d] action create (up to date)
  * ruby_block[reload_client_config] action nothing (skipped due to
  action :nothing)

Running handlers:
Running handlers complete
Chef Client finished, 0/17 resources updated in 2.72449843 seconds

Go ahead and exit back out to the host prompt now:

[vagrant@node-centos65 ~]$ exit
logout
Connection to 127.0.0.1 closed.

Your tour of the chef-client cookbook is now complete. We are now done with both our Chef Server and node. Go ahead and kitchen destroy both of them.

Linux/Mac OS X:

$ cd $HOME/chef-repo/cookbooks/enterprise-chef
$ kitchen destroy
$ cd $HOME/chef-repo/cookbooks/node
$ kitchen destroy

Windows Command Prompt:

> cd %USERPROFILE%\chef-repo\cookbooks\enterprise-chef
> kitchen destroy
> cd %USERPROFILE%\chef-repo\cookbooks\node
> kitchen destroy

Windows PowerShell:

> cd $HOME\chef-repo\cookbooks\enterprise-chef
> kitchen destroy
> cd $HOME\chef-repo\cookbooks\node
> kitchen destroy

NOTE

Don’t forget to remove the entries for default-centos65.vagrantup.com and node-centos65.vagrantup.com from /etc/hosts on Linux/Mac OS X or %WINDIR%\system32\drivers\etc\hostson Windows.

Summary

In this chapter we showed you the Chef Supermarket, which is the hub of the Chef community. We showed you how you can download cookbooks from the Chef Supermarket using both the web interface and the command line.

We recommend using the knife command line tool, because it makes it easy to not only download a community cookbook, but to upload and manage a cookbook on your Chef server so you can use it in your organization.

We presented an overview of the chef-client cookbook and how it is useful for configuring a node after it has been bootstrapped with chef-client.

In the next chapter, we’ll introduce you to Chef Zero, a small, fast-start, in-memory version of Chef Server, great for local testing.