Introduction to Puppet: Streamlined System Configuration

1149

 

If you have one Linux system to administer, you need a good working knowledge of scripting, command line utilities, and a trusty text editor. If you have two or more, it may be time to add Puppet to that list.

Every good system administrator strives to automate repetitive tasks so that they can free up their time to focus on more important matters. It’s the difference between spending a work day running the same set of commands on 20 different systems, or spending a work day improving a piece of infrastructure or testing a new open source tool that might be useful for your organization. Also, it’s just plain fun to know you can run a single command and accomplish what it would have taken half a day to finish.

In this piece, we’ll take a look at what Puppet is and some basics of installing and using Puppet on a single machine. In the next tutorial, we’ll get into the nitty gritty and focus on configuring Puppet and some more concrete examples.

What is Puppet?

So how does Puppet fit into all this? Puppet was born to automate repetitive tasks and to give system administrators a flexible framework to build on. Puppet is written in Ruby, and comprises a configuration language to write manifests and modules, daemons to run the Puppet instructions on managed systems and to coordinate machines that are using Puppet, and a dashboard to help visualize your systems and create reports.

In short: Puppet is a system to centralize and standardize configuration and administration of your systems. These can be desktop systems, workstations, servers, whatever. Now, since this is Linux.com, the primary focus for the article is Linux systems — but Puppet is not limited to Linux. You can also use Puppet with UNIX-based OSes like Solaris, the BSDs, and Mac OS X. According to the Puppet Web site, plans are also afoot for Windows support at some point “in the near future,” but no concrete date is set. (It’s probably quite a bit easier to port Puppet from Linux or a UNIX to another UNIX-like system than to wrangle it onto Windows.)

If you hadn’t guessed already, Puppet is open source. It’s licensed under the GNU General Public License (GPL).

Puppet abstracts the state you want your system to be in from the actual commands needed to get to that point. To put it another way, if you want to run updates on all your systems using Puppet, you don’t need to specify the Yum commands for Fedora systems, the Zypper commands for openSUSE, and APT commands for Ubuntu and Debian systems. Instead, you can write a manifest and run it on all your systems to update your packages.

Creating the manifest and configuring all the systems will be a bit more work, the first time. After that, it’s much easier. Let’s get started.

Basic Puppetry

Puppet packages should be available for most major distros already. Just search for puppet using your package manager of choice. For example, on Ubuntu 10.04 you’d want puppet and puppet-common for the managed systems, and puppetmaster for the central server (if you have multiple systems). You might also want the vim-puppet package if you’ll be writing Puppet manifests in Vim, or puppet-el if you want to write manifests in GNU Emacs.

When you’re working with Puppet, you’re working with resources. Users, packages, files, services, etc. A resource describes something on your system. You can find the standard types on the language resource guide on Puppet Labs’ site. Some resources are standard across all OSes (like files) others are OS-dependent (like zfs and zone, which are Solaris-only).

For single systems, you’ll usually use puppet to execute a manifest. Remember, a manifest is a file containing a set of resources and instructions on how that resource should be configured or manipulated.

Puppet also has a shell that you can use to execute Puppet commands and configure a local system. The Resource Abstraction Layer Shell (ralsh) can list resources, and operate on resources. Here’s a simple example to verify whether a user exists on the system using ralsh:

 

ralsh user norm

If norm doesn’t exist as a user account on the system yet, you’ll see this:

 

user { 'norm':
    ensure => 'absent'
}

This is Puppet providing the current system configuration, as expressed in the Puppet language. This is how you’d write a manifest to remove the user norm from a system. What if we want to add norm as a user with ralsh? Easy:

 

ralsh user norm

Ridiculously easy, isn’t it? That will create norm with some sane defaults. Here’s the manifest that ralsh executes:

 

user { 'norm':
    uid => '1001',
    ensure => 'present',
    gid => '1001',
    home => '/home/norm',
    shell => '/bin/sh'
}

You’d write that up as a manifest and run it using puppet on your local system. What if we want to make norm‘s shell bash instead of sh? Let’s look at that as a manifest:

 

user { 'norm':
    uid => '1001',
    ensure => 'present',
    gid => '1001',
    home => '/home/norm',
    shell => '/bin/sh'
}

Copy that to a file, like norm.pp, and change the shell line to shell => ‘/bin/sh’. Then run puppet norm.pp. Puppet will check the user, and make the changes necessary so that the user conforms to the manifest.

So how is this easier than running the commands to create a new user on your system? On a single system, it’s not. What if you need to create the user on 20 systems, though? Much, much easier. And this would work on Linux, Mac OS X, FreeBSD, and more.

This has been a pretty quick overview of how Puppet works on a single system. In the next tutorial, we’ll look at configuring Puppet to manage multiple systems and how to make changes across different distros.