Because I work with a lot a of Windows guys, I tend to describe Puppet as Group Policy for Linux. The basic idea is to centralize your host and service configurations, so that you don’t have to waste time configuring the same things over and over again. Once you have a set of standard templates, you can simply apply them to the desired hosts and let Puppet do all the configuring for you. This article is not meant to be an in-depth Puppet tutorial (you can find that elsewhere), but more of a high-level overview of how to design a flexible Puppet infrastructure.

Zones and Roles

The first thing we did was organize our hosts and services into “zones” and “roles” (similar to the Example (42) Infrastructure Design Guidelines). A “zone” says something about where a particular host lives (e.g., which network it’s on or which customer it belongs to), while a “role” says something about what the host does (e.g., serves web pages, routes email messages, etc.). Note that Puppet has no built-in concept of zones and roles. This is just a method of organization that worked well for us.

Modules

Once our zones and roles were defined, we needed to create the “modules” that make up our various roles. A “module” is simply a way to group related configuration options together. For example, we have modules with names like “apache,” “bind,” “mysql,” and “postfix.” Each module contains the scripts and files needed to apply the appropriate configuration for a given service.

Module Example

Here is an example of a module that we use to manage the SSH service on some of our servers:

class openssh::server {
    package { "openssh":
        name   => "openssh-server",
        ensure => installed,
    }
    file { "sshd_config":
        path    => "/etc/ssh/sshd_config",
        owner   => "root",
        group   => "root",
        mode    => "600",
        source  => "puppet:///openssh/sshd_config",
        require => Package["openssh"],
    }
    service { "openssh":
        name      => "sshd",
        enable    => true,
        ensure    => running,
        hasstatus => true,
        require   => Package["openssh"],
        subscribe => File["sshd_config"],
    }
}

I don’t want to go into a lot of detail here, but you should notice three distinct sections in this module—”package,” “file,” and “service.” In Puppet lingo, these are called “resources,” and are the basic building blocks of every Puppet configuration. Puppet resources allow you to focus on what you want to do, and let Puppet handle the platform-specific details of how it gets done. In this example, we tell Puppet to do the following:

1. Use the package resource to ensure that the “openssh-server” package is installed.
2. Use the file resource to overwrite the sshd_config file with our modified version (making sure to set the proper permissions on the file).
3. Use the service resource to ensure that the “sshd” service is running.
   • If any changes are made to the sshd_config file, then restart the sshd service so that the new configuration takes effect.

Role Example

Now that you know what a module looks like, let’s look at how roles are built up from modules:

class role_default {
    include openssh::server
}
class role_lamp {
    include role_default
    include apache::ssl
    include apache::php
    include mysql::server
}

There are two roles here; role_default (the role we apply to all hosts) and role_lamp (for Linux/Apache/MySQL/PHP servers). Notice that our example openssh::server module is assigned to role_default, and role_lamp includes role_default, as well as three other modules. This demonstrates how complex roles can be built up from smaller roles.

Zone Example

At Fandotech, we typically use zones to set variables that override the default behavior of certain modules. In other words, a given module may configure things differently depending on what zone the target host is in. In this example, we set a variable to allow the “LinuxAdmins” group to log on to hosts that live in the zone_fandotech zone:

node zone_fandotech {
    $accessconf_rules = ["+ : LinuxAdmins : ALL"]
}

Node Example – Tying it all Together

Nodes are the individual hosts managed by Puppet, and are what tie everything together. Let’s look at one final example:

node default {
    include role_default
}
node 'example.fandotech.com' inherits zone_fandotech {
    include role_lamp
}

In this example, we have a special “default” node, which refers to any puppet-managed host that does not have explicit node configuration. We also have a node called “example.fandotech.com” which lives in the zone_fandotech zone and gets all the configuration options from the role_lamp role.

Conclusion

Puppet promotes efficiency by making it possible for a single administrator to configure hundreds (or possibly even thousands) of Linux machines without having to log on to a single one. It also helps ensure standards compliance, and if your Puppet configuration is stored in a source code repository (which it should be), then you have a built-in audit history of every change made to your systems.

The bottom line is that if you’re still trying to manage Linux machines without a configuration management system (like Puppet), then you’re doing it wrong.

Michael Conigliaro

Since this is my first post on the new Fandotech blog, I think an introduction is in order. My name is Mike Conigliaro, and I’m a Systems Analyst working in the datacenter here at Fandotech. I set a personal goal each day to do less work than I did the previous day, with the ultimate goal of automating myself out of a job. Sound crazy? If you work in IT, I’d say you’d be crazy not to work this way.

It was in the Camel Book that Larry Wall (creator of the Perl programming language) famously outlined the three virtues of a programmer:

Laziness – The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it.

Impatience – The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them.

Hubris – Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about.

Unfortunately, it seems that many system administrators simply don’t think of themselves as “programmers.” I believe this is a mistake, and that those who dismiss programming as a skill strictly for full-time software developers do themselves a disservice for two main reasons:

First of all, we all know that no software is bug-free, and no vendor will ever be able to fully accommodate the specific needs of every one of its customers. Thus, it pays to be able to fix bugs and do your own customizations when needed. This is why good administrators love open source software. Some of us are far too impatient (see above) to wait for vendors to get around to fixing bugs and implementing the features we want, so we just do it ourselves! But even if you don’t have the time to write new code, simply being able to read and understand existing code can help immensely when trying to troubleshoot a problem.

Secondly, because computers are one of the most powerful tools we have for performing repetitive tasks quickly and accurately (whereas even the best human beings are slow and error prone), it is in every administrator’s best interest to make the computer do as much of their work as possible. I believe that every good administrator should constantly be asking him/herself “How can I automate this?” In Mike’s ideal world, this simple question would be the official mantra of system administrators everywhere!

So now that I’ve convinced you that programming is one of the most powerful skills a system administrator can have in his/her arsenal, I encourage you to learn to program, then find a small task that you do on a regular basis and figure out how to automate it. So what do you do once you’ve gotten good at this and automated yourself out of a job? Well, just think of 100% automation as perfection. Although you’ll never get there, it’s something that you’ll want to get as close to as reasonably possible. The point is to automate to the best of your abilities so that you can spend less time on menial tasks and more time on the fun things that make your job worth while.

Mike Conigliaro