Specify language in fenced code blocks

Markdownlint expects fenced code blocks to declare a language.

doc/administration/geo/replication/database.md

@@ -266,13 +266,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 
 1. SSH into your GitLab **secondary** server and login as root:
 
-   ```
+   ```sh
    sudo -i
    ```
 
 1. Stop application server and Sidekiq
 
-   ```
+   ```sh
    gitlab-ctl stop unicorn
    gitlab-ctl stop sidekiq
    ```
@@ -295,7 +295,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 
 1. Create a file `server.crt` in the **secondary** server, with the content you got on the last step of the **primary** node's setup:
 
-   ```
+   ```sh
    editor server.crt
    ```
 

doc/administration/geo/replication/external_database.md

@@ -13,13 +13,13 @@ developed and tested. We aim to be compatible with most external
 
 1. SSH into a GitLab **primary** application server and login as root:
 
-   ```sh
+   ```bash
    sudo -i
    ```
 
 1. Execute the command below to define the node as **primary** node:
 
-   ```sh
+   ```bash
    gitlab-ctl set-geo-primary-node
    ```
 
@@ -47,7 +47,7 @@ configures the **primary** node's database to be replicated by making changes to
 `pg_hba.conf` and `postgresql.conf`. Make the following configuration changes
 manually to your external database configuration:
 
-```
+```plaintext
 ##
 ## Geo Primary Role
 ## - pg_hba.conf
@@ -55,7 +55,7 @@ manually to your external database configuration:
 host    replication gitlab_replicator <trusted secondary IP>/32     md5
 ```
 
-```
+```plaintext
 ##
 ## Geo Primary Role
 ## - postgresql.conf
@@ -75,7 +75,7 @@ hot_standby = on
 Make the following configuration changes manually to your `postgresql.conf`
 of external replica database:
 
-```
+```plaintext
 ##
 ## Geo Secondary Role
 ## - postgresql.conf

doc/administration/geo/replication/version_specific_updates.md

@@ -357,7 +357,7 @@ is prepended with the relevant node for better clarity:
    1. **(secondary)** Save the snippet below in a file, let's say `/tmp/replica.sh`. Modify the
       embedded paths if necessary:
 
-      ```
+      ```bash
       #!/bin/bash
 
       PORT="5432"

doc/administration/git_protocol.md

@@ -37,10 +37,9 @@ service is already configured to accept the `GIT_PROTOCOL` environment and users
 need not do anything more.
 
 For Omnibus GitLab and installations from source, you have to manually update
-the SSH configuration of your server:
+the SSH configuration of your server by adding the line below to the `/etc/ssh/sshd_config` file:
 
-```
-# /etc/ssh/sshd_config
+```plaintext
 AcceptEnv GIT_PROTOCOL
 ```
 
@@ -69,7 +68,7 @@ GIT_TRACE_CURL=1 git -c protocol.version=2 ls-remote https://your-gitlab-instanc
 
 You should see that the `Git-Protocol` header is sent:
 
-```
+```plaintext
 16:29:44.577888 http.c:657              => Send header: Git-Protocol: version=2
 ```
 
@@ -105,7 +104,7 @@ GIT_SSH_COMMAND="ssh -v" git -c protocol.version=2 ls-remote ssh://your-gitlab-i
 
 You should see that the `GIT_PROTOCOL` environment variable is sent:
 
-```
+```plaintext
 debug1: Sending env GIT_PROTOCOL = version=2
 ```
 

doc/administration/gitaly/index.md

@@ -208,7 +208,7 @@ Git operations in GitLab will result in an API error.
 
    On `gitaly1.internal`:
 
-   ```
+   ```ruby
    git_data_dirs({
      'default' => {
        'path' => '/var/opt/gitlab/git-data'
@@ -221,7 +221,7 @@ Git operations in GitLab will result in an API error.
 
    On `gitaly2.internal`:
 
-   ```
+   ```ruby
    git_data_dirs({
      'storage2' => {
        'path' => '/srv/gitlab/git-data'
@@ -519,7 +519,7 @@ To configure Gitaly with TLS:
 To observe what type of connections are actually being used in a
 production environment you can use the following Prometheus query:
 
-```
+```prometheus
 sum(rate(gitaly_connections_total[5m])) by (type)
 ```
 
@@ -648,14 +648,14 @@ machine.
 Use Prometheus to see what the current authentication behavior of your
 GitLab installation is.
 
-```
+```prometheus
 sum(rate(gitaly_authentications_total[5m])) by (enforced, status)
 ```
 
 In a system where authentication is configured correctly, and where you
 have live traffic, you will see something like this:
 
-```
+```prometheus
 {enforced="true",status="ok"}  4424.985419441742
 ```
 
