Fix whitespace in many administration 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 for many admin
docs in /high_availability and /auth (part 1)

doc/administration/auth/authentiq.md

@@ -9,6 +9,7 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
 1. On your GitLab server, open the configuration file:
 
    For omnibus installation
+
    ```sh
    sudo editor /etc/gitlab/gitlab.rb
    ```

doc/administration/auth/crowd.md

@@ -55,6 +55,7 @@
             application_name: 'YOUR_APP_NAME',
             application_password: 'YOUR_APP_PASSWORD' } }
    ```
+
 1. Change `CROWD_SERVER_URL` to the URL of your Crowd server.
 1. Change `YOUR_APP_NAME` to the application name from Crowd applications page.
 1. Change `YOUR_APP_PASSWORD` to the application password you've set.

doc/administration/auth/ldap-ee.md

@@ -191,7 +191,6 @@ to lock down user abilities to invite new members to a group. When enabled follo
 1. Only administrator can manage memberships of any group including access levels.
 2. Users are not allowed to share project with other groups or invite members to a project created in a group.
 
-
 ## Adjusting LDAP user sync schedule
 
 > Introduced in GitLab Enterprise Edition Starter.
@@ -448,6 +447,7 @@ step of the sync.
    ```ruby
    Rails.logger.level = Logger::DEBUG
    ```
+
 1. Choose a GitLab group to test with. This group should have an LDAP group link
    already configured. If the output is `nil`, the group could not be found.
    If a bunch of group attributes are output, your group was found successfully.
@@ -458,11 +458,13 @@ step of the sync.
    # Output
    => #<Group:0x007fe825196558 id: 1234, name: "my_group"...>
    ```
+
 1. Run a group sync for this particular group.
 
    ```ruby
    EE::Gitlab::Auth::LDAP::Sync::Group.execute_all_providers(group)
    ```
