Puppet with Amazon AWS III - Puppet run

Puppet

Continued from the previous chapter, Puppet with Amazon AWS II - ssh and puppet install, now we want to run puppet.

By default, the Puppet client runs as a daemon, and the puppet agent command forks off the Puppet daemon into the background and exits immediately.

Puppet uses SSL certificates to authenticate communication between master and agent nodes. The Puppet master acts as a certificate authority (CA). Our master generates its own certificates which is used to sign agent certificate requests.

The first time Puppet runs on an agent node, it will send a certificate signing request to the Puppet master. Before the master will be able to communicate and control the agent node, it must sign that particular agent node's certificate.

The request for certificate from Puppet agent node on the Puppet master node looks like this:

root@puppetagent:~# puppet agent --no-daemonize --onetime --verbose
Info: Caching certificate for ca
Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml
Info: Creating a new SSL certificate request for puppetagent.ec2.internal
Info: Certificate Request fingerprint (SHA256): A0:3F:90:D1:A7:40:77:4C:1B:1A:E5:65:82:C5:A6:74:BA:5A:DA:68:CD:54:FA:A3:5D:75:DF:97:C8:2B:63:88
Info: Caching certificate for ca
Exiting; no certificate found and waitforcert is disabled

We can see the output from our connection. The agent has created a certificate signing request and a private key to secure our connection. Puppet uses SSL certificates to authenticate connections between the master and the agent. The agent sends the certificate request to the master and waits for the master to sign and return the certificate.

At this point, the agent has exited after sending in its Certificate Signing Request (CSR). The agent will need to be rerun to check in and run Puppet after the CSR has been signed by the CA. We can configure puppet agent not to exit, but instead stay alive and poll periodically for the CSR to be signed. This configuration is called waitforcert and is generally only useful if we are also auto-signing certificates on the master.

Note:

1. We could have used puppet agent --test instead of puppet agent --no-daemonize --onetime --verbose.
2. If we want to clear past request, we may us sudo rm -rf /var/lib/puppet/ssl.
3. At this point, on the 'master' side, we might already have the cert request. We can check it using sudo puppet cert list -all command.

To complete the connection and authenticate our agent, we now need to sign the certificate the agent has sent to the master. We do this using puppet cert on the master:

root@puppetmaster:~# puppet cert list -all
  "puppetagent.example.org" (SHA256) E7:79:95:BA:77:CB:D2:F1:3D:13:8F:09:38:65:F7:0F:7A:54:76:D0:C7:F7:41:AE:26:EE:51:EE:15:94:50:C8
+ "puppet"                  (SHA256) 2C:A4:74:22:4B:87:07:14:B3:66:8D:1E:33:AD:E1:3D:49:6C:74:8D:12:8D:5E:5F:D6:65:16:F1:16:71:2B:66 (alt names: "DNS:puppet", "DNS:puppet.example.org")

To sign a certificate request, the puppetmaster uses the puppet cert sign command, with the 'hostname' of the certificate we want to sign:

root@puppetmaster:~# puppet cert sign puppetagent.example.org
Notice: Signed certificate request for puppetagent.example.org
Notice: Removing file Puppet::SSL::CertificateRequest puppetagent.example.org at '/var/lib/puppet/ssl/ca/requests/puppetagent.example.org.pem'

On the client side, minutes after signing the certificate, we should see the following (or we can stop and restart the Puppet agent rather than waiting two minutes):

root@puppetagent:~# puppet agent --no-daemonize --onetime --verbose
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Caching catalog for puppetagent.example.org
Info: Applying configuration version '1414907319'
Notice: Finished catalog run in 0.05 seconds

Note: Again, we can use puppet agent --test again instead of puppet agent --no-daemonize --onetime --verbose.

The agent has connected and our signed certificate has authenticated the session with the master.

Let's look at Puppet's components, configuration language, and capabilities. Puppet manifests are made up of a number of major components:

1. Resources: Individual configuration items
2. Files: Physical files you can serve out to your agents
3. Templates: Template files that you can use to populate files
4. Nodes: Specifies the configuration of each agent
5. Classes: Collections of resources
6. Definitions: Composite collections of resources

site.pp file tells Puppet where and what configuration to load for our clients. We're going to store this file in a directory called manifests under the /etc/puppet directory. Manifest is Puppet's term for files containing configuration information. Manifest files have a suffix of .pp.

Create a site.pp file:

# /etc/puppet/manifests/site.pp

node default {
  file { "/tmp/hello" :
    content => "hello bogotobogo.com"
  }
}

Here, we specified a special node called default. If no other node definition exists, then the contents of this default node are applied to the host.

On 'agent':

root@puppetagent:/# puppet agent --server puppetmaster.example.org

If we open "/tmp/hello" file, it has:

hello bogotobogo.com

Though we'll discuss resources in depth in later chapters, here is a very brief taste of resources:

  file { "/tmp/hello" :
    content => "hello bogotobogo.com"
  }

It is constructed as follows:

  type { title:
    attribute => value,
  }

Here, we define a configuration resource for the /tmp/hello file. Each resource is made up of a type (what sort of resource is being managed: packages, services, or cron jobs), a title (the name of the resource), and a series of attributes (values that specify the state of the resource-for example, whether a service is started or stopped).

Next is the title of the resource, here the name of the file we want to create. Then, we've specified a single attribute, content, with a value of string. Attributes tell Puppet about the required state of our configuration resource. Each type has a series of attributes available to configure it.

Puppet