Merge pull request #370 from stencell/nstephan-update

ansible_rhel exercise doc fixes

exercises/ansible_rhel/1.1-setup/README.md

@@ -62,9 +62,9 @@ Log out of the root account again:
 
 You might have guessed by now this lab is pretty commandline-centric…​ :-)
 
-  - Don’t type everything manually, use copy & paste from the browser when appropriate. But don’t stop to think and understand.
+  - Don’t type everything manually, use copy & paste from the browser when appropriate. But stop to think and understand.
 
-  - All labs where prepared using **Vim**, but we understand not everybody loves it. Feel free to use alternative editors, in the lab environment we provide **Midnight Commander** (just run **mc**, function keys can be reached via Esc-\<n\> or simply clicked with the mouse) or **Nano** (run **nano**). Here is a short [editor intro](../0.0-support-docs/editor_intro.md).
+  - All labs were prepared using **Vim**, but we understand not everybody loves it. Feel free to use alternative editors. In the lab environment we provide **Midnight Commander** (just run **mc**, function keys can be reached via Esc-\<n\> or simply clicked with the mouse) or **Nano** (run **nano**). Here is a short [editor intro](../0.0-support-docs/editor_intro.md).
 
 > **Tip**
 >

exercises/ansible_rhel/1.2-adhoc/README.md

@@ -23,7 +23,7 @@ node3 ansible_host=<Z.Z.Z.Z>
 ansible ansible_host=44.55.66.77
 ```
 
-Ansible is already configured to use the inventory specific to your use case. We will show you in the next step how that is done. For now, we will execute some simple commands to work with the inventory.
+Ansible is already configured to use the inventory specific to your environment. We will show you in the next step how that is done. For now, we will execute some simple commands to work with the inventory.
 
 To reference inventory hosts, you supply a host pattern to the ansible command. Ansible has a `--list-hosts` option which can be useful for clarifying which managed hosts are referenced by the host pattern in an ansible command.
 
@@ -44,7 +44,7 @@ An inventory file can contain a lot more information, it can organize your hosts
 [student<X@>ansible ~]$ ansible all --list-hosts
 ```
 
-AS you see it is ok to put systems in more than one group, for instance a server could be both a web server and a database server. Note that in Ansible the groups are not necessarily hierarchical.
+As you see it is OK to put systems in more than one group. For instance, a server could be both a web server and a database server. Note that in Ansible the groups are not necessarily hierarchical.
 
 > **Tip**
 >
@@ -56,7 +56,7 @@ The behavior of Ansible can be customized by modifying settings in Ansible’s i
 
 > **Tip**
 >
-> The recommended practice is to create an `ansible.cfg` file in the directory from which you run Ansible commands. This directory would also contain any files used by your Ansible project, such as the inventory and Playbooks. Another practice is to create a file `.ansible.cfg` in your home directory.
+> The recommended practice is to create an `ansible.cfg` file in the directory from which you run Ansible commands. This directory would also contain any files used by your Ansible project, such as the inventory and playbooks. Another recommended practice is to create a file `.ansible.cfg` in your home directory.
 
 In the lab environment provided to you an `.ansible.cfg` file has already been created and filled with the necessary details in the home directory of your `student<X>` user on the control node:
 
@@ -81,7 +81,7 @@ inventory = /home/student<X>/lab_inventory/hosts
 
 There are multiple configuration flags provided. Most of them are not of interest here, but make sure to note the last line: there the location of the inventory is provided. That is the way Ansible knew in the previous commands what machines to connect to.
 
