Add language declarations to code blocks

Markdownlint expects fenced code blocks to declare a language.
This commit adds language declarations to fenced code blocks in
pages in the /administration area.

doc/administration/high_availability/pgbouncer.md

@@ -83,7 +83,7 @@ In a HA setup, it's recommended to run a PgBouncer node separately for each data
 
    The output should be similar to the following:
 
-   ```
+   ```plaintext
            name         |  host       | port |      database       | force_user | pool_size | reserve_pool | pool_mode | max_connections | current_connections
    ---------------------+-------------+------+---------------------+------------+-----------+--------------+-----------+-----------------+---------------------
     gitlabhq_production | MASTER_HOST | 5432 | gitlabhq_production |            |        20 |            0 |           |               0 |                   0
@@ -102,7 +102,7 @@ If you're running more than one PgBouncer node as recommended, then at this time
 
 As an example here's how you could do it with [HAProxy](https://www.haproxy.org/):
 
-```
+```plaintext
 global
     log /dev/log local0
     log localhost local1 notice

doc/administration/high_availability/redis.md

@@ -391,7 +391,7 @@ The prerequisites for a HA Redis setup are the following:
    prevent database migrations from running on upgrade, add the following
    configuration to your `/etc/gitlab/gitlab.rb` file:
 
-   ```
+   ```ruby
    gitlab_rails['auto_migrate'] = false
    ```
 
@@ -439,7 +439,7 @@ The prerequisites for a HA Redis setup are the following:
 
 1. To prevent reconfigure from running automatically on upgrade, run:
 
-   ```
+   ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
@@ -569,7 +569,7 @@ multiple machines with the Sentinel daemon.
 
 1. To prevent database migrations from running on upgrade, run:
 
-   ```
+   ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
@@ -898,14 +898,14 @@ Before proceeding with the troubleshooting below, check your firewall rules:
 You can check if everything is correct by connecting to each server using
 `redis-cli` application, and sending the `info replication` command as below.
 
-```
+```shell
 /opt/gitlab/embedded/bin/redis-cli -h <redis-host-or-ip> -a '<redis-password>' info replication
 ```
 
 When connected to a `master` Redis, you will see the number of connected
 `slaves`, and a list of each with connection details:
 
-```
+```plaintext
 # Replication
 role:master
 connected_slaves:1
@@ -920,7 +920,7 @@ repl_backlog_histlen:1048576
 When it's a `slave`, you will see details of the master connection and if
 its `up` or `down`:
 
-```
+```plaintext
 # Replication
 role:slave
 master_host:10.133.1.58
@@ -959,7 +959,7 @@ To make sure your configuration is correct:
 1. SSH into your GitLab application server
 1. Enter the Rails console:
 
-   ```
+   ```shell
    # For Omnibus installations
    sudo gitlab-rails console
 
@@ -985,7 +985,7 @@ To make sure your configuration is correct:
 
 1. Then back in the Rails console from the first step, run:
 
-   ```
+   ```ruby
    redis.info
    ```
 

doc/administration/logs.md

@@ -96,7 +96,7 @@ request that have been performed and how much time it took. This task is
 more useful for GitLab contributors and developers. Use part of this log
 file when you are going to report bug. For example:
 
-```
+```plaintext
 Started GET "/gitlabhq/yaml_db/tree/master" for 168.111.56.1 at 2015-02-12 19:34:53 +0200
 Processing by Projects::TreeController#show as HTML
   Parameters: {"project_id"=>"gitlabhq/yaml_db", "id"=>"master"}
@@ -151,7 +151,7 @@ installations from source.
 It helps you discover events happening in your instance such as user creation,
 project removing and so on. For example:
 
-```
+```plaintext
 October 06, 2014 11:56: User "Administrator" (admin@example.com) was created
 October 06, 2014 11:56: Documentcloud created a new project "Documentcloud / Underscore"
 October 06, 2014 11:56: Gitlab Org created a new project "Gitlab Org / Gitlab Ce"
@@ -167,7 +167,7 @@ installations from source.
 
 It contains information about [integrations](../user/project/integrations/project_services.md) activities such as Jira, Asana and Irker services. It uses JSON format like the example below:
 
-``` json
+```json
 {"severity":"ERROR","time":"2018-09-06T14:56:20.439Z","service_class":"JiraService","project_id":8,"project_path":"h5bp/html5-boilerplate","message":"Error sending message","client_url":"http://jira.gitlap.com:8080","error":"execution expired"}
 {"severity":"INFO","time":"2018-09-06T17:15:16.365Z","service_class":"JiraService","project_id":3,"project_path":"namespace2/project2","message":"Successfully posted","client_url":"http://jira.example.com"}
 ```
@@ -276,7 +276,7 @@ installations from source.
 GitLab Shell is used by GitLab for executing Git commands and provide
 SSH access to Git repositories. For example:
 
-```
+```plaintext
 I, [2015-02-13T06:17:00.671315 #9291]  INFO -- : Adding project root/example.git at </var/opt/gitlab/git-data/repositories/root/dcdcdcdcd.git>.
 I, [2015-02-13T06:17:00.679433 #9291]  INFO -- : Moving existing hooks directory and symlinking global hooks directory for /var/opt/gitlab/git-data/repositories/root/example.git.
 ```
@@ -294,7 +294,7 @@ serving the GitLab application. You can look at this log if, for
 example, your application does not respond. This log contains all
 information about the state of Unicorn processes at any given time.
 
-```
+```plaintext
 I, [2015-02-13T06:14:46.680381 #9047]  INFO -- : Refreshing Gem list
 I, [2015-02-13T06:14:56.931002 #9047]  INFO -- : listening on addr=127.0.0.1:8080 fd=12
 I, [2015-02-13T06:14:56.931381 #9047]  INFO -- : listening on addr=/var/opt/gitlab/gitlab-rails/sockets/gitlab.socket fd=13

doc/administration/monitoring/performance/grafana_configuration.md

@@ -57,14 +57,14 @@ repository.
 
 To use this repository you must first clone it:
 
-```
+```shell
 git clone https://gitlab.com/gitlab-org/influxdb-management.git
 cd influxdb-management
 ```
 
 Next you must install the required dependencies:
 
-```
+```shell
 gem install bundler
 bundle install
 ```
@@ -139,7 +139,7 @@ echo "0" > /var/opt/gitlab/grafana/CVE_reset_status
 
 To reinstate your old data, move it back into its original location:
 
-```
+```shell
 sudo mv /var/opt/gitlab/grafana/data.bak.xxxx/ /var/opt/gitlab/grafana/data/
 ```
 

doc/administration/monitoring/performance/influxdb_configuration.md

@@ -48,7 +48,7 @@ upcoming InfluxDB releases.
 
 Make sure you have the following in your configuration file:
 
-```
+```toml
 [data]
   dir = "/var/lib/influxdb/data"
   engine = "tsm1"
@@ -60,7 +60,7 @@ Production environments should have the InfluxDB admin panel **disabled**. This
 feature can be disabled by adding the following to your InfluxDB configuration
 file:
 
-```
+```toml
 [admin]
   enabled = false
 ```
@@ -71,7 +71,7 @@ HTTP is required when using the [InfluxDB CLI] or other tools such as Grafana,
 thus it should be enabled. When enabling make sure to _also_ enable
 authentication:
 
-```
+```toml
 [http]
   enabled = true
   auth-enabled = true
@@ -85,7 +85,7 @@ admin user](#create-a-new-admin-user)._
 GitLab writes data to InfluxDB via UDP and thus this must be enabled. Enabling
 UDP can be done using the following settings:
 
-```
+```toml
 [[udp]]
   enabled = true
   bind-address = ":8089"
@@ -138,7 +138,7 @@ allowing traffic from members of said VLAN.
 If you want to [enable authentication](#http), you might want to [create an
 admin user][influx-admin]:
 
-```
+```shell
 influx -execute "CREATE USER jeff WITH PASSWORD '1234' WITH ALL PRIVILEGES"
 ```
 
@@ -168,7 +168,7 @@ influx -execute 'SHOW DATABASES'
 
 The output should be similar to:
 
-```
+```plaintext
 name: databases
 ---------------
 name

doc/administration/monitoring/performance/influxdb_schema.md

@@ -43,7 +43,7 @@ while the method name is stored in the tag `method`. The tag `action` contains
 the full name of the transaction action. Both the `method` and `action` fields
 are in the following format:
 
-```
+```plaintext
 ClassName#method_name
 ```
 

doc/administration/operations/cleaning_up_redis_sessions.md

@@ -22,7 +22,7 @@ settings outlined in
 
 First we define a shell function with the proper Redis connection details.
 
-```
+```shell
 rcli() {
   # This example works for Omnibus installations of GitLab 7.3 or newer. For an
   # installation from source you will have to change the socket path and the
@@ -37,7 +37,7 @@ rcli ping
 Now we do a search to see if there are any session keys in the old format for
 us to clean up.
 
-```
+```shell
 # returns the number of old-format session keys in Redis
 rcli keys '*' | grep '^[a-f0-9]\{32\}$' | wc -l
 ```
@@ -45,7 +45,7 @@ rcli keys '*' | grep '^[a-f0-9]\{32\}$' | wc -l
 If the number is larger than zero, you can proceed to expire the keys from
 Redis. If the number is zero there is nothing to clean up.
 
-```
+```shell
 # Tell Redis to expire each matched key after 600 seconds.
 rcli keys '*' | grep '^[a-f0-9]\{32\}$' | awk '{ print "expire", $0, 600 }' | rcli
 # This will print '(integer) 1' for each key that gets expired.

doc/administration/operations/fast_ssh_key_lookup.md

@@ -53,7 +53,7 @@ Add the following to your `sshd_config` file. This is usually located at
 `/etc/ssh/sshd_config`, but it will be `/assets/sshd_config` if you're using
 Omnibus Docker:
 
-```
+```plaintext
 AuthorizedKeysCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-keys-check git %u %k
 AuthorizedKeysCommandUser git
 ```
@@ -117,7 +117,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
 1. First, download the package and install the required packages:
 
-   ```
+   ```shell
    sudo su -
    cd /tmp
    curl --remote-name https://mirrors.evowise.com/pub/OpenBSD/OpenSSH/portable/openssh-7.5p1.tar.gz
@@ -127,7 +127,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
 1. Prepare the build by copying files to the right place:
 
-   ```
+   ```shell
    mkdir -p /root/rpmbuild/{SOURCES,SPECS}
    cp ./openssh-7.5p1/contrib/redhat/openssh.spec /root/rpmbuild/SPECS/
    cp openssh-7.5p1.tar.gz /root/rpmbuild/SOURCES/
@@ -136,7 +136,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
 1. Next, set the spec settings properly:
 
-   ```
+   ```shell
    sed -i -e "s/%define no_gnome_askpass 0/%define no_gnome_askpass 1/g" openssh.spec
    sed -i -e "s/%define no_x11_askpass 0/%define no_x11_askpass 1/g" openssh.spec
    sed -i -e "s/BuildPreReq/BuildRequires/g" openssh.spec
@@ -144,19 +144,19 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
 1. Build the RPMs:
 
-   ```
+   ```shell
    rpmbuild -bb openssh.spec
    ```
 
 1. Ensure the RPMs were built:
 
-   ```
+   ```shell
    ls -al /root/rpmbuild/RPMS/x86_64/
    ```
 
    You should see something as the following:
 
-   ```
+   ```plaintext
    total 1324
    drwxr-xr-x. 2 root root   4096 Jun 20 19:37 .
    drwxr-xr-x. 3 root root     19 Jun 20 19:37 ..
@@ -170,7 +170,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
    with its own version, which may prevent users from logging in, so be sure
    that the file is backed up and restored after installation:
 
-   ```
+   ```shell
    timestamp=$(date +%s)
    cp /etc/pam.d/sshd pam-ssh-conf-$timestamp
    rpm -Uvh /root/rpmbuild/RPMS/x86_64/*.rpm
@@ -179,7 +179,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
 1. Verify the installed version. In another window, attempt to login to the server:
 
-   ```
+   ```shell
    ssh -v <your-centos-machine>
    ```
 
@@ -191,7 +191,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
    sure everything is working! If you need to downgrade, simple install the
    older package:
 
-   ```
+   ```shell
    # Only run this if you run into a problem logging in
    yum downgrade openssh-server openssh openssh-clients
    ```