Puppet uses the following workflow to apply configuration to a system.

Satellite 6 uses Puppet in several ways:

These functions provide an easy way for users to control system configuration aspects of the application life cycle using Puppet.

If required, to find out the version of Puppet used in your Satellite environment, see the Red Hat Knowledgebase article Satellite 6 Component Versions.

The performance of Puppet in Satellite 6 is driven more by the Satellite and Capsule storage capacity, CPU performance, and available memory, than by application limitations. Therefore, testing of your hardware and configuration is the only way to be sure the performance is acceptable for your needs.

For Satellite 6.2, the maximum number of concurrent Puppet runs is approximately 320. This should improve significantly in Satellite 6.3 due to Puppet Server replacing the Apache Passenger module and Puppet master.

Importing many Puppet modules simultaneously can take a long time. For example, on a notebook with 8GB RAM and 4 cores, importing 2000 modules takes approximately 4 minutes.

The following performance brief in the Red Hat Knowledgebase provides examples of performance tests made for Satellite 6.2: Performance & Scale Tuning of Satellite 6.2 and Capsules. The performance of Satellite 6.3 is expected to be noticeably better than indicated in the performance brief for Satellite 6.2.

For information on recommended storage and hardware requirements, see Hardware Requirements in the Red Hat Satellite Installation Guide.

Before creating our module, we need to understand the components that create a Puppet module.

A Puppet development system is useful for creating and testing your own modules. It is recommended to use a new system with a Red Hat Enterprise Linux 6 or 7 subscription.

After installing the new system and registering your version of Red Hat Enterprise Linux, enable the Red Hat Satellite 6 Tools repository. For example, for Red Hat Enterprise Linux 7:

# subscription-manager repos --enable=rhel-7-server-satellite-tools-6.2-rpms

After enabling the repository, install the puppet package:

# yum install puppet

The first step in creating a new module is to change to the Puppet module directory and create a basic module structure. Either create this structure manually or use Puppet to create a boilerplate for your module:

# cd /etc/puppet/modules
# puppet module generate user_name-module_name

An interactive wizard appears and guides you through populating the module’s metadata.json file with metadata.

# puppet module generate user_name-mymodule
# mv user_name-mymodule mymodule

When the module generation process completes, the new modules contains some basic files, including a manifests directory. This directory already contains a manifest file called init.pp, which is the module’s main manifest file. View the file to see the empty class declaration for the module:

class mymodule {


}

The module also contains a tests directory containing a manifest also named init.pp. This test manifest contains a reference to the mymodule class within manifests/init.pp:

include mymodule

Puppet will use this test manifest to test our module.

We are now ready to add our system configuration to our module.

Our Puppet module will install the packages necessary to run an HTTP server. This requires a resource definition that defines configurations for the httpd package.

In the module’s manifests directory, create a new manifest file called httpd.pp:

# touch mymodule/manifests/httpd.pp

This manifest will contain all HTTP configuration for our module. For organizational purposes, we will keep this manifest separate from the init.pp manifest.

Add the following content to the new httpd.pp manifest:

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
}

This code defines a subclass of mymodule called httpd, then defines a package resource declaration for the httpd package. The ensure ⇒ installed attribute tells Puppet to check if the package is installed. If it is not installed, Puppet executes yum to install it.

We also need to include this subclass in our main manifest file. Edit the init.pp manifest:

class mymodule {
  include mymodule::httpd
}

It is now time to test the module. Run the following command:

# puppet apply mymodule/tests/init.pp --noop

The puppet apply command applies the configuration in the manifest to your system. We use the test init.pp manifest, which refers to the main init.pp manifest. The --noop performs a dry run of the configuration, which shows only the output but does not actually apply the configuration. The output should resemble the following:

Notice: Compiled catalog for puppet.example.com in environment production in 0.59 seconds
Notice: /Stage[main]/Mymodule::Httpd/Package[httpd]/ensure: current_value absent, should be present (noop)
Notice: Class[Mymodule::Httpd]: Would have triggered 'refresh' from 1 events
Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.67 seconds

The highlighted line is the result of the ensure ⇒ installed attribute. The current_value absent means that Puppet has detected the httpd package is not installed. Without the --noop option, Puppet would install the httpd package.

After installing the httpd package, we start the service using another resource declaration: service.

Edit the httpd.pp manifest and add the highlighted lines:

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
}

