Show description

Building the module Now that we have the framework, we'll build our first module. Much like the preceding code, we'll go through it section by section covering what each resource does. The manifest we're building will be very similar to the one we used to provision the Puppet Master for the use of. pp file to create the module's main manifest. This manifest is the main unit of the Puppet code, which is invoked when we include the module. As we go through each of the sections, we'll go through what they do.

There is some evidence that this will be deprecated in Puppet 4; however, it is currently still available as this book is being written. Finally, one can use noop to monitor changes. In this mode, Puppet will report on any changes to a resource from its baseline; however, it will not make an effort to change them back. Noop can be used in a variety of fashions and will be covered at the end of the chapter. The following table summarizes the available change tracking options: Declared resources Audit Noop Requires definition of the baseline of a resource Yes No Yes Corrects the resource if it becomes out of compliance Yes No No (although you can run without noop to do so) Allows you to specify what parameters are monitored No, only what's in the Yes baseline is monitored No, see declared resources Supported in later Puppet versions Yes Yes No We'll cover the audit and noop methodologies later in the section.

Puppet contains a special type called resources to manage this. The resources type supports relatively few parameters, which are as follows: Parameter name Description purge A true/false value indicating whether to purge unmanaged resources unless_system_ user unless_uid A user-specific flag indicating to skip the system users The resource type to manage A user-specific flag indicating to skip the given uid values The resources type also accepts meta-parameters. This means we can manage users, for instance, with purge and noop as true.