Red Hat Satellite 6.

1
Puppet Guide

A guide to building your own Puppet module and importing it

into Satellite 6
Edition 1

Red Hat Satellite Documentation Team

Red Hat Satellite 6.1 Puppet Guide

A guide to building your own Puppet module and importing it

into Satellite 6
Edition 1
Red Hat Satellite Documentation Team
Red Hat Customer Content Services

Legal No tice
Copyright 2015 Red Hat.
This document is licensed by Red Hat under the Creative Commons AttributionShareAlike 3.0 Unported License. If you distribute this document, or a modified version
of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If
the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees
not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable
law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora,
the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United
States and other countries.
Linux is the registered trademark of Linus Torvalds in the United States and other
countries.
Java is a registered trademark of Oracle and/or its affiliates.
XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the
United States and/or other countries.
MySQL is a registered trademark of MySQL AB in the United States, the European
Union and other countries.
Node.js is an official trademark of Joyent. Red Hat Software Collections is not
formally related to or endorsed by the official Joyent Node.js open source or
commercial project.
The OpenStack Word Mark and OpenStack Logo are either registered
trademarks/service marks or trademarks/service marks of the OpenStack
Foundation, in the United States and other countries and are used with the
OpenStack Foundation's permission. We are not affiliated with, endorsed or
sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

Abstract
Puppet is a system configuration tool used in Red Hat Satellite 6. This book runs
through the creation of a basic Puppet Module and how to use this module in your
Red Hat Satellite 6 infrastructure.

T able o f Co nt e nt s

T able o f Co ntents

. .hapt
C
. . . .e.r. 1.
. .O
. .ve
. .r.vie
. .w
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2. . . . . . . . .
1 .1. Defining the P uppet Workflow
2
1 .2. Using P uppet on Satellite 6
2

. .hapt
C
. . . .e.r. 2.
. . Building
. . . . . . . .Puppe
. . . . . .t.Mo
. . .dule
. . . .s.f.r.o.m
. .Sc
. .r.at
. .c.h. . . . . . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . . . .
2.1. Exam ining the Anatom y of a P uppet Module
3
2.2. Setting up a P uppet Developm ent System
4
2.3. Generating a New Module Boilerplate
4
2.4. Installing a HTTP Server
5
2.5. Running the HTTP Server
6
2.6. C onfiguring the HTTP Server
7
2.7. C onfiguring the Firewall
9
2.8. C onfiguring SELinux
10
2.9. C opying a HTML file to the Web Host
2.10. Finalizing the Module

11
13

. .hapt
C
. . . .e.r. 3.
. . Adding
. . . . . . .Puppe
. . . . . .t .Mo
. . dule
....s
. .t.o. Re
. . .d. Hat
. . . .Sat
. . .e.llit
..e
. .6. . . . . . . . . . . . . . . . . . . . . .14
..........
3 .1. C reating a C ustom P roduct
14
3 .2. C reating a P uppet Repository in a C ustom P roduct
14
3 .3. Uploading a P uppet Module to a Repository
15
3 .4. Rem oving a P uppet Module from a Repository
15
3 .5. Adding P uppet Modules from a Git Repository
15
3 .6. P ublishing a C ontent View
17
3 .7. C onfiguring Sm art Variables from P uppet C lasses
18

. .hapt
C
. . . .e.r. 4. .. Clie
. . . .nt
. . and
. . . .Se
. . r.ve
. . r. Se
. . .t.t ings
. . . . .f .o.r.Co
. . nf
. . igur
. . . .at
. .io
. .n. Manage
. . . . . . .me
. . .nt
. . . . . . . . . . .21
..........
4 .1. C onfiguring P uppet on the Red Hat Satellite Server
21
4 .2. C onfiguring P uppet agent on P rovisioned System s
21

. .hapt
C
. . . .e.r. 5.
. . Applying
. . . . . . . . Co
. . .nf
. .igur
. . . at
. . io
. .n. .o.n. Clie
. . . .nt
. .s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
..........
5.1. Applying C onfiguration on C lients During P rovisioning
23
5.2. Applying C onfiguration to Existing C lients
24

. .hapt
C
. . . .e.r. 6. .. Re
. . .vie
. . wing
. . . . .Puppe
. . . . . .t .Re
. . po
. . r. t. s. .in
. .Re
. .d. .Hat
. . . Sat
. . . e. llit
. . .e. 6
. . . . . . . . . . . . . . . . . . . .27
..........

. .ppe
A
. . .ndix
. . . . A.
. . Re
. . .vis
. . io
. .n. His
. . . t. o. r. y. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
..........

Puppe t Guide

Chapt er 1. Overview
Puppe t is a tool for applying and managing s ys te m configurations . Puppe t colle cts s ys te m
information, or facts , and us e s this information to cre ate a cus tomiz e d s ys te m
configuration us ing a s e t of module s . The s e module s contain parame te rs , conditional
argume nts , actions , and te mplate s . Puppe t is us e d as e ithe r a local s ys te m command line
tool or in a clie nt-s e rve r re lations hip whe re the s e rve r acts as the Puppe t mas te r and
applie s configuration to multiple clie nt s ys te ms us ing a Puppe t age nt. This provide s a way
to automatically configure ne wly provis ione d s ys te ms , e ithe r individually or
s imultane ous ly to cre ate a s pe cific infras tructure .

1.1. Defining t he Puppet Workflow

Puppe t us e s the following workflow to apply configuration to a s ys te m.
1. Colle ct facts about e ach s ys te m. The s e facts can include hardware , ope rating
s ys te ms , package ve rs ions , and othe r information. The Puppe t age nt on e ach
s ys te m colle cts this information and s e nds it to the Puppe t mas te r.
2. The Puppe t mas te r ge ne rate s a cus tom configuration for e ach s ys te m and s e nds it
to the Puppe t age nt. This cus tom configuration is calle d a catalog.
3. The Puppe t age nt applie s the configuration to the s ys te m.
4. The Puppe t age nt s e nds a re port back to the Puppe t mas te r that indicate s the
change s applie d and if any change s we re uns ucce s s ful.
5. Third-party applications can colle ct the s e re ports us ing Puppe t's API.