-Output the content of your dedicated inventory to proof-read
+Output the content of your dedicated inventory:
 
 ```bash
 [student<X>@ansible ~]$ cat /home/student<X>/lab_inventory/hosts
@@ -101,15 +101,15 @@ ansible ansible_host=44.55.66.77
 
 > **Tip**
 >
-> Note that each student has an individual lab environment. The ip addresses shown above are only an example, the ip addresses of your individual environment are different. As with the other cases, replace **\<X\>** with your actual student number.
+> Note that each student has an individual lab environment. The IP addresses shown above are only an example and the IP addresses of your individual environments are different. As with the other cases, replace **\<X\>** with your actual student number.
 
 ## Step 2.3 - Ping a host
 
 > **Warning**
 >
 > **Don’t forget to run the commands from the home directory of your student user, `/home/student<X>`. That is where your `.ansible.cfg` file is located, without it Ansible will not know what which inventory to use.**
 
-Let's start with something really basic - pinging a host. To do that we use the Ansible `ping` module. The `ping` module makes sure our web hosts are responsive. Basically, it connects to the managed host, executes a small script there and collects the results. That way it is ensured that the managed host is reachable and that Ansible is able to execute commands properly on it.
+Let's start with something really basic - pinging a host. To do that we use the Ansible `ping` module. The `ping` module makes sure our target hosts are responsive. Basically, it connects to the managed host, executes a small script there and collects the results. This ensures that the managed host is reachable and that Ansible is able to execute commands properly on it.
 
 > **Tip**
 >
@@ -161,14 +161,14 @@ Get help for a specific module including usage examples:
 
 ## Step 2.5 - Use the command module:
 
-Now let's see how we can run a good ol' fashioned Linux command and format the output using the `command` module. It just executes a command on a managed host:
+Now let's see how we can run a good ol' fashioned Linux command and format the output using the `command` module. It simply executes the specified command on a managed host:
 
 ```bash
 [student<X>@ansible ~]$ ansible node1 -m command -a "id"
 node1 | CHANGED | rc=0 >>
 uid=1001(student1) gid=1001(student1) Gruppen=1001(student1) Kontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
 ```
-In this case the module is called `command` and the option passed with `-a` is the actual command to run. Try to run this ad hoc command on both hosts using the `all` host pattern.
+In this case the module is called `command` and the option passed with `-a` is the actual command to run. Try to run this ad hoc command on all managed hosts using the `all` host pattern.
 
 Another example: Have a quick look at the kernel versions your hosts are running:
 
@@ -190,11 +190,7 @@ Sometimes it’s desirable to have the output for a host on one line:
 
 Using the `copy` module, execute an ad hoc command on `node1` to change the contents of the `/etc/motd` file. **The content is handed to the module through an option in this case**.
 
-Run:
-
-> **Warning**
->
-> **Expect an error\!**
+Run the following, but **expect an error**:
 
 ```bash
 [student<X>@ansible ~]$ ansible node1 -m copy -a 'content="Managed by Ansible\n" dest=/etc/motd'
@@ -213,7 +209,7 @@ As mentioned this produces an **error**:
 
 The output of the ad hoc command is screaming **FAILED** in red at you. Why? Because user **student\<X\>** is not allowed to write the motd file.
 
-Now this is a case for privilege escalation and the reason `sudo` has to be setup properly. We need to instruct ansible to use `sudo` to run the command as root by using the parameter `-b` (think "become").
+Now this is a case for privilege escalation and the reason `sudo` has to be setup properly. We need to instruct Ansible to use `sudo` to run the command as root by using the parameter `-b` (think "become").
 
 > **Tip**
 >

exercises/ansible_rhel/1.3-playbook/README.md

@@ -64,7 +64,7 @@ On your control host **ansible**, create a directory called `ansible-files` in y
 [student<X>@ansible ~]$ cd ansible-files/
 ```
 
-Add a file called `apache.yml` with the following content. As in the previous chapters, use `vi` or `vim` for that. If you are new to editors on the command line, check out the [editor intro](../0.0-support-docs/editor_intro.md) again.
+Add a file called `apache.yml` with the following content. As discussed in the previous exercises, use `vi`/`vim` or, if you are new to editors on the command line, check out the [editor intro](../0.0-support-docs/editor_intro.md) again.
 
 ```yaml
 ---
@@ -106,14 +106,19 @@ In the added lines:
 
   - We started the tasks part with the keyword `tasks:`.
 
-  - A task is named and the a module for the task is referenced. Here it uses the module "yum".
+  - A task is named and the module for the task is referenced. Here it uses the `yum` module.
 
-  - Parameters for the module are added: `name:` to identify the package name, and `state:` to define the wanted state of the package.
+  - Parameters for the module are added: 
+
+    - `name:` to identify the package name
+    - `state:` to define the wanted state of the package
 
 > **Tip**
 >
 > The module parameters are individual to each module. If in doubt, look them up again with `ansible-doc`.
 