@@ -684,7 +684,7 @@ gitaly['auth_transitioning'] = true
 After you have applied this, your Prometheus query should return
 something like this:
 
-```
+```prometheus
 {enforced="false",status="would be ok"}  4424.985419441742
 ```
 
@@ -730,7 +730,7 @@ gitaly['auth_transitioning'] = false
 Refresh your Prometheus query. You should now see the same kind of
 result as you did in the beginning:
 
-```
+```prometheus
 {enforced="true",status="ok"}  4424.985419441742
 ```
 
@@ -870,7 +870,7 @@ gitaly-debug -h
 
 ### Commits, pushes, and clones return a 401
 
-```
+```plaintext
 remote: GitLab: 401 Unauthorized
 ```
 
@@ -902,7 +902,7 @@ Assuming your `grpc_client_handled_total` counter only observes Gitaly,
 the following query shows you RPCs are (most likely) internally
 implemented as calls to `gitaly-ruby`:
 
-```
+```prometheus
 sum(rate(grpc_client_handled_total[5m])) by (grpc_method) > 0
 ```
 

doc/administration/high_availability/consul.md

@@ -64,7 +64,7 @@ command to verify all server nodes are communicating:
 
 The output should be similar to:
 
-```
+```plaintext
 Node                 Address               Status  Type    Build  Protocol  DC
 CONSUL_NODE_ONE      XXX.XXX.XXX.YYY:8301  alive   server  0.9.2  2         gitlab_consul
 CONSUL_NODE_TWO      XXX.XXX.XXX.YYY:8301  alive   server  0.9.2  2         gitlab_consul
