update index

index.html

@@ -183,13 +183,13 @@ tasks, quickly firing off commands against nodes.  See <a class="reference inter
 deployment processes, executing ordered sequences on
 different sets of nodes through <a class="reference internal" href="playbooks.html"><em>Playbooks</em></a>.   Playbooks contain one or
 more plays, each executed against a different batch of nodes.  Think about
-webservers, database servers, and backend servers in a multi-node web environment.  A play could address each set of machines in a cycle, ensuring the configurations of the machines were correct and also updating them to the specified
+webservers, database servers, and backend servers in a multi-node web environment.  A play can address each set of machines in a cycle, ensuring the configurations of the machines were correct and also updating them to the specified
 version of software if required.</p>
 <p>Multi-machine software deployment is poorly solved by most systems management tools &#8211; often due to architectural nature of being pull oriented and having complex ordering systems, they cover configuration  but fail at deployment when updating tiers of machines in well defined steps. This results in using two (or more) logically distinct tools and having complex overlap between them.</p>
 </div>
 <div class="section" id="deployment-and-configuration-unified">
 <h2>Deployment and Configuration, Unified<a class="headerlink" href="#deployment-and-configuration-unified" title="Permalink to this headline">¶</a></h2>
-<p>Other deployment oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts.  Ansible playbooks &#8211; having been designed with this problem in mind &#8211; are good at both deployment &amp; idempotent configuration, meaning you don&#8217;t have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc), and performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required &#8211; while avoiding the problem of fragile scripting that assumes certain starting
+<p>Other deployment (compared to config) oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts.  Ansible playbooks &#8211; having been designed with this problem in mind &#8211; are good at both deployment &amp; idempotent configuration, meaning you don&#8217;t have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc), and performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required &#8211; while avoiding the problem of fragile scripting that assumes certain starting
 or ending states.</p>
 <p>Ansible is also unique in other ways.  Extending ansible does not require programming in any particular language &#8211; you can write <a class="reference internal" href="modules.html"><em>Ansible Modules</em></a> as idempotent scripts or programs that return simple JSON.   Ansible is also pragmatic, so when you need to, it&#8217;s also trivially easy to just execute useful shell commands.</p>
 <p>Why use Ansible versus other configuration management tools?  (Puppet, Chef, etc?) Ansible will have far
@@ -200,7 +200,7 @@ to use (not being code) and also allows intermixing of idempotent configuration
 of control.  Further, it was designed for deploying multi-node applications from the beginning.</p>
 <div class="section" id="simple-secure-by-default">
 <h3>Simple &amp; Secure By Default<a class="headerlink" href="#simple-secure-by-default" title="Permalink to this headline">¶</a></h3>
-<p>Compared with most configuration managememnt tools, Ansible is also more secure.  While most configuration management tools use a daemon, running as root with full access to the system, with its own in-house developed PKI infrastructure, Ansible just uses SSH (and supports sudo as neccesssary).  There is no additional attack surface and OpenSSH is one of the most peer reviewed security components out there.
+<p>Compared with most configuration managememnt tools, Ansible is also much more secure.  While most configuration management tools use a daemon, running as root with full access to the system, with its own in-house developed PKI infrastructure, Ansible just uses SSH (and supports sudo as neccesssary).  There is no additional attack surface and OpenSSH is one of the most peer reviewed security components out there.
 If a central server containing your playbooks are comprimised, your nodes are not &#8211; which is NOT the case
 of these other tools, which can, more or less, turn into a botnet.  Our security approach is to avoid writing custom
 crypto code altogether, and rely on the most secure part of the Linux/Unix subsystem that your machines are already using.  There is no PKI subsystem to maintain, which can be a frequent source of problems, particularly when reinstalling or migrating

rst/index.rst

@@ -34,7 +34,7 @@ Where Ansible excels though, is expressing complex multi-node
 deployment processes, executing ordered sequences on 
 different sets of nodes through :doc:`playbooks`.   Playbooks contain one or
 more plays, each executed against a different batch of nodes.  Think about
-webservers, database servers, and backend servers in a multi-node web environment.  A play could address each set of machines in a cycle, ensuring the configurations of the machines were correct and also updating them to the specified
+webservers, database servers, and backend servers in a multi-node web environment.  A play can address each set of machines in a cycle, ensuring the configurations of the machines were correct and also updating them to the specified
 version of software if required.
 
 Multi-machine software deployment is poorly solved by most systems management tools -- often due to architectural nature of being pull oriented and having complex ordering systems, they cover configuration  but fail at deployment when updating tiers of machines in well defined steps. This results in using two (or more) logically distinct tools and having complex overlap between them.  
@@ -42,7 +42,7 @@ Multi-machine software deployment is poorly solved by most systems management to
 Deployment and Configuration, Unified
 +++++++++++++++++++++++++++++++++++++
 
-Other deployment oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts.  Ansible playbooks -- having been designed with this problem in mind -- are good at both deployment & idempotent configuration, meaning you don't have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc), and performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required -- while avoiding the problem of fragile scripting that assumes certain starting
+Other deployment (compared to config) oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts.  Ansible playbooks -- having been designed with this problem in mind -- are good at both deployment & idempotent configuration, meaning you don't have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc), and performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required -- while avoiding the problem of fragile scripting that assumes certain starting
 or ending states.
 
 Ansible is also unique in other ways.  Extending ansible does not require programming in any particular language -- you can write :doc:`modules` as idempotent scripts or programs that return simple JSON.   Ansible is also pragmatic, so when you need to, it's also trivially easy to just execute useful shell commands.
@@ -57,7 +57,7 @@ of control.  Further, it was designed for deploying multi-node applications from
 Simple & Secure By Default
 ``````````````````````````
 
-Compared with most configuration managememnt tools, Ansible is also more secure.  While most configuration management tools use a daemon, running as root with full access to the system, with its own in-house developed PKI infrastructure, Ansible just uses SSH (and supports sudo as neccesssary).  There is no additional attack surface and OpenSSH is one of the most peer reviewed security components out there.
+Compared with most configuration managememnt tools, Ansible is also much more secure.  While most configuration management tools use a daemon, running as root with full access to the system, with its own in-house developed PKI infrastructure, Ansible just uses SSH (and supports sudo as neccesssary).  There is no additional attack surface and OpenSSH is one of the most peer reviewed security components out there.
 If a central server containing your playbooks are comprimised, your nodes are not -- which is NOT the case
 of these other tools, which can, more or less, turn into a botnet.  Our security approach is to avoid writing custom
 crypto code altogether, and rely on the most secure part of the Linux/Unix subsystem that your machines are already using.  There is no PKI subsystem to maintain, which can be a frequent source of problems, particularly when reinstalling or migrating