This achieves a couple of things:

Run the puppet apply command again to test the changes to our module:

# puppet apply mymodule/tests/init.pp --noop
Notice: Compiled catalog for puppet.example.com in environment production in 0.56 seconds
Notice: /Stage[main]/Mymodule::Httpd/Package[httpd]/ensure: current_value absent, should be present (noop)
Notice: /Stage[main]/Mymodule::Httpd/Service[httpd]/ensure: current_value stopped, should be running (noop)
Notice: Class[Mymodule::Httpd]: Would have triggered 'refresh' from 2 events
Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.41 seconds

The highlighted line is the result of our new resource definition for the httpd service.

The HTTP Server is now installed and enabled. The next step is to provide some configuration. The HTTP server already provides some default configuration in /etc/httpd/conf/httpd.conf, which provides a web server on port 80. We will add some additional configuration to provide an additional web server on a user-specified port.

We use a template file to store our configuration content because the user-defined port requires variable input. In our module, create a directory called templates and add a file called myserver.conf.erb in the new directory. Add the following contents to the file:

Listen <%= @httpd_port %>
NameVirtualHost *:<%= @httpd_port %>
<VirtualHost *:<%= @httpd_port %>>
  DocumentRoot /var/www/myserver/
  ServerName <%= @fqdn %>
  <Directory "/var/www/myserver/">
    Options All Indexes FollowSymLinks
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

This template follows the standard syntax for Apache web server configuration. The only difference is the inclusion of Ruby escape characters to inject variables from our module. For example, httpd_port, which we use to specify the web server port.

Notice also the inclusion of fqdn, which is a variable that stores the fully qualified domain name of the system. This is known as a system fact. System facts are collected from each system prior to generating each respective system’s Puppet catalog. Puppet uses the facter command to gather these system facts and you can also run facter to view a list of these facts.

Edit the httpd.pp manifest and add the highlighted lines:

class mymodule::httpd {
  package { 'httpd':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    require => Package["httpd"],
  }
  file {'/etc/httpd/conf.d/myserver.conf':
  notify => Service["httpd"],
    ensure => file,
    require => Package["httpd"],
    content => template("mymodule/myserver.conf.erb"),
  }
  file { "/var/www/myserver":
    ensure => "directory",
  }
}

This achieves the following:

We also need to include the httpd_port parameter in our main manifest file. Edit the init.pp manifest and add the following text shown in bold:

class mymodule (
  $httpd_port = 8120
) {
  include mymodule::httpd
}

This sets the httpd_port parameter to a default value of 8120. You can override this value with the Satellite Server.

Run the puppet apply command again to test the changes to our module:

# puppet apply mymodule/tests/init.pp --noop
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults
Notice: Compiled catalog for puppet.example.com in environment production in 0.84 seconds
Notice: /Stage[main]/Mymodule::Httpd/File[/var/www/myserver]/ensure: current_value absent, should be directory (noop)
Notice: /Stage[main]/Mymodule::Httpd/Package[httpd]/ensure: current_value absent, should be present (noop)
Notice: /Stage[main]/Mymodule::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensure: current_value absent, should be file (noop)
Notice: /Stage[main]/Mymodule::Httpd/Service[httpd]/ensure: current_value stopped, should be running (noop)
Notice: Class[Mymodule::Httpd]: Would have triggered 'refresh' from 4 events
Notice: Stage[main]: Would have triggered 'refresh' from 1 events
Notice: Finished catalog run in 0.51 seconds

The highlighted lines show the creation of the configuration file and our web server directory.

The web server requires an open port so people can access the pages hosted on our web server. The open problem is that different versions of Red Hat Enterprise Linux uses different methods for controlling the firewall. For Red Hat Enterprise Linux 6 and below, we use iptables. For Red Hat Enterprise Linux 7, we use firewalld.

This decision is something Puppet handles using conditional logic and system facts. For this step, we add a statement to check the operating system and run the appropriate firewall commands.

