Puppet

External resources

	Wikipedia

	Ohloh

Puppet is a configuration management system written in Ruby. It can be used for automating machine deployments.

Installation

Puppet is provided by the Gentoo package app-admin/puppet. Currently, there is no distinction between server and client, so the basic installation procedure is the same for both.

First, install Puppet via emerge:

root # emerge --ask app-admin/puppet

Configuration and Setup

Puppet is mainly configured through /etc/puppet/puppet.conf in an INI-style format. Comments are marked with a hash sign (#). The configuration file is separated into several sections, or blocks:

• [main] contains settings that act as a default for all parts of Puppet, unless overridden by settings in any of the following sections:
  • [master] is used for settings applying to the Puppetmaster (puppet master), or CA tool (puppet cert)
  • [agent] is used for settings applying to the Puppet agent (puppet agent)

A more in-depth explanation, as well as a list of further blocks used is available in the official Puppet documentation. Also, there is a list of all configuration options, some of which of course make only sense when applied to either server or client.

Server (Puppetmaster) Setup

The default configuration put by the Ebuild into puppet.conf can be used as-is. For Puppet 2.7.3, the server-related parts look like this:

File/etc/puppet/puppet.confServer-related default configuration

[main]
    # The Puppet log directory.
    # The default value is '$vardir/log'.
    logdir = /var/log/puppet

    # Where Puppet PID files are kept.
    # The default value is '$vardir/run'.
    rundir = /var/run/puppet

    # Where SSL certificates are kept.
    # The default value is '$confdir/ssl'.
    ssldir = $vardir/ssl

Setting up the file server

To be able to send files to the clients, the file server has to be configured. This is done in /etc/puppet/fileserver.conf. By default, there are no files being served.

File/etc/puppet/fileserver.confSetting the files share

[files]
    path /var/lib/puppet/files
    allow 192.168.0.0/24

The snippet above sets up a share called files (remember this identifier, as it will need to be referenced later), looking for files in /var/lib/puppet/files and only available for hosts with an IP from the 192.168.0.0/24 network. You can use IP addresses, CIDR notation, and host names (including wildcards like *.domain.invalid) here. The deny command can be used to explicitly deny access to certain hosts or IP ranges.

Starting the Puppetmaster daemon

Note

It is recommended that the Puppetmaster is reachable from the clients using the host name puppet. However, the name can be overridden, which of course causes configuration effort.

Important

At this point, the host name as seen from the clients should be the same as the output of hostname -f. You might have to adjust /etc/hosts to achieve this, or manually create a new certificate as explained below.

With the basic configuration as well as an initial file server configuration, we can start the Puppetmaster daemon using its init script:

root # /etc/init.d/puppetmaster start

During the first start, Puppet generates an SSL certificate for the Puppetmaster host and places it into the ssldir, as configured above.

It listens on Port 8140/TCP, make sure that there are no firewall rules obstructing access from the clients.

A simple manifest

Manifests, in Puppet's terminology, are the files in which the client configuration is specified. The documentation contains a comprehensive guide about the manifest markup language.

As a simple example, let's create a message of the day (motd) file on the client. On the puppetmaster, create a file inside the files share created earlier:

File/var/lib/puppet/files/motdMOTD file on the server

Welcome to this Puppet-managed machine!

Then, we have to create the main manifest file in the manifests directory. It is called site.pp:

File/etc/puppet/manifests/site.ppMain manifest on the server

node default {
  file { '/etc/motd':
    source => 'puppet://puppet/files/motd'
  }
}

The default node (the name for a client) definition is used in case there is no specific node statement for the host. We use a file resource and want the /etc/motd file on our clients to contain the same thing as the motd file in the files share on the host puppet. If your puppetmaster is reachable only using another host name, you have to adapt the source URI accordingly.

Client Configuration

Important

The client must have the same major and minor version as the Puppetmaster. Using a 2.7.1 Puppetmaster with 2.7.2 clients is fine, but using 2.6 for the server and 2.7 for clients can cause unexpected issues at any time.

Note

If your puppetmaster is not reachable via puppet, set server=<your hostname> to the actual host name in /etc/puppet/puppet.conf in the [main] section.

During the first execution of the Puppet agent, you have to wait for your certificate to be signed by the puppetmaster. To request a certificate, and run your first configuration run, execute:

root@client # puppet agent --test --waitforcert 60

---

info: Creating a new certificate request for client
info: Creating a new SSL key at /var/lib/puppet/ssl/private_keys/client.pem
notice: Did not receive certificate

Before the client can connect, you have to authorize the certificate request on the server. Our client should appear in the list of nodes requesting a certificate:

root@server # puppet cert --list

---

client

Now, we grant the request:

root@server # puppet cert --sign client

The client will check every 60 seconds whether its certificate has already been issued. After that, it continues with the first configuration run:

info: Caching catalog for client
info: Applying configuration version '1317317379'
notice: /Stage[main]//Node[default]/File[/etc/motd]/ensure: defined content as '{md5}30ed97991ad6f591b9995ad749b20b00'
notice: Finished catalog run in 0.05 seconds

When you're seeing this message, all went well. You can now check the contents of your /etc/motd file on the client:

user@client $ cat /etc/motd

---

Welcome to this Puppet-managed machine!

You can now start the puppet agent as a deamon and have it launch on boot:

root@client # /etc/init.d/puppet start
root@client # rc-update add puppet default

Other Topics

Manually generating certificates

To manually generate a certificate, you can use the puppet cert utility. It will place all generated certificates into the ssldir as set in the puppet configuration and will sign them with the key of your local Puppet Certificate Authority (CA).

An easy case is the generation of a certificate with only one Common Name:

root # puppet cert --generate host1

If you need to have multiple host names the certificate is valid for, use the --certdnsnames parameter and separate the additional host names with a colon:

root # puppet cert --generate --certdnsnames puppet:puppet.domain.invalid host1.domain.invalid

This example will generate a certificate valid for the three listed host names.

See also

• Upstream website
• Puppet Wiki