diff --git a/documentation/getting-started/authentication-and-authorisation/index.markdown b/documentation/getting-started/authentication-and-authorisation/index.markdown index 361eaf06..a61f2ae8 100644 --- a/documentation/getting-started/authentication-and-authorisation/index.markdown +++ b/documentation/getting-started/authentication-and-authorisation/index.markdown @@ -38,7 +38,7 @@ There are two places that we need automated, promptless authentication: #### 1.1 SSH keys from workstation to servers -**Note:** If you are on Windows, all bets are off, I'd love it if someone +**Note:** If you are on Windows, all bets are off. I'd love it if someone could contribute a Windows guide to this, so we can include it here. An SSH key is a mechanism that allows a *public* half one key to be placed on @@ -111,7 +111,7 @@ none, other none), in the `~/.ssh` directory which needs the permissions If you are on linux there often exists a command [`ssh-copy-id`](http://linux.die.net/man/1/ssh-copy-id) which streamlines this -process, otherwise the worlflow is something like: +process, otherwise the workflow is something like: {% prism bash %} me@localhost $ ssh root@remote @@ -136,7 +136,7 @@ If we did all that correctly, we should now be able to do something like this: {% endprism %} That should happen without having to enter a passphrase for your SSH key, or -promoting you for an SSH password (which the deploy user doesn't have anyway). +prompting you for an SSH password (which the deploy user doesn't have anyway). Verify that this works for all of your servers, and put your private key somewhere safe. If you're working with multiple team members, it often pays to @@ -168,7 +168,7 @@ repository automatically. The options in order of preference: As we've already set up an SSH agent, we can use the *agent forwarding* feature of SSH to make this key agent available to further *hops*. In short, -we can use **our own ssh key** to authenticate ourselves from the server, to +we can use **our own ssh key** to authenticate ourselves from the server to Github. Here's how we can check if that works, first get the URL of the repository: @@ -192,7 +192,7 @@ We can try to access the repository via our server by doing the following: me@localhost $ ssh -A deploy@one-of-my-servers.com 'git ls-remote git@github.com:capistrano/rails3-bootstrap-devise-cancan.git {% endprism %} -We first check that the agent has the keys loaded, if not we simply load it, +We first check that the agent has the keys loaded. If not we simply load it and enter the passphrase when prompted. Finally we use `ls-remote` from Git to list the remote objects, this is the @@ -224,7 +224,7 @@ servers! In the case of HTTP authentication **be sure to use HTTPS**, otherwise your password will be sent in cleartext over the network, depending what your hosts -network infratructure looks like that might be *very* bad news. +network infrastructure looks like that might be *very* bad news. Typically when we try and list our remote objects, using the https method from Github, we'll be prompted for a username and password: @@ -306,11 +306,11 @@ This example would give the user named `deploy` access to call `sudo /etc/init.d/mysql _________` and the same for the `apache2` control script. **Granting passwordless sudo should not be done lightly.** It can be dangerous. -For example if an unprivilidged user can *edit* the script that they can run +For example if an unprivileged user can *edit* the script that they can run as root, they can easily edit it to do anything they want that is evil. Use -this carefully, and ideally architect your systems so that non-privlidged +this carefully, and ideally architect your systems so that non-privileged users can restart services, or that services restart *themselves* when they -notice change. +notice a change. To configure this heirarchy, ignoring for the moment the passwordless `sudo` access that you may or may not need depending how well your servers are setup: diff --git a/documentation/getting-started/cold-start/index.markdown b/documentation/getting-started/cold-start/index.markdown index 204adaa9..6bf0438a 100644 --- a/documentation/getting-started/cold-start/index.markdown +++ b/documentation/getting-started/cold-start/index.markdown @@ -88,7 +88,7 @@ Then we simply call it: {% endprism %} If we've done something wrong, that won't happen and we'll know that we need -to jump on the mailing list to get help, or into IRC or ask a friend. +to jump on the mailing list to get help, into IRC or ask a friend. Depending how you have set your Git authentication credentials up, checking Git can be a bit complicated, so we've shipped a task in the core library that @@ -142,9 +142,9 @@ colour support, you may well see something like this: To run through that shortly, what did we do: 1. We asked Capistrano to run the command `git:check`. -2. Capistrano recognised that in order to fulfil this request, it had first -to execute the task `git:wrapper`, a *prerequisite*. -3. Capistrano exexuted the `git:wrapper` task, and uploaded the +2. Capistrano recognised that in order to fulfil this request, it had to first +execute the task `git:wrapper`, a *prerequisite*. +3. Capistrano executed the `git:wrapper` task, and uploaded the `/tmp/git-ssh.sh` file, and made it executable. This satisfies the `git:wrapper` task defined [here](https://github.com/capistrano/capistrano/blob/v3/lib/capistrano/tasks/git.rake#L9) @@ -153,7 +153,7 @@ to execute the task `git:wrapper`, a *prerequisite*. prompting us for input, so we ask git to `ls-remote` on the repository we defined. As this exited with an [unclean status](https://en.wikipedia.org/wiki/Exit_status), Capistrano aborted, and - printed out the erorr messages for us to try and figure out what broke. + printed out the error messages for us to try and figure out what broke. In this case, we'll be using SSH agent forwarding, we can check if that's working by writing a tiny Cap task, or simply using SSH to do it for us, the diff --git a/documentation/getting-started/installation/index.markdown b/documentation/getting-started/installation/index.markdown index 13991756..55dc7113 100644 --- a/documentation/getting-started/installation/index.markdown +++ b/documentation/getting-started/installation/index.markdown @@ -58,7 +58,7 @@ gems](http://blog.meldium.com/home/2013/3/3/signed-rubygems-part)) ### Usage in a Rails project -Add the following lines to the Gemfile, to the group `:development` ideally. +Add the following lines to the Gemfile to the `:development` group ideally. {% prism ruby %} group :development do diff --git a/documentation/getting-started/preparing-your-application/index.markdown b/documentation/getting-started/preparing-your-application/index.markdown index 01f15127..f25acc4f 100644 --- a/documentation/getting-started/preparing-your-application/index.markdown +++ b/documentation/getting-started/preparing-your-application/index.markdown @@ -10,13 +10,13 @@ layout: default ### 1. Commit your application to some externally available source control hosting provider. -If you are not doing already, you should host your code somewhere with a -provuder such as Github, BitBucket, Codeplane, or repositoryhosting.com. +If you are not doing so already, you should host your code somewhere with a +provider such as Github, BitBucket, Codeplane, or repositoryhosting.com.
At present Capistrano v3.0.x only supports Git. It's just a matter of time until we support Subversion, Mecurial, Darcs and friends again. Please -contribute if you know these tools well, we don't and don't want to force our +contribute if you know these tools well, we do not and don't want to force our miscomprehended notions upon anyone.
@@ -104,8 +104,8 @@ The example file generated will look something like this: # ====================== # This can be used to drop a more detailed server # definition into the server list. The second argument - # something that quacks like a hash can be used to set - # extended properties on the server. + # is something that quacks like a hash and can be used + # to set extended properties on the server. server 'example.com', roles: %w{web app}, my_property: :my_value # set :rails_env, :staging @@ -164,7 +164,7 @@ Tutorials](http://railsapps.github.io/) site; there we'll find maintained a handful of typical Rails apps with typical dependencies. The Rails application they host, which uses Devise (for authentication) and -Cancan (for authorization) along side Twitter Bootstrap for assets has been +Cancan (for authorisation) along side Twitter Bootstrap for assets has been forked to the Capistrano repository, but you can find the (unchanged) original [here](https://github.com/RailsApps/rails3-bootstrap-devise-cancan). diff --git a/documentation/overview/what-is-capistrano/index.markdown b/documentation/overview/what-is-capistrano/index.markdown index 9b014313..556aa9f9 100644 --- a/documentation/overview/what-is-capistrano/index.markdown +++ b/documentation/overview/what-is-capistrano/index.markdown @@ -9,7 +9,7 @@ It supports the scripting and execution of arbitrary tasks, and includes a set o Capistrano can be used to: -* Reliably deploy web application to any number of machines simultaniously, +* Reliably deploy web application to any number of machines simultaneously, in sequence or as a rolling set * To automate audits of any number of machines (checking login logs, enumerating uptimes, and/or applying security patches) @@ -114,7 +114,7 @@ There's lots of cool stuff in the Capistrano toy box: end on roles(:app) do - # We can set environmental varaibles for the duration of a block + # We can set environmental variables for the duration of a block # and move the process into a directoy, executing arbitrary tasks # such as letting Rails do some heavy lifting. with({:rails_env => :production}) do