The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".
The following errata were submitted by our customers and approved as valid errors by the author or editor.
| Version |
Location |
Description |
Submitted By |
Date submitted |
Date corrected |
|
?
Example 7-9 |
Checking for 'not result.failed' will not properly guard against attempts to access a missing 'result.out' variable in cases where the database has already been created as the returned value for result.failed in that situation (as shown in Example 7-6) also false.
Note from the Author or Editor: The following lines should be removed in chapter 7:
Or we could simply check for +failed+ to be false:
----
changed_when: not result.failed and "Creating tables" in result.out
----
We also need to change the failure behavior, since we don't want Ansible to consider the task as failed just because +createdb+ has been invoked already:
----
failed_when: result.failed and "Database already created" not in result.msg
----
Here the +failed+ check serves as a guard for the existence of the +msg+ variable.
In Example 7-9, the "failed_when" clause should be removed and the "changed_when" clause should be changed to:
changed_when: '"Creating tables" in result.out|default("")'
|
Ed Hynes |
Nov 13, 2015 |
|
|
1
Example 9-13 |
"include_vars" is in in the playbook in Example 9-13, 9-19, and 9-20 but it's not defined anywhere in the book. This seems like an important concept and it should be defined somewhere if it's used in the book.
Note from the Author or Editor: Should add a section that explains "include_vars".
|
Oscar Silva |
Jun 16, 2019 |
|
| Printed, PDF, ePub |
Page 4
Figure 1-1, the yaml |
The "handlers" section lists the name "notify nginx", whereas the "notify" field of the task refers to "restart nginx".
To my knowledge the name is used to identify the handler, so this is wrong.
Note from the Author or Editor: The handlers section in webservers.yml should be changed to:
handlers:
- name: restart nginx
service: name=nginx state=restarted
|
Anonymous |
May 30, 2015 |
|
| PDF |
Page 4
Step 3 |
"Execute the script on web1, web2, web3."
->
"Execute the script on web1, web2, and web3."
This is to be consistent with Step 2.
|
Jon Forrest |
Nov 06, 2016 |
|
| PDF |
Page 4
Figure 1-1 |
I'm embarrassed to even mention this, but Figure 1-1 says:
"Install nginx"
but the prose above it says:
"install nginx"
|
Jon Forrest |
Nov 06, 2016 |
|
| PDF |
Page 12
5th paragraph |
Using these specific vagrant sub-commands requires at least version 1.5.x of Vagrant. They will fail on 'vagrant up' if the user is using 1.4.x.
https://github.com/Varying-Vagrant-Vagrants/VVV/issues/354
|
MarkD |
Sep 28, 2015 |
|
| PDF |
Page 33
Last paragraph |
"you can use the --start-at-task <task name> flag to tell ansibleplaybook to start a playbook in the middle of a task,"
Shouldn't this be
"you can use the --start-at-task <task name> flag to tell ansibleplaybook to start a playbook in the middle of a play,"
You can't start in the middle of a task because a task isn't subdivisible. Since a play consists of one or more tasks, it would make sense to start the play at something other than the first task.
Note from the Author or Editor: Yes, the wording in the book is incorrect, it should be "play" rather than "task".
|
Jon Forrest |
Sep 24, 2016 |
|
| PDF |
Page 35
1st paragraph in "Putting It All Together" section |
"A play associates an unordered set of hosts with an ordered list of task_"
->
"A play associates an unordered set of hosts with an ordered list of tasks"
|
Jon Forrest |
Sep 24, 2016 |
|
| PDF |
Page 42
1st paragraph in "A few things to keep in mind about handlers" |
"Handlers only run after all of the tasks are run, and they only run once, even if they are notified multiple times. They always run in the order that they appear in the play, not the notification order"
Since the example only shows one handler, it isn't clear what the second sentence is saying. If there's only one handler then I'm guessing that the second sentence doesn't apply, since the one handler would only execute once - thus there's no ordering at all. If there's more than one handler then are you saying that they would be executed in the order they appear under the "handlers:" header no matter what order they are notified in?
Note from the Author or Editor: Reword second sentence to:
If a play contains multiple handlers, the handlers always run in the order that they are defined in the handlers section, not the notification order.
|
Jon Forrest |
Sep 24, 2016 |
|
| PDF |
Page 48
near the bottom |
The line "Modify your hosts file so it looks like this:"
Should be: "Modify your inventory file so it looks like this:"
Otherwise the following command:
ansible vagrant2 -a "ip addr show dev eth0"
Will fail with the following message:
vagrant2 | FAILED => SSH Error: ssh: Could not resolve hostname vagrant2: nodename nor servname provided, or not known
It is sometimes useful to re-run the command using -vvvv, which prints SSH debug output to help diagnose the issue.
|
kennethwolcott |
Jun 11, 2015 |
|
| PDF |
Page 50
Table 3-2 |
The table shown is repeated from the previous page (Behavioral Inventory parameters).
The correct tunable settings for the ansible.cfg [defaults] section can be found here:
http://docs.ansible.com/ansible/intro_configuration.html#general-defaults
Note from the Author or Editor: Table 3-2 is not a copy of Table 3-1, but rather is a subset which contains the parameters that can be overridden in ansible.cfg, as well as the name of the config option in ansible.cfg.
That being said, the provided link, http://docs.ansible.com/ansible/intro_configuration.html#general-defaults, is a great reference to the full list of options in the defaults section of ansible.cfg
|
Anonymous |
Jul 27, 2015 |
|
| PDF |
Page 51
near the top |
Actually this is of minor importance, just an annoyance.
It reduces readability.
The key word "ansible_shell_type" should not be broken by word wrap.
It is currently broken at "ansi".
This is the first line of the page.
|
kennethwolcott |
Jun 11, 2015 |
|
| Printed, PDF, ePub |
Page 57
Example 3.6 Specyfying group variables in inventory; section [vagrant:vars] |
Variable db_primary_port=5432 in section[vagrant:vars] is set twice.
Note from the Author or Editor: The duplicate db_primary_port=5432 in the [vagrant:vars] section should be removed.
|
Artur Owczarek |
May 01, 2015 |
|
| PDF |
Page 58
Example 3-7 |
Figure 3-7 should also contain the following two lines:
db_primary_port=5432
rabbitmq_port=5672
Ironically, Figure 3-8 correctly contains the dictionary entries corresponding to these lines.
|
Jon Forrest |
Nov 19, 2016 |
|
| PDF |
Page 63
Middle of page |
"Our dynamic inventory script will need to call these commands, parse the outputs, and output the appropriate json."
->
"Our dynamic inventory script will need to call these commands, parse the outputs, and output the appropriate JSON."
|
Jon Forrest |
Sep 25, 2016 |
|
| Printed |
Page 65
after 3rd paragraph |
It would be helpful to add a note or warning that static inventory files cannot have a .ini extension when using multiple files in a directory; these files will be skipped and may lead to a "No hosts matched" error.
http://stackoverflow.com/questions/21638996/ansible-multiple-inventory-file
Note from the Author or Editor: I wasn't aware of this limitation, but it's a good issue to note.
|
Rachel Rawlings |
Aug 18, 2015 |
|
| PDF |
Page 65
1st paragraph |
"You can grab these by going to the Ansible GitHub repo and
browsing to the plugins/inventory directory."
The location have the dynamic inventory scripts appears to have changed. I believe it's currently
ansible/lib/ansible/inventory/
Note from the Author or Editor: Apparently, these scripts are now the contrib/inventory directory in the ansible/ansible github repo.
|
Jon Forrest |
Sep 25, 2016 |
|
| PDF |
Page 66
Middle of page |
"Here’s the add_host command in action, bringing up a new vagrant machine"
->
"Here’s the add_host command in action, bringing up a new Vagrant machine"
|
Jon Forrest |
Sep 25, 2016 |
|
| PDF |
Page 66
Middle of page |
- name: Bring up a vagrant server
command: vagrant up
- name: add the Vagrant hosts to the inventory
->
- name: Bring up a vagrant machine
command: vagrant up
- name: add the vagrant machine to the inventory
This is to be consistent with the wording in the rest of the play.
|
Jon Forrest |
Nov 19, 2016 |
|
| PDF |
Page 70
2nd paragraph |
"Ansible also let you define variables"
->
"Ansible also lets you define variables"
|
Jon Forrest |
Nov 19, 2016 |
|
| PDF |
Page 77
1st paragraph in "Local Facts" |
"Ansible will recognize the file if it’s:"
->
"Ansible will recognize the file if it’s any of the following:"
|
Jon Forrest |
Sep 25, 2016 |
|
| PDF |
Page 77
1st paragraph in "Local Facts" |
"can place one or more files on the host machine"
->
"can place one or more files on the remote host machine"
You need to be clear about which machine you're talking about. This is
especially true since the topic of this section is "Local Facts" but we're talking about putting a file on a remote machine.
|
Jon Forrest |
Nov 19, 2016 |
|
| PDF |
Page 80
last paragraph |
Our configuration file would contain a fragment that looks like this:
backend web-backend
{% for host in groups.web %}
server {{ host.inventory_hostname }} {{ host.ansible_default_ipv4.address }}:80
{% endfor %}
should be:
Our configuration file would contain a fragment that looks like this:
backend web-backend
{% for host in groups.web %}
server {{ hostvars[host].inventory_hostname }} {{ hostvars[host].ansible_default_ipv4.address }}:80
{% endfor %}
|
Andrey Hsiao |
Feb 03, 2017 |
|
| PDF |
Page 81
2nd paragraph |
"when you want to want to use"
->
"when you want to use"
|
Jon Forrest |
Nov 19, 2016 |
|
| PDF |
Page 81
2nd to last paragraph |
"you’ll need two use quotes like this:"
->
"you’ll need to use quotes like this:"
|
Anonymous |
Jan 01, 2017 |
|
| ePub |
Page 85
Example 3-6. Specifying group variables in inventory |
Missing `db_primary_port=5432` in section `[staging:vars]`.
Note from the Author or Editor: Yes, there is a duplicate "db_primary_port=5432" line which should appear in the "[staging:vars]" section.
|
Alexandre Garnier |
Nov 02, 2015 |
|
| PDF |
Page 87
Last paragraph |
(I'm almost too embarrassed to mention this since it's such a trivial error.)
"If the request is for a static asset, such as a css file,"
->
"If the request is for a static asset, such as a ,css file,"
(A mention two paragraphs above uses ".css" so pick one or the other.)
|
Jon Forrest |
Sep 26, 2016 |
|
| PDF |
Page 87
Last paragraph |
(Another trivial mistake ...)
"by making an http request"
->
"by making an HTTP request"
(You capitalize HTTP everywhere else on the page.)
|
Jon Forrest |
Sep 26, 2016 |
|
| PDF |
Page 88
Figure 5-3 |
"/hom/deploy/myapp/static/style.css"
->
"/home/deploy/myapp/static/style.css"
|
Jon Forrest |
Nov 20, 2016 |
|
| PDF |
Page 91
1st paragraph |
The word "database_user" was broken in a strange way.
|
Jon Forrest |
Nov 20, 2016 |
|
| PDF |
Page 94
Bottom third of page |
(Another trivial typo.)
"Example 6-4. apt cache output"
->
"Example 6-4. apt-cache output"
|
Jon Forrest |
Sep 27, 2016 |
|
| PDF |
Page 94
1st paragraph in "Updating the Apt Cache" |
"the names of all of the Apt packages"
->
"the names of all of the apt packages"
This is to be consistent with the usage on the previous page.
|
Jon Forrest |
Nov 20, 2016 |
|
| PDF |
Page 99
2nd line |
"virtualenv" has a bad word break.
|
Jon Forrest |
Nov 20, 2016 |
|
| PDF |
Page 106
Middle of page |
This is another of those bad word break issues.
createdb is broken as
crea
tedb
|
jon@berkeleyparentsnetwork.org |
Sep 28, 2016 |
|
| PDF |
Page 108
In the "Passing Environment Variables to Ansible Tasks" section |
The word "environment" is broken incorrectly in two places.
|
Jon Forrest |
Sep 28, 2016 |
|
| PDF |
Page 109
Example 6-17 |
The text in Example 6-17 appears with syntax coloring, while Examples 6-16 and 6-18 are all have black text.
|
Jon Forrest |
Nov 25, 2016 |
|
| PDF |
Page 110
Toward the bottom of the page. |
(Another trivial issue)
"If the supervisor configuration file changes"
->
"If the Supervisor configuration file changes"
Also, the word "supervisor" is broken incorrectly.
|
Jon Forrest |
Sep 28, 2016 |
|
| Printed |
Page 128
2nd, 3rd,4th code segments |
In the three 'changed_when' examples, the author has changed '"Creating tables" in result.out' to '...not in result.out'. These should remain '"Creating tables" in result.out', as in the first code segment and Examples 7-8 and 7-9.
|
Rachel Rawlings |
Aug 13, 2015 |
|
| Printed, PDF, ePub |
Page 129
Last code sample in "Retrieving IP Address from the Host" |
live_hostname: "{{ ansible_eth1.ipv4.address }}.xip.io"
domains:
- ansible_eth1.ipv4.address.xip.io
- www.ansible_eth1.ipv4.address.xip.io
should be...
live_hostname: "{{ ansible_eth1.ipv4.address }}.xip.io"
domains:
- "{{ ansible_eth1.ipv4.address }}.xip.io"
- www.{{ansible_eth1.ipv4.address}}.xip.io
or something close to that...
Note from the Author or Editor: should be:
live_hostname: "{{ ansible_eth1.ipv4.address }}.xip.io"
domains:
- "{{ ansible_eth1.ipv4.address }}.xip.io"
- www.{{ansible_eth1.ipv4.address}}.xip.io
|
Chuck Hudson |
May 06, 2015 |
|
| PDF |
Page 129
Example 7-10 |
This example appears with colored text, unlike most of the others.
|
Jon Forrest |
Nov 26, 2016 |
|
| PDF |
Page 131
2nd paragraph of 'Patterns for Specifying Hosts' |
'...which lets will run a play against all known hosts:'
Should probably read: '... which lets you run a play...'
|
Anonymous |
Jan 03, 2017 |
|
| PDF |
Page 134
1st paragraph |
'... that are useful when a variable contains the path to a variable on the control machine’s filesystem.'
Should probably read: '...that are useful when a variable contains the path to a file...'
|
Anonymous |
Jan 03, 2017 |
|
| PDF |
Page 134
Table 7-4 |
Table 7-4 contains no header. Instead the first row of content is formatted as a header.
|
Anonymous |
Jan 03, 2017 |
|
| PDF |
Page 145
middle of the page |
We could iterate over this dictionary and print out the entries one at a time by doing:
- name: iterate over ansible_eth0
debug: msg={{ item.key }}={{ item.value }}
with_dict: ansible_eth0.ipv4
should be:
- name: iterate over ansible_eth0
debug: msg={{ item.key }}={{ item.value }}
with_dict: "{{ ansible_eth0.ipv4 }}"
|
Andrey Hsiao |
Feb 15, 2017 |
|
| PDF |
Page 148
In "Where Does Ansible Look for My Roles?" section. |
(Very minor typo)
"in the roles directory alongside your . playbooks."
->
"in the roles directory alongside your playbooks."
|
Jon Forrest |
Sep 29, 2016 |
|
| PDF |
Page 150
1st paragraph |
"and you wanted to send a notification to Slack channel"
->
"and you wanted to send a notification to a Slack channel"
|
Jon Forrest |
Dec 03, 2016 |
|
| PDF |
Page 150
2nd paragraph |
"and a list of tasks that executes after the roles"
->
"and a list of tasks that execute after the roles"
[See the first part of that sentence. Do you see the inconsistency?]
|
Jon Forrest |
Dec 03, 2016 |
|
| PDF |
Page 154
1st full paragraph |
"Example 8-9 shows the default variables defined on our mezzanine role."
->
"Example 8-9 shows the default variables defined in our mezzanine role."
|
Jon Forrest |
Dec 11, 2016 |
|
| PDF |
Page 163
Toward the bottom of the page. |
"and another session to execute the host."
Is this really what you mean? Shouldn't it be
"and another session to execute the module"
|
Jon Forrest |
Sep 30, 2016 |
|
| PDF |
Page 163
4th paragraph |
"This will time how long it takes to indicate an SSH connection"
->
"This will time how long it takes to initiate an SSH connection"
|
Jon Forrest |
Jan 02, 2017 |
|
| PDF |
Page 163
2nd to last paragraph |
"and another session to execute the host"
->
"and another session to execute the module file"
|
Jon Forrest |
Jan 02, 2017 |
|
| Printed |
Page 164
Last paragraph |
Text reads:
$HOME/.ansible.cp
Should be:
$HOME/.ansible/cp
|
Jon Brandenburg |
May 30, 2015 |
|
| PDF |
Page 165
2nd paragraph |
"There is a built-in Jinja2 filter called join, that will join a list of strings with a delimiter such as a column."
->
"There is a built-in Jinja2 filter called join, that will join a list of strings with a
delimiter such as a comma".
|
Jon Forrest |
Nov 26, 2016 |
|
| PDF |
Page 168
1st line |
(This is a very trivial error)
"Example 9-7. ansible.cfg Enable fact caching"
->
"Example 9-7. ansible.cfg enable fact caching"
(You don't capitalize words in example captions elsewhere in the book.)
|
Jon Forrest |
Jan 02, 2017 |
|
| PDF |
Page 168
Last paragraph |
(This is another extremely trivial error).
"To enable the JSON fact-caching backend"
->
"To enable the JSON file fact-caching backend"
(This is to be consistent with the usage in the previous paragraph.)
|
Jon Forrest |
Jan 02, 2017 |
|
| ePub |
Page 181
`changed_when` examples |
3 examples are:
> [...] "Creating tables" *not* in result.out [...]
Should be:
> [...] "Creating tables" in result.out [...]
(The 'not' is only for the `failed_when`: `"Database already created" not in result.msg`)
Note from the Author or Editor: In Chapter 7, the following changes should be made:
-changed_when: result.out is defined and "Creating tables" not in result.out
+changed_when: result.out is defined and "Creating tables" in result.out
-changed_when: '"Creating tables" not in result.out|default("")'
+changed_when: '"Creating tables" in result.out|default("")'
-changed_when: not result.failed and "Creating tables" not in result.out
+changed_when: not result.failed and "Creating tables" in result.out
|
Alexandre Garnier |
Nov 02, 2015 |
|
| ePub |
Page 182-183
Last code of "Retrieving the IP Address from the Host" |
Code is:
> live_hostname: "{{ ansible_eth1.ipv4.address }}.xip.io"
> domains:
> - ansible_eth1.ipv4.address.xip.io
> - www.ansible_eth1.ipv4.address.xip.io
Should be:
> live_hostname: "{{ ansible_eth1.ipv4.address }}.xip.io"
> domains:
> - {{ ansible_eth1.ipv4.address }}.xip.io
> - www.{{ ansible_eth1.ipv4.address }}.xip.io
Note from the Author or Editor: The reader is correct, the text in the book should be replaced as follows:
live_hostname: "{{ ansible_eth1.ipv4.address }}.xip.io"
domains:
- - ansible_eth1.ipv4.address.xip.io
- - www.ansible_eth1.ipv4.address.xip.io
+ - "{{ ansible_eth1.ipv4.address }}.xip.io"
+ - "www.{{ ansible_eth1.ipv4.address }}.xip.io"
|
Alexandre Garnier |
Nov 02, 2015 |
|
| Printed |
Page 193
title of final paragraph |
"Specifying an Alternaive Location for Bash"
"Alternaive" should be "Alternative".
|
Kerim Satirli |
Jul 04, 2015 |
|
| PDF |
Page 204
2nd to last paragraph |
"they typically give you provision storage so you can attach and detach
disks to your servers."
->
"they typically let you provision storage so you can attach and detach
disks to your servers."
|
Jon Forrest |
Oct 01, 2016 |
|
| PDF |
Page 206, 207
Bottom of 206, top of 207 |
You contradict yourself. On Page 206 you say:
"I recommend that you always explicitly pass the EC2 region as an argument when invoking your modules."
but on Page 207 you say:
"I recommend using environment variables because it allows you to use EC2-related modules and inventory plug-ins without putting your
credentials in any of your Ansible-related files."
Which is it?
Note from the Author or Editor: p207 should change to:
I recommend using environment variables for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY because...
|
Jon Forrest |
Oct 01, 2016 |
|
| PDF |
Page 208
Example 12-3 |
Now the following URLs are not found.
https://raw.githubusercontent.com/ansible/ansible/devel/plugins/inventory/ec2.py
https://raw.githubusercontent.com/ansible/ansible/devel/plugins/inventory/ec2.ini
It looks like they have moved to the following URLs respectively:
https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.py
https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.ini
|
Kohei Nozaki |
Sep 09, 2015 |
|
| Printed |
Page 214
footnote no. 8 |
"... but I must admit that I never bothing doing this ..."
"bothing" should be "bother", I believe.
|
Kerim Satirli |
Jul 04, 2015 |
|
| Printed |
Page 218 - 219
Example 12-8. Security groups |
The first two security groups defined here (web and ssh) do not have the region defined. The third and final group (outbound) does like so:
region: "{{ region }}"
When I look at the complete playbook on Page 226 - Example 12-13 all three plays for the ec2 groups (web, ssh, and outbound) define the region.
|
Jon Brandenburg |
Jun 05, 2015 |
|
| Printed, PDF, ePub |
Page 220
Last paragraph of Security Group Ports - 2nd word |
Text states: "The c2_group module ..."
It should state: "The ec2_group module ..."
|
Jon Brandenburg |
May 30, 2015 |
|
| Printed |
Page 227
3rd play: - name: start the instances |
defines the group as following:
group: [web, ssh outbound]
should define it as:
group: [web, ssh, outbound]
|
Jon Brandenburg |
Jun 05, 2015 |
|
| Printed |
Page 271
1st paragraph |
"... you encounter colleagues who is in clear need"
The "is" should be an "are" here, I believe.
|
Kerim Satirli |
Jul 04, 2015 |
|
| Printed |
Page 290
Step 7 - Select "Power User Access." |
Step 7 seems out of date. When I look at the options I am presented with "PowerUserAccess" not "Power User Access" and I do not see anything that resembles the example in C-1, nor the last two sentences in Step 7.
Note from the Author or Editor: It appears that Amazon has, indeed changed the interface. Steps 7-9 should be replaced with steps 7-8 below:
7. Select "PowerUserAccess" and click "Next Step"
8. Click "Create Role"
If you click on the name of the role and click the "Show Policy" link, you should see the user policy document as shown in Example C-1.
|
Jon Brandenburg |
Jun 04, 2015 |
|