Pro Puppet (14 page)

We can also specify a value called
default
.

This value is used if no other listed selection matches. If we don’t specify a
default
value and no selection matches then the
name
attribute would be set to a nil value.

As can you imagine, this requirement to select the appropriate value for a particular platform happens a lot. This means we could end up scattering a lot of very similar conditional statements across our Puppet code. That’s pretty messy; a best practice we recommend is to make this look a lot neater and more elegant by moving all your conditional checks to a separate class.

We usually call that class
module::params
, so in our current case it would be named
ssh::params
. Like before, we’re going to store that class in a separate file. Let’s create that file:

We can see that class in
Listing 2-3
.

You can see that inside our
ssh::params
class we’ve created another type of conditional, the
case
statement. Much like a selector, the case statement iterates over the value of a variable, here
$operatingsystem
. Unlike a selector, case statements allow us to specify a block of things to do if the value of the variable matches one of the cases. In our case we’re setting the value of a new variable we’ve created, called
$ssh_package_name
. You could do other things here, such as include a class or a resource, or perform some other function.

And finally, we need to include our new class in the
ssh
class:\

These includes tell Puppet that when you include the
ssh
module, you’re getting all of these classes.

FUNCTIONS

We’re going to come back to the
ssh::params
class and add more variables as we discover other elements of our OpenSSH configuration that are unique to particular platforms, but for the moment how does including this new class change our
Package["ssh"]
resource?

You can see our namespacing is useful for other things, here using variables from other classes. We can refer to a variable in another class by prefixing the variable name with the class it’s contained in, here
ssh::params
. In this case, rather than our messy conditional, the package name to be installed will use the value of the
$ssh::params::ssh_package_name
parameter. Our resource is now much neater, simpler and easier to read.

Now let’s move onto our next class,
ssh::config
, which we can see in
Listing 2-4
.

We know that the location of the sshd_config files will vary across different operating systems. Therefore, we’re going to have to add another conditional for the name and location of that file. Let’s go back to our
ssh::params
class from Example 2-3 and add a new variable:

We add the
$ssh_service_config
variable to each of the cases in our conditional and then update our file resource in the
ssh::config
class:

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.

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.

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:

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.