War on typos

Also cleanup whitespace and break some long lines

doc/ref/cli/index.rst

@@ -2,9 +2,9 @@
 Command Line Reference
 ======================
 
-Salt can be controlled by a command line client by the root user on the Salt 
+Salt can be controlled by a command line client by the root user on the Salt
 master. The Salt command line client uses the Salt client API to communicate
-with the Salt master server. The Salt client is straightforward and simple 
+with the Salt master server. The Salt client is straightforward and simple
 to use.
 
 Using the Salt client commands can be easily sent to the minions.

doc/ref/cli/salt.rst

@@ -99,7 +99,7 @@ Options
     form, this is suitable for re-reading the output into
     an executing python script with eval.
 
-.. option::   --text-out         
+.. option::   --text-out
 
     Print the output from the salt command in the same
     form the shell would.

doc/ref/configuration/master.rst

@@ -206,7 +206,7 @@ root of the base environment
 Default: None
 
 The external_nodes option allows Salt to gather data that would normally be
-placed in a top file from and external node controller. The external_nodes 
+placed in a top file from and external node controller. The external_nodes
 option is the executable that will return the ENC data. Remember that Salt
 will look for external nodes AND top files and combine the results if both
 are enabled and available!

doc/ref/configuration/minion.rst

@@ -91,7 +91,7 @@ clusters.
 ``sub_timeout``
 ---------------
 
-The minion connection to the master may be inturupted, the minion will
+The minion connection to the master may be interrupted, the minion will
 verify the connection every so many seconds, to disable connection
 verification set this value to 0
 
@@ -172,7 +172,7 @@ disabling modules will lover the minion's ram footprint.
 
 Default: ``[]`` (all returners are enabled by default)
 
-If certian returners should be disabled, this is the place
+If certain returners should be disabled, this is the place
 
 .. code-block:: yaml
 
@@ -274,7 +274,7 @@ The default renderer used for local state executions
 Default: ``False``
 
 state_verbose allows for the data returned from the minion to be more
-verbose. Normaly only states that fail or states that have changes are
+verbose. Normally only states that fail or states that have changes are
 returned, but setting state_verbose to True will return all states that
 were checked
 

doc/ref/file_server/dynamic-modules.rst

@@ -18,7 +18,7 @@ The directories are prepended with an underscore:
 
 The contents of these directories need to be synced over to the minions after
 python modules have been created in them. There are a number of ways to sync
-the modules. 
+the modules.
 
 Sync Via States
 ===============

doc/ref/file_server/file_roots.rst

@@ -6,7 +6,7 @@ The Salt file server is a high performance file server written in ZeroMQ. It
 manages large files quickly and with little overhead, and has been optimized
 to handle small files in an extremely efficient manner.
 
-The Salt file server is an environment aware file server, this means that 
+The Salt file server is an environment aware file server, this means that
 files can be allocated within many root directories and accessed by
 specifying both the file path and the environment to search. The
 individual environments can also be spanned across multiple directory roots

doc/ref/file_server/index.rst

@@ -4,7 +4,7 @@ Salt File Server
 
 Salt comes with a simple file server suitable for distributing files to the
 salt minions. The file server is a stateless ZeroMQ server that is built into
-the salt master. 
+the salt master.
 
 The main intent of the Salt File server is to present files for use in the
 Salt state system. With this said, the Salt file server can be used for any

doc/ref/modules/index.rst

@@ -32,7 +32,7 @@ This means that when creating a module functions in modules which already exist
 can be called.
 
 The variable ``__salt__`` is packed into the modules after they are loaded into
-the salt minion. This variable is a python dictionary of all of the salt 
+the salt minion. This variable is a python dictionary of all of the salt
 functions, laid out in the same way that they are made available to the salt
 command.
 
@@ -40,7 +40,7 @@ Salt modules can be cross called by accessing the value in the ``__salt__``
 dict:
 
 .. code-block:: python
-    
+
     def foo(bar):
         return __salt__['cmd.run'](bar)
 

doc/ref/python-api.rst