+Save your playbook and exit your editor.
+
 ## Step 3.3 - Running the Playbook
 
 Playbooks are executed using the `ansible-playbook` command on the control node. Before you run a new Playbook it’s a good idea to check for syntax errors:
@@ -127,7 +132,7 @@ Now you should be ready to run your Playbook:
 ```bash
 [student<X>@ansible ansible-files]$ ansible-playbook apache.yml
 ```
-The output should not report any errors but provide an overview of the tasks executed and a play recap summarizing what has been done. There is also a task called "Gathering Facts" listed there: this is an in-built task run automatically at the beginning of each play. It collects information about the managed nodes, a later chapter will discuss this.
+The output should not report any errors but provide an overview of the tasks executed and a play recap summarizing what has been done. There is also a task called "Gathering Facts" listed there: this is an built-in task that runs automatically at the beginning of each play. It collects information about the managed nodes. Exercises later on will cover this in more detail.
 
 Use SSH to make sure Apache has been installed on `node1`. The necessary IP address is provided in the inventory. Grep for the IP address there and use it to SSH to the node.
 

exercises/ansible_rhel/1.4-variables/README.md

@@ -3,7 +3,7 @@
 **Read this in other languages**: ![uk](../../../images/uk.png) [English](README.md),  ![japan](../../../images/japan.png) [日本語](README.ja.md).
 
 Previous exercises showed you the basics of Ansible Engine.  In the next few exercises, we are going
-to teach some more advanced ansible skills that will add flexibility and power to your playbooks.
+to teach some more advanced Ansible skills that will add flexibility and power to your playbooks.
 
 Ansible exists to make tasks simple and repeatable.  We also know that not all systems are exactly alike and often require
 some slight change to the way an Ansible playbook is run.  Enter variables.
@@ -22,19 +22,19 @@ Variables and their values can be defined in various places: the inventory, addi
 
 The recommended practice to provide variables in the inventory is to define them in files located in two directories named `host_vars` and `group_vars`:
 
-  - To e.g. define variables for a group "servers", a YAML file named `group_vars/servers` with the variable definitions is created.
+  - To define variables for a group "servers", a YAML file named `group_vars/servers` with the variable definitions is created.
 
   - To define variables specifically for a host `node1`, the file `host_vars/node1` with the variable definitions is created.
 
 > **Tip**
 >
-> Host variables take precedence over group variables (more about precedence can be found in the docs).
+> Host variables take precedence over group variables (more about precedence can be found in the [docs](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable)).
 
 ## Step 4.1 - Create Variable Files
 
-For understanding and practice let’s do a lab. Following up on the theme "Let’s build a webserver. Or two. Or even more…​" you will change the `index.html` to show the development environment (dev/prod) a server is deployed in.
+For understanding and practice let’s do a lab. Following up on the theme "Let’s build a webserver. Or two. Or even more…​", you will change the `index.html` to show the development environment (dev/prod) a server is deployed in.
 
-On the ansible control host, as user ansible create the directories to hold the variable definitions in `~/ansible-files/`:
+On the ansible control host, as the `student` user, create the directories to hold the variable definitions in `~/ansible-files/`:
 
 ```bash
 [student<X>@ansible ansible-files]$ mkdir host_vars group_vars

exercises/ansible_rhel/1.5-handlers/README.md

@@ -72,7 +72,7 @@ changed: [node2]
 
 ## Step 5.2 - Handlers
 
-Sometimes when a task does make a change to the system, a further task may need to be run. For example, a change to a service’s configuration file may then require that the service be restarted so that the changed configuration takes effect.
+Sometimes when a task does make a change to the system, an additional task or tasks may need to be run. For example, a change to a service’s configuration file may then require that the service be restarted so that the changed configuration takes effect.
 
 Here Ansible’s handlers come into play. Handlers can be seen as inactive tasks that only get triggered when explicitly invoked using the "notify" statement. Read more about them in the [Ansible Handlers](http://docs.ansible.com/ansible/latest/playbooks_intro.html#handlers-running-operations-on-change) documentation.
 
@@ -113,7 +113,7 @@ Next, create the Playbook `httpd_conf.yml`. Make sure that you are in the direct
 
 So what’s new here?
 
-  - The "notify" section calls the handler only when the copy task changed the file. That way the service is only restarted if needed - and not each time the playbook is run.
+  - The "notify" section calls the handler only when the copy task actually changes the file. That way the service is only restarted if needed - and not each time the playbook is run.
 
   - The "handlers" section defines a task that is only run on notification.
 
@@ -146,7 +146,7 @@ Feel free to change the httpd.conf file again and run the Playbook.
 
 ## Step 5.3 - Simple Loops
 
-Loops enable us to repeat the same task over and over again. For example, lets say you want to create multiple users. By using an Ansible loop, you can do that in a single task. Loops can also iterate over more than just lists: for example if you have a list of users with their coresponding group, loop can iterate over them as well. Find out more about loops in the [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) documentation.
+Loops enable us to repeat the same task over and over again. For example, lets say you want to create multiple users. By using an Ansible loop, you can do that in a single task. Loops can also iterate over more than just basic lists. For example, if you have a list of users with their coresponding group, loop can iterate over them as well. Find out more about loops in the [Ansible Loops](https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html) documentation.
 
 To show the loops feature we will generate three new users on `node1`. For that, create the file `loop_users.yml` in `~/ansible-files` on your control node as your student user. We will use the `user` module to generate the user accounts.
 

exercises/ansible_rhel/1.6-templates/README.md

@@ -42,11 +42,11 @@ You have done this a couple of times by now:
 
   - Understand what the Playbook does.
 
-  - Execute the Playbook `motd-facts.yml`
+  - Execute the Playbook `motd-facts.yml`.
 
-  - Login to node1 via SSH and check the motto of the day message.
+  - Login to node1 via SSH and check the message of the day content.
 
-  - Log out of node1
+  - Log out of node1.
 
 You should see how Ansible replaces the variables with the facts it discovered from the system.
 

exercises/ansible_rhel/1.7-role/README.md

@@ -4,13 +4,13 @@
 
 While it is possible to write a playbook in one file as we've done throughout this workshop, eventually you’ll want to reuse files and start to organize things.
 
-Ansible Roles is the way we do this.  When you create a role, you deconstruct your playbook into parts and those parts sit in a directory structure.  This is explained in more detail in the [best practice](http://docs.ansible.com/ansible/playbooks_best_practices.html) already mentioned in exercise 3.
+Ansible Roles are the way we do this.  When you create a role, you deconstruct your playbook into parts and those parts sit in a directory structure.  This is explained in more detail in the [best practice](http://docs.ansible.com/ansible/playbooks_best_practices.html) already mentioned in exercise 3.
 
 ## Step 7.1 - Understanding the Ansible Role Structure
 
-Roles are basically automation around *include* directives as described above, and really don’t contain much additional magic beyond some improvements to search path handling for referenced files.
+Roles are basically automation built around *include* directives and really don’t contain much additional magic beyond some improvements to search path handling for referenced files.
 
-Roles follow a defined directory structure, a role is named by the top level directory. Some of the subdirectories contain YAML files, named `main.yml`. The files and templates subdirectories can contain objects referenced by the YAML files.
+Roles follow a defined directory structure; a role is named by the top level directory. Some of the subdirectories contain YAML files, named `main.yml`. The files and templates subdirectories can contain objects referenced by the YAML files.
 
 An example project structure could look like this, the name of the role would be "apache":
 
@@ -34,7 +34,7 @@ apache/
     └── main.yml
 ```
 
-The `main.yml` files contain content depending on the corresponding directory:  `vars/main.yml` references variables, `handlers/main.yaml` describes handlers, and so on. Note that in contrast to playbooks, the `main.yml` files only contain the specific content and not additional playbook information like hosts, `become` or other keywords.
+The various `main.yml` files contain content depending on their location in the directory structure shown above. For instance, `vars/main.yml` references variables, `handlers/main.yaml` describes handlers, and so on. Note that in contrast to playbooks, the `main.yml` files only contain the specific content and not additional playbook information like hosts, `become` or other keywords.
 
 > **Tip**
 >