Free Pro Puppet by Jeffrey McCune James Turnbull Page A

configuration items.
The ssh::service Class
    Let’s look at our last class,
ssh::service
, and update it to reflect our new practice:
    class ssh::service {
  service { $ssh::params::ssh_service_name:
    ensure => running,
    hasstatus => true,
    hasresstart => true,
    enable => true,
    require => Class["ssh::config"],
  }
}
    We’ve added our new variable,
$ssh_service_name
, to the
ssh:params
class too:
    class ssh::params {
  case $operatingsystem {
    Solaris {
      $ssh_package_name = 'openssh'
      $ssh_service_config = '/etc/ssh/sshd_config'
      $ssh_service_name = 'sshd'
  }
…
}
    Let’s also look at our
Service[$ssh::params::ssh_service_name]
resource (at the start of this section), as this is the first service we’ve seen managed. You’ll notice two important attributes,
ensure
and
enable
, which specify the state and status of the resource respectively. The state of the resource specifies whether the service is running or stopped. The status of the resource specifies whether it is to be started at boot, for example as controlled by the
chkconfig
or
enable-rc.d
commands.
    Puppet understands how to manage a variety of service frameworks, like SMF and init scripts, and can start, stop and restart services. It does this by attempting to identify the service framework your platform uses and executing the appropriate commands. For example, on Red Hat it might execute:
    $ service sshd restart
    If Puppet can’t recognize your service framework, it will revert to simple parsing of the process table for processes with the same name as the service it’s trying to manage. This obviously isn’t ideal, so it helps to tell Puppet a bit more about your services to ensure it manages them appropriately. The
hasstatus
and
hasrestart
attributes we specified in the
ssh::service
class is one of the ways we tell Puppet useful things about our services. If we specify
hasstatus
as true, then Puppet knows that our service framework supports status commands of some kind. For example, on Red Hat it knows it can execute the following:
    $ service sshd status
    This enables it to determine accurately whether the service is started or stopped. The same principle applies to the
hasrestart
attribute, which specifies that the service has a restart command.
    Now we can see Puppet managing a full service, if we include our new
ssh
module in our Puppet nodes, as shown in Listing 2-5 .
    Listing 2-5. Adding the
ssh
Module
class base {
  include sudo, ssh
}

node 'puppet.example.com' {
  include base
}

node 'web.example.com' {
  include base
}

node 'db.example.com' {
  include base
}
node 'mail.example.com' {
  include base
}
    Here we’ve created a class called
base
, in which we’re going to place the modules that will be base or generic to all our nodes. Thus far, these are our
sudo
and
ssh
modules. We then
include
this class in each node statement.
    Note We talked earlier about node inheritance and some of its scoping issues. As we explained there, using a class instead of node inheritance helps avoids these issues. You can read about it at
http://projects.puppetlabs.com/projects/puppet/wiki/Frequently_Asked_Questions#Common+Misconceptions
.
    With a basic SSH module in place, and we can now manage the SSH daemon and its configuration.
Creating a Module to Manage Postfix
    Let’s now create a module to manage Postfix on
mail.example.com
. We start with a similar structure to our SSH module. In this case, we know which platform we’re going to install our mail server on so we don’t need to include any conditional logic. However, if we had multiple mail servers on different platforms, it would be easy to adjust our module using the example we’ve just shown to cater for disparate operations