Errata

In the book, the code snippet to have Vagrant add the Puppetlabs CentOS 7 box points to their 7.0 box on Atlas:

`vagrant box add --provider virtualbox puppetlabs/centos-7.0-64-nocm`

In your latest rev of the Vagrant file on the Github project, it has us downloading the newer CentOS 7.2 box:

`Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
config.vm.box = "puppetlabs/centos-7.2-64-nocm"`

Just wanted to bump the version of the box users are to add from 7.0 to 7.2.

Thanks!

Note from the Author or Editor:
Fixed in October, 2016 update.

In chapter 5, section "Using Comparison Operators", I found the following statement:

"String equality comparisons are case insensitive, while substring matches are case sensitive".

I found the latter portion of this statement to be false.

For instance, the following two expressions should both return "false" if that statement was true:
-------------------------
[vagrant@client ~]$ puppet apply -e 'notice("f" in "FOO"); notice("Fee" in "coffee")'
Notice: Scope(Class[main]): true
Notice: Scope(Class[main]): true
---------------------

Note from the Author or Editor:
Fixed in October, 2016 update.

In chapter 5, section "Using Comparison Operators", I found some sample code that fails to compile.

The text with the erroneous code is the following:
--------------------------
'tea' !in 'coffee' # you can't find tea in coffee
'Fee' !in 'coffee' # substring matches are case sensitive
--------------------------

The "!in" operator is invalid. The "!" has to surround the entire expression, like this:
--------------------
!('tea' in 'coffee') # you can't find tea in coffee
!('Fee' in 'coffee') # substring matches are case sensitive
----------------

When the original expression is executed, it fails like this:
---------------
[vagrant@client ~]$ puppet apply -e 'notice("tea" !in "coffee")'
Error: Could not parse for environment production: Syntax error at '!' at line 1:14 on node client.example.com
----------------

But the following works:
------------------
[vagrant@client ~]$ puppet apply -e 'notice(!("tea" in "coffee"))'
Notice: Scope(Class[main]): true
---------------------------

Note from the Author or Editor:
Fixed in October, 2016 update.

In chapter 8, section "Enhancing Older Manifests", subsection "Using Hash and Array Literals", there is the following code sample:
-----------------
notify { "(['one','two','three'][1] )": } # produces the output "two"
-----------------

Actually, this produces the output "(['one','two','three'][1] )".

Removing the surrounding double quotes, like this:
-----------------
notify { (['one','two','three'][1] ): } # produces the output "two"
-----------------

does result in the output "two".

Note from the Author or Editor:
Fixed in October, 2016 update.

Chapter 13, section "Using Puppet EPP Templates".

Along the lines of the earlier issue with the format of the first parameter to the "epp()" function, I note the following code sample in the "Providing parameters" subsection:
-----------------
content => epp('puppet:///puppet/puppet.conf.epp', {
'server' => $server,
'common_loglevel' => $common_loglevel,
'agent_loglevel' => $agent_loglevel,
'apply_loglevel' => $apply_loglevel,
}),
----------------

As somewhat expected, this fails with:
---------------------
[vagrant@client puppet]$ sudo puppet apply --environment test manifests/init.pp
Notice: Scope(Class[Puppet]): Install the latest version of Puppet, ensure it's running, and set boot time start true.
Error: Evaluation Error: Error while evaluating a Function Call, Could not find template 'puppet:///puppet/puppet.conf.epp' at /etc/puppetlabs/code/environments/test/modules/puppet/manifests/init.pp:85:14 on node client.example.com
----------------

Changing it back to the original format of "puppet/puppet.conf.epp" makes it work.

Note from the Author or Editor:
Fixed in October 2016 update.

Chapter 14, section "Containing Classes".

The first code sample is this:
------------------
service 'dependency' {
ensure => running,
after => Class['only_has_variables']
}
------------------

I think this is just a rhetorical example, but I would think a more correct syntax would be this:
------------------
service { 'dependency':
ensure => running,
after => Class['only_has_variables']
}
-------------

Note from the Author or Editor:
Fixed in October, 2016 update.

Chapter 14, section "Creating Reusable Modules".

There are several invalid code samples on this page, all using a pattern like this:
--------------
type 'name' {
stuff ...
}
------------

They should all be:
--------------
type { 'name':
stuff ...
}
--------------

Note from the Author or Editor:
Fixed in October, 2016 update.

The yaml file is incorrect. It shouldn't have an equal to "=" sign.

--
classes:
- puppet

puppet::version = 'latest'
puppet::status = 'stopped'
puppet::enabled = false

Note from the Author or Editor:
Fixed in the February 2018 update.

The last command you give, to put the secret token in settings.yml, is

[puppet-dashboard@dashserver ~]$ echo "secret_token: \
'$(bundle exec rake secret)'" > config/settings.yml

That overwrites settings.yml with the secret token. I think you meant

[puppet-dashboard@dashserver ~]$ echo "secret_token: \
'$(bundle exec rake secret)'" >> config/settings.yml

Note from the Author or Editor:
Fixed in October, 2016 update.

if( $facts['osfamily'] == 'redhat' ) {

Should read

if( $facts['osfamily'] == 'RedHat' ) {

This error is repeated with the other osfamily values where characters in the names are uppercase.

The line:
and ( $facts['os']['release']['major'] >= 9

will not work as this fact is a string and NOT a number so the code produces a syntax error .

same errors repeated on page 70

Note from the Author or Editor:
The conversion to Integer has been fixed in the February 2018 update.

The equals operator for String comparison is case insensitive ;)

At the start of page 75, it says,

The following manifest would provide the exact same results:
each( $facts['system_uptime'] ) |$uptime| {
notice( "System has been up $uptime[1] $uptime[0]" )
}

Above code has a minor issue of missing curly braces in variable $uptime[1] and $uptime[0]. Without those curly braces, output is not correct.

It should be ${uptime[1]} and ${uptime[0]}

Note from the Author or Editor:
Fixed in February 2018 update.