Before you install Puppet, you will need to check that you have all of the required elements, listed as follows:

$ sudo rpm –e puppet* facter ruby rubyge*

The best way to install Puppet is to use the packaged builds provided by Puppet Labs. If you are using a system listed on the following web page, installing Puppet will be quite easy:

http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html

If you are using CentOS or Red Hat, installation could be as easy as the following:

$ sudo rpm -i http://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-6.noarch.rpm
$ sudo yum install puppet puppet-server

If you are using CentOS 5, just change the path to /el/5 and your architecture. The Puppet Labs repository includes Ruby 1.8.7, so you won't have to do anything special to install puppet.

Debian is likewise simple:

$ wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb
$ sudo dpkg –I puppetlabs-release-precise.deb
$ sudo apt-get update
$ sudo apt-get puppet

Windows packages can be downloaded from http://downloads.puppetlabs.com/windows/.

Even if you prefer to build things from source, I recommend that you use the packages provided by Puppet Labs for this starter. If you have a platform that is not listed on the Puppet Labs repositories page or can't use the prebuilt packages, you can install Puppet from Ruby gems:

$ sudo gem install puppet

Or directly from source:

$ wget http://downloads.puppetlabs.com/puppet/puppet-latest.tgz
$ tar xvzf puppet-latest.tgz
$ cd puppet
$ sudo ruby install.rb

Both of these installation methods require many manual steps, which will be unique to your platform and beyond the scope of this book. You will need to follow the steps documented at the following link:

http://docs.puppetlabs.com/guides/installation.html

At this point you have installed Puppet and the Puppet server packages. Right now, before you start the server up, we're going to save you a lot of grief and a few trips to the mailing list. The single most common query on the list deals with confusion over how Puppet's mutual authentication works. Let's nip this right away, and save you the trouble:

You should make certname be a name inside your own domain, and vardir can be any directory you like. However, I recommend that you do not use the name of a real host, or the standard var client directory (/var/lib/puppet on most platforms). Use an alias for the server right now. These two settings will allow you to move your Puppet server to a new host without any difficulty later on.

I'll explain why after you add this new hostname to your DNS. Go ahead, I'll wait.

At this point we are ready to start up the server. The following command works on almost all platforms:

$sudo /sbin/service puppetmaster start

You will get the following response:

Starting puppetmaster:                [OK]

Check out /var/log/messages to ensure no errors happened. The logs will show that it created a new certificate authority based on the name you gave it earlier.

If you ever need to start again from scratch, you can always stop the server, remove the directory named in vardir, and restart the server to get a fresh, clean start:

$ sudo /sbin/service puppetmaster stop
Stopping puppetmaster:                [OK]
$ sudo rm –rf /var/lib/puppet-server
$ sudo /sbin/service puppetmaster start
Starting puppetmaster:                [OK]

Now let's configure the first client, the system running the puppet server. You will see the system authenticate by its real hostname, not the puppet alias we created in step 3. This makes it easy if you move the puppet server to another host later.

Now we create a relationship with the Puppet server. This involves a handshake on both sides, so you will need two logins, one for the client and one for the server.

On the client, run the following command:

$ sudo puppet agent --test

You'll see that the client creates a certificate request and attempts to connect to the server:

Info: Creating a new SSL key for myhost.example.net
Info: Caching certificate for ca
Info: Creating a new SSL certificate request for myhost.example.net
Info: Certificate Request fingerprint (SHA256): 12:34:56:78:9A:BC:DE…
Exiting; no certificate found and waitforcert is disabled.

The final sentence isn't an error. This gives us time to sign the certificate request on the server. On the server, use the following command to see the authentication requests:

$ sudo puppet cert list

You will get the following response:

"myhost.example.net" (SHA256) 12:34:56:78:9A:BC:DE…

Look at the certificate request from the client. Compare the fingerprint and then sign the certificate as follows:

$ sudo puppet cert sign myhost.example.net

You will get the following response:

Notice: Signed certificate request for myhost.example.net
Notice: Removing file Puppet::SSL::CertificateRequestmyhost.example.netat '/var/lib/puppet-server/ssl/ca/requests/myhost.example.net.pem'

And now in the final step, we will connect with the client again. It will download the signed certificate and complete its first transaction with the server:

$ sudo puppet agent --test 

You will get the following response:

Info: Caching certificate for myhost.example.net
Info: Caching certificate_revocation_list for ca
Info: Retrieving plugin
Info: Caching catalog for myhost.example.net
Info: Applying configuration version '1357512658'
Info: Creating state file /var/lib/puppet/state/state.yaml
Notice: Finished catalog run in 0.06 seconds

At this point you have seen the client establish a connection with the server and download the node's catalog. We will explain what the catalog is in the next section. There's nothing in the policy just yet, so there is nothing in the catalog. But the secure relationship between the client and the server has been created and we'll be using this to test our policies.

You now have a working installation of Puppet. Let's move to the next section and create a basic policy.