Chef Tutorials – Part 3 – Configuring A Chef Infrastructure Node

Introduction

This tutorial is part three (Part One, Part Two) of a multi-part series detailing the basic use of Chef Infrastructure. I am making this series to help cement my knowledge of the Chef ecosystem, and provide the knowledge I am earning to other people without too many layers of abstraction. Below is an annotated command list which describes the process I used to automagically join nodes to the chef infrastructure server. Note, what is not described is how I used Proxmox to generate the virtual machines which make up the server and clients. At some point I may create a post about my Proxmox environment. If you are interested in such an article, please do let me know.

Assumptions

  1. Ubuntu 20.04 Server with static IP Assignment and DNS preconfigured.
  2. 2 GB of Ram allocated to the server.
  3. 1 Dedicated Cores allocated to the server.
  4. 25 GB of storage space allocated to the server.
  5. SSH enabled on the server.

Step 1 – Download the installation package

We first need to have a chef-client in order to have the node communicate with the chef infrastructure server. As in my previous posts, I recommend using ssh to connect to the node prior to installing the package, instead of remoting in as a desktop environment. Below is the command I use to get the installation media for the chef-client on my endpoint nodes:

wget https://packages.chef.io/files/stable/chef/16.6.14/ubuntu/20.04/chef_16.6.14-1_amd64.deb

Your link may be different than mine. To generate a new link, go to the chef website, right click on the download button, and copy the resultant url. Then, paste the url into your wget command.

Step 2 – Install the Chef Client package

Next, we need to install the chef-client onto our node machine. From the same directory used to download the installation media, run the following command:

$ sudo apt update -y && sudo apt upgrade -y
$ sudo apt install ./chef_16.6.14-1_arm64.deb -y

Running those two commands will update the linux installation in this machine, and then install the chef-client package. To verify that everything went correctly, run the command below:

chef-client -v

If the installation was successful, the following contents should be displayed (or something very similar):

Chef Infra Client: 16.6.14

Step 3 – Creating the Chef Client Environment

In order for the chef client to be able to communicate to the Chef Infra server, a few files will be needed. First, create the client.rb file in /etc/chef. This file is an instructions set which tells the chef-client how to connect to the infrastructure server. Below are the contents of a sample client.rb file (The same one I used to set up my nodes:

chef_server_url         "https://chef-server.brooksnet.lan/organizations/brooksnet"
validation_client_name  "brooksnet-validator"
validation_key          "/etc/chef/brooksnet-validator.pem"
chef_license            "accept"
log_location            "STDOUT"
trusted_certs_dir       "/etc/chef/trusted_certs"
file_cache_path         "/etc/chef/.chef/cache"
file_backup_path        "/etc/chef/.chef/backup"

The first line is fairly self explanatory. This is the path the chef-client will use to find the chef infra server. Line two is a bit more complicated. This is the validation client name. The validation client is a node-like object in the chef infra server which is used to join new nodes to the server. In allegory, the validation client is a gate keeper for the chef infrastructure server. Tell the gate keeper the secret password, and he will open the gate and give you access to the infrastructure server. Line 3 is the validation key. This key is the public key authentication method which allows the chef-client on the joining node to communicate with the validation node already existing on the chef infrastructure server. This is the secret password for the gate keeper. The password is usually not swordfish.

The chef_license line simply automates the prompted question confirming that this chef-client instance will be used in accordance with the chef user agreement. The log_location line references where all log files will be stored. By default, this is set to STDOUT, but can be changed to a specific location. Trusted_certs_dir is the location where the chef web-server certificates are stored for ssl connections. The file_cache and file_backup lines are simply a location for maintaining a record of all files modified by chef, in case something goes sideways during operation of the chef-client.

Step 3.5 – Generating the Validation Key

In order to access the Validation key, we need to download it to our local computer and then scp it to our client device. First, we need to log into the chef infrastructure web service. Then, we will move over to the administration tab. From there, we will select our Organization (in my case Brooksnet), and then select the Reset Validation Key button.

After clicking the Reset Validation Key button, the following warning will be displayed:

This is an important warning to appreciate. If this is not the first time that a validation key has been requested, any existing client joining configurations will be rendered inoperable, because their validation certification will be out of date. For that reason, it is crucial to maintain the validation key in a safe, secure, and at least semi-permanent location.

After clicking the Reset Key button, a file explorer prompt will open, allowing for the key to be downloaded locally. Having done so, use the scp command to upload the validation key to the chef-client system. Below is a sample scp command:

$ scp validation.pem administrator@chef-client:~

Once the validation certificate has been migrated onto the client device, move the file to the /etc/chef directory.

Step 4 – Joining the Chef Node to the Infra Server

Finally, we are ready to tell the chef-client to do something! But, we need the right set of commands. In the same /etc/chef/ directory, we are going to create a new file, called first-boot.json. This file tells the Chef-Client what to do after it has joined itself to the infra server. The contents of my first-boot.json are found below:

{"run_list":
    [
        "recipe[chef-client]"
        "recipe[chef-client::delete_validation]"
    ]
}

How the chef-client cookbook (that’s what those two lines represent) works, where it came from, and what those commands do, is something we will discuss in our next installment. For now, know that the two commands above configure the chef-client to run on a schedule (by default chef checks for updates from the Infra server every 30 minutes), and remove the validation key. As soon as we run the chef-client command, the client will be joined to the infra server, and will no longer need access to the validation key to get passed the gate keeper. Because the validation key is sensitive material, its best to remove it.

A note on scheduling Chef. Chef is a pull based Central Management service. That means that the client machine PULLS information from the Central Management service. By default, without running the chef client cookbook as shown above, the client will run ONLY when it is invoked manually by a user. Manual invocation is highly useful for testing purposes, but totally defeats the point of automation in a production environment.

Finally, with the first-boot.json file in place, we are prepared to perform our joining command:

$ sudo chef-client -j /etc/chef/first-boot.json

To verify that the node is joined correctly, refer to the chef infra server and check to see if there is a node present with the hostname of your client device. If there is, then the join was successful! Now, for the hard part. Doing something with an Infra joined device. We will cover that on our next installment!

12 thoughts on “Chef Tutorials – Part 3 – Configuring A Chef Infrastructure Node”

  1. Have you ever considered creating
    an ebook or guest authoring on other blogs?
    I have a blog based on the same subjects you discuss and
    would really like
    to have you share some stories/information. I know my readers
    would appreciate your work.
    If you are even remotely interested, feel free to shoot
    me an
    e-mail.

    Reply
  2. Oh my goodness! Amazing article
    dude! Many thanks, However I am experiencing difficulties
    with your RSS. I don’t know why I am unable to subscribe
    to it. Is there anybody getting
    the same RSS problems?
    Anyone that knows the solution will you kindly respond?

    Thanks!!

    Reply
  3. Superb website you have here but I was curious if you
    knew of any discussion boards that cover the same topics discussed here?

    I’d really love to be a part of group where I can get suggestions from
    other knowledgeable people that share the same interest.
    If you have any recommendations, please let me know. Cheers!

    Reply

Leave a Comment