@@ -65,7 +65,7 @@ Compound Command Execution With the Salt API
 The Salt client API can also send what is called a compound command. Often
 a collection of commands need to be executed on the targeted minions, rather
 than send the commands one after another, they can be send in a single publish
-containing a series of commands. This can dramatically lower overhead and 
+containing a series of commands. This can dramatically lower overhead and
 speed up the application communicating with Salt.
 
 When commands are executed with compound execution the minion functions called

doc/ref/returners/index.rst

@@ -38,7 +38,7 @@ It is also possible to specify multiple returners:
     salt '*' test.ping --return mongo_return,redis_return,cassandra_return
 
 In this scenario all three returners will be called and the data from the
-test.ping command will be sent out to the three named returers.
+test.ping command will be sent out to the three named returners.
 
 Writing a Returner
 ==================

doc/ref/runners.rst

@@ -32,7 +32,7 @@ The best examples of runners can be found in the Salt source:
 
 :blob:`salt/runners`
 
-A simple runner that returns a well formated list of the minons that are
+A simple runner that returns a well-formatted list of the minions that are
 responding to salt calls would look like this:
 
 .. code-block:: python

doc/ref/states/highstate.rst

@@ -14,7 +14,7 @@ The Salt State Tree
         Configurable via :conf_master:`state_top`.
 
         .. seealso:: :doc:`A detailed description of the top file </ref/states/top>`
-        
+
 .. glossary::
 
     State tree
@@ -98,7 +98,7 @@ declaration that will restart Apache whenever the Apache configuration file,
 
     include:
       - apache
-    
+
     extend:
       apache:
         service:
@@ -108,7 +108,7 @@ declaration that will restart Apache whenever the Apache configuration file,
     mywebsite:
       file:
         - managed
-    
+
 State declaration
 -----------------
 
@@ -277,7 +277,7 @@ For example, given the following state declaration:
           - python-yaml
 
 Once converted into the :term:`lowstate` data structure the above state
-declaration will be expaneded into the following three state declarations:
+declaration will be expanded into the following three state declarations:
 
 .. code-block:: yaml
 

doc/ref/states/index.rst

@@ -121,7 +121,7 @@ Here is an example of a Salt State:
           - salt-minion
         - watch:
           - file: /etc/salt/minion
-                
+
     /etc/salt/minion:
       file:
         - managed
@@ -145,7 +145,7 @@ The top file is the mapping for the state system. The top file specifies which
 minions should have which modules applied and which environments they should
 draw the states from.
 
-The top file works by specifying the environment, containing matchers with 
+The top file works by specifying the environment, containing matchers with
 lists of Salt states sent to the matching minions:
 
 .. code-block:: yaml

doc/ref/states/ordering.rst

@@ -9,7 +9,7 @@ order is not necessarily defined the way you want it.
 A few tools exist in Salt to set up the correct state ordering. These tools
 consist of requisite declarations and order options.
 
-.. note:: 
+.. note::
 
     Salt does **not** execute :term:`state declarations <state declaration>` in
     the order they appear in the source.
@@ -149,7 +149,7 @@ restarted.
 Watch and the Watcher Function
 ------------------------------
 
-The watch requisite is based on the ``watcher`` function, state python 
+The watch requisite is based on the ``watcher`` function, state python
 modules can include a function called watcher, this function is then called
 if the watch call is invoked. In the case of the service module the underlying
 service is restarted. In the case of the cmd state the command is executed.

doc/ref/states/top.rst

@@ -121,7 +121,7 @@ A clean and recommended setup for multiple environments would look like this:
 Then only place state trees in the dev, qa and prod environments, leaving
 the base environment open for generic file transfers. Then the top.sls file
 would look something like this:
-    
+
 .. code-block:: yaml
 
     dev:

doc/ref/states/writing.rst

@@ -34,8 +34,8 @@ directly define the user interface.
 Using Custom State Modules
 ==========================
 
-Place your custom state modules inside a ``_states`` directory within the 
-``file_roots`` specified by the master config file. These custome state modules
+Place your custom state modules inside a ``_states`` directory within the
+``file_roots`` specified by the master config file. These custom state modules
 can then be distributed in a number of ways. Custom state modules are
 distributed when state.highstate is run, or via the saltutil.sync_states
 function.
@@ -114,7 +114,7 @@ executing state as an argument. The low state data is a dict and can be seen by
 executing the state.show_lowstate function. Then the mod_init function must
 return a bool. If the return value is True, then the mod_init function will not
 be executed again, meaning that the needed behavior has been set up. Otherwise,
-if the mod_init function returns False, then the function will be called the 
+if the mod_init function returns False, then the function will be called the
 next time.
 
 A good example of the mod_init function is found in the pkg state module:

doc/ref/syndic.rst

@@ -6,7 +6,7 @@ The Salt Syndic interface is a powerful tool which allows for the construction
 of Salt command topologies. A basic Salt setup has a Salt Master commanding a
 group of Salt Minions. The Syndic interface is a special passthrough
 minion, it is run on a master and connects to another master, then the master
-that the Syndic minion is listening to can control the minions attatched to
+that the Syndic minion is listening to can control the minions attached to
 the master running the syndic.
 
 The intent for supporting many layouts is not presented with the intent of
@@ -16,7 +16,7 @@ of controlling many systems.
 Configuring the Syndic
 ======================
 
-Since the Syndic only needs to be attatched to a higher level master the
+Since the Syndic only needs to be attached to a higher level master the
 configuration is very simple. On a master that is running a syndic to connect
 to a higher level master the syndic_master option needs to be set in the
 master config file. The syndic_master option contains the hostname or ip
@@ -25,7 +25,7 @@ running on.
 
 The master that the syndic connects to sees the syndic as an ordinary minion,
 and treats it as such. the higher level master will need to accept the syndic's
-minion key like any other minion. This master will also need to set the 
+minion key like any other minion. This master will also need to set the
 order_masters value in the configuration to True. The order_masters option in
 the config on the higher level master is very important, to control a syndic
 extra information needs to be sent with the publications, the order_masters
@@ -34,7 +34,7 @@ option makes sure that the extra data is sent out.
 Running the Syndic
 ==================
 
-The Syndic is a seperate daemon that needs to be started on the master that is
+The Syndic is a separate daemon that needs to be started on the master that is
 controlled by a higher master. Starting the Syndic daemon is the same as
 starting the other Salt daemons.
 

doc/topics/installation/arch.rst

@@ -2,10 +2,10 @@
 Arch Linux
 ==========
 
-Salt has primarily been developed on Arch Linux, meaning it is known to work
-very well on that distribution. The lead developer, Thomas S. Hatch (thatch45) has
-been a TU (Trusted User) for the Arch Linux distribution, and has written a
-number of Arch-specific tools in the past.
+Salt has primarily been developed on Arch Linux, meaning it is known to
+work very well on that distribution. The lead developer, Thomas S. Hatch
+(thatch45) has been a TU (Trusted User) for the Arch Linux distribution,
+and has written a number of Arch-specific tools in the past.
 
 Salt, while not Arch-specific, is packaged for and works well on Arch Linux.
 
@@ -50,8 +50,9 @@ currently relies on the following packages only available via the AUR:
 Tracking develop
 ----------------
 
-To install the bleeding edge version of Salt (**may include bugs!**), you can use
-the -git package. Installing the -git package can be done using the commands:
+To install the bleeding edge version of Salt (**may include bugs!**),
+you can use the -git package. Installing the -git package can be done
+using the commands:
 
 .. code-block:: bash
 

doc/topics/installation/fedora.rst

@@ -150,9 +150,9 @@ Minion. This ensures that the commands you send to your Minions (your cloud)
 can not be tampered with, and that communication between Master and Minion is
 only done through trusted, accepted keys.
 
-Before you'll be able to do any remote execution or configuration management you'll
-need to accept any pending keys on the Master. Run the ``salt-key`` command to
-list the keys known to the Salt Master:
+Before you'll be able to do any remote execution or configuration management
+you'll need to accept any pending keys on the Master. Run the ``salt-key``
+command to list the keys known to the Salt Master:
 
 .. code-block:: bash
 

doc/topics/installation/freebsd.rst

