Authors: Jeffrey McCune James Turnbull
Pro Puppet (7 page)
We recommend you also create a DNSCNAMEfor your Puppet host, for examplepuppet.example.com,and add it to your/etc/hostsfile and your DNS configuration:
# /etc/hosts
127.0.0.1 localhost
192.168.0.1 puppet.example.com puppet
Once we’ve configured appropriate DNS for Puppet we need to add the site.pp file which holds the basics of the configuration items we want to manage.
Thesite.ppfile tells Puppet where and what configuration to load for our clients. We’re going to store this file in a directory calledmanifestsunder the/etc/puppetdirectory.
Note
“Manifest” is Puppet’s term for files containing configuration information. Manifest files have a suffix of.pp.
This directory and file is often already created when the Puppet packages are installed. If it hasn’t already been created, then create this directory and file now:
# mkdir /etc/puppet/manifests
# touch /etc/puppet/manifests/site.pp
Tip
Puppet will not start without thesite.ppfile being present.
We’ll add some configuration to this file later in this chapter, but now we just need the file present.
Note
You can also override the name and location of themanifestsdirectory andsite.ppfile using themanifestdirandmanifestconfiguration options, respectively. These options are set in thepuppet.confconfiguration file in the[master]section. Seehttp://docs.puppetlabs.com/references/stable/configuration.htmlfor a full list of configuration options. We’ll talk about a variety of other options throughout this book.
The Puppet master runs on TCP port 8140. This port needs to be open on your master’s firewall (and any intervening firewalls and network devices), and your client must be able to route and connect to the master. To do this, you need to have an appropriate firewall rule on your master, such as the following rule for the Netfilter firewall:
-A INPUT -p tcp -m state --state NEW --dport 8140 -j ACCEPT
The preceding line allows access from everywhere to TCP port 8140. If possible, you should lock this down to only networks that require access to your Puppet master. For example:
-A INPUT -p tcp -m state --state NEW -s 192.168.0.0/24 --dport 8140 -j ACCEPT
Here we’ve restricted access to port 8140 to the 192.168.0.0/24 subnet.
Note
You can create similar rules for other operating systems’ firewalls such as pf or the Windows Firewall.
The Puppet master can be started via aninitscript on most Linux distributions. On Red Hat, we would run the init script with theservicecommand, like so:
# service puppetmaster start
On Debian or Ubuntu, we run it using theinvoke-rc.dcommand:
# invoke-rc.d puppetmaster start
Other platforms should use their appropriate service management tools.
Note
Output from the daemon can be seen in/var/log/messageson Red Hat-based hosts and/var/log/daemon.logon Debian and Ubuntu hosts. Puppet will log via thedaemonfacility to Syslog by default on most operating systems. You will find output from the daemons in the appropriate location and files for your operating system.
Starting the daemon will initiate your Puppet environment, create a local Certificate Authority, certificates and keys for the master, and open the appropriate network socket to await client connections. You can see Puppet’s SSL information and certificates in the/etc/puppet/ssldirectory.
# ls –l /etc/puppet/ssl
drwxrwx--- 5 puppet puppet 4096 2009-11-16 22:36 ca
drwxr-xr-x 2 puppet root 4096 2009-11-16 22:36 certificate_requests
drwxr-xr-x 2 puppet root 4096 2009-11-16 22:36 certs
-rw-r--r-- 1 puppet root 361 2009-11-16 22:36 crl.pem
drwxr-x--- 2 puppet root 4096 2009-11-16 22:36 private
drwxr-x--- 2 puppet root 4096 2009-11-16 22:36 private_keys
drwxr-xr-x 2 puppet root 4096 2009-11-16 22:36 public_keys
The directory on the master contains your Certificate Authority, certificate requests from your clients, a certificate for your master and certificates for all your clients.
Note
You can override the location of the SSL files using thessldiroption.
You can also run the Puppet master from the command line to help test and debug issues. I recommend doing this when testing Puppet initially. To do this we start the Puppet master daemon like so:
# puppet master --verbose --no-daemonize
The--verboseoption outputs verbose logging and the--no-daemonizeoption keeps the daemon in the foreground and redirects output to standard out. You can also add the--debugoption to produce more verbose debug output from the daemon.
A SINGLE BINARY
From version 2.6.0 and later, all the functionality of Puppet is available from a single binary,puppet, in the style of tools likegit, rather than the individual binaries previously used (the individual binaries are still available for backwards-compatibility at this time). This means you can now start the Puppet master by either running:
# puppet master
Or,
# puppetmasterd
The agent functionality is also available in the same way:
# puppet agent
Or,
# puppetd
You can see a full list of the available functionality from the puppet binary by running:
$ puppet --help
We reference both the individual binaries and the single binary commands in this book.
Once you have the Puppet master configured and started, we can configure and initiate your first agent. On the agent, as we mentioned earlier, you need to install the appropriate packages, usuallypuppetandfacter, using your operating system’s package management system. We’re going to install a client on a host callednode1.example.comand then connect to ourpuppet.example.commaster.
When connecting our first client, we want to run the Puppet agent from the command line rather than as a service. This will allow us to see what is going on as we connect. The Puppet agent daemon is run usingpuppet agent(or in versions previous to 2.6.0, using thepuppetdbinary) and you can see a connection to the master initiated in
Listing 1-2
.
Tip
You can also run a Puppet client on the Puppet master, but we’re going to start with the more traditional client server. And yes, that means you can use Puppet to manage itself!