Free Pro Puppet by Jeffrey McCune James Turnbull

the
ssh::config
class:
    file { $ssh::params::ssh_service_config:
  ensure = > present,
  …
}
    Again, we have no need for a messy conditional in the resource, we can simply reference the
$ssh::params::ssh_service_config
variable.
    We can also see that the file resource contains two metaparameters,
require
and
notify
. These metaparameters both specify relationships between resources and classes. You’ll notice here that both metaparameters reference classes rather than individual resources. They tell Puppet that it should create a relationship between this file resource and every resource in the referenced classes.
    Tip It is a best practice to establish relationships with an entire class, rather than with a resource contained within another class, because this allows the internal structure of the class to change without refactoring the resource declarations related to the class.
    For example, the
require
metaparameter tells Puppet that all the resources in the specified class must be processed prior to the current resource. In our example, the OpenSSH package must be installed before Puppet tries to manage the service’s configuration file.
    The
notify
metaparameter creates a notification relationship. If the current resource (the service’s configuration file) is changed, then Puppet should notify all the resources contained in the
ssh::service
class. In our current case, a “notification” will cause the service resources in the
ssh::service
class restart, ensuring that if we change a configuration file that the service will be restarted and running with the correct, updated configuration.
    Tip In Puppet 2.6.0, a shorthand method called “chaining” was introduced for specifying metaparameter relationships, such as
require
and
notify
. You can read about chaining at
http://docs.puppetlabs.com/guides/language_tutorial.html#chaining_resources
.
    So why specify the whole
ssh::service
class rather than just the
Service["sshd"]
resource? This is another piece of simple best practice that allows us to simplify maintaining our classes and the relationships between them. Imagine that, instead of a single package, we had twenty packages. If we didn’t require the class then we’d need to specify each individual package in our require statement, like this:
    require => [ Package["package1"], Package["package2"], Package["package3"] ],
    Note Adding [ ]s around a list creates a Puppet array. You can specify arrays as the values of variables and many attributes; for example, you can specify many items in a single resource:
package { [ "package1", "package2", "package3" ]: ensure => installed }
. In addition to arrays, Puppet also supports a hash syntax, which you can see at
http://docs.puppetlabs.com/guides/language_tutorial.html#hashe
s.
    We’d need to do that for every resource that required our packages, making our
require
statements cumbersome, potentially error prone, and most importantly requiring that every resource that requires packages be updated with any new package requirements.
    By requiring the whole class, it doesn’t matter how many packages we add to the
ssh::install
class – Puppet knows to install packages before managing configuration files, and we don’t have to update a lot of resources every time we make a change.
    Tip In our current example we could make use of arrays to extend the variables in the
ssh::params
class. For example, by changing
$ssh_package_name
to an array, we could specify multiple packages to be installed without needing to create another Package resource in the
ssh::install
class. Puppet is smart enough to know that if you specify a variable with a value of an array then it should expand the array, so changing the value of the
$ssh_package_name
variable to
[ openssh, package2, package3 ]
would result in the
ssh::install
class installing all three packages. This greatly simplifies the maintenance of our
ssh
module, as we only need to change values in one place to manage multiple