Additional Vale fixes

docs/applications/configuration-management/install-a-chef-server-workstation-on-ubuntu-14-04.md

@@ -232,7 +232,7 @@ With both the server and a workstation configured, it is possible to bootstrap y
 
 Bootstrapping a node installs the chef-client and validates the node, allowing it to read from the Chef server and make any needed configuration changes picked up by the chef-client in the future.
 
-1.	From your *workstation*, bootstrap the node either by using the node's root user, or a user with elevated privledges:
+1.	From your *workstation*, bootstrap the node either by using the node's root user, or a user with elevated privileges:
 
     - As the node's root user, changing `password` to your root password and `nodename` to the desired name for your node. You can leave this off it you would like the name to default to your node's hostname:
 

docs/applications/containers/docker-container-communication.md

@@ -373,4 +373,4 @@ By default, Docker automatically assigns an IP address to each container and to
 
 However, Docker also provides a number of convenient wrappers around these connections to help you speed up and simplify the connection process. You can connect your Docker host to a container with a unique hostname, or directly link two containers. Using Docker Compose can simplify this process even further by allowing you to declare connections in the `docker-compose.yml` file so that they are automatically established when the containers are brought up.
 
-There are other connection options that were not covered in this guide. For example, you can run a container using `--net="host"`, which will share that container's network stack with the Docker host: `localhost` on the container will point to `localhost` on the Docker host. You can also expose ports on each Docker container, or configre the default bridge network for more flexibility. For a more in-depth discussion of these options, see the links in the More Info section below.
+There are other connection options that were not covered in this guide. For example, you can run a container using `--net="host"`, which will share that container's network stack with the Docker host: `localhost` on the container will point to `localhost` on the Docker host. You can also expose ports on each Docker container, or configure the default bridge network for more flexibility. For a more in-depth discussion of these options, see the links in the More Info section below.

docs/applications/containers/how-to-deploy-apps-with-rancher.md

@@ -107,7 +107,7 @@ As an example, install the Ghost blog platform. This will showcase Rancher's int
 
 3.  Navigate to your Linode's IP address from the browser for the Ghost landing page.
 
-    You have just used Rancher to deploy a containered Ghost service.
+    You have just used Rancher to deploy a containerized Ghost service.
 
 4.  In the Rancher interface, click on the Ghost container:
 

docs/applications/containers/how-to-deploy-nginx-on-a-kubernetes-cluster.md

@@ -46,7 +46,7 @@ The steps in this guide create a two-node cluster. Evaluate your own resource re
 
 1.  Create two Linodes with at least 2GB memory within the same data center.
 
