Many Puppet-based workflows are centered on the server, which is the central source of configuration data and authority. The server hands instructions to all the computer systems in the infrastructure (where agents are installed). It serves multiple purposes in the distributed system of Puppet components.

The server will perform the following tasks:

• Storing manifests and compiling catalogs
• Serving as the SSL certification authority
• Processing reports from the agent machines
• Gathering and storing information about the agents

As such, the security of your server machine is paramount. The requirements for hardening are comparable to those of a Kerberos key distribution center.

During its first initialization, the Puppet server generates the CA certificate. This self-signed certificate will be distributed among and trusted by all the components of your infrastructure...

As was explained earlier, the master mainly serves instructions to agents in the form of catalogs that are compiled from the manifest. You have also prepared a node block for your first agent in the master manifest.

Installing the agent software is easy; you did this at the start of Chapter 1, Writing Your First Manifests. The plain Puppet package that allows you to apply a local manifest contains all the required parts in order to operate a proper agent.

If you are using Puppet Labs packages, use the instructions from earlier in this chapter. On agent machines, you need not install the puppetserver package. Just get puppet-agent instead.

After a successful package installation, one needs to specify where puppet agent can find the puppet server:

root@puppetmaster # puppet config set –-section agent server pup-petmaster.example.net 

Afterwards...

Operating a Puppet master gives you numerous benefits over just using puppet apply on all your machines. This comes at a cost, of course. The master and agents form a server/client relation, and, as with most such constructs, the server can become the bottleneck.

The good news is that the Puppet agent is a fat client. The major share of the work inspecting file contents, interfacing with the package-management subsystem, services subsystem, and much more is done by the agent. The master only has to compile manifests and build catalogs from them. This becomes increasingly complex as you hand over more control to Puppet.

There is one more task your master is responsible for. Many of your manifests will contain file resources that rely on prepared content:

file { '/usr/local/etc/my_app.ini':
  ensure => file,
  owner  => 'root',
 ...

PuppetDB is a specialized database REST API designed to interact with the Puppet master. It mainly comprises a PostgreSQL backend with an API wrapper. The latter was written in Clojure and runs in yet another JVM.

PuppetDB aids the master's secondary task of storing reports and other agent data. It is also necessary for some specific manifest compiler functionality. This is covered in Chapter 6, The Puppet Beginners Advanced Parts.

The best way to set up and configure PuppetDB is actually Puppet itself. Since the necessary tools have not yet been introduced, we will postpone this step until Chapter 6, The Puppet Beginners Advanced Parts. This is not a problem, because PuppetDB is not essential for basic master operation.

Among the most frustrating issues, especially for new users, are problems with the agent's SSL handshake. Such errors are especially troublesome because Puppet cannot always offer very helpful analysis in its logs - the problems occur in the SSL library functions, and the application cannot examine the circumstances.

Consider the following output for the --test command:

root@agent# puppet agent --test
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: SSL_connect returned=1 errno=0 state=unknown state: certificate verify failed: [CRL is not yet valid for /CN=Puppet CA: puppet.example.net]  

The agent opines that the CRL it receives from the master...

You can now set up your own Puppet master, using the sophisticated puppetserver solution. You have successfully signed the certificate for a Puppet agent and can revoke certificates, if required. Using the node blocks in the master manifest, you can describe individual manifests for each distinct agent. Finally, you learned about some things that can go wrong with the SSL-based authentication.

In Chapter 3, A Peek into the Ruby Part of Puppet - Facts, Types, and Providers, we will take a look at the inner workings of Puppet in order to give you an understanding of how the Puppet agent adapts to its environment. You will also learn how the agent provides feedback to the master, allowing you to create flexible manifests that fit different needs.