Merge pull request #453 from dpb587/patch-typos

Fix some typos in website docs

website/source/docs/agent/encryption.html.markdown

@@ -3,7 +3,7 @@ layout: "docs"
 page_title: "Encryption"
 sidebar_current: "docs-agent-encryption"
 description: |-
-  The Consul agent supports encrypting all of its network traffic. The exact method of this encryption is described on the encryption internals page. There are two seperate systems, one for gossip traffic and one for RPC.
+  The Consul agent supports encrypting all of its network traffic. The exact method of this encryption is described on the encryption internals page. There are two separate systems, one for gossip traffic and one for RPC.
 ---
 
 # Encryption
@@ -11,7 +11,7 @@ description: |-
 The Consul agent supports encrypting all of its network traffic. The exact
 method of this encryption is described on the
 [encryption internals page](/docs/internals/security.html). There are two
-seperate systems, one for gossip traffic and one for RPC.
+separate systems, one for gossip traffic and one for RPC.
 
 ## Gossip Encryption
 
@@ -74,7 +74,7 @@ key pair set using `cert_file` and `key_file`.
 If `verify_incoming` is set, then the servers verify the authenticity of all incoming
 connections. Servers will also disallow any non-TLS connections. If this is set, then all
 clients must have a valid key pair set using `cert_file` and `key_file`. To force clients to
-use TLs, `verify_outgoing` must also be set.
+use TLS, `verify_outgoing` must also be set.
 
 TLS is used to secure the RPC calls between agents, but gossip between nodes is done over UDP
 and is secured using a symmetric key. See above for enabling gossip encryption.

website/source/docs/agent/http.html.markdown

@@ -188,7 +188,7 @@ be used with a PUT request:
 
 * ?cas=\<index\> : This flag is used to turn the `PUT` into a Check-And-Set
   operation. This is very useful as it allows clients to build more complex
-  syncronization primitives on top. If the index is 0, then Consul will only
+  synchronization primitives on top. If the index is 0, then Consul will only
   put the key if it does not already exist. If the index is non-zero, then
   the key is only set if the index matches the `ModifyIndex` of that key.
 
@@ -607,7 +607,7 @@ If the API call succeeds a 200 status code is returned.
 
 ### <a name="catalog_deregister"></a> /v1/catalog/deregister
 
-The deregister endpoint is a low level mechanism for direclty removing
+The deregister endpoint is a low level mechanism for directly removing
 entries in the catalog. It is usually recommended to use the agent local
 endpoints, as they are simpler and perform anti-entropy.
 

website/source/docs/agent/options.html.markdown

@@ -152,7 +152,7 @@ at a single JSON object with configuration within it.
 Configuration files are used for more than just setting up the agent,
 they are also used to provide check and service definitions. These are used
 to announce the availability of system servers to the rest of the cluster.
-They are documented seperately under [check configuration](/docs/agent/checks.html) and
+They are documented separately under [check configuration](/docs/agent/checks.html) and
 [service configuration](/docs/agent/services.html) respectively. The service and check
 definitions support being updated during a reload.
 
@@ -188,7 +188,7 @@ definitions support being updated during a reload.
 * `acl_default_policy` - Either "allow" or "deny", defaults to "allow". The
   default policy controls the behavior of a token when there is no matching
   rule. In "allow" mode, ACLs are a blacklist: any operation not specifically
-  prohibited is allowed. In "deny" mode, ACLs are a whilelist: any operation not
+  prohibited is allowed. In "deny" mode, ACLs are a whitelist: any operation not
   specifically allowed is blocked.
 
 * `acl_down_policy` - Either "allow", "deny" or "extend-cache" which is the
@@ -237,12 +237,12 @@ definitions support being updated during a reload.
   Must be provided along with the `key_file`.
 
 * `check_update_interval` - This interval controls how often check output from
-  checks in a steady state is syncronized with the server. By default, this is
+  checks in a steady state is synchronized with the server. By default, this is
   set to 5 minutes ("5m"). Many checks which are in a steady state produce
   slightly different output per run (timestamps, etc) which cause constant writes.
-  This configuration allows defering the sync of check output for a given interval to
+  This configuration allows deferring the sync of check output for a given interval to
   reduce write pressure. If a check ever changes state, the new state and associated
-  output is syncronized immediately. To disable this behavior, set the value to "0s".
+  output is synchronized immediately. To disable this behavior, set the value to "0s".
 
 * `client_addr` - Equivalent to the `-client` command-line flag.
 
@@ -260,7 +260,7 @@ definitions support being updated during a reload.
   new version releases.
 
 * `dns_config` - This object allows a number of sub-keys to be set which can tune
-  how DNS queries are perfomed. See this guide on [DNS caching](/docs/guides/dns-cache.html).
+  how DNS queries are performed. See this guide on [DNS caching](/docs/guides/dns-cache.html).
   The following sub-keys are available:
 
   * `allow_stale` - Enables a stale query for DNS information. This allows any Consul