-2.  For each node, go into the Remote Access tab of your Linode manager and add a [private IP](/docs/networking/remote-access#adding-private-ip-addresses). It is possible to build a Kubernetes cluster using public IPs between data centers, but performance and security may suffer.
+2.  For each node, go into the Remote Access tab of your Linode Manager and add a [private IP](/docs/networking/remote-access#adding-private-ip-addresses). It is possible to build a Kubernetes cluster using public IPs between data centers, but performance and security may suffer.
 
 3.  Configure a firewall with [UFW](/docs/security/firewalls/configure-firewall-with-ufw) or [iptables](/docs/security/firewalls/control-network-traffic-with-iptables) to ensure only the two nodes can communicate with each other.
 

docs/applications/messaging/advanced-irssi-usage.md

@@ -79,9 +79,9 @@ The following plugins are popular among the Linode community:
 -   [trackbar.pl](http://scripts.irssi.org/scripts/trackbar.pl) generates a horizontal rule in a channel to mark the last time you viewed this channel's window. This is useful if you are monitoring a number of channels and would like to be reminded of the last time you viewed this window.
 -   [go.pl](http://scripts.irssi.org/scripts/go.pl) provides advanced completion for accessing windows with a `/go` command that offers tab completion for all windows, and is even able to complete based on character combinations from the middle of the channel or private message names.
 -   [nickcolor.pl](http://scripts.irssi.org/scripts/nickcolor.pl) colorizes the nicknames of all members of a channel, based on activity and join time, in an effort to make the flow of conversation a bit easier to read.
--   [screen\_away.pl](http://scripts.irssi.org/scripts/screen_away.pl) automatically detects if your Irssi session resides within an attached or detached screen session. If your screen session is detached, this plugin will set your status to away. When you reattach to the session, the plugin unsets the away status.
+-   [screen_away.pl](http://scripts.irssi.org/scripts/screen_away.pl) automatically detects if your Irssi session resides within an attached or detached screen session. If your screen session is detached, this plugin will set your status to away. When you reattach to the session, the plugin unsets the away status.
 -   [highlite.pl](http://scripts.irssi.org/scripts/highlite.pl) collects in one window all channel events like joins, parts, and quits.
--   [adv\_windowlist.pl](/docs/assets/633-adv_windowlist.pl) provides a more useful and configurable window list if you have trouble with the default window list implementation.
+-   [adv_windowlist.pl](/docs/assets/633-adv_windowlist.pl) provides a more useful and configurable window list if you have trouble with the default window list implementation.
 
 You can install all of these scripts to "autorun" when you invoke Irssi the next time by issuing the following sequence of commands:
 

docs/applications/messaging/instant-messaging-services-with-ejabberd-on-ubuntu-9-04-jaunty.md

@@ -16,7 +16,7 @@ title: 'Instant Messaging Services with ejabberd on Ubuntu 9.04 (Jaunty)'
 
 
 
-Ejabberd is a Jabber daemon written in the Erlang programming language. It is extensible, flexible and very high performance. With a web-based interface, and broad support for [XMPP standards](http://xmpp.org/), ejabberd is a great choice for a multi-purpose XMPP server. Ejabberd can be considered "heavyweight" by critics, because of the requirements of the Erlang run-times. However, it is incredibly robust and can scale to support incredibly heavy loads. Ebjabberd servers are believed to be the backbone for some of the largest Jabber servers running now.
+Ejabberd is a Jabber daemon written in the Erlang programming language. It is extensible, flexible and very high performance. With a web-based interface, and broad support for [XMPP standards](http://xmpp.org/), ejabberd is a great choice for a multi-purpose XMPP server. Ejabberd can be considered "heavyweight" by critics, because of the requirements of the Erlang run-times. However, it is incredibly robust and can scale to support incredibly heavy loads. Ejabberd servers are believed to be the backbone for some of the largest Jabber servers running now.
 
 This installation process assumes that you have a working installation of Ubuntu 9.04 (Jaunty), have followed the steps in the [getting started](/docs/getting-started/) guide, and now have an up to date instance of the Ubuntu Jaunty operating system. We also assume you are connected to your Linode via SSH as root. Once you've completed these requirements, we can begin with the installation process.
 

docs/applications/project-management/setting-up-taskwarrior-on-ubuntu-16-10.md

@@ -36,7 +36,7 @@ external_resources:
 
 ## Install Taskwarrior
 
-Install Taskwarriror with the command:
+Install Taskwarrior with the command:
 
 	sudo apt install task
 

docs/databases/postgresql/configure-postgresql.md

@@ -57,7 +57,7 @@ The contents of the configuration file are broken up into different sections:
 |---|---|
 |File Locations   | Defines where values of the database will be stored   |
 |Connections and Authentications   | Allows you to define the settings for connections, security, and authentication   |
-|Resource Usage   | Defines the paramaters (memory, space) usable by PostgreSQL.   |
+|Resource Usage   | Defines the parameters (memory, space) usable by PostgreSQL.   |
 |Write Ahead Log   | Configures *Write-Ahead logging*, which if properly configured, can result in a lower amount of disk writes.   |
 |Replication   | Control the way replications and replication data is handled by the server.   |
 |Query Tuning   | This set of directives can help you optimize the process of querying to the database.   |
@@ -115,7 +115,7 @@ To allow a user on a remote system to log in to the `example` database using a n
 host    example         exampleuser      192.0.2.0             password
 {{< /file-excerpt >}}
 
-The entires in this table are read in order for each incoming connection attempt. The first entry that matches will be applied to the connection. As a result, more general configurations (matching all users, all databases, or all IP addresses) should come at the end of the file, and should generally have tighter restrictions. More specific matches with less stringent authentication methods (such as the example above) should be placed at the beginning of the list.
+The entries in this table are read in order for each incoming connection attempt. The first entry that matches will be applied to the connection. As a result, more general configurations (matching all users, all databases, or all IP addresses) should come at the end of the file, and should generally have tighter restrictions. More specific matches with less stringent authentication methods (such as the example above) should be placed at the beginning of the list.
 
 {{< note >}}
 See the [official pg_hba documentation](https://www.postgresql.org/docs/9.3/static/auth-pg-hba-conf.html) for details about each of the configuration options.

docs/development/go/install-go-on-ubuntu.md

@@ -19,7 +19,7 @@ title: 'How to Install Go on Ubuntu'
 
 ## Install Go
 
-1. Use `curl` or `wget` to download the current binary for Go from the official [download page](https://golang.org/dl/). As of this writing, the current version is 1.9.3. Check the download page for updates, and replace `1.9.3` with the most recent stable version if necesssary.
+1. Use `curl` or `wget` to download the current binary for Go from the official [download page](https://golang.org/dl/). As of this writing, the current version is 1.9.3. Check the download page for updates, and replace `1.9.3` with the most recent stable version if necessary.
 
         curl -O https://storage.googleapis.com/golang/go1.9.3.linux-amd64.tar.gz
 

docs/development/iot/install-thingsboard-iot-dashboard.md

@@ -288,6 +288,6 @@ If the service is running successfully, data should be transmitted to your Thing
 
 ## Next Steps
 
-The widgets provided by Thingsboard can be easily edited, and it is possible to create new ones as well. Multiple widgets, representing multiple datastreams from multiple devices, can be combined to produce customized dashboards. These dashboards can then be made public, or shared with customers.
+The widgets provided by Thingsboard can be easily edited, and it is possible to create new ones as well. Multiple widgets, representing multiple data streams from multiple devices, can be combined to produce customized dashboards. These dashboards can then be made public, or shared with customers.
 
 For more information on how to customize and set up widgets and dashboards, see the Thingsboard [Widget Library](https://thingsboard.io/docs/user-guide/ui/widget-library/#time-series) and [Dashboard page](https://thingsboard.io/docs/user-guide/ui/dashboards/) The [Thingsboard Github repo](https://github.com/thingsboard/thingsboard) also has images of example dashboards.

docs/development/monitor-filesystem-events-with-pyinotify.md

@@ -45,7 +45,7 @@ Installing pyinotify within a virtual environment is highly recommended. This gu
 
 ### Create an Event Processor
 
-Similar to events in inotify, the Python implementation will be through an `EventProcessor` object with method names containing "process_" that is appended before the event name. For example, `IN_CREATE` in pyintotify though the `EventProcessor` will be `process_IN_CREATE`. The table below lists the inotify events used in this guide. In depth descriptions can be found in th [man pages of inotify](http://man7.org/linux/man-pages/man7/inotify.7.html).
+Similar to events in inotify, the Python implementation will be through an `EventProcessor` object with method names containing "process_" that is appended before the event name. For example, `IN_CREATE` in pyinotify though the `EventProcessor` will be `process_IN_CREATE`. The table below lists the inotify events used in this guide. In depth descriptions can be found in th [man pages of inotify](http://man7.org/linux/man-pages/man7/inotify.7.html).
 
 | Inotify Events      | Description                                                              |
 | ------------------- |:------------------------------------------------------------------------ |

docs/development/r/how-to-deploy-rstudio-server-using-an-nginx-reverse-proxy.md

@@ -21,7 +21,7 @@ title: 'How to Deploy RStudio Server Using an NGINX Reverse Proxy'
 
 This guide assumes an R installation version of R 3.0.1+ and will show how to install RStudio Server 1.1. See our guide on [installing R on Ubuntu and Debian](/docs/development/r/how-to-install-r-on-ubuntu-and-debian) for steps on installing the latest version of R.
 
-The steps in this guide are for Ubuntu 16.04 and should be adapted to your specfic distribution installation.
+The steps in this guide are for Ubuntu 16.04 and should be adapted to your specific distribution installation.
 
 ## Install RStudio Server
 
@@ -84,7 +84,7 @@ Running Rstudio server behind a reverse proxy offers benefits such as being able
 
         sudo apt install nginx
 
-2.  Open `nginx.conf` in a text edirot and add the following configuration:
+2.  Open `nginx.conf` in a text editor and add the following configuration:
 
     {{< file-excerpt "/etc/nginx/nginx.conf" nginx >}}
 http {

docs/development/r/how-to-install-r-on-ubuntu-and-debian.md

@@ -34,7 +34,7 @@ Although R can be installed through the default Debian or Ubuntu repository, the
 
 2.  Add the key ID for the CRAN network:
 
-    [UBuntu GPG key](https://cran.rstudio.com/bin/linux/ubuntu/):
+    [Ubuntu GPG key](https://cran.rstudio.com/bin/linux/ubuntu/):
 
         sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E084DAB9
 

docs/email/zimbra/zimbra-on-ubuntu-14-04.md

@@ -228,7 +228,7 @@ Your server was configured when you installed, and most of those settings will w
 
 4.  The **Protocol checks** can stop many spam messages before they enter your system. You may turn them all on, but at least _Sender address must be fully qualified_ should be checked.
 
-5.  **DNS checks** use realtime blacklists to reject mail coming from known spamming servers. zen.spamhuas.org is a good suggestion to start with. Enter the domain name into the **List of Client RBLs**.
+5.  **DNS checks** use realtime blacklists to reject mail coming from known spamming servers. `zen.spamhuas.org` is a good suggestion to start with. Enter the domain name into the **List of Client RBLs**.
 
 6.  Click the **AS/AV** page. Here you determine how "spammy" a message has to be to get tagged or rejected. Zimbra uses SpamAssassin to score every message. A score of zero or less than zero means the message is likely to be worth delivering. A score above zero means there are some indicators that this could be an unwanted email. The **Kill percent** is the score above which Zimbra will not deliver the message at all. The **Tag percent** is the score above which Zimbra will let the message through, but deliver it to the Junk folder.
 

docs/game-servers/install-black-mesa-on-debian-or-ubuntu.md

@@ -95,7 +95,7 @@ At the time of writing this guide, Black Mesa has yet to share with customers an
 {{< /note >}}
 
 ### Server.cfg
-The **server.cfg** file contains the settings of your server. It is not needed because you can start the server every time by specifying desidered values using parameters.
+The **server.cfg** file contains the settings of your server. It is not needed because you can start the server every time by specifying desired values using parameters.
 
 {{< file-excerpt "/home/steam/Steam/steamapps/common/Black Mesa Dedicated Server/bms/cfg/server.cfg" java >}}
 // Black Mesa server.cfg file

docs/networking/dns/use-unbound-for-local-dns-resolution-on-fedora-13.md

@@ -71,7 +71,7 @@ The next example will allow all requests from the IP address `11.22.33.44`. To s
 
 To summarize, there are four possible access control behaviors:
 
-1.  Unbound can `allow_snoop` traffic. This means that both recursive and nonrecusive requests will be filled when they originate from IP addresses belonging to specified netblocks. Nonrecursive request are needed to provide additional information for some tools, such as the `+trace` option of the `dig` utility.
+1.  Unbound can `allow_snoop` traffic. This means that both recursive and nonrecursive requests will be filled when they originate from IP addresses belonging to specified netblocks. Nonrecursive request are needed to provide additional information for some tools, such as the `+trace` option of the `dig` utility.
 2.  Unbound can `allow` traffic. This means that recursive requests will be filled when they originate from IP addresses belonging to specified netblocks.
 3.  Unbound can `deny` traffic. In this case, unbound will simply drop traffic and offer no error message.
 4.  Unbound can `refuse` traffic. This causes Unbound to send an error message in response to requests from disallowed sources.

docs/networking/dns/use-unbound-for-local-dns-resolution-on-fedora-14.md

@@ -78,7 +78,7 @@ The next example will allow all requests from the IP address `11.22.33.44`. To s
 
 To summarize, there are four possible access control behaviors:
 
-1.  Unbound can `allow_snoop` traffic. This means that both recursive and nonrecusive requests will be filled when they originate from IP addresses belonging to specified netblocks. Nonrecursive request are needed to provide additional information for some tools, such as the `+trace` option of the `dig` utility.
+1.  Unbound can `allow_snoop` traffic. This means that both recursive and nonrecursive requests will be filled when they originate from IP addresses belonging to specified netblocks. Nonrecursive request are needed to provide additional information for some tools, such as the `+trace` option of the `dig` utility.
 2.  Unbound can `allow` traffic. This means that recursive requests will be filled when they originate from IP addresses belonging to specified netblocks.
 3.  Unbound can `deny` traffic. In this case, unbound will simply drop traffic and offer no error message.
 4.  Unbound can `refuse` traffic. This causes Unbound to send an error message in response to requests from disallowed sources.

docs/networking/dns/use-unbound-for-local-dns-resolution-on-fedora-15.md

@@ -78,7 +78,7 @@ The next example will allow all requests from the IP address `11.22.33.44`. To s
 
 To summarize, there are four possible access control behaviors:
 
-1.  Unbound can `allow_snoop` traffic. This means that both recursive and nonrecusive requests will be filled when they originate from IP addresses belonging to specified netblocks. Nonrecursive request are needed to provide additional information for some tools, such as the `+trace` option of the `dig` utility.
+1.  Unbound can `allow_snoop` traffic. This means that both recursive and nonrecursive requests will be filled when they originate from IP addresses belonging to specified netblocks. Nonrecursive request are needed to provide additional information for some tools, such as the `+trace` option of the `dig` utility.
 2.  Unbound can `allow` traffic. This means that recursive requests will be filled when they originate from IP addresses belonging to specified netblocks.
 3.  Unbound can `deny` traffic. In this case, unbound will simply drop traffic and offer no error message.
 4.  Unbound can `refuse` traffic. This causes Unbound to send an error message in response to requests from disallowed sources.

docs/platform/disk-images/copying-a-disk-image-over-ssh.md

@@ -144,7 +144,7 @@ As above, you will want to verify the disk by mounting it on the receiving Linod
 
 ### Expand the Filesystem
 
-If the disk you created on the receiving Linode is larger than the source disk (for example you're transferring a disk from a smaller linode to a larger Linode), you'll have to resize the filesystem in order to make use of the new space.
+If the disk you created on the receiving Linode is larger than the source disk (for example you're transferring a disk from a smaller Linode to a larger Linode), you'll have to resize the filesystem in order to make use of the new space.
 
 You can check if this is necessary by comparing the space reported by the filesystem: