Fix indentation

[ci skip]

doc/gitlab-geo/configuration.md

@@ -220,10 +220,8 @@ Host example.com                    # The FQDN of the primary Geo node
 ## Troubleshooting
 
 Setting up Geo requires careful attention to details and sometimes it's easy to
-miss a step.
-
-Here is a checklist of questions you should ask to try to detect where you have
-to fix (all commands and path locations are for Omnibus installs):
+miss a step. Here is a checklist of questions you should ask to try to detect
+where you have to fix (all commands and path locations are for Omnibus installs):
 
 - Is Postgres replication working?
 - Are my nodes pointing to the correct database instance?
@@ -235,38 +233,48 @@ to fix (all commands and path locations are for Omnibus installs):
       with the value defined in `/etc/gitlab/gitlab.rb` configuration file.
       The relevant line looks like: `external_url "http://gitlab.example.com"`.
     - To check if node on current machine is correctly detected type:
-      `sudo gitlab-rails runner "Gitlab::Geo.current_node"`,
-      expect something like: `#<GeoNode id: 2, schema: "https", host: "gitlab.example.com", port: 443, relative_url_root: "", primary: false, ...>`
+
+        ```
+        sudo gitlab-rails runner "Gitlab::Geo.current_node"
+        ```
+
+        and expect something like:
+
+        ```
+        #<GeoNode id: 2, schema: "https", host: "gitlab.example.com", port: 443, relative_url_root: "", primary: false, ...>
+        ```
+
     - By running the command above, `primary` should be `true` when executed in
       the primary node, and `false` on any secondary
-- Did I defined the correct SSH Key for the node?
+- Did I define the correct SSH Key for the node?
     - You must create an SSH Key for `git` user
     - This key is the one you have to inform at `Admin > Geo`
 - Can I SSH from secondary to primary node using `git` user account?
     - This is the most obvious cause of problems with repository replication issues.
-      If you have not added primary node's key to `known_hosts`, you will end up with
+      If you haven't added the primary node's key to `known_hosts`, you will end up with
       a lot of failed sidekiq jobs with an error similar to:
 
-      ```
-      Gitlab::Shell::Error: Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
-      ```
+        ```
+        Gitlab::Shell::Error: Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
+        ```
 
-      Easy way to fix is by logging in as the `git` user in the secondary node and run:
+        An easy way to fix is by logging in as the `git` user in the secondary node and run:
 
-      ```
-      # remove old entries to your primary gitlab in known_hosts
-      ssh-keyscan -R your-primary-gitlab.example.com
+        ```
+        # remove old entries to your primary gitlab in known_hosts
+        ssh-keyscan -R your-primary-gitlab.example.com
 
-      # add a new entry in known_hosts
-      ssh-keyscan -t rsa your-primary-gitlab.example.com >> ~/.ssh/known_hosts
-      ```
+        # add a new entry in known_hosts
+        ssh-keyscan -t rsa your-primary-gitlab.example.com >> ~/.ssh/known_hosts
+        ```
 - Can primary node communicate with secondary node by HTTP/HTTPS ports?
 - Can secondary nodes communicate with primary node by HTTP/HTTPS/SSH ports?
-- Can secondary nodes execute a succesfull git clone using git user's own
+- Can secondary nodes execute a successful git clone using git user's own
   SSH Key to primary node repository?
 
-> This list is an attempt to document all the moving parts that can go wrong.
+>**Note:**
+This list is an attempt to document all the moving parts that can go wrong.
 We are working into getting all this steps verified automatically in a
-rake task in the future. :)
+rake task in the future.
 
 [ssh-pair]: #create-ssh-key-pairs-for-new-geo-nodes