@@ -35,10 +35,11 @@ Configuration
 In the sections below I'll outline configuration options for both the Salt
 Master and Salt Minions.
 
-The Salt port installs two sample configuration files, ``salt/master.sample`` and
-``salt/minion.sample`` (these should be installed in ``/usr/local/etc/``, unless you use a
-different ``%%PREFIX%%``). You'll need to copy these .sample files into place and
-make a few edits. First, copy them into place as seen here:
+The Salt port installs two sample configuration files, ``salt/master.sample``
+and ``salt/minion.sample`` (these should be installed in ``/usr/local/etc/``,
+unless you use a different ``%%PREFIX%%``). You'll need to copy these
+.sample files into place and make a few edits. First, copy them into place
+as seen here:
 
 .. code-block:: bash
 

doc/topics/pillar/index.rst

@@ -12,13 +12,13 @@ Declaring the Master Pillar
 ===========================
 
 The Salt Master server maintains a pillar_roots setup that matches the
-structure of the file_roots used in the Salt file server. Like the 
+structure of the file_roots used in the Salt file server. Like the
 Salt file server the ``pillar_roots`` option in the master config is based
 on environments mapping to directories. The pillar data is then mapped to
 minions based on matchers in a top file which is laid out in the same way
 as the state top file.
 
-the configuration for the pillar_roots in the master config is identical in
+The configuration for the pillar_roots in the master config is identical in
 behavior and function as the file_roots configuration:
 
 .. code-block:: yaml

doc/topics/specs/salt_auth_proto.rst

@@ -4,7 +4,7 @@ Salt Authentication Protocol
 
 The Salt Authentication Protocol (SAP) defines a viable mechanism to create an
 authenticated, encrypted communication channel. The SAP is used to create a
-general purpose secure comunication channel.
+general purpose secure communication channel.
 
 Editor: Thomas S Hatch <thatch45@gmail.com>
 

doc/topics/specs/salt_auth_proto_abs.rst

@@ -2,10 +2,10 @@
 Abstract on Salt Authentication and Encryption
 ==============================================
 
-The Salt authentication and entcryption system uses Public Key authentication
-and AES encryption to faciliate both authentication and high speed encryption.
+The Salt authentication and encryption system uses Public Key authentication
+and AES encryption to facilitate both authentication and high speed encryption.
 
-The core components of this system can be seperated into a few sections,
+The core components of this system can be separated into a few sections,
 Message Formatting, PubKey Handshake, AES key management, and encryption.
 
 Message Formatting
@@ -24,7 +24,7 @@ The message itself is abstracted as a python dict in this fashion:
      'load': <encrypted python pickle>}
 
 When this message is received the load can be decrypted using the shared AES
-key. The 'enc' dict ket can also be "pub" for pubkey encryption, or "clear"
+key. The 'enc' dict key can also be "pub" for pubkey encryption, or "clear"
 for passing messages in the clear.
 
 PubKey Handshake
@@ -32,13 +32,13 @@ PubKey Handshake
 
 RSA Public keys are generated on the Salt master and on the Salt minion. When
 A salt minion establishes an initial connection to the salt master the minion
-sends its public key in the clear to the salt master, allong with the id of
+sends its public key in the clear to the salt master, along with the id of
 the minion, and the command to execute on the master, in this case "_auth":
 
 .. code-block:: python
 
     {'enc': 'clear',
-     'load': 
+     'load':
         {'cmd': '_auth',
          'id': <minion id>,
          'pub': <minion public key>}}
@@ -53,17 +53,17 @@ information on how to connect to the salt master publish interface.
 The returned AES key is encrypted with the minion's public key, and can
 therefore only be decrypted by the minion that sent out the public key.
 
-Once the minion has authenticated and is in possesion of the revolving master
-AES key (The AES key is regererated when the master restarts) then it atatches
+Once the minion has authenticated and is in possession of the revolving master
+AES key (The AES key is regenerated when the master restarts) then it attaches
 the minion subscriber to the master publisher.
 