Add the following code inside your mymodule::httpd class:

  if versioncmp($::operatingsystemmajrelease, '6') <= 0 {
    exec { 'iptables':
      command => "iptables -I INPUT 1 -p tcp -m multiport --ports ${httpd_port} -m comment --comment 'Custom HTTP Web Host' -j ACCEPT &amp;&amp; iptables-save > /etc/sysconfig/iptables",
      path => "/sbin",
      refreshonly => true,
      subscribe => Package['httpd'],
    }
    service { 'iptables':
      ensure => running,
      enable => true,
      hasrestart => true,
      subscribe => Exec['iptables'],
    }
  }
  elsif $operatingsystemmajrelease == 7 {
    exec { 'firewall-cmd':
      command => "firewall-cmd --zone=public --add-port=${httpd_port}/tcp --permanent",
      path => "/usr/bin/",
      refreshonly => true,
      subscribe => Package['httpd'],
    }
    service { 'firewalld':
      ensure => running,
      enable => true,
      hasrestart => true,
      subscribe => Exec['firewall-cmd'],
    }
  }

This code performs the following:

Run the puppet apply command again to test the changes to our module. The following example is a test of Red Hat Enterprise Linux 6:

# puppet apply mymodule/tests/init.pp --noop
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults
Notice: Compiled catalog for puppet.example.com in environment production in 0.82 seconds
Notice: /Stage[main]/Mymodule::Httpd/Exec[iptables]/returns: current_value notrun, should be 0 (noop)
Notice: /Stage[main]/Mymodule::Httpd/Service[iptables]: Would have triggered 'refresh' from 1 events
...

The highlighted lines show the execution of the firewall rule creation and the subsequent service refresh as a result of the subscribe attribute.

SELinux restricts non-standard access to the HTTP server by default. If we define a custom port, we need to add configuration that allows SELinux to grant access.

Puppet contains resource types to manage some SELinux functions, such as Booleans and modules. However, we need to execute the semanage command to manage port settings. This tool is a part of the policycoreutils-python package, which is not installed on Red Hat Enterprise Linux systems by default.

Add the following code inside your mymodule::httpd class:

  exec { 'semanage-port':
    command => "semanage port -a -t http_port_t -p tcp ${httpd_port}",
    path => "/usr/sbin",
    require => Package['policycoreutils-python'],
    before => Service['httpd'],
    subscribe => Package['httpd'],
    refreshonly => true,
  }
  package { 'policycoreutils-python':
    ensure => installed,
  }

This code performs the following:

Run the puppet apply command again to test the changes to our module.

# puppet apply mymodule/tests/init.pp --noop
...
Notice: /Stage[main]/Mymodule::Httpd/Package[policycoreutils-python]/ensure: current_value absent, should be present (noop)
...
Notice: /Stage[main]/Mymodule::Httpd/Exec[semanage-port]/returns: current_value notrun, should be 0 (noop)
...
Notice: /Stage[main]/Mymodule::Httpd/Service[httpd]/ensure: current_value stopped, should be running (noop)
...

Puppet installs policycoreutils-python first, then configures port access before starting the httpd service.

The HTTP server configuration is now complete. This provides a platform for installing a web-based application, which Puppet can also configure. For this example, however, we will only copy over a simple index web page to our web server.

Create a file named index.html in the files directory. Add the following content to this file:

<html>
  <head>
    <title>Congratulations</title>
  <head>
  <body>
    <h1>Congratulations</h1>
    <p>Your puppet module has correctly applied your configuration.</p>
  </body>
</html>

Create a manifest named app.pp in the manifests directory. Add the following content to this file:

class mymodule::app {
  file { "/var/www/myserver/index.html":
    ensure => file,
    mode   => '755',
    owner  => root,
    group  => root,
    source => "puppet:///modules/mymodule/index.html",
    require => Class["mymodule::httpd"],
  }
}

This new class contains a single resource declaration. This declaration copies a file from the module’s file directory from the Puppet Server to the system and sets its permissions. Additionally, the require attribute ensures the mymodule::httpd class completes the configuration successfully before we apply mymodule::app.

Finally, include this new manifest in our main init.pp manifest:

class mymodule (
  $httpd_port = 8120
) {
  include mymodule::httpd
  include mymodule::app
}

Run the puppet apply command again to test the changes to our module. The output should resemble the following:

