Fix whitespace in install and integration docs

Many code blocks are 4spaced, and they render in GitLab
without coloring as a result, even though they are
fenced with a language label. If in a list, other items
will render as being in a code block too, even if not
meant to. This fixes all these issues, and cleans up
minor white space issues in install and integration docs

doc/install/aws/index.md

@@ -63,6 +63,7 @@ Here's a list of the AWS services we will use, with links to pricing information
 NOTE: **Note:** Please note that while we will be using EBS for storage, we do not recommend using EFS as it may negatively impact GitLab's performance. You can review the [relevant documentation](../../administration/high_availability/nfs.md#avoid-using-awss-elastic-file-system-efs) for more details.
 
 ## Creating an IAM EC2 instance role and profile
+
 To minimize the permissions of the user, we'll create a new [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)
 role with limited access:
 

doc/install/azure/index.md

@@ -74,6 +74,7 @@ The first items we need to configure are the basic settings of the underlying vi
    public keys)_
    1. If you chose **Password** - enter the password you wish to use _(this is the password that you
    will use later in this tutorial to [SSH] into the VM, so make sure it's a strong password/passphrase)_
+
 1. Choose the appropriate `Subscription` tier for your Azure account
 1. Choose an existing `Resource Group` or create a new one - e.g. **"GitLab-CE-Azure"**
 
@@ -248,6 +249,7 @@ rules in the list:
 ![Azure - Inbound security rules - List](img/azure-inbound-sec-rules-list.png)
 
 ## Connecting to GitLab
+
 Use the domain name you set up earlier (or the public IP address) to visit your new GitLab instance
 in your browser. If everything has gone according to plan you should be presented with the
 following page, asking you to set a _new_ password for the administrator account automatically
@@ -348,6 +350,7 @@ your VM, you can use the IP address in its place in the following command:
 ```bash
 ssh username@your-azure-domain-name.com
 ```
+
 Provide your password at the prompt to authenticate.
 
 #### SSH from Windows (PuTTY)

doc/install/installation.md

@@ -851,6 +851,7 @@ Using a self-signed certificate is discouraged but if you must use it, follow th
    sudo openssl req -newkey rsa:2048 -x509 -nodes -days 3560 -out gitlab.crt -keyout gitlab.key
    sudo chmod o-r gitlab.key
    ```
+
 1. In the `config.yml` of gitlab-shell set `self_signed_cert` to `true`.
 
 ### Enable Reply by email

doc/integration/elasticsearch.md

@@ -12,6 +12,7 @@ special searches:
 - [Advanced Syntax Search](../user/search/advanced_search_syntax.md)
 
 ## Version Requirements
+
 <!-- Please remember to update ee/lib/system_check/app/elasticsearch_check.rb if this changes -->
 
 | GitLab version | Elasticsearch version |
@@ -511,4 +512,3 @@ Here are some common pitfalls and how to overcome them:
   AWS has [fixed limits](http://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/aes-limits.html)
   for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of
   the underlying instance.
-

doc/integration/github.md

@@ -127,7 +127,7 @@ and changing the global Git `sslVerify` option to `false` in the GitLab server.
 For omnibus package:
 
 ```ruby
-  gitlab_rails['omniauth_providers'] = [
+gitlab_rails['omniauth_providers'] = [
   {
     "name" => "github",
     "app_id" => "YOUR_APP_ID",
@@ -136,7 +136,7 @@ For omnibus package:
     "verify_ssl" => false,
     "args" => { "scope" => "user:email" }
   }
-  ]
+]
 ```
 
 You will also need to disable Git SSL verification on the server hosting GitLab.
@@ -148,7 +148,7 @@ omnibus_gitconfig['system'] = { "http" => ["sslVerify = false"] }
 For installation from source:
 
 ```
-  - { name: 'github', app_id: 'YOUR_APP_ID',
+- { name: 'github', app_id: 'YOUR_APP_ID',
   app_secret: 'YOUR_APP_SECRET',
   url: "https://github.example.com/",
   verify_ssl: false,

doc/integration/omniauth.md

@@ -161,13 +161,13 @@ want their accounts to be upgraded to full internal accounts.
 **For Omnibus installations**
 
 ```ruby
-  gitlab_rails['omniauth_external_providers'] = ['twitter', 'google_oauth2']
+gitlab_rails['omniauth_external_providers'] = ['twitter', 'google_oauth2']
 ```
 
 **For installations from source**
 
 ```yaml
-  omniauth:
+omniauth:
   external_providers: ['twitter', 'google_oauth2']
 ```
 
@@ -188,21 +188,29 @@ from the Omniauth provider's documentation.
 
 - Stop GitLab:
 
+  ```sh
   sudo service gitlab stop
+  ```
 
 - Add the gem to your [Gemfile](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile):
 
+  ```sh
   gem "omniauth-your-auth-provider"
+  ```
 
 - Install the new Omniauth provider gem by running the following command:
 
+  ```sh
   sudo -u git -H bundle install --without development test mysql --path vendor/bundle --no-deployment
+  ```
 
   > These are the same commands you used during initial installation in the [Install Gems section](../install/installation.md#install-gems) with `--path vendor/bundle --no-deployment` instead of `--deployment`.
 
 - Start GitLab:
 
+  ```sh
   sudo service gitlab start
+  ```
 
 ### Examples
 
@@ -247,7 +255,7 @@ gitlab_rails['omniauth_enabled'] = false
 **For installations from source**
 
 ```yaml
-  omniauth:
+omniauth:
   enabled: false
 ```
 
@@ -258,14 +266,14 @@ You can enable profile syncing from selected OmniAuth providers and for all or f
 When authenticating using LDAP, the user's name and email are always synced.
 
 ```ruby
-  gitlab_rails['sync_profile_from_provider'] = ['twitter', 'google_oauth2']
-  gitlab_rails['sync_profile_attributes'] = ['name', 'email', 'location']
- ```
+gitlab_rails['sync_profile_from_provider'] = ['twitter', 'google_oauth2']
+gitlab_rails['sync_profile_attributes'] = ['name', 'email', 'location']
+```
 
 **For installations from source**
 
 ```yaml
-  omniauth:
+omniauth:
   sync_profile_from_provider: ['twitter', 'google_oauth2']
   sync_profile_attributes: ['email', 'location']
 ```

doc/integration/salesforce.md

@@ -17,12 +17,14 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
    - **Description**: Description for the application.
 
    ![Salesforce App Details](img/salesforce_app_details.png)
+
 1. Select **API (Enable OAuth Settings)** and click on **Enable OAuth Settings**.
 1. Fill in the application details into the following fields:
    - **Callback URL**: The callback URL of your GitLab installation. For example, `https://gitlab.example.com/users/auth/salesforce/callback`.
    - **Selected OAuth Scopes**: Move **Access your basic information (id, profile, email, address, phone)** and **Allow access to your unique identifier (openid)** to the right column.
 
    ![Salesforce Oauth App Details](img/salesforce_oauth_app_details.png)
+
 1. Click **Save**.
 
 1. On your GitLab server, open the configuration file.
@@ -64,8 +66,10 @@ To get the credentials (a pair of Client ID and Client Secret), you must [create
        app_secret: 'SALESFORCE_CLIENT_SECRET'
      }
    ```
+
 1. Change `SALESFORCE_CLIENT_ID` to the Consumer Key from the Salesforce connected application page.
 1. Change `SALESFORCE_CLIENT_SECRET` to the Consumer Secret from the Salesforce connected application page.
+
    ![Salesforce App Secret Details](img/salesforce_app_secret_details.png)
 
 1. Save the configuration file.

doc/integration/shibboleth.md

@@ -97,44 +97,44 @@ The order of the first 2 Location directives is important. If they are reversed,
 you will not get a shibboleth session!
 
 ```
-  <Location />
+<Location />
   Require all granted
   ProxyPassReverse http://127.0.0.1:8181
   ProxyPassReverse http://YOUR_SERVER_FQDN/
-  </Location>
+</Location>
 
-  <Location /users/auth/shibboleth/callback>
+<Location /users/auth/shibboleth/callback>
   AuthType shibboleth
   ShibRequestSetting requireSession 1
   ShibUseHeaders On
   Require shib-session
-  </Location>
+</Location>
 
-  Alias /shibboleth-sp /usr/share/shibboleth
+Alias /shibboleth-sp /usr/share/shibboleth
 
-  <Location /shibboleth-sp>
+<Location /shibboleth-sp>
   Require all granted
-  </Location>
+</Location>
 
-  <Location /Shibboleth.sso>
+<Location /Shibboleth.sso>
   SetHandler shib
-  </Location>
+</Location>
 
-  RewriteEngine on
+RewriteEngine on
 
-  #Don't escape encoded characters in api requests
-  RewriteCond %{REQUEST_URI} ^/api/v4/.*
-  RewriteCond %{REQUEST_URI} !/Shibboleth.sso
-  RewriteCond %{REQUEST_URI} !/shibboleth-sp
-  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
+#Don't escape encoded characters in api requests
+RewriteCond %{REQUEST_URI} ^/api/v4/.*
+RewriteCond %{REQUEST_URI} !/Shibboleth.sso
+RewriteCond %{REQUEST_URI} !/shibboleth-sp
+RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
 
-  #Forward all requests to gitlab-workhorse except existing files
-  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
-  RewriteCond %{REQUEST_URI} ^/uploads/.*
-  RewriteCond %{REQUEST_URI} !/Shibboleth.sso
-  RewriteCond %{REQUEST_URI} !/shibboleth-sp
-  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]
+#Forward all requests to gitlab-workhorse except existing files
+RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
+RewriteCond %{REQUEST_URI} ^/uploads/.*
+RewriteCond %{REQUEST_URI} !/Shibboleth.sso
+RewriteCond %{REQUEST_URI} !/shibboleth-sp
+RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]
 
-  RequestHeader set X_FORWARDED_PROTO 'https'
-  RequestHeader set X-Forwarded-Ssl on
+RequestHeader set X_FORWARDED_PROTO 'https'
+RequestHeader set X-Forwarded-Ssl on
 ```

doc/integration/ultra_auth.md

@@ -11,11 +11,17 @@ To get the credentials (a pair of Client ID and Client Secret), you must registe
 1. Navigate to [Create an App](https://ultraauth.com/select-strategy) and click on "Ruby on Rails".
 1. Scroll down the page that is displayed to locate the **Client ID** and **Client Secret**.
    Keep this page open as you continue configuration.
+
    ![UltraAuth Credentials: OPENID_CLIENT_ID and OPENID_CLIENT_SECRET](img/ultra_auth_credentials.png)
+
 1. Click on "Edit Callback URL" link.
+
    ![Edit UltraAuth Callback URL](img/ultra_auth_edit_callback_url_highlighted.png)
+
 1. The callback URL will be `http(s)://<your_domain>/users/auth/ultraauth/callback`
+
    ![UltraAuth Callback URL](img/ultra_auth_edit_callback_url.png)
+
 1. Select **Register application**.
 1. On your GitLab server, open the configuration file.
 
@@ -31,6 +37,7 @@ To get the credentials (a pair of Client ID and Client Secret), you must registe
    cd /home/git/gitlab
    sudo -u git -H editor config/gitlab.yml
    ```
+
 1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
 1. Add the provider configuration:
 
@@ -64,11 +71,13 @@ To get the credentials (a pair of Client ID and Client Secret), you must registe
        }
      }
    ```
+
    __Replace `https://example.com/users/auth/ultraauth/callback` with your application's Callback URL.__
+
 1. Change `OPENID_CLIENT_ID` to the Client ID from the UltraAuth application page.
 1. Change `OPENID_CLIENT_SECRET` to the Client Secret from the UltraAuth application page.
 1. Save the configuration file.
-1.  [Reconfigure GitLab]( ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure ) or [restart GitLab]( ../administration/restart_gitlab.md#installations-from-source ) for the changes to take effect if you
+1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../administration/restart_gitlab.md#installations-from-source) for the changes to take effect if you
    installed GitLab via Omnibus or from source respectively.
 
 On the sign in page, there should now be an UltraAuth icon below the regular sign in form.