Chapter 3 Writing better manifest


instead of

package { 'cron':ensure =>installed }
package { 'locate':ensure =>installed }
package { 'lsof':ensure =>installed }

package { ['cron','locate','lsof']:ensure =>installed, }


Like the array is good to avoid to repeat the code

this code will create tre file called a , b, c

define tmpfile() {
 files {"/tmp/${name}":
content => "Hello world \n",

tmpfile {['a','b','c']: }

you can either define using variable name

define tmpfile( $greeting ) {
file { "/tmp/$name":
content => $greeting,
tmpfile{ "foo": greeting => "Hello, world" }

You can declare multiple parameters as a comma-separated list:

define webapp( $domain, $path, $platform ) {
webapp { "mywizzoapp":
domain => "mywizzoapp.com",
path => "/var/www/apps/mywizzoapp",
platform => "Rails",

you can also declare default variable for the parameters

define tmpfile($greeting, $mode='0644') {


notify , require, ensure .
Puppet needs those because it is not procedural

class admin::ntp {
package { "ntp":
ensure => installed,
service { "ntp":
ensure => running,
require => Package["ntp"],
file { "/etc/ntp.conf":
source => "puppet:///modules/admin/ntp.conf",
notify => Service["ntp"],
require => Package["ntp"],

Keep the resource in the correct order is one of the most difficult part of building a package manifest
If your manifest require 2/3 execution to be completed is because the resource are not apply in the right order
some examples:

  • files require parent directory exist
  • service require that a package is installed before the execution
  • service controlled by init or upstart script need that the script is before placed
  • exec resource that require a script needs that the script is already placed
  • exec script that install a binary require that are executed before the first use7

if a resource require everything about a class is a require of the whole class

require => Class['important_thing']

if lots of thing depend on this class, you may decide to put this class in own run stage , there is a section for this.

chapter 7 Server and Cloud infrastructure

vagrant , ec2, haproxy, firewall, nfs, heartbeat

there is the configuration of file to use heartbeast for exchange a single ip

there is either a configuration for nfs

mange ec2 instance pag 172

Chapter 9 Monitoring Reporting and Trobleshooting



nel command line permit to check what the puppet do without modify the machine


in an exec command you can specify if you want log prints or not

exec { 'a-command':
     command => '/bin/cat /etc/hostname',
     logoutput => true,

Possible value
  • false : never print command output
  • on_failure : print only if the command fails
  • true: print always

Set default in your site.pp

Exec {
    logoutput => true,

with the capital E is for say to puppet to apply this to all exec resource in your manifest

options to have report
—report in the command line
report = true
in puppet.conf

to have a summary of the report
—summarize at the command line

to collect the logs in a central system you should use the rsyslog utility

e' possibile produrre della documentazione automatica per i pp file

with graphviz is possible have a graphical form to understand and fix the dependencies

I parametri sono definiti dentro puppet.conf se si vogliono sapere quelli di default che non sono scritti li eseguire

puppet config print

stampa tutti i valori
Salvo diversa indicazione, il contenuto di questa pagina è sotto licenza Creative Commons Attribution-ShareAlike 3.0 License