Merge branch 'docs-aqualls-20200302.1-codeblocks' into 'master'

Add language declarations to code blocks

See merge request gitlab-org/gitlab!26338

doc/raketasks/backup_restore.md

@@ -115,7 +115,7 @@ also running Unicorn/Puma and/or Sidekiq.
 
 Example output:
 
-```
+```plaintext
 Dumping database tables:
 - Dumping table events... [DONE]
 - Dumping table issues... [DONE]
@@ -465,7 +465,7 @@ For installations from source:
 Note: This option only works for remote storage. If you want to group your backups
 you can pass a `DIRECTORY` environment variable:
 
-```
+```shell
 sudo gitlab-backup create DIRECTORY=daily
 sudo gitlab-backup create DIRECTORY=weekly
 ```
@@ -586,7 +586,7 @@ crontab -e
 
 There, add the following line to schedule the backup for everyday at 2 AM:
 
-```
+```plaintext
 0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
 ```
 
@@ -614,7 +614,7 @@ sudo -u git crontab -e # Edit the crontab for the git user
 
 Add the following lines at the bottom:
 
-```
+```plaintext
 # Create a full backup of the GitLab repositories and SQL database every day at 4am
 0 4 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1
 ```
@@ -674,7 +674,7 @@ Read more on [configuring NFS mounts](../administration/high_availability/nfs.md
 
 ### Restore for installation from source
 
-```
+```shell
 # Stop processes that are connected to the database
 sudo service gitlab stop
 
@@ -683,7 +683,7 @@ bundle exec rake gitlab:backup:restore RAILS_ENV=production
 
 Example output:
 
-```
+```plaintext
 Unpacking backup... [DONE]
 Restoring database tables:
 -- create_table("events", {:force=>true})
@@ -853,7 +853,7 @@ will have all your repositories, but not any other data.
 
 If you are using backup restore procedures you might encounter the following warnings:
 
-```
+```plaintext
 psql:/var/opt/gitlab/backups/db/database.sql:22: ERROR:  must be owner of extension plpgsql
 psql:/var/opt/gitlab/backups/db/database.sql:2931: WARNING:  no privileges could be revoked for "public" (two occurrences)
 psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING:  no privileges were granted for "public" (two occurrences)
@@ -1003,7 +1003,7 @@ GitLab instance after restoring the registry data.
 
 These failures will mention permission issues in the registry logs, like:
 
-```
+```plaintext
 level=error
 msg="response completed with error"
 err.code=unknown

doc/raketasks/cleanup.md

@@ -6,7 +6,7 @@ Clean up local project upload files if they don't exist in GitLab database. The
 task attempts to fix the file if it can find its project, otherwise it moves the
 file to a lost and found directory.
 
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-rake gitlab:cleanup:project_uploads
 
@@ -16,8 +16,9 @@ bundle exec rake gitlab:cleanup:project_uploads RAILS_ENV=production
 
 Example output:
 
-```
+```shell
 $ sudo gitlab-rake gitlab:cleanup:project_uploads
+
 I, [2018-07-27T12:08:27.671559 #89817]  INFO -- : Looking for orphaned project uploads to clean up. Dry run...
 D, [2018-07-27T12:08:28.293568 #89817] DEBUG -- : Processing batch of 500 project upload file paths, starting with /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test.out
 I, [2018-07-27T12:08:28.689869 #89817]  INFO -- : Can move to lost and found /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test.out -> /opt/gitlab/embedded/service/gitlab-rails/public/uploads/-/project-lost-found/test.out
@@ -35,7 +36,7 @@ I, [2018-07-27T12:08:33.760257 #89817]  INFO -- : Did move to lost and found /op
 
 Remove object store upload files if they don't exist in GitLab database.
 
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-rake gitlab:cleanup:remote_upload_files
 
@@ -45,7 +46,7 @@ bundle exec rake gitlab:cleanup:remote_upload_files RAILS_ENV=production
 
 Example output:
 
-```
+```shell
 $ sudo gitlab-rake gitlab:cleanup:remote_upload_files
 
 I, [2018-08-02T10:26:13.995978 #45011]  INFO -- : Looking for orphaned remote uploads to remove. Dry run...
@@ -54,7 +55,7 @@ I, [2018-08-02T10:26:14.120482 #45011]  INFO -- : Can be moved to lost and found
 I, [2018-08-02T10:26:14.120634 #45011]  INFO -- : To cleanup these files run this command with DRY_RUN=false
 ```
 
