Fix inconsistent heading sizes

index.html

@@ -129,12 +129,10 @@ s.parentNode.insertBefore(ga, s);
   <span class="localtoc"><ul>
 <li><a class="reference internal" href="#">Introducing Ansible</a><ul>
 <li><a class="reference internal" href="#innovative-multi-node-control">Innovative Multi-node Control</a></li>
-<li><a class="reference internal" href="#deployment-and-configuration-unified">Deployment and Configuration, Unified</a><ul>
+<li><a class="reference internal" href="#deployment-and-configuration-unified">Deployment and Configuration, Unified</a></li>
 <li><a class="reference internal" href="#simple-secure-by-default">Simple &amp; Secure By Default</a></li>
 </ul>
 </li>
-</ul>
-</li>
 <li><a class="reference internal" href="#architecture">Architecture</a></li>
 <li><a class="reference internal" href="#features">Features</a></li>
 <li><a class="reference internal" href="#resources">Resources</a></li>
@@ -198,8 +196,9 @@ easiest thing to hack on and use you&#8217;ll ever see &#8211; regardless of you
 favorite language of choice.  Versus other deployment tools?  (Capistrano, Fabric?).  Ansible playbooks are easier
 to use (not being code) and also allows intermixing of idempotent configuration management rules for a higher level
 of control.  Further, it was designed for deploying multi-node applications from the beginning.</p>
+</div>
 <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>
+<h2>Simple &amp; Secure By Default<a class="headerlink" href="#simple-secure-by-default" title="Permalink to this headline">¶</a></h2>
 <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
@@ -208,7 +207,6 @@ hosts.</p>
 <p>Systems management doesn&#8217;t have to be complicated.  Ansible&#8217;s docs will remain short &amp; simple, and the source will be blindingly obvious.  We&#8217;ve learned well from &#8220;Infrastructure is Code&#8221;.  Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project &#8211; bugs, complexity, and overhead.  Infrastructure configurations should be simple, easy to develop, and easy to audit.</p>
 </div>
 </div>
-</div>
 <div class="section" id="architecture">
 <h1>Architecture<a class="headerlink" href="#architecture" title="Permalink to this headline">¶</a></h1>
 <div align="center" class="align-center"><img alt="&quot;Architecture Diagram&quot;" class="align-center" src="http://ansible.github.com/ansible_arch2.jpg" style="width: 800px;" /></div>

rst/index.rst

@@ -28,7 +28,7 @@ Ansible isn't just for idempotent configuration -- it's also great for ad-hoc
 tasks, quickly firing off commands against nodes.  See :doc:`examples`.
 
 Innovative Multi-node Control
-+++++++++++++++++++++++++++++
+`````````````````````````````
 
 Where Ansible excels though, is expressing complex multi-node 
 deployment processes, executing ordered sequences on 
@@ -40,7 +40,7 @@ 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.  
 
 Deployment and Configuration, Unified
-+++++++++++++++++++++++++++++++++++++
+`````````````````````````````````````
 
 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.