In order to work with Chef, you will need a way to interact with it. Fortunately, Chef provides a suite of command-line utilities, which we will discuss at length as the book progresses. There is one primary tool, knife, that allows an administrator to interact with the service in the command line. The knife tool is run from a workstation and provides many commands to view, search, and modify data maintained by the Chef service. Once you have installed and verified that all the services are running, we can move on to setting up knife.
Tip
You will see that the standard place to store your Chef configuration data is in $HOME/.chef (on a UNIX-like system.) This is not mandatory, and these files can be stored anywhere you like.
The knife tool communicates with the Chef server via HTTP and uses certificates for authentication between the workstation and the server. In order to get started with knife, we will need to do two things: gain access to the certificates that were generated during the installation of Chef and then use those credentials to set up a new user in the system.
In the following examples, we will be using the host that the Chef services were installed on as our workstation (where we will use knife). If you want to use a different host, you will need to get the required certificate (.pem) files to your local machine using scp or some other mechanism. By using the following commands, we can get the required authentication materials into our work directory:
Chef uses a signed header authentication for requests to the API, which means there must be a shared key that is present on both the client and the server. Chef-server will generate the chef-validator.pem file when it is configured. New nodes or clients use the chef-validator.pem file to sign the requests used to register themselves with the system.
Once you have these files copied into your Chef work directory, it is time to configure knife itself. Fortunately, knife has an interactive configuration mode that will walk you through the process of generating a configuration file. First, ensure that you are using your Chef gemset (if you are using RVM as we discussed earlier) and then run knife on your workstation (again, in this example, we are using our Chef service host for both purposes):
user@chef:~$ rvm use 1.9.3@chefuser@chef:~$ knife configure -i
When you run knife with the -i flag, you will be prompted by the following questions, which you can answer with the defaults for almost everything (non-default answers are in bold):
WARNING: No knife configuration file foundWhere should I put the config file? [/home/user/.chef/knife.rb] Please enter the chef server URL: [https://localhost:443] Please enter a name for the new user: [user] Please enter the existing admin name: [admin] Please enter the location of the existing admin's private key: [/etc/chef-server/admin.pem] ~/.chef/admin.pemPlease enter the validation clientname: [chef-validator] Please enter the location of the validation key: [/etc/chef-server/chef-validator.pem] ~/.chef/chef-validator.pemPlease enter the path to a chef repository (or leave blank): Creating initial API user...Please enter a password for the new user: Created user[user]Configuration file written to /home/user/.chef/knife.rbuser@chef:~$
As mentioned earlier, this does two things:
First, it uses the validation key and client name specified at the prompts to contact the API service and register a new client (user) with the service
Secondly, it generates a configuration file for knife that has the settings needed to connect to the service from now on
Since Chef and its components are written in Ruby, the resulting configuration file is a Ruby script, which contains some code that configures knife so that it knows what API server to connect to, which key files to use, what client name to use, and so on.
An inspection of the configuration file that was generated by the previous command will look like the following:
Because we are using the service host as our workstation, the Chef server URL points to the localhost. If your workstation were to be a different system such as your laptop, then this URL would be the IP or hostname of the host running the Chef service.
Ensuring that your knife configuration works
After setting up knife, we can use it to validate that it was configured correctly by querying the Chef server using some simple commands. The knife commands follow the format knife <command> <subcommand>, where command is either a client, configuration, cookbook, cookbook site, data bag, environment, exec, help, index, node, recipe, role, search, ssh, status, or tag. Subcommands will vary with the command, but they typically include things such as show, create, list, and delete (among others).
As there will initially be no nodes, cookbooks, recipes, roles, data bags, and such, we will query the list of clients that the server knows about. This should be a list of two clients: chef-webui (as it is a consumer of the API itself) and chef-validator (without it, it wouldn't be possible to register a new client).
The client command, with the list subcommand, prints a list of clients that the server knows about. At this point, running the command would look like this:
If you do not get the previous output, but get an error instead, you will need to go back and make sure that all the previous steps are completed and verified.
Once you know that it works, you can use knife to interact with the API. Unfortunately, we do not have much data in the system just yet, but we can use the show subcommand in conjunction with the client command and a client name to display more detailed information about a client:
user@chef:~$ knife client show chef-webuiadmin: truechef_type: clientjson_class: Chef::ApiClientname: chef-webuipublic_key: -----BEGIN PUBLIC KEY-----MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAos5cQ1NxP7zKf1zRM33gYeVyHNOO5NcICjSIvqQ5A37wwLfgtPLJQqboW7ZcNL3xYcKOlfYSEK7xha3ss8tTA+XMifaFp3JsdheyPeIJir2bc9iltUUcbpw9PJ2aQKTBlFNx23A7ag+zBfxcDjbY7RkdcziwB74ynd6e/K8c0JTRnA5NxoHkFc6v8a/itwujGwugWJXDQunWfCmAvjwsJgDOUu2aHOCVIVkc8it51Sc7Anx0YnCjNmdhz1xIo0MOVNOEmC9ypP0Z7mVv1C69WWBOEvS9zimjXo4rxBwFmWkPEIG6yPQjhuNmFd69K14vZQtAsH07AZFRSS7HLWnZWQIDAQAB-----END PUBLIC KEY-----validator: falseuser@chef:~$