Pulling Strings With Puppet - James Turnbull [51]
Writing Custom Facts
After configuring Puppet to deliver our custom facts, we actually need to create some new facts. As we mentioned, our custom facts are snippets of Ruby code that call the Facter. add function to add new facts. In Listing 7-2, you can see a simple custom fact.
In Listing 7-2, our custom fact returns the value of the HOME environmental value as a fact called home, which in turn would be available in our manifests as the variable $home.
Let's break down Listing 7-2. The Facter.add function allows us to specify the name of our new fact. We then use the setcode block to specify the contents of our new fact, in our case using Ruby's built-in ENV variable to access an environmental variable. In Listing 7-3, we can see a custom fact that reads a file to return the value of the fact.
In Listing 7-3, we're returning the timezone of a Debian host. In Listing 7-3, we've also done two interesting things. First, we've specified a confine statement. This statement restricts the execution of the fact if a particular criteria is not met. This restriction is commonly implemented by taking advantage of the values of other facts. In this case, we've specified that the value of the operatingsystem fact should be Debian for the fact to be executed. We can also use the values of other facts, for example:
The previous confine is commonly used to limit the use of a particular fact to nodes with Linux-based kernels.
Second, we've used the readlines file method to read in the contents of the /etc/timezone file. The contents are returned as the fact timezone, which in turn would be available as the variable $timezone.
timezone => Australia/Melbourne
You can create more complex facts and even return more than one fact in your Ruby snippets as you can see in Listing 7-4.
In Listing 7-4, you can see a more complicated fact. This fact actually creates a series of facts, each fact taken from information collected from the /etc/networks file. This file, used on Debian hosts, associates network names with networks. Our snippet parses this file and adds a series of facts, one per each network in the file. So that if our file looked like
then three facts would be returned:
You can take a similar approach to commands, or files, or a variety of other sources.
Testing Your Facts
There is a simple process for testing your facts. We import our facts into Facter and use it to test them before making use of them in Puppet. To do this, we need to set up a testing environment. We create a directory structure to hold our test facts-we'll call ours lib/ruby/facter. We'll situate this structure beneath the root user's home directory. We then create an environmental variable, $RUBYLIB, that references this directory and will allow Facter to find our test facts.
We then copy our fact snippets into this new directory.
After this we can call Facter with the name of the fact we've just created. If the required output appears, your fact is working correctly. If your fact is not working correctly, an error message you can debug will be generated.
On the previous lines, we've tested our home fact and discovered it has returned the correct value.
Extending Puppet
When configuring your nodes, you are not limited to the resource types provided with Puppet. You can build your own resource types to manage additional configuration components and items. Custom resource types are developed in Ruby and like custom facts can be propagated by Puppet from your master to all of your clients.
Tip - Your best source of information about how to build your own types and providers are the existing types and providers that come with Puppet. Among them you can find examples of most types of configuration management. I recommend reviewing them before embarking on creating a particular type or provider.
Each resource type should consist of the type definition and any required providers. The type creates the model for what the type actually does. It specifies the attributes and features available to configure your component, sets