-```
+```shell
 $ sudo gitlab-rake gitlab:cleanup:remote_upload_files DRY_RUN=false
 
 I, [2018-08-02T10:26:47.598424 #45087]  INFO -- : Looking for orphaned remote uploads to remove...
@@ -109,7 +110,7 @@ level with `NICENESS`. Below are the valid levels, but consult
 
 ## Remove expired ActiveSession lookup keys
 
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-rake gitlab:cleanup:sessions:active_sessions_lookup_keys
 

doc/raketasks/features.md

@@ -15,6 +15,6 @@ Old path: `git@example.org:myrepo.git`
 
 New path: `git@example.org:username/myrepo.git` or `git@example.org:groupname/myrepo.git`
 
-```
+```shell
 bundle exec rake gitlab:enable_namespaces RAILS_ENV=production
 ```

doc/raketasks/generate_sample_prometheus_data.md

@@ -11,6 +11,6 @@ which loads the appropriate data set if it is present within the `sample_metrics
 
 **Example:**
 
-```
+```shell
 bundle exec rake gitlab:generate_sample_prometheus_data[21]
 ```

doc/raketasks/import.md

@@ -15,7 +15,7 @@
 
 The new folder needs to have Git user ownership and read/write/execute access for Git user and its group:
 
-```
+```shell
 sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
 ```
 
@@ -27,7 +27,7 @@ sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
 If we copy the repos to `/var/opt/gitlab/git-data/repository-import-<date>`, and repo A needs to be under the groups G1 and G2, it will
 have to be created under those folders: `/var/opt/gitlab/git-data/repository-import-<date>/G1/G2/A.git`.
 
-```
+```shell
 sudo cp -r /old/git/foo.git /var/opt/gitlab/git-data/repository-import-<date>/new_group/
 
 # Do this once when you are done copying git repositories
@@ -57,7 +57,7 @@ sudo -u git -H bundle exec rake gitlab:import:repos['/var/opt/gitlab/git-data/re
 
 #### Example output
 
-```
+```plaintext
 Processing /var/opt/gitlab/git-data/repository-import-1/a/b/c/blah.git
  * Using namespace: a/b/c
  * Created blah (a/b/c/blah)

doc/raketasks/list_repos.md

@@ -3,7 +3,7 @@
 You can print a list of all Git repositories on disk managed by
 GitLab with the following command:
 
-```
+```shell
 # Omnibus
 sudo gitlab-rake gitlab:list_repos
 
@@ -17,7 +17,7 @@ a date with the 'SINCE' environment variable. The time you specify
 is parsed by the Rails [TimeZone#parse
 function](https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-parse).
 
-```
+```shell
 # Omnibus
 sudo gitlab-rake gitlab:list_repos SINCE='Sep 1 2015'
 

doc/raketasks/user_management.md

@@ -91,7 +91,7 @@ production:
 
 Next, generate a new secret:
 
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-rake secret
 
@@ -102,7 +102,7 @@ bundle exec rake secret RAILS_ENV=production
 Now you need to stop the GitLab server, back up the existing secrets file and
 update the database:
 
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-ctl stop
 sudo cp config/secrets.yml config/secrets.yml.bak
@@ -122,7 +122,7 @@ error.
 Finally, change `config/secrets.yml` to set `otp_key_base` to `<new key>` and
 restart. Again, make sure you're operating in the **production** section.
 
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-ctl start
 
@@ -133,7 +133,7 @@ sudo /etc/init.d/gitlab start
 If there are any problems (perhaps using the wrong value for `old_key`), you can
 restore your backup of `config/secrets.yml` and rollback the changes:
 
-```
+```shell
 # omnibus-gitlab
 sudo gitlab-ctl stop
 sudo gitlab-rake gitlab:two_factor:rotate_key:rollback filename=backup.csv

doc/security/crime_vulnerability.md

@@ -33,7 +33,7 @@ Although SPDY is enabled in Omnibus installations, CRIME relies on compression
 The Nessus scanner, [reports a possible CRIME vulnerability][nessus] in GitLab
 similar to the following format:
 
-```
+```plaintext
 Description
 
 This remote service has one of two configurations that are known to be required for the CRIME attack: