Merge branch 'master' into fix-wording-add-clusters

app/assets/javascripts/geo_nodes.js

@@ -3,7 +3,7 @@ import axios from 'axios';
 import SmartInterval from '~/smart_interval';
 import { s__ } from '~/locale';
 import { parseSeconds, stringifyTime } from './lib/utils/pretty_time';
-import { timeIntervalInWords } from './lib/utils/datetime_utility';
+import { formatDate, timeIntervalInWords } from './lib/utils/datetime_utility';
 import timeago from './vue_shared/mixins/timeago';
 
 const healthyClass = 'geo-node-healthy';
@@ -115,7 +115,7 @@ class GeoNodeStatus {
     let eventDate = notAvailable;
 
     if (eventTimestamp && eventTimestamp > 0) {
-      eventDate = gl.utils.formatDate(new Date(eventTimestamp * 1000));
+      eventDate = formatDate(new Date(eventTimestamp * 1000));
     }
 
     if (eventId) {

app/views/help/index.html.haml

 %div
-- if current_application_settings.help_text.present?
-  = markdown(current_application_settings.help_text)
+- if current_application_settings.help_page_text.present?
+  = markdown(current_application_settings.help_page_text)
   %hr
 
 - unless current_application_settings.help_page_hide_commercial_content?

changelogs/unreleased-ee/4090-authorized-keys-check.yml

+---
+title: 'Geo: Added Authorized Keys specific checks'
+merge_request: 3728
+author:
+type: added

doc/README.md

@@ -107,6 +107,7 @@ Manage your [repositories](user/project/repository/index.md) from the UI (user i
   - [Work In Progress Merge Requests](user/project/merge_requests/work_in_progress_merge_requests.md)
   - [Merge Request discussion resolution](user/discussions/index.md#moving-a-single-discussion-to-a-new-issue): Resolve discussions, move discussions in a merge request to an issue, only allow merge requests to be merged if all discussions are resolved.
   - **(EES/EEP)** [Merge Request approval](user/project/merge_requests/merge_request_approvals.md): Make sure every merge request is approved by one or more people before getting merged.
+  - **(EEU)** [Static Application Security Testing](user/project/merge_requests/sast.md): Scan your code for vulnerabilities and display the results in merge requests.
   - [Checkout merge requests locally](user/project/merge_requests/index.md#checkout-merge-requests-locally)
   - [Cherry-pick](user/project/merge_requests/cherry_pick_changes.md)
 - [Milestones](user/project/milestones/index.md): Organize issues and merge requests into a cohesive group, optionally setting a due date.

doc/administration/operations/fast_ssh_key_lookup.md

+# Fast lookup of authorized SSH keys in the database
+
+Regular SSH operations become slow as the number of users grows because OpenSSH
+searches for a key to authorize a user via a linear search. In the worst case,
+such as when the user is not authorized to access GitLab, OpenSSH will scan the
+entire file to search for a key. This can take significant time and disk I/O,
+which will delay users attempting to push or pull to a repository. Making
+matters worse, if users add or remove keys frequently, the operating system may
+not be able to cache the `authorized_keys` file, which causes the disk to be
+accessed repeatedly.
+
+GitLab Shell solves this by providing a way to authorize SSH users via a fast,
+indexed lookup in the GitLab database. This page describes how to enable the fast
+lookup of authorized SSH keys.
+
+> **Warning:** OpenSSH version 6.9+ is required because
+`AuthorizedKeysCommand` must be able to accept a fingerprint. These
+instructions will break installations using older versions of OpenSSH, such as
+those included with CentOS 6 as of September 2017. If you want to use this
+feature for CentOS 6, follow [the instructions on how to build and install a custom OpenSSH package](#compiling-a-custom-version-of-openssh-for-centos-6) before continuing.
+
+
+## Fast lookup is required for GitLab Geo
+
+By default, GitLab manages an `authorized_keys` file, which contains all the
+public SSH keys for users allowed to access GitLab. However, to maintain a
+single source of truth, [Geo](../../gitlab-geo/README.md) needs to be configured to perform SSH fingerprint
+lookups via database lookup.
+
+As part of [setting up GitLab Geo](../../gitlab-geo/README.md#setup-instructions),
+you will be required to follow the steps outlined below for both the primary and
+secondary nodes, but note that the `Write to "authorized keys" file` checkbox
+only needs to be unchecked on the primary node since it will be reflected
+automatically on the secondary if database replication is working.
+
+## Setting up fast lookup via GitLab Shell
+
+GitLab Shell provides a way to authorize SSH users via a fast, indexed lookup
+to the GitLab database. GitLab Shell uses the fingerprint of the SSH key to
+check whether the user is authorized to access GitLab.
+
+Create the directory `/opt/gitlab-shell` first:
+
+```bash
+sudo mkdir -p /opt/gitlab-shell
+```
+
+Create this file at `/opt/gitlab-shell/authorized_keys`:
+
+```
+#!/bin/bash
+
+if [[ "$1" == "git" ]]; then
+  /opt/gitlab/embedded/service/gitlab-shell/bin/authorized_keys $2
+fi
+```
+
+Set appropriate ownership and permissions:
+
+```
+sudo chown root:git /opt/gitlab-shell/authorized_keys
+sudo chmod 0650 /opt/gitlab-shell/authorized_keys
+```
+
+Add the following to `/etc/ssh/sshd_config` or to `/assets/sshd_config` if you
+are using Omnibus Docker:
+
+```
+AuthorizedKeysCommand /opt/gitlab-shell/authorized_keys %u %k
+AuthorizedKeysCommandUser git
+```
+
+Reload OpenSSH:
+
+```bash
+# Debian or Ubuntu installations
+sudo service ssh reload
+
+# CentOS installations
+sudo service sshd reload
+```
+
+Confirm that SSH is working by removing your user's SSH key in the UI, adding a
+new one, and attempting to pull a repo.
+
+> **Warning:** Do not disable writes until SSH is confirmed to be working
+perfectly because the file will quickly become out-of-date.
+
+In the case of lookup failures (which are not uncommon), the `authorized_keys`
+file will still be scanned. So git SSH performance will still be slow for many
+users as long as a large file exists.
+
+You can disable any more writes to the `authorized_keys` file by unchecking
+`Write to "authorized_keys" file` in the Application Settings of your GitLab
+installation.
+
+![Write to authorized keys setting](img/write_to_authorized_keys_setting.png)
+
+Again, confirm that SSH is working by removing your user's SSH key in the UI,
+adding a new one, and attempting to pull a repo.
+
+Then you can backup and delete your `authorized_keys` file for best performance.
+
+## How to go back to using the `authorized_keys` file
+
+This is a brief overview. Please refer to the above instructions for more context.
+
+1. [Rebuild the `authorized_keys` file](../raketasks/maintenance.md#rebuild-authorized_keys-file)
+1. Enable writes to the `authorized_keys` file in Application Settings
+1. Remove the `AuthorizedKeysCommand` lines from `/etc/ssh/sshd_config` or from `/assets/sshd_config` if you are using Omnibus Docker.
+1. Reload sshd: `sudo service sshd reload`
+1. Remove the `/opt/gitlab-shell/authorized_keys` file
+
+## Compiling a custom version of OpenSSH for CentOS 6
+
+Building a custom version of OpenSSH is not necessary for Ubuntu 16.04 users,
+since Ubuntu 16.04 ships with OpenSSH 7.2.
+
+It is also unnecessary for CentOS 7.4 users, as that version ships with
+OpenSSH 7.4. If you are using CentOS 7.0 - 7.3, we strongly recommend that you
+upgrade to CentOS 7.4 instead of following this procedure. This should be as
+simple as running `yum update`.
+
+CentOS 6 users must build their own OpenSSH package to enable SSH lookups via
+the database. The following instructions can be used to build OpenSSH 7.5:
+
+1. First, download the package and install the required packages:
+
+    ```
+    sudo su -
+    cd /tmp
+    curl --remote-name https://mirrors.evowise.com/pub/OpenBSD/OpenSSH/portable/openssh-7.5p1.tar.gz
+    tar xzvf openssh-7.5p1.tar.gz
+    yum install rpm-build gcc make wget openssl-devel krb5-devel pam-devel libX11-devel xmkmf libXt-devel
+    ```
+
+3. Prepare the build by copying files to the right place:
+
+    ```
+    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/
+    cd /root/rpmbuild/SPECS
+    ```
+
+3. Next, set the spec settings properly:
+
+    ```
+    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
+    ```
+
+3. Build the RPMs:
+
+    ```
+    rpmbuild -bb openssh.spec
+    ```
+
+4. Ensure the RPMs were built:
+
+    ```
+    ls -al /root/rpmbuild/RPMS/x86_64/
+    ```
+
+    You should see something as the following:
+
+    ```
+    total 1324
+    drwxr-xr-x. 2 root root   4096 Jun 20 19:37 .
+    drwxr-xr-x. 3 root root     19 Jun 20 19:37 ..
+    -rw-r--r--. 1 root root 470828 Jun 20 19:37 openssh-7.5p1-1.x86_64.rpm
+    -rw-r--r--. 1 root root 490716 Jun 20 19:37 openssh-clients-7.5p1-1.x86_64.rpm
+    -rw-r--r--. 1 root root  17020 Jun 20 19:37 openssh-debuginfo-7.5p1-1.x86_64.rpm
+    -rw-r--r--. 1 root root 367516 Jun 20 19:37 openssh-server-7.5p1-1.x86_64.rpm
+    ```
+
+5. Install the packages. OpenSSH packages will replace `/etc/pam.d/sshd`
+   with its own version, which may prevent users from logging in, so be sure
+   that the file is backed up and restored after installation:
+
+    ```
+    timestamp=$(date +%s)
+    cp /etc/pam.d/sshd pam-ssh-conf-$timestamp
+    rpm -Uvh /root/rpmbuild/RPMS/x86_64/*.rpm
+    yes | cp pam-ssh-conf-$timestamp /etc/pam.d/sshd
+    ```
+
+6. Verify the installed version. In another window, attempt to login to the server:
+
+    ```
+    ssh -v <your-centos-machine>
+    ```
+
+    You should see a line that reads: "debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5"
+
+    If not, you may need to restart sshd (e.g. `systemctl restart sshd.service`).
+
+7.  *IMPORTANT!* Open a new SSH session to your server before exiting to make
+    sure everything is working! If you need to downgrade, simple install the
+    older package:
+
+    ```
+    # Only run this if you run into a problem logging in
+    yum downgrade openssh-server openssh openssh-clients
+    ```

doc/administration/operations/index.md

@@ -15,5 +15,4 @@ that to prioritize important jobs.
 to restart Sidekiq.
 - **(EES/EEP)** [Extra Sidekiq operations](extra_sidekiq_processes.md): Configure an extra set of Sidekiq processes to ensure certain queues always have dedicated workers, no matter the amount of jobs that need to be processed.
 - [Unicorn](unicorn.md): Understand Unicorn and unicorn-worker-killer.
-- **(EES/EEP)** [Speed up SSH operations](speed_up_ssh.md): Authorize SSH users via a fast, indexed lookup to the GitLab database.
-- [Unicorn](unicorn.md): Understand Unicorn and unicorn-worker-killer.
+- **(EES/EEP)** [Speed up SSH operations](fast_ssh_key_lookup.md): Authorize SSH users via a fast, indexed lookup to the GitLab database.

doc/administration/operations/speed_up_ssh.md

-# Speed up SSH operations
-
->
-- [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/250) in GitLab Enterprise Edition 8.7.
-- Available in GitLab Enterprise Edition Starter.
-
-## The problem
-
-SSH operations become slow as the number of users grows.
-
-## The reason
-
-OpenSSH searches for a key to authorize a user via a linear search. In the worst case, such as when the user is not authorized to access GitLab, OpenSSH will scan the entire file to search for a key. This can take significant time and disk I/O, which will delay users attempting to push or pull to a repository. Making matters worse, if users add or remove keys frequently, the operating system may not be able to cache the authorized_keys file, which causes the disk to be accessed repeatedly.
-
-## The solution
-
-GitLab Shell provides a way to authorize SSH users via a fast, indexed lookup to the GitLab database. GitLab Shell uses the fingerprint of the SSH key to check whether the user is authorized to access GitLab.
-
-> **Warning:** OpenSSH version 6.9+ is required because
-`AuthorizedKeysCommand` must be able to accept a fingerprint. These
-instructions will break installations using older versions of OpenSSH, such as
-those included with CentOS 6 as of September 2017. If you want to use this
-feature for CentOS 6, follow [the instructions on how to build and install a custom OpenSSH package]
-(#compiling-a-custom-version-of-openssh-for-centos-6) before continuing.
-
-Create the directory `/opt/gitlab-shell` first:
-
-```bash
-sudo mkdir -p /opt/gitlab-shell
-```
-
-Create this file at `/opt/gitlab-shell/authorized_keys`:
-
-```
-#!/bin/bash
-
-if [[ "$1" == "git" ]]; then
-  /opt/gitlab/embedded/service/gitlab-shell/bin/authorized_keys $2
-fi
-```
-
-Set appropriate ownership and permissions:
-
-```
-sudo chown root:git /opt/gitlab-shell/authorized_keys
-sudo chmod 0650 /opt/gitlab-shell/authorized_keys
-```
-
-Add the following to `/etc/ssh/sshd_config` or to `/assets/sshd_config` if you are using Omnibus Docker:
-
-```
-AuthorizedKeysCommand /opt/gitlab-shell/authorized_keys %u %k
-AuthorizedKeysCommandUser git
-```
-
-Reload OpenSSH:
-
-```bash
-# Debian or Ubuntu installations
-sudo service ssh reload
-
-# CentOS installations
-sudo service sshd reload
-```
-
-Confirm that SSH is working by removing your user's SSH key in the UI, adding a new one, and attempting to pull a repo.
-
-> **Warning:** Do not disable writes until SSH is confirmed to be working perfectly because the file will quickly become out-of-date.
-
-In the case of lookup failures (which are not uncommon), the `authorized_keys` file will still be scanned. So git SSH performance will still be slow for many users as long as a large file exists.
-
-You can disable any more writes to the `authorized_keys` file by unchecking `Write to "authorized_keys" file` in the Application Settings of your GitLab installation.
-
-![Write to authorized keys setting](img/write_to_authorized_keys_setting.png)
-
-Again, confirm that SSH is working by removing your user's SSH key in the UI, adding a new one, and attempting to pull a repo.
-
-Then you can backup and delete your `authorized_keys` file for best performance.
-
-## How to go back to using the `authorized_keys` file
-
-This is a brief overview. Please refer to the above instructions for more context.
-
-1. [Rebuild the `authorized_keys` file](../raketasks/maintenance.md#rebuild-authorized_keys-file)
-1. Enable writes to the `authorized_keys` file in Application Settings
-1. Remove the `AuthorizedKeysCommand` lines from `/etc/ssh/sshd_config` or from `/assets/sshd_config` if you are using Omnibus Docker.
-1. Reload sshd: `sudo service sshd reload`
-1. Remove the `/opt/gitlab-shell/authorized_keys` file
-
-## Compiling a custom version of OpenSSH for CentOS 6
-
-Building a custom version of OpenSSH is not necessary for Ubuntu 16.04 users,
-since Ubuntu 16.04 ships with OpenSSH 7.2.
-
-It is also unnecessary for CentOS 7.4 users, as that version ships with
-OpenSSH 7.4. If you are using CentOS 7.0 - 7.3, we strongly recommend that you
-upgrade to CentOS 7.4 instead of following this procedure. This should be as
-simple as running `yum update`.
-
-CentOS 6 users must build their own OpenSSH package to enable SSH lookups via
-the database. The following instructions can be used to build OpenSSH 7.5:
-
-1. First, download the package and install the required packages:
-
-    ```
-    sudo su -
-    cd /tmp
-    curl --remote-name https://mirrors.evowise.com/pub/OpenBSD/OpenSSH/portable/openssh-7.5p1.tar.gz
-    tar xzvf openssh-7.5p1.tar.gz
-    yum install rpm-build gcc make wget openssl-devel krb5-devel pam-devel libX11-devel xmkmf libXt-devel
-    ```
-
-3. Prepare the build by copying files to the right place:
-
-    ```
-    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/
-    cd /root/rpmbuild/SPECS
-    ```
-
-3. Next, set the spec settings properly:
-
-    ```
-    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
-    ```
-
-3. Build the RPMs:
-
-    ```
-    rpmbuild -bb openssh.spec
-    ```
-
-4. Ensure the RPMs were built:
-
-    ```
-    ls -al /root/rpmbuild/RPMS/x86_64/
-    ```
-
-    You should see something as the following:
-
-    ```
-    total 1324
-    drwxr-xr-x. 2 root root   4096 Jun 20 19:37 .
-    drwxr-xr-x. 3 root root     19 Jun 20 19:37 ..
-    -rw-r--r--. 1 root root 470828 Jun 20 19:37 openssh-7.5p1-1.x86_64.rpm
-    -rw-r--r--. 1 root root 490716 Jun 20 19:37 openssh-clients-7.5p1-1.x86_64.rpm
-    -rw-r--r--. 1 root root  17020 Jun 20 19:37 openssh-debuginfo-7.5p1-1.x86_64.rpm
-    -rw-r--r--. 1 root root 367516 Jun 20 19:37 openssh-server-7.5p1-1.x86_64.rpm
-    ```
-
-5. Install the packages. OpenSSH packages will replace `/etc/pam.d/sshd`
-   with its own version, which may prevent users from logging in, so be sure
-   that the file is backed up and restored after installation:
-
-    ```
-    timestamp=$(date +%s)
-    cp /etc/pam.d/sshd pam-ssh-conf-$timestamp
-    rpm -Uvh /root/rpmbuild/RPMS/x86_64/*.rpm
-    yes | cp pam-ssh-conf-$timestamp /etc/pam.d/sshd
-    ```
-
-6. Verify the installed version. In another window, attempt to login to the server:
-
-    ```
-    ssh -v <your-centos-machine>
-    ```
-
-    You should see a line that reads: "debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5"
-
-    If not, you may need to restart sshd (e.g. `systemctl restart sshd.service`).
-
-7.  *IMPORTANT!* Open a new SSH session to your server before exiting to make
-    sure everything is working! If you need to downgrade, simple install the
-    older package:
-
-    ```
-    # Only run this if you run into a problem logging in
-    yum downgrade openssh-server openssh openssh-clients
-    ```
+This document was moved to [another location](fast_ssh_key_lookup.md).

doc/api/groups.md

@@ -366,16 +366,16 @@ POST /groups
 
 Parameters:
 
-- `name` (required) - The name of the group
-- `path` (required) - The path of the group
-- `description` (optional) - The group's description
-- `membership_lock` (optional, boolean) - Prevent adding new members to project membership within this group
-- `share_with_group_lock` (optional, boolean) - Prevent sharing a project with another group within this group
-- `visibility` (optional) - The group's visibility. Can be `private`, `internal`, or `public`.
-- `lfs_enabled` (optional)      - Enable/disable Large File Storage (LFS) for the projects in this group
-- `request_access_enabled` (optional) - Allow users to request member access.
-- `parent_id` (optional) - The parent group id for creating nested group.
-- `shared_runners_minutes_limit` (optional) - (admin-only) Pipeline minutes quota for this group
+| Attribute | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `name` | string | yes | The name of the group |
+| `path` | string | yes | The path of the group |
+| `description` | string | no | The group's description |
+| `visibility` | string | no | The group's visibility. Can be `private`, `internal`, or `public`. |
+| `lfs_enabled` | boolean | no | Enable/disable Large File Storage (LFS) for the projects in this group |
+| `request_access_enabled` | boolean | no | Allow users to request member access. |
+| `parent_id` | integer | no | The parent group id for creating nested group. |
+| `shared_runners_minutes_limit` | integer | no | (admin-only) Pipeline minutes quota for this group. |
 
 ## Transfer project to group
 
@@ -387,8 +387,10 @@ POST  /groups/:id/projects/:project_id
 
 Parameters:
 
-- `id` (required) - The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user
-- `project_id` (required) - The ID or path of a project
+| Attribute | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `id` | integer/string | yes | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user |
+| `project_id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) |
 
 ## Update group
 

doc/ci/examples/README.md

@@ -58,6 +58,10 @@ Apart from those, here is an collection of tutorials and guides on setting up yo
 
 - [Analyze code quality with the Code Climate CLI](code_climate.md)
 
+### Static Application Security Testing (SAST)
+
+- [Scan your code for vulnerabilities](sast.md)
+
 ### Other
 
 - [Using `dpl` as deployment tool](deployment/README.md)

doc/ci/examples/sast.md

+# Static application security testing with GitLab CI/CD
+
+NOTE: **Note:**
+In order to use this tool, a [GitLab Enterprise Edition Ultimate][ee] license
+is needed.
+
+This example shows how to run
+[Static Application Security Testing (SAST)](https://en.wikipedia.org/wiki/Static_program_analysis)
+on your project's source code by using GitLab CI/CD.
+
+All you need is a GitLab Runner with the Docker executor (the shared Runners on
+GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`,
+called `sast`:
+
+```yaml
+sast:
+  image: registry.gitlab.com/gitlab-org/gl-sast:latest
+  script:
+    - /app/bin/run .
+  artifacts:
+    paths: [gl-sast-report.json]
+```
+
+Behind the scenes, the [gl-sast Docker image](https://gitlab.com/gitlab-org/gl-sast)
+is used to detect the language/framework and in turn runs the matching scan tool.
+
+The above example will create a `sast` job in your CI pipeline and will allow
+you to download and analyze the report artifact in JSON format.
+
+The results are sorted by the priority of the vulnerability:
+
+1. High
+1. Medium
+1. Low
+1. Unknown
+1. Everything else
+
+TIP: **Tip:**
+Starting with GitLab Enterprise Edition Ultimate 10.3, this information will
+be automatically extracted and shown right in the merge request widget. To do
+so, the CI job must be named `sast` and the artifact path must be
+`gl-sast-report.json`.
+[Learn more on application security testing results shown in merge requests](../../user/project/merge_requests/sast.md).
+
+## Supported languages and frameworks
+
+The following languages and frameworks are supported.
+
+| Language / framework | Scan tool |
+| -------------------- | --------- |
+| JavaScript    | [Retire.js](https://retirejs.github.io/retire.js)
+| Python        | [bandit](https://github.com/openstack/bandit) |
+| Ruby          | [bundler-audit](https://github.com/rubysec/bundler-audit) |
+| Ruby on Rails | [brakeman](https://brakemanscanner.org) |
+
+[ee]: https://about.gitlab.com/gitlab-ee/

doc/development/README.md

@@ -81,10 +81,9 @@ comments: false
 
 ## Documentation guides
 
-- [Documentation styleguide](doc_styleguide.md): Use this styleguide if you are
-  contributing to the documentation.
 - [Writing documentation](writing_documentation.md)
-  - [Distinction between general documentation and technical articles](writing_documentation.md#distinction-between-general-documentation-and-technical-articles)
+- [Documentation styleguide](doc_styleguide.md)
+- [Markdown](../user/markdown.md)
 
 ## Internationalization (i18n) guides
 

doc/development/writing_documentation.md

 # Writing documentation
 
   - **General Documentation**: written by the [developers responsible by creating features](#contributing-to-docs). Should be submitted in the same merge request containing code. Feature proposals (by GitLab contributors) should also be accompanied by its respective documentation. They can be later improved by PMs and Technical Writers.
-  - **Technical Articles**: written by any [GitLab Team](https://about.gitlab.com/team/) member, GitLab contributors, or [Community Writers](https://about.gitlab.com/handbook/product/technical-writing/community-writers/).
+  - **[Technical Articles](#technical-articles)**: written by any [GitLab Team](https://about.gitlab.com/team/) member, GitLab contributors, or [Community Writers](https://about.gitlab.com/handbook/product/technical-writing/community-writers/).
   - **Indexes per topic**: initially prepared by the Technical Writing Team, and kept up-to-date by developers and PMs in the same merge request containing code. They gather all resources for that topic in a single page (user and admin documentation, articles, and third-party docs).
 
-## Distinction between General Documentation and Technical Articles
-
-### General documentation
-
-General documentation is categorized by _User_, _Admin_, and _Contributor_, and describe what that feature is, what it does, and its available settings.
-
-### Technical Articles
-
-Technical articles replace technical content that once lived in the [GitLab Blog](https://about.gitlab.com/blog/), where they got out-of-date and weren't easily found.
-
-They are topic-related documentation, written with an user-friendly approach and language, aiming to provide the community with guidance on specific processes to achieve certain objectives.
-
-A technical article guides users and/or admins to achieve certain objectives (within guides and tutorials), or provide an overview of that particular topic or feature (within technical overviews). It can also describe the use, implementation, or integration of third-party tools with GitLab.
-
-They live under `doc/articles/article-title/index.md`, and their images should be placed under `doc/articles/article-title/img/`. Find a list of existing [technical articles](../articles/index.md) here.
-
-#### Types of Technical Articles
-
-- **User guides**: technical content to guide regular users from point A to point B
-- **Admin guides**: technical content to guide administrators of GitLab instances from point A to point B
-- **Technical Overviews**: technical content describing features, solutions, and third-party integrations
-- **Tutorials**: technical content provided step-by-step on how to do things, or how to reach very specific objectives
-
-#### Understanding guides, tutorials, and technical overviews
-
-Suppose there's a process to go from point A to point B in 5 steps: `(A) 1 > 2 > 3 > 4 > 5 (B)`.
-
-A **guide** can be understood as a description of certain processes to achieve a particular objective. A guide brings you from A to B describing the characteristics of that process, but not necessarily going over each step. It can mention, for example, steps 2 and 3, but does not necessarily explain how to accomplish them.
-
-- Live example: "GitLab Pages from A to Z - [Part 1](../user/project/pages/getting_started_part_one.md) to [Part 4](../user/project/pages/getting_started_part_four.md)"
-
-A **tutorial** requires a clear **step-by-step** guidance to achieve a singular objective. It brings you from A to B, describing precisely all the necessary steps involved in that process, showing each of the 5 steps to go from A to B.
-It does not only describes steps 2 and 3, but also shows you how to accomplish them.
-
-- Live example (on the blog): [Hosting on GitLab.com with GitLab Pages](https://about.gitlab.com/2016/04/07/gitlab-pages-setup/)
-
-A **technical overview** is a description of what a certain feature is, and what it does, but does not walk
-through the process of how to use it systematically.
-
-- Live example (on the blog): [GitLab Workflow, an overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/)
-
-#### Special format
-
-Every **Technical Article** contains, in the very beginning, a blockquote with the following information:
-
-- A reference to the **type of article** (user guide, admin guide, tech overview, tutorial)
-- A reference to the **knowledge level** expected from the reader to be able to follow through (beginner, intermediate, advanced)
-- A reference to the **author's name** and **GitLab.com handle**
-- A reference of the **publication date**
-
-```md
-> **Article [Type](../../development/writing_documentation.html#types-of-technical-articles):** tutorial ||
-> **Level:** intermediary ||
-> **Author:** [Name Surname](https://gitlab.com/username) ||
-> **Publication date:** AAAA/MM/DD
-```
-
-#### Technical Articles - Writing Method
-
-Use the [writing method](https://about.gitlab.com/handbook/product/technical-writing/#writing-method) defined by the Technical Writing team.
-
 ## Documentation style guidelines
 
 All the docs follow the same [styleguide](doc_styleguide.md).
 
-### Contributing to docs
+## Contributing to docs
 
 Whenever a feature is changed, updated, introduced, or deprecated, the merge
 request introducing these changes must be accompanied by the documentation
@@ -118,13 +57,31 @@ and for every **major** feature present in Community Edition.
 
 Currently GitLab docs use Redcarpet as [markdown](../user/markdown.md) engine, but there's an [open discussion](https://gitlab.com/gitlab-com/gitlab-docs/issues/50) for implementing Kramdown in the near future.
 
-## Testing
+### Previewing locally
 
-We try to treat documentation as code, thus have implemented some testing.
+To preview your changes to documentation locally, please follow
+this [development guide](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/README.md#development).
+
+### Testing
+
+We treat documentation as code, thus have implemented some testing.
 Currently, the following tests are in place:
 
 1. `docs lint`: Check that all internal (relative) links work correctly and
-   that all cURL examples in API docs use the full switches.
+   that all cURL examples in API docs use the full switches. It's recommended
+   to [check locally](#previewing-locally) before pushing to GitLab by executing the command
+   `bundle exec nanoc check internal_links` on your local
+   [`gitlab-docs`](https://gitlab.com/gitlab-com/gitlab-docs) directory.
+1. [`ee_compat_check`](https://docs.gitlab.com/ee/development/automatic_ce_ee_merge.html#avoiding-ce-gt-ee-merge-conflicts-beforehand) (runs on CE only):
+    When you submit a merge request to GitLab Community Edition (CE),
+    there is this additional job that runs against Enterprise Edition (EE)
+    and checks if your changes can apply cleanly to the EE codebase.
+    If that job fails, read the instructions in the job log for what to do next.
+    As CE is merged into EE once a day, it's important to avoid merge conflicts.
+    Submitting an EE-equivalent merge request cherry-picking all commits from CE to EE is
+    essential to avoid them.
+
+### Branch naming
 
 If your contribution contains **only** documentation changes, you can speed up
 the CI process by following some branch naming conventions. You have three
@@ -139,17 +96,7 @@ choices:
 If your branch name matches any of the above, it will run only the docs
 tests. If it doesn't, the whole test suite will run (including docs).
 
----
-
-When you submit a merge request to GitLab Community Edition (CE), there is an
-additional job called `ee_compat_check` that runs against Enterprise
-Edition (EE) and checks if your changes can apply cleanly to the EE codebase.
-If that job fails, read the instructions in the job log for what to do next.
-Contributors do not need to submit their changes to EE, GitLab Inc. employees
-on the other hand need to make sure that their changes apply cleanly to both
-CE and EE.
-
-## Previewing the changes live
+### Previewing the changes live
 
 If you want to preview the doc changes of your merge request live, you can use
 the manual `review-docs-deploy` job in your merge request. You will need at
@@ -164,7 +111,7 @@ You will need to push a branch to those repositories, it doesn't work for forks.
 
 TIP: **Tip:**
 If your branch contains only documentation changes, you can use
-[special branch names](#testing) to avoid long running pipelines.
+[special branch names](#branch-naming) to avoid long running pipelines.
 
 In the mini pipeline graph, you should see an `>>` icon. Clicking on it will
 reveal the `review-docs-deploy` job. Hit the play button for the job to start.
@@ -209,12 +156,12 @@ working on. If you don't, the remote docs branch won't be removed either,
 and the server where the Review Apps are hosted will eventually be out of
 disk space.
 
-### Behind the scenes
+#### Technical aspects
 
 If you want to know the hot details, here's what's really happening:
 
 1. You manually run the `review-docs-deploy` job in a CE/EE merge request.
-1. The job runs the [`scirpts/trigger-build-docs`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/scripts/trigger-build-docs)
+1. The job runs the [`scripts/trigger-build-docs`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/scripts/trigger-build-docs)
    script with the `deploy` flag, which in turn:
    1. Takes your branch name and applies the following:
       - The slug of the branch name is used to avoid special characters since
@@ -243,3 +190,65 @@ The following GitLab features are used among others:
 - [Review Apps](../ci/review_apps/index.md)
 - [Artifacts](../ci/yaml/README.md#artifacts)
 - [Specific Runner](../ci/runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects)
+
+## General Documentation vs Technical Articles
+
+### General documentation
+
+General documentation is categorized by _User_, _Admin_, and _Contributor_, and describe what that feature is, what it does, and its available settings.
+
+### Technical Articles
+
+Technical articles replace technical content that once lived in the [GitLab Blog](https://about.gitlab.com/blog/), where they got out-of-date and weren't easily found.
+
+They are topic-related documentation, written with an user-friendly approach and language, aiming to provide the community with guidance on specific processes to achieve certain objectives.
+
+A technical article guides users and/or admins to achieve certain objectives (within guides and tutorials), or provide an overview of that particular topic or feature (within technical overviews). It can also describe the use, implementation, or integration of third-party tools with GitLab.
+
+They should be placed in a new directory named `/article-title/index.md` under a topic-related folder, and their images should be placed in `/article-title/img/`. For example, a new article on GitLab Pages should be placed in `doc/user/project/pages/article-title/` and a new article on GitLab CI/CD should be placed in `doc/ci/article-title/`.
+
+#### Types of Technical Articles
+
+- **User guides**: technical content to guide regular users from point A to point B
+- **Admin guides**: technical content to guide administrators of GitLab instances from point A to point B
+- **Technical Overviews**: technical content describing features, solutions, and third-party integrations
+- **Tutorials**: technical content provided step-by-step on how to do things, or how to reach very specific objectives
+
+#### Understanding guides, tutorials, and technical overviews
+
+Suppose there's a process to go from point A to point B in 5 steps: `(A) 1 > 2 > 3 > 4 > 5 (B)`.
+
+A **guide** can be understood as a description of certain processes to achieve a particular objective. A guide brings you from A to B describing the characteristics of that process, but not necessarily going over each step. It can mention, for example, steps 2 and 3, but does not necessarily explain how to accomplish them.
+
+- Live example: "GitLab Pages from A to Z - [Part 1](../user/project/pages/getting_started_part_one.md) to [Part 4](../user/project/pages/getting_started_part_four.md)"
+
+A **tutorial** requires a clear **step-by-step** guidance to achieve a singular objective. It brings you from A to B, describing precisely all the necessary steps involved in that process, showing each of the 5 steps to go from A to B.
+It does not only describes steps 2 and 3, but also shows you how to accomplish them.
+
+- Live example (on the blog): [Hosting on GitLab.com with GitLab Pages](https://about.gitlab.com/2016/04/07/gitlab-pages-setup/)
+
+A **technical overview** is a description of what a certain feature is, and what it does, but does not walk
+through the process of how to use it systematically.
+
+- Live example (on the blog): [GitLab Workflow, an overview](https://about.gitlab.com/2016/10/25/gitlab-workflow-an-overview/)
+
+#### Special format
+
+Every **Technical Article** contains, in the very beginning, a blockquote with the following information:
+
+- A reference to the **type of article** (user guide, admin guide, tech overview, tutorial)
+- A reference to the **knowledge level** expected from the reader to be able to follow through (beginner, intermediate, advanced)
+- A reference to the **author's name** and **GitLab.com handle**
+- A reference of the **publication date**
+
+```md
+> **[Article Type](../../development/writing_documentation.html#types-of-technical-articles):** tutorial ||
+> **Level:** intermediary ||
+> **Author:** [Name Surname](https://gitlab.com/username) ||
+> **Publication date:** AAAA-MM-DD
+```
+
+#### Technical Articles - Writing Method
+
+Use the [writing method](https://about.gitlab.com/handbook/product/technical-writing/#writing-method) defined by the Technical Writing team.
+

doc/gitlab-geo/README.md

@@ -86,7 +86,7 @@ current version of OpenSSH:
 
 Note that CentOS 6 and 7.0 ship with an old version of OpenSSH that do not
 support a feature that Geo requires. See the [documentation on GitLab Geo SSH
-access](ssh.md) for more details.
+access](../administration/operations/fast_ssh_key_lookup.md) for more details.
 
 ### LDAP
 
@@ -145,8 +145,8 @@ If you installed GitLab using the Omnibus packages (highly recommended):
    Geo node to unlock GitLab Geo.
 1. [Setup the database replication](database.md) (`primary (read-write) <->
    secondary (read-only)` topology).
-1. [Lookup authorized SSH keys in the database](../administration/operations/speed_up_ssh.html),
-   do this step for both primary AND secondary nodes.
+1. [Configure fast lookup of authorized SSH keys in the database](../administration/operations/fast_ssh_key_lookup.md),
+   this step is required and needs to be done on both the primary AND secondary nodes.
 1. [Configure GitLab](configuration.md) to set the primary and secondary nodes.
 1. Optional: [Configure a secondary LDAP server](../administration/auth/ldap.md)
    for the secondary. See [notes on LDAP](#ldap).
@@ -165,7 +165,7 @@ If you installed GitLab from source:
    Geo node to unlock GitLab Geo.
 1. [Setup the database replication](database_source.md) (`primary (read-write)
    <-> secondary (read-only)` topology).
-1. [Lookup authorized SSH keys in the database](../administration/operations/speed_up_ssh.html),
+1. [Configure fast lookup of authorized SSH keys in the database](../administration/operations/fast_ssh_key_lookup.md),
    do this step for both primary AND secondary nodes.
 1. [Configure GitLab](configuration_source.md) to set the primary and secondary
    nodes.

doc/gitlab-geo/after_setup.md

+This document was moved to [another location](using_a_geo_server.md).

doc/gitlab-geo/database.md

@@ -6,76 +6,77 @@ from source, follow the
 [**database replication for installations from source**](database_source.md) guide.
 
 >**Note:**
-Stages of the setup process must be completed in the documented order.
+If your GitLab installation uses external PostgreSQL, the Omnibus roles
+will not be able to perform all necessary configuration steps. Refer to the
+section on [External PostreSQL][external postgresql] for additional instructions.
+
+>**Note:**
+The stages of the setup process must be completed in the documented order.
 Before attempting the steps in this stage, [complete all prior stages][toc].
 
 This document describes the minimal steps you have to take in order to
-replicate your GitLab database into another server. You may have to change
-some values according to your database setup, how big it is, etc.
+replicate your primary GitLab database to a secondary node's database. You may
+have to change some values according to your database setup, how big it is, etc.
 
 You are encouraged to first read through all the steps before executing them
 in your testing/production environment.
 
+
+
 ## PostgreSQL replication
 
 The GitLab primary node where the write operations happen will connect to
-primary database server, and the secondary ones which are read-only will
-connect to secondary database servers (which are read-only too).
+the primary database server, and the secondary nodes which are read-only will
+connect to the secondary database servers (which are also read-only).
 
 >**Note:**
-In many databases documentation you will see "primary" being referenced as "master"
+In database documentation you may see "primary" being referenced as "master"
 and "secondary" as either "slave" or "standby" server (read-only).
 
 We recommend using [PostgreSQL replication
 slots](https://medium.com/@tk512/replication-slots-in-postgresql-b4b03d277c75)
-to ensure the primary retains all the data necessary for the secondaries to
+to ensure that the primary retains all the data necessary for the secondaries to
 recover. See below for more details.
 
-### Prerequisites
-
 The following guide assumes that:
 
-- You are using PostgreSQL 9.6 or later which includes the
-  [`pg_basebackup` tool][pgback]. If you are using Omnibus it includes the required
-  PostgreSQL version for Geo.
-- You have a primary server already set up (the GitLab server you are
-  replicating from), running Omnibus' PostgreSQL (or equivalent version), and you
-  have a new secondary server set up on the same OS and PostgreSQL version. Also
-  make sure the GitLab version is the same on all nodes.
+- You are using Omnibus and therefore you are using PostgreSQL 9.6 or later
+ which includes the [`pg_basebackup` tool][pgback].
+- You have a primary node already set up (the GitLab server you are
+  replicating from), running Omnibus' PostgreSQL (or equivalent version), and
+  you have a new secondary server set up with the same versions of the OS,
+  PostgreSQL, and GitLab on all nodes.
 - The IP of the primary server for our examples will be `1.2.3.4`, whereas the
   secondary's IP will be `5.6.7.8`. Note that the primary and secondary servers
-  **must** be able to communicate over these addresses. These IP addresses can
-  either be public or private.
+  **must** be able to communicate over these addresses. More on this in the
+  guide below.
 
-If your GitLab installation is using external PostgreSQL, the Omnibus roles
-will not be able to perform all necessary configuration steps. Refer to
-[External PostreSQL][external postgresql] for additional instructions.
 
 ### Step 1. Configure the primary server
 
 1. SSH into your GitLab **primary** server and login as root:
 
-    ```
+    ```bash
     sudo -i
     ```
 
 1. Execute the command below to define the node as primary Geo node:
 
-    ```
+    ```bash
     gitlab-ctl set-geo-primary-node
     ```
 
     This command will use your defined `external_url` in `/etc/gitlab/gitlab.rb`.
 
-1. Omnibus GitLab already has a replication user called `gitlab_replicator`.
-   You must set its password manually. You will be prompted to enter a
-   password:
+1. Omnibus GitLab already has a [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication)
+ called `gitlab_replicator`. You must set the password for this user manually.
+ You will be prompted to enter a password:
 
     ```bash
     gitlab-ctl set-replication-password
     ```
 
-    This command will also read `postgresql['sql_replication_user']` Omnibus
+    This command will also read the `postgresql['sql_replication_user']` Omnibus
     setting in case you have changed `gitlab_replicator` username to something
     else.
 
@@ -84,11 +85,11 @@ will not be able to perform all necessary configuration steps. Refer to
     For security reasons, PostgreSQL does not listen on any network interfaces
     by default. However, GitLab Geo requires the secondary to be able to
     connect to the primary's database. For this reason, we need the address of
-    each node.
+    each node. Note: For external PostgreSQL instances, see [additional instructions][external postgresql].
 
     If you are using a cloud provider, you can lookup the addresses for each
-    Geo node through their management console. A table of terminology is
-    provided below because terminology varies between vendors.
+    Geo node through your cloud provider's management console. A table of common
+    terminology is provided below as it varies between vendors.
 
     | GitLab Terminology | Amazon Web Services | Google Cloud Platform |
     |-----|-----|-----|-----|
@@ -126,7 +127,7 @@ will not be able to perform all necessary configuration steps. Refer to
     Depending on your network configuration, the suggested addresses may not
     be correct. If your primary and secondary connect over a local
     area network, or a virtual network connecting availability zones like
-    Amazon's [VPC](https://aws.amazon.com/vpc/) of Google's [VPC](https://cloud.google.com/vpc/)
+    [Amazon's VPC](https://aws.amazon.com/vpc/) or [Google's VPC](https://cloud.google.com/vpc/)
     you should use the secondary's private address for `postgresql['md5_auth_cidr_addresses']`.
 
     Edit `/etc/gitlab/gitlab.rb` and add the following, replacing the IP
@@ -163,8 +164,6 @@ will not be able to perform all necessary configuration steps. Refer to
     gitlab_rails['auto_migrate'] = false
     ```
 
-    For external PostgreSQL instances, [see additional instructions][external postgresql].
-
 1. Optional: If you want to add another secondary, the relevant setting would look like:
 
     ```ruby
@@ -208,16 +207,13 @@ will not be able to perform all necessary configuration steps. Refer to
    `netstat -plnt` to make sure that PostgreSQL is listening on port `5432` to
    the primary server's private address.
 
-1. Make a copy of the PostgreSQL `server.crt` file.
-
-    A certificate was automatically generated when GitLab was reconfigured. This
-    will be used automatically to protect your PostgreSQL traffic from
-    eavesdroppers, but to protect against active ("man-in-the-middle") attackers,
-    the secondary needs a copy of the certificate.
-
-    Run this command:
+1. A certificate was automatically generated when GitLab was reconfigured. This
+   will be used automatically to protect your PostgreSQL traffic from
+   eavesdroppers, but to protect against active ("man-in-the-middle") attackers,
+   the secondary needs a copy of the certificate. Make a copy of the PostgreSQL
+    `server.crt` file on the primary node by running this command:
 
-    ```
+    ```bash
     cat ~gitlab-psql/data/server.crt
     ```
 
@@ -233,7 +229,7 @@ will not be able to perform all necessary configuration steps. Refer to
     zone, but when the respective times are converted to UTC time, the clocks
     must be synchronized to within 60 seconds of each other.
 
-    If you are using Ubuntu, verify NTP sync is enabled:
+    Verify NTP sync is enabled using:
 
     ```bash
     timedatectl status | grep 'NTP synchronized'
@@ -244,8 +240,8 @@ will not be able to perform all necessary configuration steps. Refer to
 
 ### Step 2. Add the secondary GitLab node
 
-To prevent the secondary geo node trying to act as the primary once the
-database is replicated, the secondary geo node must be configured on the
+To prevent the secondary geo node from trying to act as the primary once the
+database is replicated, the secondary geo node must be added on the
 primary before the database is replicated.
 
 1. Visit the **primary** node's **Admin Area ➔ Geo Nodes**
@@ -310,29 +306,23 @@ because we have not yet configured the secondary server. This is the next step.
 
     For external PostgreSQL instances, [see additional instructions][external postgresql].
 
-1. [Reconfigure GitLab][] for the changes to take effect.
+1. Reconfigure GitLab for the changes to take effect:
 
-1. Verify that clock synchronization is enabled.
-
-    >**Important:**
-    For Geo to work correctly, all nodes must have their clocks
-    synchronized. It is not required for all nodes to be set to the same time
-    zone, but when the respective times are converted to UTC time, the clocks
-    must be synchronized to within 60 seconds of each other.
+    ```bash
+    gitlab-ctl reconfigure
+    ```
 
-    If you are using Ubuntu, verify NTP sync is enabled:
+1. Verify that clock synchronization is enabled, using:
 
     ```bash
     timedatectl status | grep 'NTP synchronized'
     ```
 
-    Refer to your Linux distribution documentation to setup clock
-    synchronization. This can easily be done using any NTP-compatible daemon.
-
 ### Step 4. Initiate the replication process
 
-Below we provide a script that connects to the primary server, replicates the
-database and creates the needed files for replication.
+Below we provide a script that connects the database on the secondary node to
+the database on the primary node, replicates the database, and creates the
+needed files for streaming replication.
 
 The directories used are the defaults that are set up in Omnibus. If you have
 changed any defaults or are using a source installation, configure it as you
@@ -353,46 +343,36 @@ data before running `pg_basebackup`.
    `secondary.geo.example.com`, you may use `secondary_example` as the slot
    name as shown in the commands below.
 
-1. Execute the command below to start a backup/restore and begin the replication:
+1. Execute the command below to start a backup/restore and begin the replication
+(various options that can be added to these commands are listed below):
 
-    ```
+    ```bash
     gitlab-ctl replicate-geo-database --slot-name=secondary_example --host=1.2.3.4
     ```
 
-    If PostgreSQL is listening on a non-standard port, add `--port=` as well.
-
-    If your database is too large to be transferred in 30 minutes, you will need
-    to increase the timeout, e.g., `--backup-timeout=3600` if you expect the
-    initial replication to take under an hour.
-
-    Pass `--sslmode=disable` to skip PostgreSQL TLS authentication altogether
-    (e.g., you know the network path is secure, or you are using a site-to-site
-    VPN). This is **not** safe over the public Internet!
-
-    You can read more details about each `sslmode` in the
-    [PostgreSQL documentation](https://www.postgresql.org/docs/9.6/static/libpq-ssl.html#LIBPQ-SSL-PROTECTION);
-    the instructions above are carefully written to ensure protection against
-    both passive eavesdroppers and active "man-in-the-middle" attackers.
-
     When prompted, enter the password you set up for the `gitlab_replicator`
     user in the first step.
 
-    New for 9.4: Change the `--slot-name` to the name of the replication slot
-    to be used on the primary database. The script will attempt to create the
-    replication slot automatically if it does not exist.
-
     This command also takes a number of additional options. You can use `--help`
     to list them all, but here are a couple of tips:
-
-    If you're setting up replication on a brand-new secondary that has no data,
-    you may want to pass `--no-wait --skip-backup` to speed up the process - but
-    be **certain** that you're running it against the right GitLab installation
-    first! It **will** cause data loss otherwise.
-
-    If you're repurposing an old server into a Geo secondary, you'll need to
-    add `--force` to the command line.
-
-The replication process is now over.
+       - If PostgreSQL is listening on a non-standard port, add `--port=` as well.
+       - If your database is too large to be transferred in 30 minutes, you will need
+       to increase the timeout, e.g., `--backup-timeout=3600` if you expect the
+       initial replication to take under an hour.
+       - Pass `--sslmode=disable` to skip PostgreSQL TLS authentication altogether
+      (e.g., you know the network path is secure, or you are using a site-to-site
+      VPN). This is **not** safe over the public Internet!
+       - You can read more details about each `sslmode` in the
+       [PostgreSQL documentation](https://www.postgresql.org/docs/9.6/static/libpq-ssl.html#LIBPQ-SSL-PROTECTION);
+       the instructions above are carefully written to ensure protection against
+       both passive eavesdroppers and active "man-in-the-middle" attackers.
+       - Change the `--slot-name` to the name of the replication slot
+       to be used on the primary database. The script will attempt to create the
+       replication slot automatically if it does not exist.
+       - If you're repurposing an old server into a Geo secondary, you'll need to
+       add `--force` to the command line.
+
+The replication process is now complete.
 
 ### External PostgreSQL instances
 
@@ -446,7 +426,7 @@ instructions for [enabling tracking database on the secondary server][tracking].
 
 ## MySQL replication
 
-We don't support MySQL replication for GitLab Geo.
+MySQL replication is not supported for GitLab Geo.
 
 ## Troubleshooting
 

doc/gitlab-geo/database_source.md

@@ -6,12 +6,12 @@ using the Omnibus GitLab packages, follow the
 [**database replication for Omnibus GitLab**](database.md) guide.
 
 >**Note:**
-Stages of the setup process must be completed in the documented order.
+The stages of the setup process must be completed in the documented order.
 Before attempting the steps in this stage, [complete all prior stages][toc].
 
 This document describes the minimal steps you have to take in order to
-replicate your GitLab database into another server. You may have to change
-some values according to your database setup, how big it is, etc.
+replicate your primary GitLab database to a secondary node's database. You may
+have to change some values according to your database setup, how big it is, etc.
 
 You are encouraged to first read through all the steps before executing them
 in your testing/production environment.
@@ -26,19 +26,19 @@ connect to secondary database servers (which are read-only too).
 In many databases documentation you will see "primary" being referenced as "master"
 and "secondary" as either "slave" or "standby" server (read-only).
 
-Since GitLab 9.4: We recommend using [PostgreSQL replication
+We recommend using [PostgreSQL replication
 slots](https://medium.com/@tk512/replication-slots-in-postgresql-b4b03d277c75)
 to ensure the primary retains all the data necessary for the secondaries to
 recover. See below for more details.
 
-### Prerequisites
-
 The following guide assumes that:
 
-- You are using PostgreSQL 9.6 or later which includes the [`pg_basebackup` tool][pgback].
-- You have a primary server already set up (the GitLab server you are
-  replicating from), and you have a new secondary server set up on the same OS
-  and PostgreSQL version. Also make sure the GitLab version is the same on all nodes.
+- You are using PostgreSQL 9.6 or later
+  which includes the [`pg_basebackup` tool][pgback].
+- You have a primary node already set up (the GitLab server you are
+  replicating from), running PostgreSQL 9.6 or later, and
+  you have a new secondary server set up with the same versions of the OS,
+  PostgreSQL, and GitLab on all nodes.
 - The IP of the primary server for our examples will be `1.2.3.4`, whereas the
   secondary's IP will be `5.6.7.8`. Note that the primary and secondary servers
   **must** be able to communicate over these addresses. These IP addresses can either
@@ -48,7 +48,7 @@ The following guide assumes that:
 
 1. SSH into your GitLab **primary** server and login as root:
 
-    ```
+    ```bash
     sudo -i
     ```
 
@@ -58,13 +58,14 @@ The following guide assumes that:
     bundle exec rake geo:set_primary_node
     ```
 
-1. Create a replication user named `gitlab_replicator`:
+1. Create a [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication) named `gitlab_replicator`:
 
     ```bash
     sudo -u postgres psql -c "CREATE USER gitlab_replicator REPLICATION ENCRYPTED PASSWORD 'thepassword';"
     ```
 
 1. Set up TLS support for the PostgreSQL primary server
+
     > **Warning**: Only skip this step if you **know** that PostgreSQL traffic
     > between the primary and secondary will be secured through some other
     > means, e.g., a known-safe physical network path or a site-to-site VPN that
@@ -185,7 +186,7 @@ The following guide assumes that:
     zone, but when the respective times are converted to UTC time, the clocks
     must be synchronized to within 60 seconds of each other.
 
-    If you are using Ubuntu, verify NTP sync is enabled:
+    Verify NTP sync is enabled, using:
 
     ```bash
     timedatectl status | grep 'NTP synchronized'
@@ -196,57 +197,15 @@ The following guide assumes that:
 
 ### Step 2. Add the secondary GitLab node
 
-To prevent the secondary geo node trying to act as the primary once the
-database is replicated, the secondary geo node must be configured on the
-primary before the database is replicated.
-
-1. Visit the **primary** node's **Admin Area ➔ Geo Nodes**
-   (`/admin/geo_nodes`) in your browser.
-1. Add the secondary node by providing its full URL. **Do NOT** check the box
-   'This is a primary node'.
-1. Optionally, choose which namespaces should be replicated by the
-   secondary node. Leave blank to replicate all. Read more in
-   [selective replication](#selective-replication).
-1. Click the **Add node** button.
-
-The new secondary geo node will have the status **Unhealthy**. This is expected
-because we have not yet configured the secondary server. This is the next step.
+Follow the steps in ["add the secondary GitLab node"](database.md#step-2-add-the-secondary-gitlab-node).
 
 ### Step 3. Configure the secondary server
 
-1. SSH into your GitLab **secondary** server and login as root:
-
-    ```
-    sudo -i
-    ```
-
-1. Set up PostgreSQL TLS verification on the secondary
-
-    Copy the generated `server.crt` file onto the secondary server from the
-    primary, then install it in the right place:
-
-    ```bash
-    install -D -o postgres -g postgres -m 0400 -T server.crt ~postgres/.postgresql/root.crt
-    ```
-
-    PostgreSQL will now only recognize that exact certificate when verifying TLS
-    connections. The certificate can only be replicated by someone with access
-    to the private key, which is **only** present on the primary node.
-
-1. Test that the remote connection to the primary server works:
-
-    ```
-    sudo -u postgres psql --list -U gitlab_replicator -d "dbname=gitlabhq_production sslmode=verify-ca" -W -h 1.2.3.4
-    ```
-
-    When prompted enter the password you set in the first step for the
-    `gitlab_replicator` user. If all worked correctly, you should see the
-    database prompt.
-
-    A failure to connect here indicates that the TLS or networking configuration
-    is incorrect. Ensure that you've used the correct certificates and IP
-    addresses throughout. If you have a firewall, ensure that the secondary is
-    permitted to access the primary on port 5432.
+Follow the first steps in ["configure the secondary server"](database.md#step-3-configure-the-secondary-server),
+but note that since you are installing from source, the username and
+group listed as `gitlab-psql` in those steps should be replaced by `postgres`
+instead. After completing the "Test that the remote connection to the
+primary server works" step, continue here:
 
 1. Edit `postgresql.conf` to configure the secondary for streaming replication
    (for Debian/Ubuntu that would be `/etc/postgresql/9.*/main/postgresql.conf`):
@@ -261,45 +220,26 @@ because we have not yet configured the secondary server. This is the next step.
 
 1. Restart PostgreSQL for the changes to take effect.
 
-1. Optional since GitLab 9.1, and required for GitLab 10.0 or higher:
-   [Enable tracking database on the secondary server](#enable-tracking-database-on-the-secondary-server)
+1. Verify that clock synchronization is enabled, using:
 
-1. Otherwise, continue to [initiate the replication process](#step-3-initiate-the-replication-process).
+    ```bash
+    timedatectl status | grep 'NTP synchronized'
+    ```
 
 #### Enable tracking database on the secondary server
 
 Geo secondary nodes use a tracking database to keep track of replication status
-and recover automatically from some replication issues.
-
-It is added in GitLab 9.1, and since GitLab 10.0 it is required.
-
-1. Verify that clock synchronization is enabled.
-
-    >**Important:**
-    For Geo to work correctly, all nodes must have their clocks
-    synchronized. It is not required for all nodes to be set to the same time
-    zone, but when the respective times are converted to UTC time, the clocks
-    must be synchronized to within 60 seconds of each other.
+and recover automatically from some replication issues. Follow the steps below to create
+the tracking database.
 
-    If you are using Ubuntu, verify NTP sync is enabled:
+1. On the secondary node, run the following command to create `database_geo.yml` with the
+information of your secondary PostgreSQL instance:
 
     ```bash
-    timedatectl status | grep 'NTP synchronized'
-    ```
-
-    Refer to your Linux distribution documentation to setup clock
-    synchronization. This can easily be done using any NTP-compatible daemon.
-
-1. Create `database_geo.yml` with the information of your secondary PostgreSQL
-   database.  Note that GitLab will set up another database instance separate
-   from the primary, since this is where the secondary will track its internal
-   state:
-
-    ```
     sudo cp /home/git/gitlab/config/database_geo.yml.postgresql /home/git/gitlab/config/database_geo.yml
     ```
 
-1. Edit the content of `database_geo.yml` in `production:` like the example below:
+1. Edit the content of `database_geo.yml` in `production:` as in the example below:
 
     ```yaml
     #
@@ -315,19 +255,20 @@ It is added in GitLab 9.1, and since GitLab 10.0 it is required.
       host: /var/opt/gitlab/geo-postgresql
     ```
 
-1. Create the database `gitlabhq_geo_production` in that PostgreSQL
-   instance.
+1. Create the database `gitlabhq_geo_production` on the PostgreSQL instance of the secondary
+node.
 
 1. Set up the Geo tracking database:
 
-    ```
+    ```bash
     bundle exec rake geo:db:migrate
     ```
 
 ### Step 4. Initiate the replication process
 
-Below we provide a script that connects to the primary server, replicates the
-database and creates the needed files for replication.
+Below we provide a script that connects the database on the secondary node to
+the database on the primary node, replicates the database, and creates the
+needed files for streaming replication.
 
 The directories used are the defaults for Debian/Ubuntu. If you have changed
 any defaults, configure it as you see fit replacing the directories and paths.
@@ -397,7 +338,7 @@ data before running `pg_basebackup`.
     ```
 
     When prompted, enter the IP/FQDN of the primary, and the password you set up
-    for the `gitlab_replicator` user in the first step. 
+    for the `gitlab_replicator` user in the first step.
 
     You should use `verify-ca` for the `sslmode`. You can use `disable` if you
     are happy to skip PostgreSQL TLS authentication altogether (e.g., you know
@@ -413,7 +354,7 @@ The replication process is now over.
 
 ## MySQL replication
 
-We don't support MySQL replication for GitLab Geo.
+MySQL replication is not supported for GitLab Geo.
 
 ## Troubleshooting
 

doc/gitlab-geo/ssh.md

-# GitLab Geo SSH access
-
-By default, GitLab manages an `authorized_keys` file, which contains all the
-public SSH keys for users allowed to access GitLab. However, to maintain a
-single source of truth, Geo needs to be configured to perform SSH fingerprint
-lookups via database lookup. This approach is also much faster than scanning a
-file.
-
->**Note:**
-GitLab 10.0 and higher require database lookups for SSH keys.
-
-Note this feature is only available on operating systems that support OpenSSH
-6.9 and above. For CentOS 6, see the [instructions on building custom
-version of OpenSSH for your server]
-(../administration/operations/speed_up_ssh.html#compiling-a-custom-version-of-openssh-for-centos-6).
-
-For both primary AND secondary nodes, follow the instructions on
-[looking up authorized SSH keys in the database](../administration/operations/speed_up_ssh.html).
-
-Note that the 'Write to "authorized keys" file' checkbox only needs
-to be unchecked on the primary node since it will be reflected automatically
-in the secondary if database replication is working.
+This document was moved to [another location](../administration/operations/fast_ssh_key_lookup.md).

doc/gitlab-geo/updating_the_geo_nodes.md

@@ -93,7 +93,7 @@ for existing repositories was added in GitLab 10.1.
 ## Upgrading to GitLab 10.0
 
 Since GitLab 10.0, we require all **Geo** systems to [use SSH key lookups via
-the database](ssh.md) to avoid having to maintain consistency of the
+the database](../administration/operations/fast_ssh_key_lookup.md) to avoid having to maintain consistency of the
 `authorized_keys` file for SSH access. Failing to do this will prevent users
 from being able to clone via SSH.
 

doc/topics/autodevops/index.md

@@ -19,6 +19,7 @@ project in an easy and automatic way:
 1. [Auto Build](#auto-build)
 1. [Auto Test](#auto-test)
 1. [Auto Code Quality](#auto-code-quality)
+1. [Auto SAST (Static Application Security Testing)](#auto-sast)
 1. [Auto Review Apps](#auto-review-apps)
 1. [Auto Deploy](#auto-deploy)
 1. [Auto Monitoring](#auto-monitoring)
@@ -198,6 +199,18 @@ out. In GitLab Enterprise Edition Starter, differences between the source and
 target branches are
 [shown in the merge request widget](../../user/project/merge_requests/code_quality_diff.md).
 
+### Auto SAST
+
+> Introduced in [GitLab Enterprise Edition Ultimate][ee] 10.3.
+
+Static Application Security Testing (SAST) uses the
+[gl-sast Docker image](https://gitlab.com/gitlab-org/gl-sast) to run static
+analysis on the current code and checks for potential security issues. Once the
+report is created, it's uploaded as an artifact which you can later download and
+check out.
+
+Any security warnings are also [shown in the merge request widget](../../user/project/merge_requests/sast.md).
+
 ### Auto Review Apps
 
 NOTE: **Note:**
@@ -536,3 +549,4 @@ curl --data "value=true" --header "PRIVATE-TOKEN: personal_access_token" https:/
 [postgresql]: https://www.postgresql.org/
 [Auto DevOps template]: https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Auto-DevOps.gitlab-ci.yml
 [GitLab Omnibus Helm Chart]: ../../install/kubernetes/gitlab_omnibus.md
+[ee]: https://about.gitlab.com/gitlab-ee/

doc/user/index.md

@@ -55,6 +55,7 @@ and [Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.
 - [Lock files](https://docs.gitlab.com/ee/user/project/file_lock.html) to prevent conflicts
 - View of the current health and status of each CI environment running on Kubernetes with [Deploy Boards](https://docs.gitlab.com/ee/user/project/deploy_boards.html)
 - Leverage your continuous delivery method with [Canary Deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html)
+- Scan your code for vulnerabilities and [display them in merge requests](project/merge_requests/sast.md).
 
 You can also [integrate](project/integrations/project_services.md) GitLab with numerous third-party applications, such as Mattermost, Microsoft Teams, HipChat, Trello, Slack, Bamboo CI, JIRA, and a lot more.
 

doc/user/project/merge_requests/index.md

@@ -193,6 +193,17 @@ can show the Code Climate report right in the merge request widget area.
 
 [Read more about Code Quality reports.](code_quality_diff.md)
 
+## Static Application Security Testing
+
+> Introduced in [GitLab Enterprise Edition Ultimate][products] 10.3.
+
+If you are using [GitLab CI/CD][ci], you can analyze your source code for known
+vulnerabilities using Static Application Security Testing (SAST).
+Going a step further, GitLab can show the vulnerability report right in the
+merge request widget area.
+
+[Read more about Static Application Security Testing reports.](sast.md)
+
 ## Live preview with Review Apps
 
 If you configured [Review Apps](https://about.gitlab.com/features/review-apps/) for your project,

doc/user/project/merge_requests/sast.md

+# Static Application Security Testing (SAST)
+
+> [Introduced][ee-3775] in [GitLab Enterprise Edition Ultimate][ee] 10.3.
+
+## Overview
+
+If you are using [GitLab CI/CD][ci], you can analyze your source code for known
+vulnerabilities using Static Application Security Testing (SAST).
+
+Going a step further, GitLab can show the vulnerability list right in the merge
+request widget area:
+
+![SAST Widget](img/sast.png)
+
+## Use cases
+
+- Your application is using an external (open source) library, locked to a
+  specific version (e.g., via `Gemfile.lock`) and the version is known to be
+  vulnerable.
+- Your code has a potentially dangerous attribute in a class, or unsafe code
+  that can lead to unintended code execution.
+
+## How it works
+
+In order for the report to show in the merge request, you need to specify a
+`sast` job (exact name) that will analyze the code and upload the resulting
+`gl-sast-report.json` file as an artifact. GitLab will then check this file and
+show the information inside the merge request.
+
+This JSON file needs to be the only artifact file for the job. If you try
+to also include other files, it will break the vulnerability display in the
+merge request.
+
+For more information on how the `sast` job should look like, check the
+example on [analyzing a project's code for vulnerabilities][cc-docs].
+
+[ee-3775]: https://gitlab.com/gitlab-org/gitlab-ee/issues/3775
+[ee]: https://about.gitlab.com/gitlab-ee/
+[ci]: ../../../ci/README.md
+[cc-docs]: ../../../ci/examples/sast.md

ee/app/views/projects/ee/_service_desk_settings.html.haml

@@ -8,7 +8,7 @@
         = expanded ? 'Collapse' : 'Expand'
       %p
         Customize your service desk settings.
-        = link_to "Learn more about service desk.", help_page_path('user/project/service_desk')
+        = link_to "Learn more about service desk.", help_page_path('user/project/service_desk'), target: '_blank'
     .settings-content
       - if EE::Gitlab::ServiceDesk.enabled?(project: @project)
         .js-service-desk-setting-root{ data: { endpoint: project_service_desk_path(@project),

ee/lib/system_check/geo/authorized_keys_check.rb

+module SystemCheck
+  module Geo
+    class AuthorizedKeysCheck < ::SystemCheck::BaseCheck
+      set_name 'OpenSSH configured to use AuthorizedKeysCommand'
+
+      AUTHORIZED_KEYS_DOCS = 'doc/administration/operations/speed_up_ssh.md'.freeze
+      OPENSSH_AUTHORIZED_KEYS_CMD_REGEXP = %r{
+        ^AuthorizedKeysCommand # line starts with
+        \s+                    # one space or more
+        (?<quote>['"]?)        # detect optional quotes
+        (?<content>[^#'"]+)    # content should be at least 1 char, non quotes or start-comment symbol
+        \k<quote>              # boundary for command, backtracks the same detected quote, or none
+        \s*                    # optional any amount of space character
+        (?:\#.*)?$             # optional start-comment symbol followed by optionally any character until end of line
+      }x
+      OPENSSH_AUTHORIZED_KEYS_USER_REGEXP = %r{
+        ^AuthorizedKeysCommandUser # line starts with
+        \s+                        # one space or more
+        (?<quote>['"]?)            # detect optional quotes
+        (?<content>[^#'"]+)        # content should be at least 1 char, non quotes or start-comment symbol
+        \k<quote>                  # boundary for command, backtracks the same detected quote, or none
+        \s*                        # optional any amount of space character
+        (?:\#.*)?$                 # optional start-comment symbol followed by optionally any character until end of line
+      }x
+      OPENSSH_EXPECTED_COMMAND = '/opt/gitlab-shell/authorized_keys %u %k'.freeze
+
+      def multi_check
+        unless openssh_config_exists?
+          print_failure("Cannot find OpenSSH configuration file at: #{openssh_config_path}")
+
+          if in_docker?
+            try_fixing_it(
+              'If you are not using our official docker containers,',
+              'make sure you have OpenSSH server installed and configured correctly on this system'
+            )
+
+            for_more_information(AUTHORIZED_KEYS_DOCS)
+          else
+            try_fixing_it(
+              'Make sure you have OpenSSH server installed on this system'
+            )
+          end
+
+          return
+        end
+
+        unless openssh_config_readable?
+          print_skipped('Cannot access OpenSSH configuration file')
+
+          try_fixing_it(
+            'This is expected if you are using SELinux. You may want to check configuration manually'
+          )
+
+          for_more_information(AUTHORIZED_KEYS_DOCS)
+          return
+        end
+
+        authorized_keys_command = extract_authorized_keys_command
+        unless authorized_keys_command
+          print_failure('OpenSSH configuration file does not contain a AuthorizedKeysCommand')
+
+          try_fixing_it(
+            'Change your OpenSSH configuration file pointing to the correct command'
+          )
+
+          for_more_information(AUTHORIZED_KEYS_DOCS)
+          return
+        end
+
+        unless openssh_is_expected_command?(authorized_keys_command)
+          print_warning('OpenSSH configuration file points to a different AuthorizedKeysCommand')
+
+          try_fixing_it(
+            "We were expecting AuthorizedKeysCommand to be: #{OPENSSH_EXPECTED_COMMAND}",
+            "but instead it is: #{authorized_keys_command}",
+            'If you made a custom command, make sure it behaves according to GitLab\'s Documentation'
+          )
+
+          for_more_information(AUTHORIZED_KEYS_DOCS)
+          # this check should not block the others
+        end
+
+        authorized_keys_command_path = openssh_extract_command_path(authorized_keys_command)
+        unless File.file?(authorized_keys_command_path)
+          print_failure("Cannot find configured AuthorizedKeysCommand: #{authorized_keys_command_path}")
+
+          try_fixing_it(
+            'You need to create the file and add the correct content to it'
+          )
+
+          for_more_information(AUTHORIZED_KEYS_DOCS)
+          return
+        end
+
+        authorized_keys_command_user = extract_authorized_keys_command_user
+        unless authorized_keys_command_user
+          print_failure('OpenSSH configuration file does not contain a AuthorizedKeysCommandUser')
+
+          try_fixing_it(
+            'Change your OpenSSH configuration file pointing to the correct user'
+          )
+
+          for_more_information(AUTHORIZED_KEYS_DOCS)
+          return
+        end
+
+        unless authorized_keys_command_user == gitlab_user
+          print_warning('OpenSSH configuration file points to a different AuthorizedKeysCommandUser')
+
+          try_fixing_it(
+            "We were expecting AuthorizedKeysCommandUser to be: #{gitlab_user}",
+            "but instead it is: #{authorized_keys_command_user}",
+            'Fix your OpenSSH configuration file pointing to the correct user'
+          )
+
+          for_more_information(AUTHORIZED_KEYS_DOCS)
+          return
+        end
+
+        $stdout.puts 'yes'.color(:green)
+        true
+      end
+
+      def extract_authorized_keys_command
+        extract_openssh_config(OPENSSH_AUTHORIZED_KEYS_CMD_REGEXP)
+      end
+
+      def extract_authorized_keys_command_user
+        extract_openssh_config(OPENSSH_AUTHORIZED_KEYS_USER_REGEXP)
+      end
+
+      def openssh_config_path
+        @openssh_config_path ||= begin
+          if in_docker?
+            '/assets/sshd_config' # path in our official docker containers
+          else
+            '/etc/ssh/sshd_config'
+          end
+        end
+      end
+
+      private
+
+      def print_skipped(reason)
+        $stdout.puts 'skipped'.color(:magenta)
+
+        $stdout.puts '  Reason:'.color(:blue)
+        $stdout.puts "  #{reason}"
+      end
+
+      def print_warning(reason)
+        $stdout.puts 'warning'.color(:magenta)
+
+        $stdout.puts '  Reason:'.color(:blue)
+        $stdout.puts "  #{reason}"
+      end
+
+      def print_failure(reason)
+        $stdout.puts 'no'.color(:red)
+
+        $stdout.puts '  Reason:'.color(:blue)
+        $stdout.puts "  #{reason}"
+      end
+
+      def openssh_config_exists?
+        File.file?(openssh_config_path)
+      end
+
+      def openssh_config_readable?
+        File.readable?(openssh_config_path)
+      end
+
+      def openssh_extract_command_path(cmd_with_params)
+        cmd_with_params.split(' ').first
+      end
+
+      def openssh_is_expected_command?(authorized_keys_command)
+        authorized_keys_command.squeeze(' ') == OPENSSH_EXPECTED_COMMAND
+      end
+
+      def in_docker?
+        File.file?('/.dockerenv')
+      end
+
+      def gitlab_user
+        Gitlab.config.gitlab.user
+      end
+
+      def extract_openssh_config(regexp)
+        return false unless openssh_config_exists? && openssh_config_readable?
+
+        File.open(openssh_config_path) do |f|
+          f.each_line do |line|
+            if (match = line.match(regexp))
+              raw_content = match[:content]
+              # remove linebreak, and lead and trailing spaces
+              return raw_content.chomp.strip
+            end
+          end
+        end
+
+        nil
+      end
+    end
+  end
+end

ee/lib/system_check/geo/authorized_keys_flag_check.rb

+module SystemCheck
+  module Geo
+    class AuthorizedKeysFlagCheck < ::SystemCheck::BaseCheck
+      set_name 'GitLab configured to disable writing to authorized_keys file'
+
+      def check?
+        !Gitlab::CurrentSettings.current_application_settings.authorized_keys_enabled
+      end
+
+      def show_error
+        try_fixing_it(
+          "You need to disable `Write to authorized_keys file` in GitLab's Admin panel"
+        )
+
+        for_more_information(AUTHORIZED_KEYS_DOCS)
+      end
+    end
+  end
+end

lib/tasks/gitlab/check.rake

@@ -464,7 +464,9 @@ namespace :gitlab do
         SystemCheck::Geo::HttpConnectionCheck,
         SystemCheck::Geo::HTTPCloneEnabledCheck,
         SystemCheck::Geo::ClocksSynchronizationCheck,
-        SystemCheck::App::GitUserDefaultSSHConfigCheck
+        SystemCheck::App::GitUserDefaultSSHConfigCheck,
+        SystemCheck::Geo::AuthorizedKeysCheck,
+        SystemCheck::Geo::AuthorizedKeysFlagCheck
       ]
 
       SystemCheck.run('Geo', checks)

spec/ee/fixtures/system_check/sshd_config

+# Package generated configuration file
+# See the sshd_config(5) manpage for details
+
+# What ports, IPs and protocols we listen for
+Port 22
+# Use these options to restrict which interfaces/protocols sshd will bind to
+#ListenAddress ::
+#ListenAddress 0.0.0.0
+Protocol 2
+# HostKeys for protocol version 2
+HostKey /etc/ssh/ssh_host_rsa_key
+HostKey /etc/ssh/ssh_host_dsa_key
+HostKey /etc/ssh/ssh_host_ecdsa_key
+HostKey /etc/ssh/ssh_host_ed25519_key
+#Privilege Separation is turned on for security
+UsePrivilegeSeparation yes
+
+# Lifetime and size of ephemeral version 1 server key
+KeyRegenerationInterval 3600
+ServerKeyBits 1024
+
+# Logging
+SyslogFacility AUTH
+LogLevel INFO
+
+# Authentication:
+LoginGraceTime 120
+PermitRootLogin yes
+StrictModes yes
+
+RSAAuthentication yes
+PubkeyAuthentication yes
+#AuthorizedKeysFile	%h/.ssh/authorized_keys
+#AuthorizedKeysCommand /opt/gitlab-shell/invalid_authorized_keys %u %k
+AuthorizedKeysCommand /opt/gitlab-shell/authorized_keys %u %k
+AuthorizedKeysCommandUser git
+
+# Don't read the user's ~/.rhosts and ~/.shosts files
+IgnoreRhosts yes
+# For this to work you will also need host keys in /etc/ssh_known_hosts
+RhostsRSAAuthentication no
+# similar for protocol version 2
+HostbasedAuthentication no
+# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
+#IgnoreUserKnownHosts yes
+
+# To enable empty passwords, change to yes (NOT RECOMMENDED)
+PermitEmptyPasswords no
+
+# Change to yes to enable challenge-response passwords (beware issues with
+# some PAM modules and threads)
+ChallengeResponseAuthentication no
+
+# Change to no to disable tunnelled clear text passwords
+PasswordAuthentication yes
+
+# Kerberos options
+#KerberosAuthentication no
+#KerberosGetAFSToken no
+#KerberosOrLocalPasswd yes
+#KerberosTicketCleanup yes
+
+# GSSAPI options
+#GSSAPIAuthentication no
+#GSSAPICleanupCredentials yes
+
+X11Forwarding yes
+X11DisplayOffset 10
+PrintMotd no
+PrintLastLog yes
+TCPKeepAlive yes
+#UseLogin no
+
+#MaxStartups 10:30:60
+#Banner /etc/issue.net
+
+# Allow client to pass locale environment variables
+AcceptEnv LANG LC_*
+
+Subsystem sftp /usr/lib/openssh/sftp-server
+
+# Set this to 'yes' to enable PAM authentication, account processing,
+# and session processing. If this is enabled, PAM authentication will
+# be allowed through the ChallengeResponseAuthentication and
+# PasswordAuthentication.  Depending on your PAM configuration,
+# PAM authentication via ChallengeResponseAuthentication may bypass
+# the setting of "PermitRootLogin yes
+# If you just want the PAM account and session checks to run without
+# PAM authentication, then enable this but set PasswordAuthentication
+# and ChallengeResponseAuthentication to 'no'.
+UsePAM yes

spec/ee/fixtures/system_check/sshd_config_invalid_command

+# Package generated configuration file
+# See the sshd_config(5) manpage for details
+
+RSAAuthentication yes
+PubkeyAuthentication yes
+#AuthorizedKeysFile	%h/.ssh/authorized_keys
+AuthorizedKeysCommand "/opt/gitlab-shell/invalid_authorized_keys   %u      %k"         # comment
+#AuthorizedKeysCommand /opt/gitlab-shell/authorized_keys %u %k
+AuthorizedKeysCommandUser anotheruser  #comment with more stuff#

spec/ee/fixtures/system_check/sshd_config_invalid_user

+# Package generated configuration file
+# See the sshd_config(5) manpage for details
+
+RSAAuthentication yes
+PubkeyAuthentication yes
+#AuthorizedKeysFile	%h/.ssh/authorized_keys
+AuthorizedKeysCommand /opt/gitlab-shell/authorized_keys %u %k          # comment
+AuthorizedKeysCommandUser anotheruser  #comment with more stuff#

spec/ee/fixtures/system_check/sshd_config_no_command

+# Package generated configuration file
+# See the sshd_config(5) manpage for details
+
+RSAAuthentication yes
+PubkeyAuthentication yes
+# AuthorizedKeysFile	%h/.ssh/authorized_keys
+# AuthorizedKeysCommand /opt/gitlab-shell/invalid_authorized_keys %u %k
+# AuthorizedKeysCommand /opt/gitlab-shell/authorized_keys %u %k
+# AuthorizedKeysCommandUser git

spec/ee/fixtures/system_check/sshd_config_no_user

+# Package generated configuration file
+# See the sshd_config(5) manpage for details
+
+RSAAuthentication yes
+PubkeyAuthentication yes
+#AuthorizedKeysFile	%h/.ssh/authorized_keys
+#AuthorizedKeysCommand /opt/gitlab-shell/invalid_authorized_keys %u %k
+AuthorizedKeysCommand /opt/gitlab-shell/authorized_keys %u %k
+#AuthorizedKeysCommandUser git

spec/ee/spec/lib/system_check/geo/authorized_keys_check_spec.rb

+require 'spec_helper'
+require 'rake_helper'
+
+describe SystemCheck::Geo::AuthorizedKeysCheck do
+  describe '#multi_check' do
+    subject { described_class.new }
+
+    before do
+      allow(File).to receive(:file?).and_call_original # provides a default behavior when mocking
+      allow(File).to receive(:file?).with('/opt/gitlab-shell/authorized_keys') { true }
+    end
+
+    context 'OpenSSH config file' do
+      context 'in docker' do
+        it 'fails when config file does not exist' do
+          allow(subject).to receive(:in_docker?) { true }
+          allow(File).to receive(:file?).with('/assets/sshd_config') { false }
+
+          expect_failure('Cannot find OpenSSH configuration file at: /assets/sshd_config')
+
+          subject.multi_check
+        end
+      end
+
+      it 'fails when config file does not exist' do
+        allow(subject).to receive(:in_docker?) { false }
+        allow(File).to receive(:file?).with('/etc/ssh/sshd_config') { false }
+
+        expect_failure('Cannot find OpenSSH configuration file at: /etc/ssh/sshd_config')
+
+        subject.multi_check
+      end
+
+      it 'skips when config file is not readable' do
+        override_sshd_config('system_check/sshd_config')
+        allow(File).to receive(:readable?).with(expand_fixture_ee_path('system_check/sshd_config')) { false }
+
+        expect_skipped('Cannot access OpenSSH configuration file')
+
+        subject.multi_check
+      end
+    end
+
+    context 'AuthorizedKeysCommand' do
+      it 'fails when config file does not contain the AuthorizedKeysCommand' do
+        override_sshd_config('system_check/sshd_config_no_command')
+
+        expect_failure('OpenSSH configuration file does not contain a AuthorizedKeysCommand')
+
+        subject.multi_check
+      end
+
+      it 'warns when config file does not contain the correct AuthorizedKeysCommand' do
+        override_sshd_config('system_check/sshd_config_invalid_command')
+
+        expect_warning('OpenSSH configuration file points to a different AuthorizedKeysCommand')
+
+        subject.multi_check
+      end
+
+      it 'fails when cannot find referred authorized keys file on disk' do
+        override_sshd_config('system_check/sshd_config')
+        allow(subject).to receive(:extract_authorized_keys_command) { '/tmp/nonexistent/authorized_keys' }
+
+        expect_failure('Cannot find configured AuthorizedKeysCommand: /tmp/nonexistent/authorized_keys')
+
+        subject.multi_check
+      end
+    end
+
+    context 'AuthorizedKeysCommandUser' do
+      it 'fails when config file does not contain the AuthorizedKeysCommandUser' do
+        override_sshd_config('system_check/sshd_config_no_user')
+
+        expect_failure('OpenSSH configuration file does not contain a AuthorizedKeysCommandUser')
+
+        subject.multi_check
+      end
+
+      it 'fails when config file does not contain the correct AuthorizedKeysCommandUser' do
+        override_sshd_config('system_check/sshd_config_invalid_user')
+
+        expect_warning('OpenSSH configuration file points to a different AuthorizedKeysCommandUser')
+
+        subject.multi_check
+      end
+    end
+
+    it 'succeed when all conditions are met' do
+      override_sshd_config('system_check/sshd_config')
+      allow(subject).to receive(:gitlab_user) { 'git' }
+
+      result = subject.multi_check
+      expect($stdout.string).to include('yes')
+      expect(result).to be_truthy
+    end
+  end
+
+  describe '#extract_authorized_keys_command' do
+    it 'returns false when no command is available' do
+      override_sshd_config('system_check/sshd_config_no_command')
+
+      expect(subject.extract_authorized_keys_command).to be_falsey
+    end
+
+    it 'returns correct (uncommented) command' do
+      override_sshd_config('system_check/sshd_config')
+
+      expect(subject.extract_authorized_keys_command).to eq('/opt/gitlab-shell/authorized_keys %u %k')
+    end
+
+    it 'returns command without comments and without quotes' do
+      override_sshd_config('system_check/sshd_config_invalid_command')
+
+      expect(subject.extract_authorized_keys_command).to eq('/opt/gitlab-shell/invalid_authorized_keys   %u      %k')
+    end
+  end
+
+  describe '#extract_authorized_keys_command_user' do
+    it 'returns false when no command user is available' do
+      override_sshd_config('system_check/sshd_config_no_command')
+
+      expect(subject.extract_authorized_keys_command_user).to be_falsey
+    end
+
+    it 'returns correct (uncommented) command' do
+      override_sshd_config('system_check/sshd_config')
+
+      expect(subject.extract_authorized_keys_command_user).to eq('git')
+    end
+
+    it 'returns command without comments' do
+      override_sshd_config('system_check/sshd_config_invalid_command')
+
+      expect(subject.extract_authorized_keys_command_user).to eq('anotheruser')
+    end
+  end
+
+  describe '#openssh_config_path' do
+    context 'when in docker container' do
+      it 'returns /assets/sshd_config' do
+        allow(subject).to receive(:in_docker?) { true }
+
+        expect(subject.openssh_config_path).to eq('/assets/sshd_config')
+      end
+    end
+
+    context 'when not in docker container' do
+      it 'returns /etc/ssh/sshd_config' do
+        allow(subject).to receive(:in_docker?) { false }
+
+        expect(subject.openssh_config_path).to eq('/etc/ssh/sshd_config')
+      end
+    end
+  end
+
+  def expect_failure(reason)
+    expect(subject).to receive(:print_failure).with(reason)
+  end
+
+  def expect_warning(reason)
+    expect(subject).to receive(:print_warning).with(reason)
+  end
+
+  def expect_skipped(reason)
+    expect(subject).to receive(:print_skipped).with(reason)
+  end
+
+  def override_sshd_config(relative_path)
+    allow(subject).to receive(:openssh_config_path) { expand_fixture_ee_path(relative_path) }
+  end
+end

spec/ee/spec/lib/system_check/geo/authorized_keys_flag_check_spec.rb

+require 'spec_helper'
+require 'rake_helper'
+
+describe SystemCheck::Geo::AuthorizedKeysFlagCheck do
+  before do
+    silence_output
+  end
+
+  describe '#check?' do
+    it 'fails when write to authorized_keys still enabled' do
+      stub_application_setting(authorized_keys_enabled: true)
+
+      expect(subject.check?).to be_falsey
+    end
+
+    it 'succeed when write to authorized_keys is disabled' do
+      stub_application_setting(authorized_keys_enabled: false)
+
+      expect(subject.check?).to be_truthy
+    end
+  end
+end

spec/features/help_pages_spec.rb

@@ -37,7 +37,7 @@ describe 'Help Pages' do
   context 'in a production environment with version check enabled', :js do
     before do
       allow(Rails.env).to receive(:production?) { true }
-      allow_any_instance_of(ApplicationSetting).to receive(:version_check_enabled) { true }
+      stub_application_setting(version_check_enabled: true)
       allow_any_instance_of(VersionCheck).to receive(:url) { '/version-check-url' }
 
       sign_in(create(:user))
@@ -56,9 +56,9 @@ describe 'Help Pages' do
 
   describe 'when help page is customized' do
     before do
-      allow_any_instance_of(ApplicationSetting).to receive(:help_page_hide_commercial_content?) { true }
-      allow_any_instance_of(ApplicationSetting).to receive(:help_text) { "My Custom Text" }
-      allow_any_instance_of(ApplicationSetting).to receive(:help_page_support_url) { "http://example.com/help" }
+      stub_application_setting(help_page_hide_commercial_content: true,
+                               help_page_text: 'My Custom Text',
+                               help_page_support_url: 'http://example.com/help')
 
       sign_in(create(:user))
       visit help_path

spec/javascripts/vue_mr_widget/ee_mr_widget_options_spec.js

@@ -382,6 +382,7 @@ describe('ee merge request widget options', () => {
     describe('when it is loading', () => {
       it('should render loading indicator', () => {
         vm = mountComponent(Component);
+
         expect(
           vm.$el.querySelector('.js-docker-widget').textContent.trim(),
         ).toContain('Loading clair report');
@@ -389,21 +390,16 @@ describe('ee merge request widget options', () => {
     });
 
     describe('with successful request', () => {
-      const interceptor = (request, next) => {
-        if (request.url === 'clair.json') {
-          next(request.respondWith(JSON.stringify(dockerReport), {
-            status: 200,
-          }));
-        }
-      };
+      let mock;
 
       beforeEach(() => {
-        Vue.http.interceptors.push(interceptor);
+        mock = mock = new MockAdapter(axios);
+        mock.onGet('clair.json').reply(200, dockerReport);
         vm = mountComponent(Component);
       });
 
       afterEach(() => {
-        Vue.http.interceptors = _.without(Vue.http.interceptors, interceptor);
+        mock.reset();
       });
 
       it('should render provided data', (done) => {
@@ -433,21 +429,16 @@ describe('ee merge request widget options', () => {
     });
 
     describe('with failed request', () => {
-      const interceptor = (request, next) => {
-        if (request.url === 'clair.json') {
-          next(request.respondWith({}, {
-            status: 500,
-          }));
-        }
-      };
+      let mock;
 
       beforeEach(() => {
-        Vue.http.interceptors.push(interceptor);
+        mock = mock = new MockAdapter(axios);
+        mock.onGet('clair.json').reply(500, {});
         vm = mountComponent(Component);
       });
 
       afterEach(() => {
-        Vue.http.interceptors = _.without(Vue.http.interceptors, interceptor);
+        mock.reset();
       });
 
       it('should render error indicator', (done) => {

spec/support/fixture_helpers.rb

@@ -5,9 +5,19 @@ module FixtureHelpers
     File.read(expand_fixture_path(filename))
   end
 
+  def fixture_file_ee(filename)
+    return '' if filename.blank?
+
+    File.read(expand_fixture_ee_path(filename))
+  end
+
   def expand_fixture_path(filename)
     File.expand_path(Rails.root.join('spec/fixtures/', filename))
   end
+
+  def expand_fixture_ee_path(filename)
+    File.expand_path(Rails.root.join('spec/ee/fixtures/', filename))
+  end
 end
 
 RSpec.configure do |config|

spec/support/stub_configuration.rb

@@ -7,6 +7,9 @@ module StubConfiguration
     allow_any_instance_of(ApplicationSetting).to receive_messages(to_settings(messages))
     allow(Gitlab::CurrentSettings.current_application_settings)
       .to receive_messages(to_settings(messages))
+
+    # Ensure that we don't use the Markdown cache when stubbing these values
+    allow_any_instance_of(ApplicationSetting).to receive(:cached_html_up_to_date?).and_return(false)
   end
 
   def stub_application_setting_on_object(object, messages)