# puppet apply mymodule/tests/init.pp --noop
Warning: Config file /etc/puppet/hiera.yaml not found, using Hiera defaults
Notice: Compiled catalog for puppet.example.com in environment production in 0.66 seconds
Notice: /Stage[main]/Mymodule::Httpd/Exec[iptables]/returns: current_value notrun, should be 0 (noop)
Notice: /Stage[main]/Mymodule::Httpd/Package[policycoreutils-python]/ensure: current_value absent, should be present (noop)
Notice: /Stage[main]/Mymodule::Httpd/Service[iptables]: Would have triggered 'refresh' from 1 events
Notice: /Stage[main]/Mymodule::Httpd/File[/var/www/myserver]/ensure: current_value absent, should be directory (noop)
Notice: /Stage[main]/Mymodule::Httpd/Package[httpd]/ensure: current_value absent, should be present (noop)
Notice: /Stage[main]/Mymodule::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensure: current_value absent, should be file (noop)
Notice: /Stage[main]/Mymodule::Httpd/Exec[semanage-port]/returns: current_value notrun, should be 0 (noop)
Notice: /Stage[main]/Mymodule::Httpd/Service[httpd]/ensure: current_value stopped, should be running (noop)
Notice: Class[Mymodule::Httpd]: Would have triggered 'refresh' from 8 events
Notice: /Stage[main]/Mymodule::App/File[/var/www/myserver/index.html]/ensure: current_value absent, should be file (noop)
Notice: Class[Mymodule::App]: Would have triggered 'refresh' from 1 events
Notice: Stage[main]: Would have triggered 'refresh' from 2 events
Notice: Finished catalog run in 0.74 seconds

The highlighted line shows that the index.html file would be copied to the web server.

Our module is ready for use. To export the module into an archive for Red Hat Satellite 6 to use, enter the following command:

# puppet module build mymodule

This creates an archive file at mymodule/pkg/mymodule-0.1.0.tar.gz, which contains the contents of our mymodule directory. We upload this module to our Red Hat Satellite 6 Server to provision our own HTTP server.

If any changes are required, edit the files within the modules directories and rebuild the module using the puppet module build command. The changes will only be reflected in Satellite if the module version is increased. To increase the version number, edit the /etc/puppet/modules/mymodule/metadata.json file and then rebuild the module. Upload and publish the new version in Satellite Server.

The first step to adding our Puppet module is to create a custom Product.

Creating a Custom Product

Satellite now has a new Product called MyProduct.

The next procedure creates a Puppet repository in our custom Product.

Creating a Custom Puppet Repository

The custom Product now contains a repository to store our Puppet modules.

Now we upload our mymodule module to the newly created repository, which adds it to our custom Product.

You can upload more modules to this repository. For our example, we only need to upload the mymodule module.

Our Puppet module is now a part of your Red Hat Satellite 6 environment. Next we publish the module as part of a content view.

If you aim to remove redundant modules from custom repositories in the future, use the Manage Puppet Modules feature.

Satellite removes the chosen modules from your repository.

As an alternative to manually uploading modules, Red Hat Satellite 6 includes a utility called pulp-puppet-module-builder. This tool checks out repositories containing a set of modules, builds the modules, and publishes them in a structure for Satellite 6 to synchronize. This provides an efficient way to manage module development in Git and include them in the Satellite 6 workflow.

The use of Modulefile is deprecated since Puppet version 3. If you build any Puppet module containing a Modulefile when using Puppet version 3.X, a deprecation warning is printed. Satellite 6.3 will include Puppet version 4 which will ignore the Modulefile data. The data in the Modulefile must be moved to a metadata.json file. You can convert a module to use a metadata.json file as follows:

One common method is to run the utility on the Satellite 6 Server itself and publish to a local directory.

Publishing a Git Repository to a Local Directory

The same procedure applies to publishing modules to an HTTP server.

Publishing Git Repository to a Web Server

In the Satellite 6 web UI, create a new repository with the URL set to the location of your published modules.

Creating a Repository for Puppet Modules from Git

The Puppet modules in the Git repository are now included in your Satellite 6 Server.

The final step to getting our Puppet module ready for consumption is to publish it as part of a content view. You can add this module to an existing view but for our example we will create a new view.

Publishing a Content View

Our content view is now published. As a part of the content view creation, Red Hat Satellite 6 creates a new Puppet environment for use in the provisioning process. This Puppet environment contains our module. You can view this new Puppet environment on the Configure > Environments page.

A Puppet environment is defined as an isolated set of Puppet agent nodes that can be associated with a specific set of Puppet modules. In Satellite 6 context we can think of a Puppet environment as a set of Hosts running the Puppet agent that are associated with a specific set of Puppet modules. For example, nodes that are associated with environment Production only have access to the modules that are in environment Production.

