How to Write a Puppet Site Manifest

Language:

The following procedure describes how to write a Puppet site manifest to enforce configuration globally within your infrastructure.

Before You Begin

Prior to writing a Puppet site manifest, you will need to do the following:

Determine which resource types to declare in the manifest. You can obtain this information by using the puppet describe resource-type command, which displays all of the available attributes and parameters for the specified resource type.
```
# puppet describe resource-type
```
See Puppet Resource Type Descriptions.
Familiarize yourself with the basic syntax that you use to declare resources within a Puppet manifest. See About Declaring Puppet Resources. For more detailed information, go to Language: Resources.
Familiarize yourself with the syntax that you use to define specific Oracle Solaris system configuration within a Puppet manifest. See Using Puppet to Manage System Configuration in Oracle Solaris for examples.

Become an administrator who is assigned the Puppet Management rights profile or assume the root role.
See Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.
Create a site.pp file on the Puppet master.
```
# touch /etc/puppet/manifests/site.pp
```
This file should always reside in the /etc/puppet/manifests directory on the master.
Define the specified configuration within the Puppet site manifest (site.pp) and save your changes.
See Working With Puppet Resources and Resource Types in Oracle Solaris for more details.
Test the configuration changes that you made to the site.pp file before they are permanently applied.
```
# puppet apply -v --noop /etc/puppet/manifests/site.pp
```
apply

Applies the configuration to the Puppet manifest on the master.

–v

Indicates to use verbose mode.

–noop

Enables you to perform a dry run without actually applying your changes. Use this option for testing purposes.

The Puppet agent that is running on each node queries the master for configuration changes at regular intervals and then applies any required changes to the node.
Check the log file (/var/log/puppet/puppet-agent.log) on each node to verify that it retrieved the latest configuration changes.
(Optional) To manually apply the latest configuration changes, run the following command on the node:
```
# puppet agent -t
```
Specifying the –t (–-test) option enables verbose logging, which causes the agent daemon to remain in the foreground, exits if the master server's configuration is invalid (as in the case of a syntax error), then exits after running the configuration one time.

To display all of the available Puppet subcommands, use the /usr/sbin/puppet help agent command. See also the puppet (8) man page.

Example 2 Writing a Puppet Manifest

The following example shows how you would declare resources in Puppet site manifest. This example assumes that you have already created a site.pp file and that the file is stored in the correct directory on the Puppet master.

First, you would declare resources in the site.pp file. In this example, the file resource type is declared. For this resource type, two attributes are specified: ensure and content. These two attributes ensure that a custom-file.txt file exists in the root directory on the node and that the file includes the words, "Hello World".

file { '/custom-file.txt':
  ensure => 'present',
  content => "Hello World",
}

After saving the site.pp file, you can test the configuration's validity on the master as follows:

# puppet apply -v --noop /etc/puppet/manifests/site.pp
Notice: Compiled catalog for master in environment production in 0.16 seconds
Info: Applying configuration version '1400794990'
Notice: /Stage[main]/Main/File[/custom-file.txt]/ensure: current_value absent, should be present (noop)
Notice: Class[Main]: Would have triggered 'refresh' from 1 events
Notice: Stage[Main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.27 seconds

The –v option specifies to use verbose mode, and the –noop option ensures that no changes are actually made. Using the –noop option for testing purposes enables you to perform a dry run without actually applying the changes to the manifest.

The Puppet agent that is running on each node queries the master for configuration changes at regular intervals and then applies any new changes, as needed. You can check the node's log file (/var/log/puppet/puppet-agent.log) to verify that the node applied the latest changes:

# ls -la /custom-file.txt
-rw-------   1 root     root          16 Mar 22 21:50 /custom-file.txt
# cat /custom-file.txt
Hello World
# tail /var/log/puppet/puppet-agent.log
....
2016-03-22 21:50:17 +0000 /Stage[main]/Main/File[/custom-file.txt]/ensure (notice): created
2016-03-22 21:50:17 +0000 Puppet (notice): Finished catalog run in 0.21 seconds

The previous output indicates that the configuration is being enforced on the node. By default, agents poll the master for configuration changes at 30-minute intervals. You could also verify the configuration by checking whether the custom-file.txt file exists on the node.

Optionally, you would manually apply the configuration changes by running the following command on the node:

# puppet agent -t

For specific examples that show how to use Puppet to define Oracle Solaris system configuration, see Using Puppet to Manage System Configuration in Oracle Solaris.