1.2. Using Puppet on Sat ellit e 6

Sate llite 6 us e s Puppe t in s e ve ral ways :
Sate llite 6 imports Puppe t module s us e d to de fine the s ys te m configuration. This
include s control ove r module ve rs ions and the ir e nvironme nts .
Sate llite 6 imports s e ts of parame te rs , als o known as Puppe t clas s parame te rs , from
Puppe t module s . Us e rs can acce pt the de fault value s from Puppe t clas s e s or provide
the ir own at a global or s ys te m-s pe cific le ve l.
Sate llite 6 trigge rs the e xe cution of Puppe t be twe e n the mas te r and the re s pe ctive
age nts on e ach s ys te m. Puppe t runs can occur e ithe r:
Automatically, s uch as afte r the provis ioning proce s s comple te s or as a dae mon that
che cks and manage s the machine 's configuration ove r its life cycle .
Manually, s uch as ne e ding to trigge r an imme diate Puppe t run.
Sate llite 6 colle cts re ports from Puppe t afte r the configuration workflow comple te s . This
he lps with auditing and archiving s ys te m configuration ove r long te rm pe riods .
The s e functions provide an e as y way for us e rs to control s ys te m configuration as pe cts of
the application life cycle us ing Puppe t.

C hapt e r 2. Building Puppe t Mo dule s f r o m Sc r at c h

Chapt er 2. Building Puppet Modules from Scrat ch

This chapte r e xplore s how to build and te s t your own Puppe t module s . This include s a
bas ic tutorial on cre ating a Puppe t module that de ploys a s imple we b s e rve r configuration.

2.1. Examining t he Anat omy of a Puppet Module

Be fore cre ating our module , we ne e d to unde rs tand the compone nts that cre ate a Puppe t
module .
Manif est s
Manife s ts are file s that contain code to de fine a s e t of re s ource and the ir
attribute s . A re s ource is any configurable part of a s ys te m. Example s of
re s ource s include package s , s e rvice s , file s , us e rs and groups , SELinux
configuration, SSH ke y authe ntication, cron jobs , and more . A manife s t de fine s
e ach re quire d re s ource us ing a s e t of ke y-value pairs for the ir attribute s . For
e xample :
package { 'httpd':
ensure => installed,
}
This de claration che cks if the httpd package is ins talle d. If not, the manife s t
e xe cute s yum and ins talls it.
Manife s ts are locate d in the manifest dire ctory of a module .
Puppe t module s als o us e a test dire ctory for te s t manife s ts . The s e manife s ts
are us e d to te s t ce rtain clas s e s containe d in your official manife s ts .
St at ic Files
Module s can contain s tatic file s that Puppe t can copy to ce rtain locations on your
s ys te m. The s e locations , and othe r attribute s s uch as pe rmis s ions , are de fine d
through file re s ource de clarations in manife s ts .
Static file s are locate d in the files dire ctory of a module .
T emplat es
Some time s configuration file s re quire cus tom conte nt. In this s ituation, us e rs
would cre ate a te mplate ins te ad of a s tatic file . Like s tatic file s , te mplate s are
de fine d in manife s ts and copie d to locations on a s ys te m. The diffe re nce is that
te mplate s allow Ruby e xpre s s ions to de fine cus tomiz e d conte nt and variable
input. For e xample , if you wante d to configure ht t pd with a cus tomiz able port
the n the te mplate for the configuration file would include :
Listen <%= @httpd_port %>
The httpd_port variable in this cas e is de fine d in the manife s t that re fe re nce s
this te mplate .
Te mplate s are locate d in the templates dire ctory of a module .
P lugins

Puppe t Guide

Plugins allow for as pe cts that e xte nd be yond the core functionality of Puppe t. For
e xample , you can us e plugins to de fine cus tom facts , cus tom re s ource s , or ne w
functions . For e xample , a databas e adminis trator might ne e d a re s ource type for
Pos tgre SQL databas e s . This could he lp the databas e adminis trator populate
Pos tgre SQL with a s e t of ne w databas e s afte r ins talling Pos tgre SQL. As a re s ult,
the databas e adminis trator ne e d only cre ate a Puppe t manife s t that e ns ure s
Pos tgre SQL ins talls and the databas e s are cre ate d afte rwards .
Plugins are locate d in the lib dire ctory of a module . This include s a s e t of
s ubdire ctorie s de pe nding on the plugin type . For e xample :
/lib/facter - Location for cus tom facts .
/lib/puppet/type - Location for cus tom re s ource type de finitions , which
outline the ke y-value pairs for attribute s .
/lib/puppet/provider - Location for cus tom re s ource provide rs , which are
us e d in conjunction with re s ource type de finitions to control re s ource s .
/lib/puppet/parser/functions - Location for cus tom functions .

2.2. Set t ing up a Puppet Development Syst em

A Puppe t de ve lopme nt s ys te m is us e ful for cre ating and te s ting your own module s . It is
re comme nde d to us e a ne w s ys te m with a Re d Hat Ente rpris e Linux 6 or 7 s ubs cription.
Afte r ins talling the ne w s ys te m and re gis te ring your ve rs ion of Re d Hat Ente rpris e Linux,
e nable the Re d Hat Sate llite 6 Tools re pos itory. For e xample , for Re d Hat Ente rpris e Linux
7:
# subscription-manager repos --enable=rhel-7-server-satellite-tools-6.1rpms
Afte r e nabling the re pos itory, ins tall the puppet package :
# yum install puppet

2.3. Generat ing a New Module Boilerplat e

The firs t s te p in cre ating a ne w module is to change to the Puppe t module dire ctory and
cre ate a bas ic module s tructure . Eithe r cre ate this s tructure manually or us e Puppe t to
cre ate a boile rplate for your module :
# cd /etc/puppet/modules
# puppet module generate [module-name]
An inte ractive wiz ard appe ars and guide s you through populating the module 's
metadata.json file with me tadata.

C hapt e r 2. Building Puppe t Mo dule s f r o m Sc r at c h

Impo rtant
The puppet module generate command re quire s module-name take the format of
[username]-[module] to comply with Puppe t Forge s pe cifications . Howe ve r, to te s t
our tutorial module and us e it with Sate llite 6 we ne e d to re name the module
dire ctory without the [username]. For e xample , for dmacpher-mymodule you would
run:
# puppet module generate dmacpher-mymodule
# mv dmacpher-mymodule mymodule

Whe n the module ge ne ration proce s s comple te s , the ne w module s contains s ome bas ic
file s , including a manifests dire ctory. This dire ctory alre ady contains a manife s t file calle d
init.pp, which is the module 's main manife s t file . Vie w the file to s e e the e mpty clas s
de claration for the module :
class mymodule {

}
The module als o contains a tests dire ctory containing a manife s t als o name d init.pp.
This te s t manife s t contains a re fe re nce to the mymodule clas s within manifests/init.pp:
include mymodule
Puppe t will us e this te s t manife s t to te s t our module .
We are now re ady to add our s ys te m configuration to our module .

2.4. Inst alling a HT T P Server

Our Puppe t module will ins tall the package s ne ce s s ary to run a HTTP s e rve r. This re quire s
a re s ource de finition that de fine s configurations for the httpd package .
In the module 's manifests dire ctory, cre ate a ne w manife s t file calle d httpd.pp:
# touch mymodule/manifests/httpd.pp
This manife s t will contain all HTTP configuration for our module . For organiz ational
purpos e s , we will ke e p this manife s t s e parate from the init.pp manife s t.
Add the following conte nt to the ne w httpd.pp manife s t:
class mymodule::httpd {
package { 'httpd':
ensure => installed,
}
}

Puppe t Guide

This code de fine s a s ubclas s of mymodule calle d httpd, the n de fine s a package re s ource
de claration for the httpd package . The ensure => installed attribute te lls Puppe t to
che ck if the package is ins talle d. If it is not ins talle d, Puppe t e xe cute s yum to ins tall it.
We als o ne e d to include this s ubclas s in our main manife s t file . Edit the init.pp manife s t:
class mymodule {
include mymodule::httpd
}
It is now time to te s t the module . Run the following command:
# puppet apply mymodule/tests/init.pp --noop
The puppet apply command applie s the configuration in the manife s t to your s ys te m. We
us e the te s t init.pp manife s t, which re fe rs to the main init.pp manife s t. The --noop
pe rforms a dry-run of the configuration, which s hows only the output but doe s not actually
apply the configuration. The output s hould re s e mble 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 highlighte d line is the re s ult of the ensure => installed attribute . The
current_value absent me ans that Puppe t has de te cte d the httpd package is not
ins talle d. Without the --noop option, Puppe t would ins tall the httpd package .

2.5. Running t he HT T P Server

Afte r ins talling the httpd package , we s tart the s e rvice us ing anothe r re s ource
de claration: service.
Edit the httpd.pp manife s t and add the highlighte d line s :
class mymodule::httpd {
package { 'httpd':
ensure => installed,
}
service { 'httpd':
ensure => running,
enable => true,
require => Package["httpd"],
}
}
This achie ve s a couple of things :
The ensure => running attribute che cks if the s e rvice if running. If not, Puppe t
e nable s it.

C hapt e r 2. Building Puppe t Mo dule s f r o m Sc r at c h

The enable => true attribute s e ts the s e rvice to run whe n the s ys te m boots .
The require => Package["httpd"] attribute de fine s an orde ring re lations hip be twe e n
one re s ource de claration and anothe r. In this cas e , it e ns ure s the httpd s e rvice s tarts
afte r the httpd package ins talls . This cre ate s a de pe nde ncy be twe e n the s e rvice and
its re s pe ctive package .
Run the puppet apply command again to te s t the change s 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 highlighte d line is the re s ult of our ne w re s ource de finition for the httpd s e rvice .

2.6. Configuring t he HT T P Server

The HTTP Se rve r is now ins talle d and e nable d. The ne xt s te p is to provide s ome
configuration. The HTTP s e rve r alre ady provide s s ome de fault configuration in
/etc/httpd/conf/httpd.conf, which provide s a we b hos t on port 80. We will add s ome
additional configuration to provide an additional we b hos t on a us e r-s pe cifie d port.
We us e a te mplate file to s tore our configuration conte nt be caus e the us e r-de fine d port
re quire s variable input. In our module , cre ate a dire ctory calle d templates and add a file
calle d myserver.conf.erb in the ne w dire ctory. Add the following conte nts 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 te mplate follows the s tandard s yntax for Apache we b s e rve r configuration. The only
diffe re nce is the inclus ion of Ruby e s cape characte rs to inje ct variable s from our module .
For e xample , httpd_port, which we us e to s pe cify the we b s e rve r port.
Notice als o the inclus ion of fqdn, which is a variable that s tore s the fully qualifie d domain
name of the s ys te m. This is known as a s ys te m fact. Sys te m facts are colle cte d from
e ach s ys te m prior to ge ne rating e ach re s pe ctive s ys te m's Puppe t catalog. Puppe t us e s
the facter command to gathe r the s e s ys te m facts and you can als o run facter to vie w a
lis t of the s e facts .

Puppe t Guide

Edit the httpd.pp manife s t and add the highlighte d line s :

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 achie ve s the following:
We add a file re s ource de claration for the s e rve r configuration file
(/etc/httpd/conf.d/myserver.conf). The content for this file is the
myserver.conf.erb te mplate we cre ate d e arlie r. We als o che ck the httpd package is
ins talle d be fore adding this file .
We als o add a s e cond file re s ource de claration. This one cre ate s a dire ctory
(/var/www/myserver for our we b s e rve r.
We als o add a re lations hip be twe e n the configuration file and the httpd s e rvice us ing
the notify => Service["httpd"] attribute . This che cks our configuration file for any
change s . If the file has change d, Puppe t re s tarts the s e rvice .
Run the puppet apply command again to te s t the change s 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]/ensur
e: 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

C hapt e r 2. Building Puppe t Mo dule s f r o m Sc r at c h

No te
The warning for the hiera.yaml file is s afe to ignore .
The highlighte d line s s how the cre ation of the configuration file and our we b hos t dire ctory

2.7. Configuring t he Firewall

The we b s e rve r re quire s an ope n port s o pe ople can acce s s the page s hos te d on our
we b s e rve r. The ope n proble m is that diffe re nt ve rs ions of Re d Hat Ente rpris e Linux us e s
diffe re nt me thods for controlling the fire wall. For Re d Hat Ente rpris e Linux 6 and be low, we
us e iptables. For Re d Hat Ente rpris e Linux 7, we us e firewalld.
This de cis ion is s ome thing Puppe t handle s us ing conditional logic and s ys te m facts . For
this s te p, we add a s tate me nt to che ck the ope rating s ys te m and run the appropriate
fire wall commands .
Add the following code ins ide your mymodule::http clas s :
if $operatingsystemmajrelease <= 6 {
exec { 'iptables':
command => "iptables -I INPUT 1 -p tcp -m multiport --ports
${httpd_port} -m comment --comment 'Custom HTTP Web Host' -j ACCEPT &&
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 --addport=${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 pe rforms the following:
Us e the operatingsystemmajrelease fact to de te rmine whe the r the ope rating s ys te m

Puppe t Guide

is Re d Hat Ente rpris e Linux 6 or 7.

If us ing Re d Hat Ente rpris e Linux 6, de clare an e xe cutable (exec) re s ource that runs
iptables and iptables-save to add a pe rmane nt fire wall rule . The httpd_port
variable is us e d in-line to de fine the port to ope n. Afte r the exec re s ource comple te s ,
we trigge r a re fre s h of the iptables s e rvice . To achie ve this , we de fine a s e rvice
re s ource that include s the subscribe attribute . This attribute che cks if any the re are
any change s to anothe r re s ource and, if s o, pe rforms a re fre s h. In this cas e , it che cks
the iptables e xe cutable re s ource .
If us ing Re d Hat Ente rpris e Linux 7, de clare a s imilar e xe cutable re s ource that runs
firewall-cmd to add a pe rmane nt fire wall rule . The httpd_port variable is als o us e d
in-line to de fine the port to ope n. Afte r the exec re s ource comple te s , we trigge r a
re fre s h of the firewalld s e rvice but with a subscribe attribute pointing to the
firewall-cmd e xe cutable re s ource .
The code for both fire wall e xe cutable re s ource s contains refreshonly => true and
subscribe => Package['httpd'] attribute s . This e ns ure s the fire wall commands only
run afte r the httpd ins talls . Without the s e attribute s , s ubs e que nt runs will add multiple
ins tance s of the s ame fire wall rule .
Run the puppet apply command again to te s t the change s to our module . The following
e xample is a te s t of Re d Hat Ente rpris e 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 highlighte d line s s how the e xe cution of the fire wall rule cre ation and the s ubs e que nt
s e rvice re fre s h as a re s ult of the subscribe attribute .

Impo rtant
This configuration s e rve s only as an e xample of us ing conditional s tate me nts . If you
aim to manage multiple fire wall rule s for your s ys te m in the future , it is
re comme nde d to cre ate a cus tom re s ource for fire walls . It is inadvis able to us e
e xe cutable re s ource s to cons tantly chain many Bas h commands .

2.8. Configuring SELinux

SELinux re s tricts non-s tandard acce s s to the HTTP s e rve r by de fault. If we de fine a
cus tom port, we ne e d to add configuration that allows SELinux to grant acce s s .
Puppe t contains re s ource type s to manage s ome SELinux functions , s uch as Boole ans and
module s . Howe ve r, we ne e d to e xe cute the semanage command to manage port s e ttings .
This tool is a part of the policycoreutils-python package , which is not ins talle d on Re d
Hat Ente rpris e Linux s ys te ms by de fault.

10

C hapt e r 2. Building Puppe t Mo dule s f r o m Sc r at c h

Add the following code ins ide your mymodule::http clas s :

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 pe rforms the following:
The require => Package['policycoreutils-python'] attribute make s s ure the
policycoreutils-python is ins talle d prior to e xe cuting the command.
Puppe t e xe cute s semanage to ope n a port us ing httpd_port as a variable .
The before => Service ['httpd'] make s s ure to e xe cute this command be fore the
httpd s e rvice s tarts . If httpd s tarts be fore the SELinux command, SELinux de nie s
acce s s to the port and the s e rvice fails to s tart.
The code for the SELinux e xe cutable re s ource contains refreshonly => true and
subscribe => Package['httpd'] attribute s . This e ns ure s the SELinux commands only
run afte r the httpd ins talls . Without the s e attribute s , s ubs e que nt runs re s ult in failure .
This is be caus e SELinux de te cts the port is alre ady e nable d and re ports an e rror.
Run the puppet apply command again to te s t the change s to our module .
# puppet apply mymodule/tests/init.pp --noop
...
Notice: /Stage[main]/Mymodule::Httpd/Package[policycoreutilspython]/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)
...
Puppe t ins talls policycoreutils-python firs t, the n configure s port acce s s be fore s tarting
the httpd s e rvice .

2.9. Copying a HT ML file t o t he Web Host

The HTTP s e rve r configuration is now comple te . This provide s a platform for ins talling a
we b-bas e d application, which Puppe t can als o configure . For this e xample , howe ve r, we will
only copy ove r a s imple inde x we bpage to our we b hos t.
Cre ate file name d index.html in the files dire ctory. Add the following conte nt to this file :

11

Puppe t Guide

<html>
<head>
<title>Congratulations</title>
<head>
<body>
<h1>Congratulations</h1>
<p>Your puppet module has correctly applied your configuration.</p>
</body>
</html>
Cre ate manife s t name d app.pp in the manifests dire ctory. Add the following conte nt 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 ne w clas s contains a s ingle re s ource de claration. This de claration copie s a file from
the module 's file dire ctory from the Puppe t s e rve r to the s ys te m and s e ts its
pe rmis s ions . Additionally, the require attribute e ns ure s the mymodule::http clas s
comple te s configuration s ucce s s fully be fore we apply mymodule::app.
Finally, include this ne w manife s t in our main init.pp manife s t:
class mymodule {
include mymodule::httpd
include mymodule::app
}
Run the puppet apply command again to te s t the change s to our module . The output
s hould re s e mble 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[policycoreutilspython]/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:

12

C hapt e r 2. Building Puppe t Mo dule s f r o m Sc r at c h

/Stage[main]/Mymodule::Httpd/File[/etc/httpd/conf.d/myserver.conf]/ensur
e: 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 highlighte d line s hows the re s ult of the index.html file be ing copie d to the we bhos t.

2.10. Finalizing t he Module

Our module is re ady for us e . To e xport the module into an archive for Re d Hat Sate llite 6
to us e , run the following command:
# puppet module build mymodule
This cre ate s an archive file at mymodule/pkg/mymodule-0.1.0.tar.gz, which contains the
conte nts of our mymodule dire ctory. We upload this module to our Re d Hat Sate llite 6
s e rve r to provis ion our own HTTP s e rve r.

13

Puppe t Guide

Chapt er 3. Adding Puppet Modules t o Red Hat

Sat ellit e 6
Puppe t module s form a part of a product in Re d Hat Sate llite 6. This me ans you mus t
cre ate a cus tom product and the n upload the module s that form the bas is of that product.
For e xample , a cus tom product might cons is t of a s e t of Puppe t module s re quire d to s e tup
a HTTP s e rve r, a databas e , and a cus tom application. Cus tom products can als o include
re pos itorie s with RPM package s that apply to your application.

3.1. Creat ing a Cust om Product

The firs t s te p to adding our Puppe t module is to cre ate a cus tom product.
Pro cedure 3.1. Creat ing a Cust o m Pro duct
1. Login to your Re d Hat Sate llite 6 s e rve r.
2. Navigate to Co nt ent Pro duct s.
3. Click + New Product.
4. Provide your cus tom product with a Name. In this e xample , us e MyProduct as the
name .
5. The Label fie ld automatically populate s with a labe l bas e d on the Name.
6. Provide a GPG Key, Sync Plan, and a Description if re quire d. For our e xample ,
le ave thos e fie lds blank.
7. Click Save.
Sate llite now has a ne w product calle d MyProduct.

3.2. Creat ing a Puppet Reposit ory in a Cust om Product

The ne xt proce dure cre ate s a Puppe t re pos itory in our cus tom product.
Pro cedure 3.2. Creat ing a Cust o m Puppet Repo sit o ry
1. On the Products page , click on the cus tom product cre ate d pre vious ly (MyProduct).
2. Navigate to the Repositories s ubtab.
3. Click Create Repository.
4. Provide the re pos itory with a Name. This e xample us e s the name MyRepo.
5. The Label fie ld automatically populate s with a labe l bas e d on the Name.
6. Se le ct puppet as the re pos itory Type.
7. Le ave the URL fie ld blank. This fie ld is us e d for re mote re pos itorie s , but in our cas e
Sate llite 6 cre ate s its own re pos itory.
8. Click Save.

14

C hapt e r 3. Adding Puppe t Mo dule s t o Re d Hat Sat e llit e 6

The cus tom product now contains a re pos itory to s tore our Puppe t module s .

3.3. Uploading a Puppet Module t o a Reposit ory

Now we upload our mymodule module to the ne wly cre ate d re pos itory, which adds it to our
cus tom product.
1. Click the Name of the ne wly cre ate d re pos itory.
2. In the Upload Puppet Module s e ction, click Browse and s e le ct the mymodule
archive .
3. Click Upload.
You can upload more module s to this re pos itory. For our e xample , we only ne e d to upload
the mymodule module .
Our Puppe t module is now a part of your Re d Hat Sate llite 6 e nvironme nt. Ne xt we publis h
the module as part of a conte nt vie w.

3.4. Removing a Puppet Module from a Reposit ory

If you aim to re move re dundant module s from cus tom re pos itorie s in the future , us e the
Manage Puppet Modules fe ature .
1. On the Products page , click on the cus tom product containing the module to
re move .
2. Click the Name of the re pos itory containing the module to re move .
3. Click Manage Puppet Modules. The s cre e n dis plays a lis t of Puppe t module s
containe d within the re pos itory.
4. Se le ct the module s to re move .
5. Click Remove Puppet Modules.
Sate llite re move s the chos e n module s from your re pos itory.

3.5. Adding Puppet Modules from a Git Reposit ory

As an alte rnative to manually uploading module s , Re d Hat Sate llite 6 include s a utility
calle d pulp-puppet-module-builder. This tool che cks out re pos itorie s containing a s e t of
module s , builds the module s , and publis he s the m in a s tructure for Sate llite 6 to
s ynchroniz e . This provide s an e fficie nt way to manage module de ve lopme nt in Git and
include the m in the Sate llite 6 workflow.

No te
You can als o ins tall the pulp-puppet-module-builder tool on othe r machine s us ing
the pulp-puppet-tools package .
One common me thod is to run the utility on the Sate llite 6 s e rve r its e lf and publis h to a
local dire ctory.

15

Puppe t Guide

Pro cedure 3.3. Publishing Git Repo sit o ry t o a Lo cal Direct o ry

1. Cre ate a dire ctory on the Sate llite s e rve r to s ynchroniz e the module s .
# mkdir /modules
# chmod 755 /modules
2. Run the pulp-puppet-module-builder and che ckout the Git re pos itory.
# pulp-puppet-module-builder --output-dir=/modules -url=git@mygitserver.com:mymodules.git --branch=develop
This che cks out the develop branch of the Git re pos itory from
git@mygitserver.com:mymodules.git and publis he s the module s to /modules.
The s ame proce dure applie s to publis hing module s to a HTTP s e rve r.
Pro cedure 3.4. Publishing Git Repo sit o ry t o a Web Server
1. Cre ate a dire ctory on the we b s e rve r to s ynchroniz e the module s .
# mkdir /var/www/html/modules
# chmod 755 /var/www/html/modules/
2. Run the pulp-puppet-module-builder and che ckout the Git re pos itory.
# pulp-puppet-module-builder --output-dir=/var/www/html/modules/ -url=git@mygitserver.com:mymodules.git --branch=develop
This che cks out the develop branch of the Git re pos itory from
git@mygitserver.com:mymodules.git and publis he s the module s to /modules.
In the Sate llite 6 We b UI, cre ate a ne w re pos itory with the URL s e t to the location of your
publis he d module s .
Pro cedure 3.5. Creat ing a Repo sit o ry f o r Puppet Mo dules f ro m Git
1. On the Products page , click on the cus tom product cre ate d pre vious ly (MyProduct).
2. Navigate to the Repositories s ubtab.
3. Click Create Repository.
4. Provide the re pos itory with a Name. This e xample us e s the name MyGitRepo.
5. The Label fie ld automatically populate s with a labe l bas e d on the Name.
6. Se le ct puppet as the re pos itory Type.
7. In the URL fie ld, s e t the location you de fine d e arlie r. For e xample , local dire ctorie s
on the Sate llite 6 s e rve r us e the file:// protocol:
file:///modules
A re mote re pos itory us e s the http:// protocol:

16

C hapt e r 3. Adding Puppe t Mo dule s t o Re d Hat Sat e llit e 6

http://webserver.example.com/modules/
8. Click Save.
9. Click Sync Now to s ynchroniz e the re pos itory.
The Puppe t module s in the Git re pos itory are now include d in your Sate llite 6 s e rve r.

3.6. Publishing a Cont ent View

The final s te p to ge tting our Puppe t module re ady for cons umption is to publis h it as part
of a conte nt vie w. You can add this module to an e xis ting vie w but for our e xample we will
cre ate a ne w vie w.
Pro cedure 3.6. Publishing a Co nt ent View
1. Navigate to Co nt ent Co nt ent Views.
2. Click + Create New View.
3. Provide your vie w with a Name. In this e xample , we us e MyView as the name .
4. The Label fie ld automatically populate s with a labe l bas e d on the Name.
5. Make s ure Composite View is not s e le cte d.
6. Click Save.
7. Se le ct the Name of your ne wly cre ate d vie w.
8. Navigate to Co nt ent Repo sit o ries.
9. Add the re quire d Re d Hat Ente rpris e Linux re pos itorie s , including a bas e Re d Hat
Ente rpris e Linux Se rve r RPM colle ction and a Re d Hat Sate llite Tools RPM colle ction
for the s ame ve rs ion. The Tools RPM colle ction contains the package s to s e t up our
re mote Puppe t configuration on provis ione d s ys te ms .
10. Navigate to Puppet Modules.
11. Click + Add New Module.
12. Scroll to your module and click Select a Version.
13. Scroll to the module ve rs ion Use Latest and click Select Version.
14. Our module is now a part of the conte nt vie w. Navigate to Versions to publis h and
promote a ne w ve rs ion of the conte nt vie w.
15. Click Publish New Version. On the Publish New Version page , click Save. This
publis he s the conte nt vie w with our module .
16. Scroll to the ne w ve rs ion of our vie w and click Promote. Choos e a life cycle
e nvironme nt and click Promote Version. This make s the vie w a part of the chos e n
life cycle e nvironme nt.
Our conte nt vie w is now publis he d. As a part of the conte nt vie w cre ation, Re d Hat Sate llite
6 cre ate s a ne w Puppe t e nvironme nt for us e in the provis ioning proce s s . This puppe t
e nvironme nt contains our module . You can vie w this ne w Puppe t e nvironme nt on the
Co nf igure Enviro nment s page .

17

Puppe t Guide

3.7. Configuring Smart Variables from Puppet Classes

Some module clas s e s contain variable parame te rs . Sate llite 6 has the ability to import
clas s e s and allow modification of s uch parame te rs . This is calle d a smart variable.
For e xample , mymodule contains a parame te r for the HTTP port of our we b s e rve r. This
parame te r, httpd_port, is s e t to a de fault of 8120. Howe ve r, a s ituation might occur
whe re we ne e d to us e a diffe re nt port for a provis ione d s ys te m. Sate llite 6 can conve rt
the httpd_port parame te r into a s mart variable , ove rride it, and s e nd it back to the
s ys te m during configuration. This provide s an e as y way to change the HTTP port on our
we bs e rve r.
This proce dure re quire s the mymodule module uploade d to a product and adde d to a
conte nt vie w. This is be caus e we ne e d to e dit the clas s e s in the re s ulting Puppe t
e nvironme nt.
1. Navigate to Co nf igure Smart variables.
2. A table appe ars lis ting all s mart variable s from the clas s e s in your Puppe t
module s . Click on the httpd_port variable .
3. The options for the s mart variable appe ars . To allow ove rriding this variable during
provis ioning, s e le ct the Override option.
4. Se le cting the Override option allows us to change the Parameter type and
Default value. This is us e ful if we aim to globally change this value for all future
configurations .
The following parame te r type s are available :
St ring
The value is inte rpre te d as a plain te xt s tring. For e xample , if your s mart
variable s e ts the hos tname , the value is inte rpre te d as a s tring:
myhost.example.com
Bo o lean
The value is inte rpre te d and validate d as a true or fals e value . Example s
include :
True
true
1
Int eger
The value is inte rpre te d and validate d as an inte ge r value . Example s
include :
8120
-8120
Real
The value is inte rpre te d and validate d as a re al numbe r value . Example s
include :

18

C hapt e r 3. Adding Puppe t Mo dule s t o Re d Hat Sat e llit e 6

include :
8120
-8120
8.12
Array
The value is inte rpre te d and validate d as a JSON or YAML array. For
e xample :
["Monday","Tuesday","Wednesday","Thursday","Friday"]
Hash
The value is inte rpre te d and validate d as a JSON or YAML has h map. For
e xample :
{"Weekdays":
["Monday","Tuesday","Wednesday","Thursday","Friday"],
"Weekend": ["Saturday","Sunday"]}
YAML
The value is inte rpre te d and validate d as a YAML file . For e xample :
email:
delivery_method: smtp
smtp_settings:
address: smtp.example.com
port: 25
domain: example.com
authentication: none
JSON
The value is inte rpre te d and validate d as a JSON file . For e xample :
{
"email":[
{
"delivery_method": "smtp"
"smtp_settings": [
{
"address": "smtp.example.com",
"port": 25,
"domain": "example.com",
"authentication": "none"
}
]
}
]
}
For this e xample , le ave the de fault as 8120.

19

Puppe t Guide

5. Se le cting the Override option als o e xpos e s Optional Input Validator, which
provide s validation for the ove rridde n value . For e xample , we can include a re gular
e xpre s s ion to make s ure httpd_port is a nume rical value . For our e xample , le ave
this s e ction blank.
6. Se le cting the Override option als o e xpos e s Override Value For Specific
Hosts, which de fine s a hie rarchical orde r of s ys te m facts and a s e t of matche rvalue combinations . The matche r-value combinations de te rmine the right
parame te r to us e de pe nding on an e valuation of the s ys te m facts . For our
e xample , le ave this s e ction with the de fault s e ttings .
7. Click Submit.
We now have a s mart variable for httpd_port. We can s e t a value for this s mart variable
at e ithe r a Hos t Group le ve l or at a Hos t le ve l.

20

C hapt e r 4 . Clie nt and Se r ve r Se t t ings f o r Co nf igur at io n Manage me nt

Chapt er 4. Client and Server Set t ings for

Configurat ion Management
An important part of Re d Hat Sate llite 6's configuration proce s s is making s ure the Puppe t
clie nts (calle d Puppe t age nts ) can communicate with the Puppe t s e rve r (calle d Puppe t
mas te r) on e ithe r the inte rnal Sate llite Caps ule or an e xte rnal Sate llite Caps ule . This
chapte r e xamine s how Re d Hat Sate llite 6 configure s both the Puppe t mas te r and the
Puppe t age nt.

4.1. Configuring Puppet on t he Red Hat Sat ellit e Server

Re d Hat Sate llite 6 controls the main configuration for the Puppe t mas te r on all Sate llite
Caps ule s . No additional configuration is re quire d and it is re comme nde d to avoid manually
modify the s e configuration file s . For e xample , the main /etc/puppet.conf configuration
file contains the following [master] s e ction:
[master]
autosign
=
reports
=
external_nodes =
node_terminus =
ca
=
ssldir
=
certname
=
strict_variables

$confdir/autosign.conf { mode = 664 }

foreman
/etc/puppet/node.rb
exec
true
/var/lib/puppet/ssl
sat6.example.com
= false

manifest
=
/etc/puppet/environments/$environment/manifests/site.pp
modulepath
= /etc/puppet/environments/$environment/modules
config_version =
This s e ction contains variable s (s uch as $environment) that Sate llite 6 us e s to cre ate
configuration for diffe re nt e nvironme nts .
Some Puppe t configuration options appe ar in the Sate llite 6 UI. Navigate to Administ er
Set t ings and choos e the Puppet s ubtab. This page lis ts a s e t of Puppe t configuration
options and a de s cription of e ach.

4.2. Configuring Puppet agent on Provisioned Syst ems

As part of the provis ioning proce s s , Sate llite 6 ins talls Puppe t to the s ys te m. This proce s s
als o ins talls /etc/puppet/puppet.conf file that configure s Puppe t as an age nt of the
Puppe t mas te r on a chos e n Caps ule . This configuration file is s tore d as a provis ioning
te mplate s nippe t in Sate llite 6. Navigate to Ho st s Pro visio ning t emplat es and click
the puppet.conf s nippe t to vie w it.
The de fault puppet.conf s nippe t contains the following age nt configuration:
[agent]
pluginsync
report
ignoreschedules
daemon

=
=
=
=

true
true
true
false

21

Puppe t Guide

ca_server
certname
environment
server

=
=
=
=

<%=
<%=
<%=
<%=

@host.puppet_ca_server %>
@host.certname %>
@host.environment %>
@host.puppetmaster %>

This s nippe t contains s ome te mplate variable s , which are :

@ho st .puppet _ca_server and @ho st .cert name - The ce rtificate and ce rtificate
authority for s e curing Puppe t communication.
@ho st .enviro nment - The Puppe t e nvironme nt on the Sate llite 6 s e rve r to us e for
configuration.
@ho st .puppet mast er - The hos t containing the Puppe t mas te r. This is e ithe r the
Sate llite 6 s e rve r's inte rnal Caps ule or an e xte rnal Sate llite Caps ule .

22

C hapt e r 5. Applying Co nf igur at io n o n Clie nt s

Chapt er 5. Applying Configurat ion on Client s

At this point, Sate llite 6 s e rve r's Puppe t e cos ys te m is configure d and contains the
mymodule module . We now aim to apply this module 's configuration to a re gis te re d
s ys te m.

5.1. Applying Configurat ion on Client s During Provisioning

We firs t de fine a ne w hos t's Puppe t configuration us ing the following proce dure . This
proce dure us e s the uploade d mymodule as an e xample .
Pro cedure 5.1. Applying Co nf igurat io n o n Client s During Pro visio ning
1. Navigate to Ho st s New ho st .
2. Click the Host tab. Ente r a Name for the hos t and choos e the organiz ation and
location for the s ys te m. Choos e the Lifecycle Environment and its promote d
Content View. This de fine s the Puppe t e nvironme nt to us e for the configuration.
Als o choos e a Puppet CA and Puppet Master from the Capsule Settings. The
chos e n caps ule acts as the s e rve r that controls the configuration and
communicate s with the age nt on the ne w hos t.
3. Click the Puppet Classes tab and from the Available Classes s e ction choos e the
Puppe t clas s e s that contain the configuration to apply. In our e xample , choos e :
mymodule
mymodule:httpd
mymodule:app
4. Choos e the ne ce s s ary options from the Network and Operating System tabs .
The s e options de pe nd on your own Sate llite 6 infras tructure . Make s ure the
Provisioning templates option include s the Satellite Kickstart Default
kicks tart te mplate . This te mplate contains ins tallation commands for the Puppe t
age nt on the ne w hos t.
5. Click the Parameters tab and provide any cus tom ove rride s to our Puppe t clas s
parame te rs . For e xample , modify the httpd_port from the mymodule to s e t your
own cus tom port.
6. Afte r comple ting all provis ioning options , click Submit.
The provis ioning proce s s be gins . Sate llite 6 ins talls the re quire d configuration tools as
part of the Satellite Kickstart Default provis ioning te mplate . This provis ioning
te mplate 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

23

Puppe t Guide

# 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 s e ction pe rforms the following:
Ins talls the puppet package from the Re d Hat Sate llite 6 Tools RPMs re pos itory.
Ins talls the Puppe t configuration s nippe t to the s ys te m at /etc/puppet/puppet.conf.
Enable s the Puppe t s e rvice to run on the s ys te m.
Run Puppe t for the firs t time and apply the s ys te m configuration.
Afte r the provis ioning and configuration proce s s e s comple te on the ne w hos t, acce s s the
hos t and us e r-de fine d port in your we b brows e r. For e xample , navigate to
http://newhost.example.com:8120/ and the following me s s age appe ars in your
brows e r:
Congratulations
Your puppet module has correctly applied your configuration.

5.2. Applying Configurat ion t o Exist ing Client s

You might aim to have Puppe t configuration applie d to an e xis ting clie nt not provis ione d
through Re d Hat Sate llite 6. In this s ituation, ins tall and configure Puppe t on the e xis ting
clie nt afte r re gis te ring it to Re d Hat Sate llite 6.
Re gis te r your e xis ting s ys te m to Re d Hat Sate llite 6. For information on re gis te ring
e xis ting hos ts , s e e 12.3.1. Re gis te ring a Hos t in the Re d Hat Sate llite 6.1 Us e r Guide .

Impo rtant
The puppet package is part of the Re d Hat Sate llite 6 Tools re pos itory. Ens ure you
e nable this re pos itory be fore you proce e d.

Pro cedure 5.2. T o Inst all and Enable t he Puppet Agent :

1. Ope n a te rminal cons ole and log in as root.
2. Ins tall the Puppe t age nt:
# yum install puppet
3. Configure the puppe t age nt to s tart at boot:
A. On Re d Hat Ente rpris e Linux 6:

24

C hapt e r 5. Applying Co nf igur at io n o n Clie nt s

# chkconfig puppet on
B. On Re d Hat Ente rpris e Linux 7:
# systemctl enable puppet
Pro cedure 5.3. Co nf iguring t he Puppet Agent
1. Configure the Puppe t age nt by changing the /etc/puppet/puppet.conf file :
# vi /etc/puppet/puppet.conf
[main]
# The Puppet log directory.
# The default value is '$vardir/log'.
logdir = /var/log/puppet
# Where Puppet PID files are kept.
# The default value is '$vardir/run'.
rundir = /var/run/puppet
# Where SSL certificates are kept.
# The default value is '$confdir/ssl'.
ssldir = $vardir/ssl
[agent]
# The file in which puppetd stores a list of the classes
# associated with the retrieved configuratiion. Can be loaded
in
# the separate ``puppet`` executable using the ``-loadclasses``
# option.
# The default value is '$confdir/classes.txt'.
classfile = $vardir/classes.txt
pluginsync = true
report = true
ignoreschedules = true
daemon = false
ca_server = satellite.example.com
server = satellite.example.com
environment = KT_Example_Org_Library_RHEL6Server_3
# Where puppetd caches the local configuration. An
# extension indicating the cache format is added
automatically.
# The default value is '$confdir/localconfig'.
localconfig = $vardir/localconfig

25

Puppe t Guide

Impo rtant
Se t the environment parame te r to the hos t's Puppe t e nvironme nt from the
Sate llite s e rve r. The Puppe t e nvironme nt labe l contains the organiz ation
labe l, life cycle e nvironme nt, conte nt vie w name , and the conte nt vie w ID. To
s e e a lis t of Puppe t e nvironme nts in the Sate llite 6 we b UI, navigate to
Co nf igure Enviro nment s.
2. Run the Puppe t age nt on the hos t:
# puppet agent -t --server satellite.example.com
3. Sign the SSL ce rtificate for the puppe t clie nt through the Sate llite Se rve r we b
inte rface :
a. Log in to the Sate llite Se rve r through the we b inte rface .
b. Se le ct Inf rast ruct ure Capsules.
c. Click Certificates to the right of the re quire d hos t.
d. Click Sign.
e . Re run the puppet agent command:
# puppet agent -t --server satellite.example.com

No te
Whe n the Puppe t age nt is configure d on the hos t it will be lis te d unde r All Hosts
but only whe n Any Context is s e le cte d as the hos t will not be as s igne d to an
organiz ation or location.

26

C hapt e r 6 . Re vie wing Puppe t Re po r t s in Re d Hat Sat e llit e 6

Chapt er 6. Reviewing Puppet Report s in Red Hat

Sat ellit e 6
Puppe t ge ne rate s a re port e ach time it applie s configuration. Provis ione d hos ts s e nd this
re port to the Re d Hat Sate llite 6 s e rve r. Vie w the s e re ports on the hos ts de tails page .
Pro cedure 6.1. Reviewing Puppet Repo rt s in Red Hat Sat ellit e 6
1. Navigate to Ho st s All ho st s.
2. Click the Name of your de s ire d hos t.
3. Click the Reports button.
4. Se le ct a re port to vie w.
Each re port s hows the s tatus of e ach Puppe t re s ource and its configuration applie d to the
hos t.

27

Puppe t Guide

Appendix A. Revision Hist ory

Revisio n 1.3-1
Mo n Oct 12 20 15
BZ 1253895: Typo in puppe t guide
Building for as ync 1

Hayley Hudgeo ns

Revisio n 1.1-1
Wed Aug 26 20 15
Dan Macpherso n
Adde d Puppe t Module Re moval ins tructions
Adde d Puppe t Age nt ins tallation and configuration for e xis ting hos ts
Revisio n 1.0 -2
T ue Jul 14 20 15
Re build for te chnical re vie w.

David O'Brien

Revisio n 1.0 -1
6.1 Public Be ta re le as e .

Sun Jun 14 20 15

David O'Brien

Revisio n 1.0 -0
Initial cre ation of book

Fri Jun 12 20 15

Dan Macpherso n

28