+
 1. Look through the output of the sync. See [example log output](#example-log-output)
    below for more information about the output.
 1. If you still aren't able to see why the user isn't being added, query the
@@ -476,6 +478,7 @@ step of the sync.
    # Output
    => #<EE::Gitlab::Auth::LDAP::Group:0x007fcbdd0bb6d8
    ```
+
 1. Query the LDAP group's member DNs and see if the user's DN is in the list.
    One of the DNs here should match the 'Identifier' from the LDAP identity
    checked earlier. If it doesn't, the user does not appear to be in the LDAP
@@ -487,6 +490,7 @@ step of the sync.
    # Output
    => ["uid=john,ou=people,dc=example,dc=com", "uid=mary,ou=people,dc=example,dc=com"]
    ```
+
 1. Some LDAP servers don't store members by DN. Rather, they use UIDs instead.
    If you didn't see results from the last query, try querying by UIDs instead.
 

doc/administration/high_availability/consul.md

@@ -77,6 +77,7 @@ check the [Troubleshooting section](#troubleshooting) before proceeding.
 ### Checking cluster membership
 
 To see which nodes are part of the cluster, run the following on any member in the cluster
+
 ```
 # /opt/gitlab/embedded/bin/consul members
 Node            Address               Status  Type    Build  Protocol  DC
@@ -112,7 +113,6 @@ You will see messages like the following in `gitlab-ctl tail consul` output if y
 2017-09-25_19:53:41.74356     2017/09/25 19:53:41 [ERR] agent: failed to sync remote state: No cluster leader
 ```
 
-
 To fix this:
 
 1. Pick an address on each node that all of the other nodes can reach this node through.
@@ -124,6 +124,7 @@ To fix this:
      bind_addr: 'IP ADDRESS'
    }
    ```
+
 1. Run `gitlab-ctl reconfigure`
 
 If you still see the errors, you may have to [erase the consul database and reinitialize](#recreate-from-scratch) on the affected node.
@@ -150,6 +151,7 @@ To fix this:
      bind_addr: 'IP ADDRESS'
    }
    ```
+
 1. Run `gitlab-ctl reconfigure`
 
 ### Outage recovery
@@ -157,6 +159,7 @@ To fix this:
 If you lost enough server agents in the cluster to break quorum, then the cluster is considered failed, and it will not function without manual intervenetion.
 
 #### Recreate from scratch
+
 By default, GitLab does not store anything in the consul cluster that cannot be recreated. To erase the consul database and reinitialize
 
 ```
@@ -168,4 +171,5 @@ By default, GitLab does not store anything in the consul cluster that cannot be
 After this, the cluster should start back up, and the server agents rejoin. Shortly after that, the client agents should rejoin as well.
 
 #### Recover a failed cluster
+
 If you have taken advantage of consul to store other data, and want to restore the failed cluster, please follow the [Consul guide](https://www.consul.io/docs/guides/outage.html) to recover a failed cluster.

doc/administration/high_availability/database.md

@@ -288,7 +288,6 @@ Make sure you install the necessary dependencies from step 1,
 add GitLab package repository from step 2.
 When installing the GitLab package, do not supply `EXTERNAL_URL` value.
 
-
 #### Configuring the Database nodes
 
 1. Make sure to [configure the Consul nodes](consul.md).
@@ -343,6 +342,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
    to `/etc/gitlab/gitlab.rb`. In addition, append the following configuration
    to inform gitlab-ctl that they are standby nodes initially and it need not
    attempt to register them as primary node
+
    ```
    # HA setting to specify if a node should attempt to be master on initialization
    repmgr['master_on_initialization'] = false
@@ -977,7 +977,7 @@ If you enable Monitoring, it must be enabled on **all** database servers.
 
 ## Troubleshooting
 
-### Consul and PostgreSQL changes not taking effect.
+### Consul and PostgreSQL changes not taking effect
 
 Due to the potential impacts, `gitlab-ctl reconfigure` only reloads Consul and PostgreSQL, it will not restart the services. However, not all changes can be activated by reloading.
 

doc/administration/high_availability/nfs.md

@@ -42,8 +42,8 @@ maintaining ID mapping without LDAP, in most cases you should enable numeric UID
 and GIDs (which is off by default in some cases) for simplified permission
 management between systems:
 
-  - [NetApp instructions](https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-24367A9F-E17B-4725-ADC1-02D86F56F78E.html)
-  - For non-NetApp devices, disable NFSv4 `idmapping` by performing opposite of [enable NFSv4 idmapper](https://wiki.archlinux.org/index.php/NFS#Enabling_NFSv4_idmapping)
+- [NetApp instructions](https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-24367A9F-E17B-4725-ADC1-02D86F56F78E.html)
+- For non-NetApp devices, disable NFSv4 `idmapping` by performing opposite of [enable NFSv4 idmapper](https://wiki.archlinux.org/index.php/NFS#Enabling_NFSv4_idmapping)
 
 ### Improving NFS performance with GitLab
 

doc/administration/high_availability/pgbouncer.md

@@ -147,9 +147,9 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
 
 > [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3786) in GitLab 12.0.
 
-  If you enable Monitoring, it must be enabled on **all** pgbouncer servers.
+If you enable Monitoring, it must be enabled on **all** pgbouncer servers.
 
-  1. Create/edit `/etc/gitlab/gitlab.rb` and add the following configuration:
+1. Create/edit `/etc/gitlab/gitlab.rb` and add the following configuration:
 
    ```ruby
    # Enable service discovery for Prometheus
@@ -168,7 +168,7 @@ It is recommended to run pgbouncer alongside the `gitlab-rails` service, or on i
    pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
    ```
 
-  1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
+1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
 
 ### Interacting with pgbouncer
 
@@ -190,6 +190,7 @@ pgbouncer=#
 The password you will be prompted for is the PGBOUNCER_USER_PASSWORD
 
 To get some basic information about the instance, run
+
 ```shell
 pgbouncer=# show databases; show clients; show servers;
         name         |   host    | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections

doc/administration/high_availability/redis.md

@@ -593,7 +593,7 @@ which ideally should not have Redis or Sentinels on it for a HA setup.
 1. SSH into the server where the GitLab application is installed.
 1. Edit `/etc/gitlab/gitlab.rb` and add/change the following lines:
 
-    ```
+   ```ruby
    ## Must be the same in every sentinel node
    redis['master_name'] = 'gitlab-redis'
 
@@ -796,10 +796,12 @@ cache, queues, and shared_state. To make this work with Sentinel:
    gitlab_rails['redis_queues_instance'] = REDIS_QUEUES_URL
    gitlab_rails['redis_shared_state_instance'] = REDIS_SHARED_STATE_URL
    ```
+
     **Note**: Redis URLs should be in the format: `redis://:PASSWORD@SENTINEL_MASTER_NAME`
 
    1. PASSWORD is the plaintext password for the Redis instance
    1. SENTINEL_MASTER_NAME is the Sentinel master name (e.g. `gitlab-redis-cache`)
+
 1. Include an array of hashes with host/port combinations, such as the following:
 
    ```ruby
@@ -816,6 +818,7 @@ cache, queues, and shared_state. To make this work with Sentinel:
      { host: SHARED_STATE_SENTINEL_HOST2, port: PORT2 }
    ]
    ```
+
 1. Note that for each persistence class, GitLab will default to using the
    configuration specified in `gitlab_rails['redis_sentinels']` unless
    overridden by the settings above.

doc/administration/high_availability/redis_source.md

@@ -160,6 +160,7 @@ master with IP `10.0.0.1` (some settings might overlap with the master):
    ##   the exact parallel-syncs progression as specified.
    sentinel failover_timeout 30000
    ```
+
 1. Restart the Redis service for the changes to take effect.
 1. Go through the steps again for all the other Sentinel nodes.