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
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.
See Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.
# touch /etc/puppet/manifests/site.pp
This file should always reside in the /etc/puppet/manifests directory on the master.
See Working With Puppet Resources and Resource Types in Oracle Solaris for more details.
# puppet apply -v --noop /etc/puppet/manifests/site.pp
Applies the configuration to the Puppet manifest on the master.
Indicates to use verbose mode.
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.
# 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.
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.