Puppet environments are used to separate Puppet modules from different types of Host. A typical use is to enable changes to a module to be tested in one environment before being pushed to another. A Puppet module can contain facts and functions as well as one or more Puppet Classes that you can assign to Hosts. Modules are part of an environment, Puppet Classes are only part of an environment because they are part of a module.

In Red Hat Satellite, a Puppet environment will be created automatically for a Content View if the CV has a Puppet module. The automatically created Puppet environment name includes the organization label, the life-cycle environment, the Content View name, and the content view ID. For example, KT_Example_Org_Library_RHEL6Server_3.

Creating Puppet Environments within Red Hat Satellite

Navigate to Configure > Environments and click New Puppet Environment. Give the new environment a name and click Submit to save the changes. Note that if the environment does not exist on the Puppet master and you subsequently run an import, Satellite will prompt for the environment to be deleted.

Importing Puppet Environments to Red Hat Satellite

Satellite can detect all the environments and Puppet modules contained on a Puppet master, and import them automatically. To do this, go to Configure > Environments and click on the "Import from" button. The button name will be include the FQDN of the internal or external Capsule. Satellite will scan the Puppet master via the Capsule, and display a list of the detected changes. Select the changes you want to apply and select Update to apply the changes.

Note that the Capsule will only detect environments that contain one or more Puppet Classes, so ensure that at least one Puppet module containing a class has been deployed to the Puppet master.

Assigning a Puppet Environment to a Host

Navigate to Hosts > All Hosts, select a host by name from the Hosts list and then select Edit. On the Host tab you can select a Puppet Environment for the host. Selecting an environment will filter the classes on the Puppet Classes tab to help distinguish the classes in the selected environment.

You can mass-assign an environment to a group of hosts. Select the check boxes of the required hosts in the Hosts list, and then select Change Environment from the Select Action drop-down menu at the top of the page.

Assigning Puppet Environments to Host Groups

When creating a Host Group, the environment field is pre-populated by the environment that was automatically created by the associated Content View, if any.

By default, a user creating a new host and selecting the Host Group will automatically have the environment pre-selected. The user can change the environment of the new host.

Some module classes contain complex parameters, called Smart Class Parameters, that define a value for a key just as a simple parameter does, but allow conditional arguments, validation, and overrides for specific object types. Satellite 6 has the ability to import these parameterized classes and allow modification of such smart parameters. For more information on the types of parameters in Puppet, see Parameters in the Red Hat Satellite Host Configuration Guide.

For example, mymodule contains a parameter for the HTTP port of our web server. This parameter, httpd_port, is set to a default of 8120. However, a situation might occur where we need to use a different port for a provisioned system. Satellite 6 can override the httpd_port parameter during configuration. This provides an easy way to change the HTTP port on our web server.

This procedure requires the mymodule module to be uploaded to a Product and added to a Content View. This is because we need to edit the classes in the resulting Puppet environment. Alternatively, you can download and install another module as described in Chapter 3, Adding Puppet Modules to Red Hat Satellite 6.

We now have an override value for the Smart Class Parameter httpd_port.

Smart Variables are a tool for providing global parameters to the Puppet master for use with Puppet Classes that do not contain Smart Class Parameters. The same Smart Matcher rules are used for both Smart Variables and Smart Class Parameters.

Before Smart Class Parameters were introduced, users who wanted to override a parameter where asked to rewrite their Puppet code to use a global parameter. For example:

class example1 {
  file { '/tmp/foo': content => $global_var }
}

For the above example, $global_var is set in the Smart Variables section of the web UI and the value is associated with the "example1" class. Although it is recommend to precede global variables with :: to restrict Puppet to search the global scope, their absence does not mean a variable is not a global variable.

With the introduction of Smart Class Parameters, the following form could be used:

class example2($var="default") {
  file { '/tmp/foo': content => $var }
}

For the above example, $var is set in the Smart Class Parameters section of the web UI and the value is associated with the "example2" class. If you see a variable defined in the class header, as in the above class example2($var="default"), then you can be sure that $var is a class parameter and you should use the Smart Class Parameter function to override the variable.

