Puppet tutorial series

• Part 1: Powering up with Puppet
• Part 2: Client and Server

In Part 1 of this Puppet tutorial we saw how to install Puppet on a Linux machine from source, and create a basic manifest which controls the NTP service. In this episode we’ll cover setting up a Puppet server and then using it to control multiple client machines.

Install Puppet from packages

In the first part of the tutorial, we installed Puppet directly from the source. This is a great way to learn and experiment, but for production purposes we would like to use a standard package - in this case, an RPM package we can install via Yum or Cobbler. This way, you can ensure that the same version of Puppet is present on your servers and update it automatically if need be. The RPM also has a few bonus features that the source package doesn’t.

If you want to follow along with the tutorial using your existing Puppet source install, that’s fine. It’s a good idea to make sure you’re using the same version of Puppet on both client and server, or you may run into obscure and annoying problems, so either install from the same source package on your client machine, or set up two fresh machines with the RPM package as described below.

If you’re using RHEL or CentOS then the EPEL repository is the best place to start. Enable the repository by installing the correct package for your OS version, following the instructions on How to Use EPEL:

# rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noa...
Retrieving http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noa...
warning: /var/tmp/rpm-xfer.2O73tR: Header V3 DSA signature: NOKEY, key ID 217521f6
Preparing...                ########################################### [100%]
   1:epel-release           ########################################### [100%]

You can then run:

# yum install puppet-server

and the Puppet server package will be installed from EPEL along with a bunch of dependencies. (Note that in EPEL puppet and puppet-server are two separate packages; on the client machines you’ll only need to install puppet.)

You can now start the Puppetmaster daemon and make the service persistent:

# chkconfig puppetmaster on
# service puppetmaster start
Starting puppetmaster:                                     [  OK  ]

If there is a firewall between the Puppetmaster and its clients (eg an iptables firewall on the Puppetmaster server itself) you will need to open TCP port 8140 to the clients.

Create a client manifest

In Part 1 of the Puppet Tutorial we created a file /etc/puppet/manifests/nodes.pp, which lists the nodes (machines) that Puppet knows about, and what configuration they should have. Currently it looks like this:

node myserver {
    include ntp
}

As we’re adding a new node to the system, we need to modify the file so that it reads like this:

node myserver {
    include ntp
}

node myclient {
    include ntp
}

Authorising a client

Puppet uses SSL (Secure Sockets Layer), an encrypted protocol, to communicate between master and clients. This means that only a client with a correctly signed SSL certificate can access the Puppetmaster and receive its configuration. To exchange certificates between the master and client, follow this procedure.

Adding a ‘puppet’ host entry

By default Puppet will look for a host called puppet on the local domain. To make this work, add the IP address of the Puppetmaster into the /etc/hosts file on the client, like this:

83.222.113.61   puppet

Test this with ping puppet (assuming you have allowed ICMP in the firewall).

Generate a certificate request

On the client, run:

# puppetd --test
info: Creating a new certificate request for myclient.mydomain.com
info: Creating a new SSL key at /etc/puppet/ssl/private_keys/myclient.mydomain.com.pem
warning: peer certificate won't be verified in this SSL session
notice: Did not receive certificate
notice: Set to run 'one time'; exiting with no certificate

Sign the certificate

On the master:

# puppetca -l
myclient.mydomain.com

There is a certificate request pending for myclient. To sign it, run:

# puppetca -s myclient.mydomain.com
notice: Signed certificate request for myclient.mydomain.com
notice: Removing file Puppet::SSL::CertificateRequest myclient.mydomain.com at '/var/lib/puppet/ssl/ca/requests/myclient.mydomain.com.pem'

If there is no certificate request listed, the client was not able to contact the server for some reason. Check that you have the right IP address for puppet in /etc/hosts on the client, and that TCP port 8140 is open on both the master and client firewalls. The puppetmasterd daemon also needs to be running on the master.

Run Puppet for the first time

On the client, you should now be able to run:

# puppetd --test
notice: Got signed certificate
info: Caching catalog at /var/puppet/state/localconfig.yaml
notice: Starting catalog run
notice: //ntp/Service[ntpd]/ensure: ensure changed 'stopped' to 'running'
notice: Finished catalog run in 0.92 seconds

Just as on the server in the first part of the tutorial, Puppet is now applying the ntp class to myclient. At the moment all this class does is ensure the ntp service is running, but of course it could do many more interesting things. And that’s what we’ll look at next time in Part 3.

Drupal, Puppet. Puppet, meet Drupal

Puppet and Drupal make a great combination. Drupal is an amazing tool for quickly constructing attractive, functional web sites. It lets you manage large numbers of web sites from a single installation, and (via add-on modules) provides almost any CMS or blog feature you could want.

However, like any powerful tool, Drupal takes some learning. It also needs a certain amount of discipline to manage Drupal servers without getting into a chaotic mess. The Drupal sysadmin can end up trying to navigate a spaghetti of ad-hoc symlinks and face problems upgrading, maintaining, monitoring and backing up a large Drupal installation. Aegir can help with this (I’ll look at Aegir vs. Puppet in a future article) but first we need to get Drupal itself under control.

Fortunately, Puppet can help you tame Drupal and use the power of configuration management to bring your Drupal sites under control. In this article I’ll explain some techniques and Puppet recipes I use to manage Drupal sites and servers, including my own sites, including this one! Read more »

Puppet tutorial series

• Part 1: Powering up with Puppet
• Part 2: Client and Server

This Linux Puppet tutorial will help you install Puppet for the first time and start managing your servers. Server configuration management (CM) is big news in the IT world these days. Rightly so, because Linux automation, devops and CM tools like Puppet and Chef can save you an enormous amount of time and money and help you build a really reliable and automated Linux infrastructure. In this tutorial, I’ll show you how to set up Puppet on Linux.

If you’re a sysadmin, or anyone else who manages a bunch of servers, CM tools can help you create patterns or recipes which you can use to build lots of identical servers, or cloud instances, or re-use in different places and for different applications. Automating Linux servers is a snap with Puppet. Puppet can manage thousands of servers as easily as just one or two - but let’s start with one or two!

If you’re a developer, Linux configuration management lets you write code which describes how servers should be set up - saving you the time and effort of doing it manually, and letting you create large, load-balanced groups of interchangeable servers which are guaranteed to be identically configured.

Installing Puppet

So much for the sales pitch. Let’s take a look at the steps required to get up and running with your first Puppet install (we’ll come to Chef in a later article). Read more »