-All messages sent from the publisher are encypted using the revolving AES key,
+All messages sent from the publisher are encrypted using the revolving AES key,
 in the event that the master restarts the minions will all have an invalid
 AES key because it has been regenerated on the master. The master will then
 send out a publication that the minions cannot decrypt. If the minion receives
 a publication that cannot be decrypted then the minion will re-authenticate,
 obtain the correct AES key, and decrypt the message. This means that the
-AES key on the salt master can safely revolve without inturupting the minion
+AES key on the salt master can safely revolve without interrupting the minion
 connection.
 
 Regular Communication
@@ -91,7 +91,7 @@ Conclusion
 
 In the end Salt uses formatted messages with clear header data to specify how
 the message data is encrypted. Only uses pubkey encryption for authentication
-and to securely retrive the master AES key. Then all regular communication
+and to securely retrieve the master AES key. Then all regular communication
 is sent in AES encrypted messages.
 
 

doc/topics/targeting/grains.rst

@@ -25,29 +25,29 @@ Just add the option ``grains`` and pass options to it:
 .. code-block:: yaml
 
     grains:
-      roles: 
+      roles:
         - webserver
         - memcache
       deployment: datacenter4
       cabinet: 13
       cab_u: 14-15
 
-Then statis data specific to your servers can be retrived via Salt, or used
+Then status data specific to your servers can be retrieved via Salt, or used
 inside of the state system for matching. It also makes targeting, in the case
 of the example above, simply based on specific data about your deployment.
 
 Writing Grains
 ==============
 
-Grains are easy to write. The grains interface is derived by executing all of
-the "public" functions found in the modules located in the grains package or 
-the custom grains directory. The functions in the modules of the grains must 
-return a python dict, where the keys in the dict are the names of the grains and
-the values are the values.
+Grains are easy to write. The grains interface is derived by executing
+all of the "public" functions found in the modules located in the grains
+package or the custom grains directory. The functions in the modules of
+the grains must return a python dict, where the keys in the dict are the
+names of the grains and the values are the values.
 
-Custom grains should be placed in a ``_grains`` directory located under your 
-:conf_master:`file_roots`. Before adding a grain to salt, consider what the grain 
-is and remember that grains need to be static data.
+Custom grains should be placed in a ``_grains`` directory located under
+your :conf_master:`file_roots`. Before adding a grain to salt, consider
+what the grain is and remember that grains need to be static data.
 
 Examples of Grains
 ------------------

doc/topics/troubleshooting/index.rst

@@ -2,7 +2,7 @@
 Troubleshooting
 ===============
 
-The intent of the  troubleshootign secion is to introduce solutions to a 
+The intent of the  troubleshooting section is to introduce solutions to a
 number of common issues encountered by users and the tools that are available
 to aid in developing states and salt code.
 
@@ -23,32 +23,32 @@ Using salt-call
 The salt-call command was originally developed for aiding in the development
 of new salt modules. Since then many applications have arisen for the salt-call
 command that is bundled with the salt minion. These range from the original
-intent of the salt-call, developmetn assistance, to gathering large amounts of
+intent of the salt-call, development assistance, to gathering large amounts of
 data from complex calls like state.highstate.
 
-When developing the state tree it is geenrally recommended to invoke
+When developing the state tree it is generally recommended to invoke
 state.highstate with salt-call, this displays a great deal more information
-about the highstate execution then if it is called remotely.
+about the highstate execution than if it is called remotely.
 
 Too many open files
 ===================
 
 The salt-master needs at least 2 sockets per host that connects to it, one for
-the Publisher and one for response port. Thus, large installations may upon 
+the Publisher and one for response port. Thus, large installations may upon
 scaling up the number of minions accessing a given master, encounter:
 
         12:45:29,289 [salt.master    ][INFO    ] Starting Salt worker process 38
         Too many open files
         sock != -1 (tcp_listener.cpp:335)
 
-The solution to this would be to check the number of files allowed to be 
+The solution to this would be to check the number of files allowed to be
 opened by the user running salt-master (root by default):
 
         [root@salt-master ~]# ulimit -n
         1024
 
 And modify that value to be at least equal to the number of minions x 2.
