Creating a Key Pair

The easiest way to create a key pair for a node is to attempt to connect to a server. The Puppet agent will create the private and public TLS keys, and then submit a certificate signing request (CSR) to the server for authorization.

The default hosts file associates the name puppet.example.com with the puppetserver node. If you are using the deprecated Puppet master, you will need to edit /etc/hosts to look like this:

192.168.250.5  puppetmaster.example.com puppet.example.com 
192.168.250.6  puppetserver.example.com

If you are testing the Puppet Server, then you’ll want that name associated with the puppetserver instance’s IP address.

Once you have confirmed that this is correct, attempt a connection to the server using this command:

[vagrant@client ~]$ puppet agent --test --server=puppet.example.com
Info: Creating a new SSL key for client.example.com
Info: Caching certificate for ca
Info: csr_attributes file loading from /etc/puppetlabs/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for client.example.com
Info: Certificate Request fingerprint (SHA256): C3:37:C8:76:CE:3A:D7:81:64:DF:80
Info: Caching certificate for ca
Exiting; no certificate found and waitforcert is disabled

There’s a lot of information here, so let’s review it. The client has done all of the following:

1. Created a private and public TLS key pair for itself.
2. Connected to the server, and retrieved a copy of the server’s TLS certificate.
3. Created a CSR for itself and submitted it to the server.

The client cannot proceed until it is authorized. You can run the command again and you’ll see the same output. This is security for your environment—a node may not connect and download information that it has not been authorized for:

[vagrant@client ~]$ puppet agent --test --server=puppet.example.com
Exiting; no certificate found and waitforcert is disabled

Authorizing the Node

At this point, you’ll need to return to the Puppet server and sign the client’s CSR in order to authorize it. First, let’s see what requests are waiting to be signed:

[vagrant@puppetserver ~]$ puppet cert --list
  "client.example.com" (SHA256) C3:37:C8:76:CE:3A:D7:81:64:DF:80

Compare the CSR’s fingerprint with the request you made earlier to ensure that it is the request you created. Sign the request in order to authorize the client:

[vagrant@puppetserver ~]$ puppet cert --sign client.example.com
Notice: Signed certificate request for client.example.com
Notice: Removing file Puppet::SSL::CertificateRequest client.example.com
  at '/var/opt/puppetlabs/puppetserver/ssl/ca/requests/client.example.com.pem'

The next time the client connects, it will be given the signed certificate and a Puppet catalog will be built for it.

Downloading the First Catalog

Now that the request has been signed, you can return to the client node and retry the connection attempt:

[vagrant@client ~]$ puppet agent --test --server=puppet.example.com
Info: Caching certificate for client.example.com
Info: Caching certificate_revocation_list for ca
Info: Caching certificate for client.example.com
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for client.example.com
Info: Applying configuration version '1438539603'
Notice: Applied catalog in 0.01 seconds

The Puppet agent has received the signed certificate for the node and stored it. Then it performed all the steps listed in “Understanding the Catalog Builder”:

1. The agent submitted the node name, environment, and facts to the Puppet server.
2. The Puppet master built a Puppet catalog for the node in 0.28 seconds.
3. The agent evaluates the catalog on the node in 0.01 seconds.

How did we know that the catalog was built in 0.28 seconds? You can find this in the syslog logfile:

[vagrant@puppetmaster ~]$ grep client.example.com /var/log/messages
Aug  2 18:20:03 puppetmaster puppet: Notice: Compiled catalog for
  client.example.com in environment production in 0.28 seconds

You’ll probably be thinking two things right now:

• Wow, evaluating a policy in 0.01 seconds is fast!
• But this didn’t do anything…

You are absolutely correct. At this moment in time, the catalog given back to the node was completely empty. Let’s go on to configure the server with your Hiera data and modules.

Installing Hiera Data and Modules

If you are building a new Puppet environment, install the Hiera data, environments, and modules you built in Part II. You can simply copy these from the client instance used earlier in the book.

On the client instance, give the vagrant user a password:

[vagrant@client ~]$ sudo passwd vagrant
Changing password for user vagrant.
New password: a good password
Retype new password: a good password
passwd: all authentication tokens updated successfully.

On the puppetserver instance, recursively copy over the entire code-dir path:

[vagrant@puppetserver ~]$ rsync -aH client:/etc/puppetlabs/code /etc/puppetlabs/
vagrant@client.example.com's password: 

With this simple process you have installed the Hiera data and modules built and tested earlier with puppet apply for use on the Puppet server.

Testing with a Client Node

At this time, you can now test your manifests, exactly as you did in Part II. The only difference is that this time the Puppet server will evaluate the manifest and build the catalog, instead of the local Puppet agent. On the client node, run this command:

$ sudo puppet agent --test --server=puppet.example.com --environment=test
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Info: Caching catalog for client.example.com
Info: Applying configuration version '1438557124'
Notice: Client is using catalog from the Test environment.
Notice: /Stage[main]/Main/Notify[UsingTest]/message: defined 'message' as
  'Client is using catalog from the Test environment.'
Notice: /Stage[main]/Puppet::Agent/Service[puppet]/ensure:
  ensure changed 'stopped' to 'running'
Info: /Stage[main]/Puppet::Agent/Service[puppet]:
  Unscheduling refresh on Service[puppet]
Notice: Applied catalog in 0.65 seconds

$ ps auwx |grep puppet
root     13615  0.0  7.4 256776 37340 ?      Ssl  22:52   0:00
   ruby /bin/puppet agent --server=puppet.example.com --environment=test

As you can see, the agent has configured the node exactly the same as when Puppet was run with the local manifests.

Learning More About Puppet Server

The absolute best way to expand on what you have learned in this chapter is to build out a Puppet server. Configure the client to use it, and test the process. Once you have this working, do all of the following:

1. Start Puppet agent on the client instance to connect to the server.
2. Review the certificate request and compare the fingerprint on the puppetserver instance.
3. Sign the agent’s certificate request.
4. Observe the Puppet agent implement the empty catalog on the client instance.
5. Review the node report stored in the $vardir/reports directory.
6. Copy the module and Hiera data from the client instance to the puppetserver instance.
7. Run the Puppet agent on the client instance again to observe the module convergence.

For extra credit, go on to perform advanced configuration changes:

1. Alter the list of classes assigned to the node in Hiera.
2. vagrant up web1, install Puppet, and connect it to the Puppet server.