As demonstrated, Smart Variables require custom-designed modules using global-namespace parameters, rather than standard modules from the Puppet community, and the result is the same: text placed in '/tmp/foo' in the examples above. Consequently, there is no longer a reason to use Smart Variables except to support legacy modules.

Although Smart Variables are global variables, they are associated with a Puppet class and will only be sent to a host that has that specific Puppet Class assigned in Satellite. You can create a Smart Variable with any name, no validation is done in Satellite, but unless the associated Puppet module applied has a matching variable in its code, the Smart Variable will not be used.

Satellite adds the variable you create in Satellite to the Host YAML file. This file can be viewed in the web UI by navigating to Hosts > All Hosts, selecting the name of the host, and then clicking on the YAML button. Satellite sends the Host YAML file to the external node classifier (ENC), a function included with the Puppet master. When the Puppet master queries the ENC about a host, the ENC returns a YAML document describing the state of the host. This YAML document is based on data taken from Puppet manifests, but is subject to Smart Class Parameter overrides and any Smart Variables.

class anothermodule {
   file { '/tmp/motd':
     ensure  => file,
     content => $::content_for_motd,
  }
}

This example will supply a value for the $::content_for_motd parameter.

Red Hat Satellite 6 controls the main configuration for the Puppet master on all Satellite Capsules. No additional configuration is required and it is recommended to avoid manually modify these configuration files. For example, the main /etc/puppet/puppet.conf configuration file contains the following [master] section:

[master]
    autosign       = $confdir/autosign.conf { mode = 664 }
    reports        = foreman
    external_nodes = /etc/puppet/node.rb
    node_terminus  = exec
    ca             = true
    ssldir         = /var/lib/puppet/ssl
    certname       = sat6.example.com
    strict_variables = false

    manifest       = /etc/puppet/environments/$environment/manifests/site.pp
    modulepath     = /etc/puppet/environments/$environment/modules
    config_version =

This section contains variables (such as $environment) that Satellite 6 uses to create configuration for different environments.

Some Puppet configuration options appear in the Satellite 6 web UI. Navigate to Administer > Settings and choose the Puppet subtab. This page lists a set of Puppet configuration options and a description of each.

As part of the provisioning process, Satellite 6 installs Puppet to the system. This process also installs the /etc/puppet/puppet.conf file that configures Puppet as an agent of the Puppet master on a chosen Capsule. This configuration file is stored as a provisioning template snippet in Satellite 6. Navigate to Hosts > Provisioning templates and click the puppet.conf snippet to view it.

The default puppet.conf snippet contains the following agent configuration:

[agent]
pluginsync      = true
report          = true
ignoreschedules = true
daemon          = false
ca_server       = <%= @host.puppet_ca_server %>
certname        = <%= @host.certname %>
environment     = <%= @host.environment %>
server          = <%= @host.puppetmaster %>

This snippet contains some template variables, which are:

We first define a new host’s Puppet configuration using the following procedure. This procedure uses the uploaded mymodule as an example.

Applying Configuration on Clients During Provisioning

The provisioning process begins. Satellite 6 installs the required configuration tools as part of the Satellite Kickstart Default provisioning template. This provisioning template contains the following:

<% if puppet_enabled %>
# and add the puppet package
yum -t -y -e 0 install puppet

echo "Configuring puppet"
cat > /etc/puppet/puppet.conf << EOF
<%= snippet 'puppet.conf' %>
EOF

# Setup puppet to run on system reboot
/sbin/chkconfig --level 345 puppet on

/usr/bin/puppet agent --config /etc/puppet/puppet.conf -o --tags no_such_tag <%= @host.puppetmaster.blank? ? '' : "--server #{@host.puppetmaster}" %> --no-daemonize
<% end -%>

This section performs the following:

After the provisioning and configuration processes complete on the new host, access the host at the user-defined port in your web browser. For example, navigate to http://newhost.example.com:8120/. The following message should appear in your browser:

Congratulations

Your puppet module has correctly applied your configuration.

You might aim to have Puppet configuration applied to an existing client not provisioned through Red Hat Satellite 6. In this situation, install and configure Puppet on the existing client after registering it to Red Hat Satellite 6.

Register your existing system to Red Hat Satellite 6. For information on registering existing hosts, see Registering a Host in the Red Hat Satellite Host Configuration Guide.

To Install and Enable the Puppet Agent:

Configuring the Puppet Agent