@@ -80,8 +80,8 @@ check the [Troubleshooting section](#troubleshooting) before proceeding.
 
 To see which nodes are part of the cluster, run the following on any member in the cluster
 
-```
-# /opt/gitlab/embedded/bin/consul members
+```shell
+$ /opt/gitlab/embedded/bin/consul members
 Node            Address               Status  Type    Build  Protocol  DC
 consul-b        XX.XX.X.Y:8301        alive   server  0.9.0  2         gitlab_consul
 consul-c        XX.XX.X.Y:8301        alive   server  0.9.0  2         gitlab_consul
@@ -127,7 +127,7 @@ By default, the server agents will attempt to [bind](https://www.consul.io/docs/
 
 You will see messages like the following in `gitlab-ctl tail consul` output if you are running into this issue:
 
-```
+```plaintext
 2017-09-25_19:53:39.90821     2017/09/25 19:53:39 [WARN] raft: no known peers, aborting election
 2017-09-25_19:53:41.74356     2017/09/25 19:53:41 [ERR] agent: failed to sync remote state: No cluster leader
 ```
@@ -154,7 +154,7 @@ In the case that a node has multiple private IPs the agent be confused as to whi
 
 You will see messages like the following in `gitlab-ctl tail consul` output if you are running into this issue:
 
-```
+```plaintext
 2017-11-09_17:41:45.52876 ==> Starting Consul agent...
 2017-11-09_17:41:45.53057 ==> Error creating agent: Failed to get advertise address: Multiple private IPs found. Please configure one.
 ```
@@ -181,10 +181,10 @@ If you lost enough server agents in the cluster to break quorum, then the cluste
 
 By default, GitLab does not store anything in the Consul cluster that cannot be recreated. To erase the Consul database and reinitialize
 
-```
-# gitlab-ctl stop consul
-# rm -rf /var/opt/gitlab/consul/data
-# gitlab-ctl start consul
+```shell
+gitlab-ctl stop consul
+rm -rf /var/opt/gitlab/consul/data
+gitlab-ctl start consul
 ```
 
 After this, the cluster should start back up, and the server agents rejoin. Shortly after that, the client agents should rejoin as well.

doc/administration/high_availability/database.md

@@ -229,7 +229,7 @@ available database connections.
 
 In this document we are assuming 3 database nodes, which makes this configuration:
 
-```
+```ruby
 postgresql['max_wal_senders'] = 4
 ```
 
@@ -352,7 +352,7 @@ When installing the GitLab package, do not supply `EXTERNAL_URL` value.
    to inform `gitlab-ctl` that they are standby nodes initially and it need not
    attempt to register them as primary node
 
-   ```
+   ```ruby
    # HA setting to specify if a node should attempt to be master on initialization
    repmgr['master_on_initialization'] = false
    ```
@@ -396,7 +396,7 @@ Select one node as a primary node.
 
    The output should be similar to the following:
 
-   ```
+   ```plaintext
    Role      | Name     | Upstream | Connection String
    ----------+----------|----------|----------------------------------------
    * master  | HOSTNAME |          | host=HOSTNAME user=gitlab_repmgr dbname=gitlab_repmgr
@@ -442,7 +442,7 @@ Select one node as a primary node.
 
    The output should be similar to the following:
 
-   ```
+   ```plaintext
    Role      | Name    | Upstream  | Connection String
    ----------+---------|-----------|------------------------------------------------
    * master  | MASTER  |           | host=MASTER_NODE_NAME user=gitlab_repmgr dbname=gitlab_repmgr
@@ -463,7 +463,7 @@ gitlab-ctl repmgr cluster show
 
 The output should be similar to:
 
-```
+```plaintext
 Role      | Name         | Upstream     | Connection String
 ----------+--------------|--------------|--------------------------------------------------------------------
 * master  | MASTER  |        | host=MASTER port=5432 user=gitlab_repmgr dbname=gitlab_repmgr
@@ -652,7 +652,7 @@ On secondary nodes, edit `/etc/gitlab/gitlab.rb` and add all the configuration
 added to primary node, noted above. In addition, append the following
 configuration:
 
-```
+```ruby
 # HA setting to specify if a node should attempt to be master on initialization
 repmgr['master_on_initialization'] = false
 ```
@@ -706,7 +706,7 @@ After deploying the configuration follow these steps:
    gitlab-psql -d gitlabhq_production
    ```
 
-   ```
+   ```shell
    CREATE EXTENSION pg_trgm;
    ```
 
@@ -804,7 +804,7 @@ consul['configuration'] = {
 On secondary nodes, edit `/etc/gitlab/gitlab.rb` and add all the information added
 to primary node, noted above. In addition, append the following configuration
 
-```
+```ruby
 # HA setting to specify if a node should attempt to be master on initialization
 repmgr['master_on_initialization'] = false
 ```
@@ -908,7 +908,7 @@ after it has been restored to service.
 
   It will output something like:
 
-  ```
+  ```plaintext
   959789412
   ```
 
@@ -1052,7 +1052,7 @@ Now there should not be errors. If errors still occur then there is another prob
 You may get this error when running `gitlab-rake gitlab:db:configure` or you
 may see the error in the PgBouncer log file.
 
-```
+```plaintext
 PG::ConnectionBad: ERROR:  pgbouncer cannot connect to server
 ```
 
@@ -1063,13 +1063,13 @@ You can confirm that this is the issue by checking the PostgreSQL log on the mas
 database node. If you see the following error then `trust_auth_cidr_addresses`
 is the problem.
 
-```
+```plaintext
 2018-03-29_13:59:12.11776 FATAL:  no pg_hba.conf entry for host "123.123.123.123", user "pgbouncer", database "gitlabhq_production", SSL off
 ```
 
 To fix the problem, add the IP address to `/etc/gitlab/gitlab.rb`.
 
-```
+```ruby
 postgresql['trust_auth_cidr_addresses'] = %w(123.123.123.123/32 <other_cidrs>)
 ```
 

doc/administration/high_availability/gitlab.md

@@ -11,7 +11,7 @@ these additional steps before proceeding with GitLab installation.
 1. If necessary, install the NFS client utility packages using the following
    commands:
 
-   ```
+   ```shell
    # Ubuntu/Debian
    apt-get install nfs-common
 
@@ -24,7 +24,7 @@ these additional steps before proceeding with GitLab installation.
    to configure your NFS server. See [NFS documentation](nfs.md) for the various
    options. Here is an example snippet to add to `/etc/fstab`:
 
-   ```
+   ```plaintext
    10.1.0.1:/var/opt/gitlab/.ssh /var/opt/gitlab/.ssh nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2
    10.1.0.1:/var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/uploads nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2
    10.1.0.1:/var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-rails/shared nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2
@@ -35,7 +35,7 @@ these additional steps before proceeding with GitLab installation.
 1. Create the shared directories. These may be different depending on your NFS
    mount locations.
 
-   ```
+   ```shell
    mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
    ```
 

doc/administration/high_availability/nfs.md

@@ -132,7 +132,7 @@ For supported database architecture, please see our documentation on
 Below is an example of an NFS mount point defined in `/etc/fstab` we use on
 GitLab.com:
 
-```
+```plaintext
 10.1.1.1:/var/opt/gitlab/git-data /var/opt/gitlab/git-data nfs4 defaults,soft,rsize=1048576,wsize=1048576,noatime,nofail,lookupcache=positive 0 2
 ```
 
@@ -149,7 +149,7 @@ Note there are several options that you should consider using:
 It's recommended to nest all GitLab data dirs within a mount, that allows automatic
 restore of backups without manually moving existing data.
 
-```
+```plaintext
 mountpoint
 └── gitlab-data
     ├── builds