-This setting can be changed in limits.conf as the nofile value(s), 
+This setting can be changed in limits.conf as the nofile value(s),
 and activated upon new a login of the specified user.
 
 So, an environment with 1800 minions, would need 1800 x 2 = 3600 as a minimum

doc/topics/troubleshooting/yaml_idiosyncrasies.rst

@@ -18,11 +18,10 @@ no tabs have crept in!
 
 Indentation
 ===========
-The suggested
-syntax for Yaml files is to use 2 spaces for indentation, but Yaml will
-follow whatever indentation system that the individual file uses. Generally
-2 space indentation works very well for sls files given the fact that the
-represented data is uniform and not deeply nested.
+The suggested syntax for Yaml files is to use 2 spaces for indentation,
+but Yaml will follow whatever indentation system that the individual file
+uses. Generally 2 space indentation works very well for sls files given
+the fact that the represented data is uniform and not deeply nested.
 
 Nested Dicts (key-value)
 ------------------------
@@ -52,7 +51,7 @@ state:
 Notice that the spacing used is 2 spaces, and that when defining the context
 and defaults options there is a 4 space indent. If only a 2 space indent is
 used then the information will not be correctly loaded. If using double spacing
-is not desireable, then a deeply nested dict can be declared with curly braces:
+is not desirable, then a deeply nested dict can be declared with curly braces:
 
 .. code-block:: yaml
 

doc/topics/tutorials/bootstrap_ec2.rst

@@ -2,9 +2,16 @@
 Boostrapping Salt on Linux EC2 with Cloud-Init
 ==============================================
 
-`Salt <http://saltstack.org>`_ is a great tool for remote execution and configuration management, however you will still need to bootstrap the daemon when spinning up a new node. One option is to create and save a custom AMI, but this creates another resource to maintain and document.
+`Salt <http://saltstack.org>`_ is a great tool for remote execution and
+configuration management, however you will still need to bootstrap the
+daemon when spinning up a new node. One option is to create and save a
+custom AMI, but this creates another resource to maintain and document.
 
-A better method for Linux machines uses Canonical's `CloudInit <https://help.ubuntu.com/community/CloudInit>`_ to run a bootstrap script during an EC2 Instance initialization. Cloud-init takes the ``user_data`` string passed into a new AWS instance and runs it in a manner similar to rc.local. The bootstrap script needs to:
+A better method for Linux machines uses Canonical's `CloudInit
+<https://help.ubuntu.com/community/CloudInit>`_ to run a bootstrap script
+during an EC2 Instance initialization. Cloud-init takes the ``user_data``
+string passed into a new AWS instance and runs it in a manner similar to
+rc.local. The bootstrap script needs to:
 
 #. Install `Salt`_ with dependencies
 #. Point the minion to the master
@@ -24,12 +31,17 @@ Here is a sample script::
     sed -i '' -e 's/#master: salt/master: [salt_master_fqdn]' /etc/salt/minion
     salt-minion -d
 
-First the script adds the saltstack ppa and installs the package. Then we copy over the minion config template and tell it where to find the master. You will have to replace ``[salt_master_fqdn]`` with something that resolves to your salt master. 
+First the script adds the saltstack ppa and installs the package. Then
+we copy over the minion config template and tell it where to find the
+master. You will have to replace ``[salt_master_fqdn]`` with something
+that resolves to your salt master.
 
 Used With Boto
 --------------
 
-`Boto <https://github.com/boto/boto>`_ will accept a string for user data which can be used to pass our bootstrap script. If the script is saved to a file, you can read it into a string::
+`Boto <https://github.com/boto/boto>`_ will accept a string for user data
+which can be used to pass our bootstrap script. If the script is saved to
+a file, you can read it into a string::
 
     import boto
 
@@ -47,4 +59,6 @@ Additional Notes
 
 Sometime in the future the ppa will include and install an upstart file. In the meantime, you can use the bootstrap to `build one <https://gist.github.com/1617054>`_.
 
-It may also be useful to set the node's role during this phase. One option would be saving the node's role to a file and then using a custom grain to select it.
+It may also be useful to set the node's role during this phase. One option
+would be saving the node's role to a file and then using a custom grain
+to select it.