@@ -395,7 +395,7 @@ port.
 * Serf LAN (Default 8301). This is used to handle gossip in the LAN.
   Required by all agents, TCP and UDP.
 
-* Serf WAN( Default 8302). This is used by servers to gossip over the
+* Serf WAN (Default 8302). This is used by servers to gossip over the
   WAN to other servers. TCP and UDP.
 
 * CLI RPC (Default 8400). This is used by all agents to handle RPC

website/source/docs/agent/watches.html.markdown

@@ -32,7 +32,7 @@ in a JSON body when using agent configuration, or as CLI flags for the watch com
 
 ## Handlers
 
-The watch specifiation specifies the view of data to be monitored.
+The watch specification specifies the view of data to be monitored.
 Once that view is updated the specified handler is invoked. The handler
 can be any executable.
 

website/source/docs/commands/event.html.markdown

@@ -16,7 +16,7 @@ to build scripting infrastructure to do automated deploys, restart services,
 or perform any other orchestration action. Events can be handled by
 [using a watch](/docs/agent/watches.html).
 
-Under the hood, events are propogated using the [gossip protocol](/docs/internals/gossip.html).
+Under the hood, events are propagated using the [gossip protocol](/docs/internals/gossip.html).
 While the details are not important for using events, an understanding of
 the semantics is useful. The gossip layer will make a best-effort to deliver
 the event, but there is **no guarantee** delivery. Unlike most Consul data, which is
@@ -24,7 +24,7 @@ replicated using [consensus](/docs/internals/consensus.html), event data
 is purely peer-to-peer over gossip. This means it is not persisted and does
 not have a total ordering. In practice, this means you cannot rely on the
 order of message delivery. An advantage however is that events can still
-be used even in the absense of server nodes or during an outage.
+be used even in the absence of server nodes or during an outage.
 
 The underlying gossip also sets limits on the size of a user event
 message. It is hard to give an exact number, as it depends on various

website/source/docs/commands/exec.html.markdown

@@ -16,7 +16,7 @@ the `web` service.
 
 Remote execution works by specifying a job which is stored in the KV store.
 Agent's are informed about the new job using the [event system](/docs/commands/event.html),
-which propogates messages via the [gossip protocol](/docs/internals/gossip.html).
+which propagates messages via the [gossip protocol](/docs/internals/gossip.html).
 As a result, delivery is best-effort, and there is **no guarantee** of execution.
 
 While events are purely gossip driven, remote execution relies on the KV store

website/source/docs/internals/sessions.html.markdown

@@ -3,12 +3,12 @@ layout: "docs"
 page_title: "Sessions"
 sidebar_current: "docs-internals-sessions"
 description: |-
-  Consul provides a session mechansim which can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data. They are designed to provide granular locking, and are heavily inspired by The Chubby Lock Service for Loosely-Coupled Distributed Systems.
+  Consul provides a session mechanism which can be used to build distributed locks. Sessions act as a binding layer between nodes, health checks, and key/value data. They are designed to provide granular locking, and are heavily inspired by The Chubby Lock Service for Loosely-Coupled Distributed Systems.
 ---
 
 # Sessions
 
-Consul provides a session mechansim which can be used to build distributed locks.
+Consul provides a session mechanism which can be used to build distributed locks.
 Sessions act as a binding layer between nodes, health checks, and key/value data.
 They are designed to provide granular locking, and are heavily inspired
 by [The Chubby Lock Service for Loosely-Coupled Distributed Systems](http://research.google.com/archive/chubby.html).
@@ -31,7 +31,7 @@ Below is a diagram showing the relationship between these components:
 ![Consul Sessions](consul-sessions.png)
 </div>
 
-The contract that Consul provides is that under any of the folllowing
+The contract that Consul provides is that under any of the following
 situations the session will be *invalidated*:
 
 * Node is deregistered
@@ -79,7 +79,7 @@ mechanism by providing a zero delay value.
 
 Integration between the Key/Value store and sessions are the primary
 place where sessions are used. A session must be created prior to use,
-and is then refered to by it's ID.
+and is then referred to by it's ID.
 
 The Key/Value API is extended to support an `acquire` and `release` operation.
 The `acquire` operation acts like a Check-And-Set operation, except it

website/source/intro/vs/chef-puppet.html.markdown

@@ -30,7 +30,7 @@ integrated health checking, Consul can route traffic away from unhealthy
 nodes, allowing systems and services to gracefully recover. Static configuration
 that may be provided by configuration management tools can be moved into the
 dynamic key/value store. This allows application configuration to be updated
-without a slow convergence run. Lastly, because each datacenter runs indepedently,
+without a slow convergence run. Lastly, because each datacenter runs independently,
 supporting multiple datacenters is no different than a single datacenter.
 
 That said, Consul is not a replacement for configuration management tools.