Fix spacing in geo docs

Spacing following lists should be 2 spaces, and 3 for numbered lists

1 files changed, 86 insertions, 89 deletions

diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index 3d4f69d3abe..dd5e09c0dd7 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -16,11 +16,10 @@ The basic steps of configuring a **secondary** node are to:
 You are encouraged to first read through all the steps before executing them
 in your testing/production environment.
 
-> **Notes:**
-> - **Do not** setup any custom authentication for the **secondary** nodes. This will be
-  handled by the **primary** node.
-> - Any change that requires access to the **Admin Area** needs to be done in the
-  **primary** node because the **secondary** node is a read-only replica.
+NOTE: **Note:**
+**Do not** set up any custom authentication for the **secondary** nodes. This will be handled by the **primary** node.  
+Any change that requires access to the **Admin Area** needs to be done in the
+**primary** node because the **secondary** node is a read-only replica.
 
 ### Step 1. Manually replicate secret GitLab values
 
@@ -31,47 +30,47 @@ they must be manually replicated to the **secondary** node.
 
 1. SSH into the **primary** node, and execute the command below:
 
-    ```sh
-    sudo cat /etc/gitlab/gitlab-secrets.json
-    ```
+   ```sh
+   sudo cat /etc/gitlab/gitlab-secrets.json
+   ```
 
-    This will display the secrets that need to be replicated, in JSON format.
+   This will display the secrets that need to be replicated, in JSON format.
 
 1. SSH into the **secondary** node and login as the `root` user:
 
-    ```sh
-    sudo -i
-    ```
+   ```sh
+   sudo -i
+   ```
 
 1. Make a backup of any existing secrets:
 
-    ```sh
-    mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
-    ```
+   ```sh
+   mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
+   ```
 
 1. Copy `/etc/gitlab/gitlab-secrets.json` from the **primary** node to the **secondary** node, or
    copy-and-paste the file contents between nodes:
 
-    ```sh
-    sudo editor /etc/gitlab/gitlab-secrets.json
+   ```sh
+   sudo editor /etc/gitlab/gitlab-secrets.json
 
-    # paste the output of the `cat` command you ran on the primary
-    # save and exit
-    ```
+   # paste the output of the `cat` command you ran on the primary
+   # save and exit
+   ```
 
 1. Ensure the file permissions are correct:
 
-    ```sh
-    chown root:root /etc/gitlab/gitlab-secrets.json
-    chmod 0600 /etc/gitlab/gitlab-secrets.json
-    ```
+   ```sh
+   chown root:root /etc/gitlab/gitlab-secrets.json
+   chmod 0600 /etc/gitlab/gitlab-secrets.json
+   ```
 
 1. Reconfigure the **secondary** node for the change to take effect:
 
-    ```sh
-    gitlab-ctl reconfigure
-    gitlab-ctl restart
-    ```
+   ```sh
+   gitlab-ctl reconfigure
+   gitlab-ctl restart
+   ```
 
 ### Step 2. Manually replicate the **primary** node's SSH host keys
 
@@ -89,80 +88,80 @@ keys must be manually replicated to the **secondary** node.
 
 1. SSH into the **secondary** node and login as the `root` user:
 
-    ```sh
-    sudo -i
-    ```
+   ```sh
+   sudo -i
+   ```
 
 1. Make a backup of any existing SSH host keys:
 
-    ```sh
-    find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
-    ```
+   ```sh
+   find /etc/ssh -iname ssh_host_* -exec cp {} {}.backup.`date +%F` \;
+   ```
 
 1. Copy OpenSSH host keys from the **primary** node:
 
-    If you can access your **primary** node using the **root** user:
+   If you can access your **primary** node using the **root** user:
 
-    ```sh
-    # Run this from the secondary node, change `<primary_node_fqdn>` for the IP or FQDN of the server
-    scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
-    ```
+   ```sh
+   # Run this from the secondary node, change `<primary_node_fqdn>` for the IP or FQDN of the server
+   scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
+   ```
 
-    If you only have access through a user with **sudo** privileges:
+   If you only have access through a user with **sudo** privileges:
 
-    ```sh
-    # Run this from your primary node:
-    sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
+   ```sh
+   # Run this from your primary node:
+   sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
 
-    # Run this from your secondary node:
-    scp <user_with_sudo>@<primary_node_fqdn>:geo-host-key.tar.gz .
-    tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
-    ```
+   # Run this from your secondary node:
+   scp <user_with_sudo>@<primary_node_fqdn>:geo-host-key.tar.gz .
+   tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
+   ```
 
 1. On your **secondary** node, ensure the file permissions are correct:
 
-    ```sh
-    chown root:root /etc/ssh/ssh_host_*_key*
-    chmod 0600 /etc/ssh/ssh_host_*_key*
-    ```
+   ```sh
+   chown root:root /etc/ssh/ssh_host_*_key*
+   chmod 0600 /etc/ssh/ssh_host_*_key*
+   ```
 
 1. To verify key fingerprint matches, execute the following command on both nodes:
 
-    ```sh
-    for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
-    ```
+   ```sh
+   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
+   ```
 
-    You should get an output similar to this one and they should be identical on both nodes:
+   You should get an output similar to this one and they should be identical on both nodes:
 
-    ```sh
-    1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
-    256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
-    256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
-    2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)
-    ```
+   ```sh
+   1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
+   256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
+   256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
+   2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)
+   ```
 
 1. Verify that you have the correct public keys for the existing private keys:
 
-    ```sh
-    # This will print the fingerprint for private keys:
-    for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
+   ```sh
+   # This will print the fingerprint for private keys:
+   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
 
-    # This will print the fingerprint for public keys:
-    for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
-    ```
+   # This will print the fingerprint for public keys:
+   for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
+   ```
 
-    NOTE: **Note**:
-    The output for private keys and public keys command should generate the same fingerprint.
+   NOTE: **Note:**
+   The output for private keys and public keys command should generate the same fingerprint.
 
 1. Restart sshd on your **secondary** node:
 
-    ```sh
-    # Debian or Ubuntu installations
-    sudo service ssh reload
+   ```sh
+   # Debian or Ubuntu installations
+   sudo service ssh reload
 
-    # CentOS installations
-    sudo service sshd reload
-    ```
+   # CentOS installations
+   sudo service sshd reload
+   ```
 
 ### Step 3. Add the **secondary** node
 
@@ -176,22 +175,22 @@ keys must be manually replicated to the **secondary** node.
 1. Click the **Add node** button.
 1. SSH into your GitLab **secondary** server and restart the services:
 
-    ```sh
-    gitlab-ctl restart
-    ```
+   ```sh
+   gitlab-ctl restart
+   ```
 
-    Check if there are any common issue with your Geo setup by running:
+   Check if there are any common issue with your Geo setup by running:
 
-    ```sh
-    gitlab-rake gitlab:geo:check
-    ```
+   ```sh
+   gitlab-rake gitlab:geo:check
+   ```
 
 1. SSH into your **primary** server and login as root to verify the
    **secondary** node is reachable or there are any common issue with your Geo setup:
 
-    ```sh
-    gitlab-rake gitlab:geo:check
-    ```
+   ```sh
+   gitlab-rake gitlab:geo:check
+   ```
 
 Once added to the admin panel and restarted, the **secondary** node will automatically start
 replicating missing data from the **primary** node in a process known as **backfill**.
@@ -250,9 +249,8 @@ The two most obvious issues that can become apparent in the dashboard are:
 1. Database replication not working well.
 1. Instance to instance notification not working. In that case, it can be
    something of the following:
-     - You are using a custom certificate or custom CA (see the
-       [troubleshooting document]).
-     - The instance is firewalled (check your firewall rules).
+   - You are using a custom certificate or custom CA (see the [troubleshooting document](troubleshooting.md)).
+   - The instance is firewalled (check your firewall rules).
 
 Please note that disabling a **secondary** node will stop the synchronization process.
 
@@ -304,5 +302,4 @@ See the [troubleshooting document](troubleshooting.md).
 [gitlab-org/gitlab-ee#3789]: https://gitlab.com/gitlab-org/gitlab-ee/issues/3789
 [gitlab-com/infrastructure#2821]: https://gitlab.com/gitlab-com/infrastructure/issues/2821
 [omnibus-ssl]: https://docs.gitlab.com/omnibus/settings/ssl.html
-[troubleshooting document]: troubleshooting.md
 [using-geo]: using_a_geo_server.md