Add latest changes from gitlab-org/gitlab@master

26 files changed, 98 insertions, 88 deletions

diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 50bd943b8e4..8207918dbbc 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -393,6 +393,8 @@ The following user actions on a GitLab instance generate instance audit events:
 - User was unblocked using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115727) in GitLab 15.11.
 - User was banned using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116103) in GitLab 15.11.
 - User was unbanned using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116221) in GitLab 15.11.
+- User was deactivated using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117776) in GitLab 16.0.
+- User was activated using the Admin Area or API. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121708) in GitLab 16.1.
 
 Instance events can also be accessed using the [Instance Audit Events API](../api/audit_events.md#instance-audit-events).
 
diff --git a/doc/administration/cicd.md b/doc/administration/cicd.md
index ad0671d4c13..f015658761b 100644
--- a/doc/administration/cicd.md
+++ b/doc/administration/cicd.md
@@ -15,7 +15,7 @@ GitLab CI/CD is enabled by default in all new projects on an instance. You can s
 CI/CD to be disabled by default in new projects by modifying the settings in:
 
 - `gitlab.yml` for source installations.
-- `gitlab.rb` for Omnibus GitLab installations.
+- `gitlab.rb` for Linux package installations.
 
 Existing projects that already had CI/CD enabled are unchanged. Also, this setting only changes
 the project default, so project owners [can still enable CI/CD in the project settings](../ci/enable_or_disable_ci.md#enable-cicd-in-a-project).
@@ -42,7 +42,7 @@ For installations from source:
    sudo service gitlab restart
    ```
 
-For Omnibus GitLab installations:
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add this line:
 
diff --git a/doc/administration/compliance.md b/doc/administration/compliance.md
index 9ae0e9d7790..79133d5a6c7 100644
--- a/doc/administration/compliance.md
+++ b/doc/administration/compliance.md
@@ -73,5 +73,5 @@ These features can also help with compliance requirements:
 | [Lock project membership to group](../user/group/access_and_permissions.md#prevent-members-from-being-added-to-projects-in-a-group) | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Group owners can prevent new members from being added to projects in a group.                                                                                          |
 | [LDAP group sync](auth/ldap/ldap_synchronization.md#group-sync)                                                                     | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Automatically synchronize groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.          |
 | [LDAP group sync filters](auth/ldap/ldap_synchronization.md#group-sync)                                                             | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.                                  |
-| [Omnibus GitLab package supports<br/>log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)         | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Forward your logs to a central system.                                                                                                                                 |
+| [Linux package installations support<br/>log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)     | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Forward your logs to a central system.                                                                                                                                 |
 | [Restrict SSH Keys](../security/ssh_keys_restrictions.md)                                                                           | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Control the technology and key length of SSH keys used to access GitLab.                                                                                               |
diff --git a/doc/administration/consul.md b/doc/administration/consul.md
index 965231db440..3257c197445 100644
--- a/doc/administration/consul.md
+++ b/doc/administration/consul.md
@@ -76,7 +76,7 @@ To upgrade your Consul nodes, upgrade the GitLab package.
 
 Nodes should be:
 
-- Members of a healthy cluster prior to upgrading the Omnibus GitLab package.
+- Members of a healthy cluster prior to upgrading the GitLab Linux package.
 - Upgraded one node at a time.
 
 Identify any existing health issues in the cluster by running the following command
diff --git a/doc/administration/encrypted_configuration.md b/doc/administration/encrypted_configuration.md
index 1ddf2951f70..808967778fa 100644
--- a/doc/administration/encrypted_configuration.md
+++ b/doc/administration/encrypted_configuration.md
@@ -19,22 +19,14 @@ GitLab can read settings for certain features from encrypted settings files. The
 To enable the encrypted configuration settings, a new base key must be generated for
 `encrypted_settings_key_base`. The secret can be generated in the following ways:
 
-**Omnibus**
+- For Linux package installations, the new secret is automatically generated for you, but you must ensure your
+  `/etc/gitlab/gitlab-secrets.json` contains the same values on all nodes.
+- For Helm chart installations, the new secret is automatically generated if you have the `shared-secrets` chart enabled.
+  Otherwise, you need to follow the [secrets guide for adding the secret](https://docs.gitlab.com/charts/installation/secrets.html#gitlab-rails-secret).
+- For self-compiled installations, the new secret can be generated by running:
 
-Starting with 13.7 the new secret is automatically generated for you, but you must ensure your
-`/etc/gitlab/gitlab-secrets.json` contains the same values on all nodes.
+  ```shell
+  bundle exec rake gitlab:env:info RAILS_ENV=production GITLAB_GENERATE_ENCRYPTED_SETTINGS_KEY_BASE=true
+  ```
 
-**Helm chart**
-
-Starting with GitLab 13.7, the new secret is automatically generated if you have the `shared-secrets` chart enabled. Otherwise, you need
-to follow the [secrets guide for adding the secret](https://docs.gitlab.com/charts/installation/secrets.html#gitlab-rails-secret).
-
-**Source**
-
-The new secret can be generated by running:
-
-```shell
-bundle exec rake gitlab:env:info RAILS_ENV=production GITLAB_GENERATE_ENCRYPTED_SETTINGS_KEY_BASE=true
-```
-
-This prints general information on the GitLab instance, but also causes the key to be generated in `<path-to-gitlab-rails>/config/secrets.yml`.
+  This prints general information on the GitLab instance and generates the key in `<path-to-gitlab-rails>/config/secrets.yml`.
diff --git a/doc/administration/environment_variables.md b/doc/administration/environment_variables.md
index a453d703a18..260095d12ac 100644
--- a/doc/administration/environment_variables.md
+++ b/doc/administration/environment_variables.md
@@ -10,8 +10,10 @@ type: reference
 GitLab exposes certain environment variables which can be used to override
 their defaults values.
 
-People usually configure GitLab with `/etc/gitlab/gitlab.rb` for Omnibus
-installations, or `gitlab.yml` for installations from source.
+People usually configure GitLab with:
+
+- `/etc/gitlab/gitlab.rb` for Linux package installations.
+- `gitlab.yml` for self-compiled installations.
 
 You can use the following environment variables to override certain values:
 
@@ -44,11 +46,10 @@ We welcome merge requests to make more settings configurable by using variables.
 Make changes to the `config/initializers/1_settings.rb` file, and use the
 naming scheme `GITLAB_#{name in 1_settings.rb in upper case}`.
 
-## Omnibus configuration
+## Linux package installation configuration
 
 To set environment variables, follow [these instructions](https://docs.gitlab.com/omnibus/settings/environment-variables.html).
 
 It's possible to preconfigure the GitLab Docker image by adding the environment
 variable `GITLAB_OMNIBUS_CONFIG` to the `docker run` command.
-For more information, see the [Pre-configure Docker container](../install/docker.md#pre-configure-docker-container)
-section of the Omnibus GitLab documentation.
+For more information, see [Pre-configure Docker container](../install/docker.md#pre-configure-docker-container).
diff --git a/doc/administration/feature_flags.md b/doc/administration/feature_flags.md
index 26deff0ca84..ea79a2b69b4 100644
--- a/doc/administration/feature_flags.md
+++ b/doc/administration/feature_flags.md
@@ -71,7 +71,7 @@ the status of the flag and the command to enable or disable it.
 The first thing you must do to enable or disable a feature behind a flag is to
 start a session on GitLab Rails console.
 
-For Omnibus installations:
+For Linux package installations:
 
 ```shell
 sudo gitlab-rails console
diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md
index dfddf38475c..904da47caff 100644
--- a/doc/administration/file_hooks.md
+++ b/doc/administration/file_hooks.md
@@ -34,13 +34,12 @@ where you can find some basic examples.
 
 Follow the steps below to set up a custom hook:
 
-1. On the GitLab server, navigate to the plugin directory.
-   For an installation from source the path is usually
-   `/home/git/gitlab/file_hooks/`. For Omnibus installs the path is
-   usually `/opt/gitlab/embedded/service/gitlab-rails/file_hooks`.
+1. On the GitLab server, locate the plugin directory. For self-compiled installations, the path is usually
+   `/home/git/gitlab/file_hooks/`. For Linux package installations, the path is usually
+   `/opt/gitlab/embedded/service/gitlab-rails/file_hooks`.
 
-    For [configurations with multiple servers](reference_architectures/index.md),
-    your hook file should exist on each application server.
+   For [configurations with multiple servers](reference_architectures/index.md), your hook file should exist on each
+   application server.
 
 1. Inside the `file_hooks` directory, create a file with a name of your choice,
    without spaces or special characters.
@@ -59,11 +58,8 @@ need to restart GitLab to apply a new file hook.
 If a file hook executes with non-zero exit code or GitLab fails to execute it, a
 message is logged to:
 
-- `gitlab-rails/file_hook.log` in an Omnibus installation.
-- `log/file_hook.log` in a source installation.
-
-NOTE:
-In GitLab 13.12 and earlier, the filename was `plugin.log`
+- `gitlab-rails/file_hook.log` in a Linux package installation.
+- `log/file_hook.log` in a self-compiled installation.
 
 ## Creating file hooks
 
diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index e698b990d8a..1ca86a6a55d 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -152,6 +152,8 @@ sites for improved latency and bandwidth nearby. All write requests are proxied
 The following table details the components currently tested through the Geo secondary site Workhorse proxy.
 It does not cover all data types.
 
+In this context, accelerated reads refer to read requests served from the secondary site, provided that the data is up to date for the component on the secondary site. If the data on the secondary site is determined to be out of date, the request is forwarded to the primary site. Read requests for components not listed in the table below are always automatically forwarded to the primary site.
+
 | Feature / component                                 | Accelerated reads?     |
 |:----------------------------------------------------|:-----------------------|
 | Project, wiki, design repository (using the web UI) | **{dotted-circle}** No |
@@ -165,11 +167,12 @@ It does not cover all data types.
 | LFS objects (using Git)                             | **{check-circle}** Yes |
 | Pages                                               | **{dotted-circle}** No <sup>2</sup> |
 | Advanced search (using the web UI)                  | **{dotted-circle}** No |
-| Container registry                                  | **{dotted-circle}** No |
+| Container registry                                  | **{dotted-circle}** No <sup>3</sup>|
 
 1. Git reads are served from the local secondary while pushes get proxied to the primary.
    Selective sync or cases where repositories don't exist locally on the Geo secondary throw a "not found" error.
 1. Pages can use the same URL (without access control), but must be configured separately and are not proxied.
+1. The container registry is only recommended for Disaster Recovery scenarios. If the secondary site's container registry is not up to date, the read request is served with old data as the request is not forwarded to the primary site.
 
 ## Disable Geo proxying
 
diff --git a/doc/administration/get_started.md b/doc/administration/get_started.md
index b780008281b..26848f454b5 100644
--- a/doc/administration/get_started.md
+++ b/doc/administration/get_started.md
@@ -126,11 +126,11 @@ GitLab provides backup methods to keep your data safe and recoverable. Whether y
 
 ### Back up a GitLab self-managed instance
 
-The routine differs, depending on whether you deployed with Omnibus or the Helm chart.
+The routine differs, depending on whether you deployed with the Linux package or the Helm chart.
 
-When you backing up an Omnibus (single node) GitLab server, you can use a single Rake task.
+When backing up (single node) GitLab server installed using the Linux package, you can use a single Rake task.
 
-Learn about [backing up Omnibus or Helm variations](../raketasks/backup_restore.md).
+Learn about [backing up Linux package or Helm variations](../raketasks/backup_restore.md).
 This process backs up your entire instance, but does not back up the configuration files. Ensure those are backed up separately.
 Keep your configuration files and backup archives in a separate location to ensure the encryption keys are not kept with the encrypted data.
 
@@ -138,7 +138,7 @@ Keep your configuration files and backup archives in a separate location to ensu
 
 You can restore a backup only to **the exact same version and type** (Community Edition/Enterprise Edition) of GitLab on which it was created.
 
-- Review the [Omnibus backup and restore documentation](https://docs.gitlab.com/omnibus/settings/backups).
+- Review the [Linux package (Omnibus) backup and restore documentation](https://docs.gitlab.com/omnibus/settings/backups).
 - Review the [Helm Chart backup and restore documentation](https://docs.gitlab.com/charts/backup-restore/).
 
 ### Back up GitLab SaaS
@@ -172,7 +172,7 @@ If your GitLab server contains a lot of Git repository data, you may find the Gi
 Slowness typically starts at a Git repository data size of around 200 GB. In this case, you might consider using file system snapshots as part of your backup strategy.
 For example, consider a GitLab server with the following components:
 
-- Using Omnibus GitLab
+- Using the GitLab Linux package.
 - Hosted on AWS with an EBS drive containing an ext4 file system mounted at `/var/opt/gitlab`.
 
 The EC2 instance meets the requirements for an application data backup by taking an EBS snapshot. The backup includes all repositories, uploads, and PostgreSQL data.
diff --git a/doc/administration/git_protocol.md b/doc/administration/git_protocol.md
index b996b9efae9..1ece7d773ee 100644
--- a/doc/administration/git_protocol.md
+++ b/doc/administration/git_protocol.md
@@ -29,7 +29,7 @@ and [All-in-one Docker image](../install/docker.md), the SSH
 service is already configured to accept the `GIT_PROTOCOL` environment. Users
 need not do anything more.
 
-For Omnibus GitLab and installations from source, update
+For installations from the Linux package or self-compiled installations, update
 the SSH configuration of your server manually by adding this line to the `/etc/ssh/sshd_config` file:
 
 ```plaintext
diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md
index 3b4eaeb161c..0024c42972b 100644
--- a/doc/administration/incoming_email.md
+++ b/doc/administration/incoming_email.md
@@ -156,7 +156,7 @@ If the sender's address is spoofed, the reject notice is delivered to the spoofe
 `FROM` address, which can cause the mail server's IP or domain to appear on a block
 list.
 
-### Omnibus package installations
+### Linux package installations
 
 1. Find the `incoming_email` section in `/etc/gitlab/gitlab.rb`, enable the feature
     and fill in the details for your specific IMAP server and email account (see [examples](#configuration-examples) below).
@@ -270,7 +270,7 @@ Reply by email should now be working.
 
 Example configuration for Postfix mail server. Assumes mailbox `incoming@gitlab.example.com`.
 
-Example for Omnibus installs:
+Example for Linux package installations:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -362,7 +362,7 @@ Example configuration for Gmail/Google Workspace. Assumes mailbox `gitlab-incomi
 NOTE:
 `incoming_email_email` cannot be a Gmail alias account.
 
-Example for Omnibus installs:
+Example for Linux package installations:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -459,7 +459,7 @@ Exchange does not support sub-addressing, only two options exist:
 
 Assumes the catch-all mailbox `incoming@exchange.example.com`.
 
-Example for Omnibus installs:
+Example for Linux package installations:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -533,7 +533,7 @@ Cannot support [Service Desk](../user/project/service_desk.md).
 
 Assumes the dedicated email address `incoming@exchange.example.com`.
 
-Example for Omnibus installs:
+Example for Linux package installations:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -617,7 +617,7 @@ To enable sub-addressing:
    Disconnect-ExchangeOnline
    ```
 
-This example for Omnibus GitLab assumes the mailbox `incoming@office365.example.com`:
+This example for Linux package installations assumes the mailbox `incoming@office365.example.com`:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -678,7 +678,7 @@ incoming_email:
 
 ##### Catch-all mailbox
 
-This example for Omnibus installs assumes the catch-all mailbox `incoming@office365.example.com`:
+This example for Linux package installations assumes the catch-all mailbox `incoming@office365.example.com`:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -743,7 +743,7 @@ NOTE:
 Supports [Reply by Email](reply_by_email.md) only.
 Cannot support [Service Desk](../user/project/service_desk.md).
 
-This example for Omnibus installs assumes the dedicated email address `incoming@office365.example.com`:
+This example for Linux package installations assumes the dedicated email address `incoming@office365.example.com`:
 
 ```ruby
 gitlab_rails['incoming_email_enabled'] = true
@@ -821,7 +821,7 @@ To mitigate security concerns, we recommend configuring an application access
 policy which limits the mailbox access for all accounts, as described in
 [Microsoft documentation](https://learn.microsoft.com/en-us/graph/auth-limit-mailbox-access).
 
-This example for Omnibus GitLab assumes you're using the following mailbox: `incoming@example.onmicrosoft.com`:
+This example for Linux package installations assumes you're using the following mailbox: `incoming@example.onmicrosoft.com`:
 
 ##### Configure Microsoft Graph
 
diff --git a/doc/administration/libravatar.md b/doc/administration/libravatar.md
index 802a3be46fa..1b7406546ef 100644
--- a/doc/administration/libravatar.md
+++ b/doc/administration/libravatar.md
@@ -25,7 +25,7 @@ You can use only the MD5 hash in the URL for the Libravatar service. See [issue
 In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab/-/blob/68dac188ec6b1b03d53365e7579422f44cbe7a1c/config/gitlab.yml.example#L469-476), set
 the configuration options as follows:
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -39,7 +39,7 @@ the configuration options as follows:
 
 1. To apply the changes, run `sudo gitlab-ctl reconfigure`.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
@@ -57,12 +57,12 @@ the configuration options as follows:
 
 ## Set the Libravatar service to default (Gravatar)
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Delete `gitlab_rails['gravatar_ssl_url']` or `gitlab_rails['gravatar_plain_url']` from `/etc/gitlab/gitlab.rb`.
 1. To apply the changes, run `sudo gitlab-ctl reconfigure`.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Remove `gravatar:` section from `config/gitlab.yml`.
 1. Save the file, then [restart](restart_gitlab.md#installations-from-source)
@@ -72,7 +72,7 @@ the configuration options as follows:
 
 To disable Gravatar, for example, to prohibit third-party services, complete the following steps:
 
-**For Omnibus installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -82,7 +82,7 @@ To disable Gravatar, for example, to prohibit third-party services, complete the
 
 1. To apply the changes, run `sudo gitlab-ctl reconfigure`.
 
-**For installations from source**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
diff --git a/doc/administration/merge_request_diffs.md b/doc/administration/merge_request_diffs.md
index 3250a2339e2..c49a9f8accb 100644
--- a/doc/administration/merge_request_diffs.md
+++ b/doc/administration/merge_request_diffs.md
@@ -21,7 +21,7 @@ that only [stores outdated diffs](#alternative-in-database-storage) outside of d
 
 ## Using external storage
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -41,7 +41,7 @@ that only [stores outdated diffs](#alternative-in-database-storage) outside of d
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
    GitLab then migrates your existing merge request diffs to external storage.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -74,7 +74,7 @@ Instead of storing the external diffs on disk, we recommended the use of an obje
 store like AWS S3 instead. This configuration relies on valid AWS credentials to
 be configured already.
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -86,7 +86,7 @@ be configured already.
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
    GitLab then migrates your existing merge request diffs to external storage.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -109,7 +109,7 @@ In GitLab 13.2 and later, you should use the
 This section describes the earlier configuration format.
 
 For source installations, these settings are nested under `external_diffs:` and
-then `object_store:`. On Omnibus installations, they are prefixed by
+then `object_store:`. On Linux package installations, they are prefixed by
 `external_diffs_object_store_`.
 
 | Setting | Description | Default |
@@ -123,7 +123,7 @@ then `object_store:`. On Omnibus installations, they are prefixed by
 
 See [the available connection settings for different providers](object_storage.md#configure-the-connection-settings).
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines by replacing with
    the values you want:
@@ -153,7 +153,7 @@ See [the available connection settings for different providers](object_storage.m
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -182,7 +182,7 @@ in the database.
 
 To enable this feature, perform the following steps:
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -192,7 +192,7 @@ To enable this feature, perform the following steps:
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -236,13 +236,13 @@ Then you are affected by this issue. Because it's not possible to safely determi
 all these conditions automatically, we've provided a Rake task in GitLab v13.2.0
 that you can run manually to correct the data:
 
-**In Omnibus installations:**
+For Linux package installations:
 
 ```shell
 sudo gitlab-rake gitlab:external_diffs:force_object_storage
 ```
 
-**In installations from source:**
+For self-compiled installations:
 
 ```shell
 sudo -u git -H bundle exec rake gitlab:external_diffs:force_object_storage RAILS_ENV=production
diff --git a/doc/ci/runners/saas/macos_saas_runner.md b/doc/ci/runners/saas/macos_saas_runner.md
index 52a5f89d7e7..165f1c2e494 100644
--- a/doc/ci/runners/saas/macos_saas_runner.md
+++ b/doc/ci/runners/saas/macos_saas_runner.md
@@ -25,7 +25,7 @@ Intel x86-64 runners were deprecated in favor of Apple silicon. To build for an
 
 ## VM images
 
-In comparison to our SaaS runners on Linux, where you can run any Docker image, 
+In comparison to our SaaS runners on Linux, where you can run any Docker image,
 GitLab SaaS provides a set of VM images for macOS.
 
 ### Supported macOS images
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index 5e255921a29..bc8ed6e2cd4 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -141,7 +141,7 @@ Lastly, keep the following in mind when submitting merge requests:
 
 ## Contributing to Premium/Ultimate features with an Enterprise Edition license
 
-If you would like to work on GitLab features that are within a paid tier, also known as the code that lives in the [EE folder](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee), it requires a GitLab Enterprise Edition license. 
+If you would like to work on GitLab features that are within a paid tier, also known as the code that lives in the [EE folder](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee), it requires a GitLab Enterprise Edition license.
 Please request an Enterprise Edition Developers License according to the [documented process](https://about.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows.html#contributing-to-the-gitlab-enterprise-edition-ee).
 
 ## Get help
diff --git a/doc/index.md b/doc/index.md
index 958f7fe6111..654204048af 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -43,9 +43,9 @@ Have a look at some of our most popular topics:
 | [Back up and restore GitLab](raketasks/backup_restore.md)                                  | Rake tasks for backing up and restoring GitLab self-managed instances. |
 | [GitLab release and maintenance policy](policy/maintenance.md)                             | Policies for version naming and cadence, and also upgrade recommendations. |
 | [Elasticsearch integration](integration/advanced_search/elasticsearch.md)                  | Integrate Elasticsearch with GitLab to enable advanced search. |
-| [Omnibus GitLab database settings](https://docs.gitlab.com/omnibus/settings/database.html) | Database settings for Omnibus GitLab self-managed instances. |
-| [Omnibus GitLab NGINX settings](https://docs.gitlab.com/omnibus/settings/nginx.html)       | NGINX settings for Omnibus GitLab self-managed instances. |
-| [Omnibus GitLab SSL configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html)      | SSL settings for Omnibus GitLab self-managed instances. |
+| [Database settings for Linux package installations](https://docs.gitlab.com/omnibus/settings/database.html) | Database settings for self-managed instances installed using Linux packages. |
+| [NGINX settings for Linux package installations](https://docs.gitlab.com/omnibus/settings/nginx.html)       | NGINX settings for self-managed instances installed using Linux packages. |
+| [SSL configuration for Linux package installations](https://docs.gitlab.com/omnibus/settings/ssl/index.html)      | SSL settings for self-managed instances installed using Linux packages. |
 | [GitLab.com settings](user/gitlab_com/index.md)                                            | Settings used for GitLab.com. |
 
 ## The entire DevOps lifecycle
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 5cb7b00ddc5..cf7adb9d354 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -570,7 +570,7 @@ after which users must reactivate 2FA.
 
    These are the variables that you need to delete.
 
-1. Drop the table:
+1. Delete all variables:
 
    ```sql
    DELETE FROM ci_group_variables;
diff --git a/doc/tutorials/left_sidebar/img/shortcuts_v16_0.png b/doc/tutorials/left_sidebar/img/shortcuts_v16_0.png
deleted file mode 100644
index 07094898117..00000000000
--- a/doc/tutorials/left_sidebar/img/shortcuts_v16_0.png
+++ /dev/null
diff --git a/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png b/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png
new file mode 100644
index 00000000000..75e6f496c0c
--- /dev/null
+++ b/doc/tutorials/left_sidebar/img/sidebar_bottom_v16_1.png
diff --git a/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png b/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png
new file mode 100644
index 00000000000..75fb1ae7ffe
--- /dev/null
+++ b/doc/tutorials/left_sidebar/img/sidebar_middle_v16_1.png
diff --git a/doc/tutorials/left_sidebar/img/sidebar_top_v16_1.png b/doc/tutorials/left_sidebar/img/sidebar_top_v16_1.png
new file mode 100644
index 00000000000..fcb56370fc7
--- /dev/null
+++ b/doc/tutorials/left_sidebar/img/sidebar_top_v16_1.png
diff --git a/doc/tutorials/left_sidebar/index.md b/doc/tutorials/left_sidebar/index.md
index 7de50afbe77..01dffc7e6dc 100644
--- a/doc/tutorials/left_sidebar/index.md
+++ b/doc/tutorials/left_sidebar/index.md
@@ -22,12 +22,32 @@ To view the new sidebar:
 
 To turn off this sidebar, return to your avatar and turn off the toggle.
 
+## Layout of the left sidebar
+
+At the top of the left sidebar are several shortcuts. Use these shortcuts to
+quickly create new items, view your profile, search, and view your list of issues,
+merge requests, and to-do items.
+
+![Top of sidebar](img/sidebar_top_v16_1.png)
+
+The next area of the left sidebar changes based on the information you're viewing. For example,
+you might be viewing a project, exploring projects or groups, or viewing your profile.
+Use this area to switch to other areas of the left sidebar.
+
+![Context switching](img/sidebar_middle_v16_1.png)
+
+The rest of the left sidebar is populated based on the option you choose. For example,
+if you're in a project, the sidebar is project-specific:
+
+![Project-specific options](img/sidebar_bottom_v16_1.png)
+
 ## Find your project
 
-Let's get started exploring the GitLab UI and left sidebar.
+Now let's go over a few common tasks you'll use the left sidebar for.
+
+To start, we will find the project we want to work on.
 
-1. Start by finding the project you want to work on.
-   To explore all available projects, on the left sidebar, select **Explore**:
+1. To explore all available projects, on the left sidebar, select **Explore**:
 
    ![Explore](img/explore_v16_0.png)
 
@@ -41,11 +61,6 @@ Let's get started exploring the GitLab UI and left sidebar.
 
    ![Project-specific options](img/project_selected_v16_0.png)
 
-Your issues, merge requests, and to-do items are listed in the shortcuts
-at the top:
-
-![shortcuts](img/shortcuts_v16_0.png)
-
 ## Customize the sidebar
 
 You can pin menu items if you tend to use them frequently.
diff --git a/doc/update/index.md b/doc/update/index.md
index c5e40d59bbd..54686567e5b 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -292,7 +292,7 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
 - Sidekiq jobs are only routed to `default` and `mailers` queues by default, and as a result,
   every Sidekiq process also listens to those queues to ensure all jobs are processed across
   all queues. This behavior does not apply if you have configured the [routing rules](../administration/sidekiq/processing_specific_job_classes.md#routing-rules).
-- Docker 20.10.10 or later is required to run the GitLab Docker image. Older versions 
+- Docker 20.10.10 or later is required to run the GitLab Docker image. Older versions
   [throw errors on startup](../install/docker.md#threaderror-cant-create-thread-operation-not-permitted).
 
 ### 15.11.1
diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md
index 0826258de9e..e6c710d1326 100644
--- a/doc/user/application_security/vulnerability_report/index.md
+++ b/doc/user/application_security/vulnerability_report/index.md
@@ -72,7 +72,8 @@ The available filters are:
 
 <!-- vale gitlab.SubstitutionWarning = NO -->
 
-- **Status**: Detected, Confirmed, Dismissed, Resolved.
+- **Status**: Detected, Confirmed, Dismissed, Resolved. For details on what each status means, see
+  [vulnerability status values](../vulnerabilities/index.md#vulnerability-status-values).
 - **Severity**: Critical, High, Medium, Low, Info, Unknown.
 - **Tool**: For more details, see [Tool filter](#tool-filter).
 - **Project**: For more details, see [Project filter](#project-filter).
diff --git a/doc/user/workspace/index.md b/doc/user/workspace/index.md
index 45d9e262bed..038b5e44af6 100644
--- a/doc/user/workspace/index.md
+++ b/doc/user/workspace/index.md
@@ -154,6 +154,6 @@ If you already have running workspaces, an administrator must manually delete th
 ## Arbitrary user IDs
 
 You can provide your own container image, which can run as any Linux user ID. It's not possible for GitLab to predict the Linux user ID for a container image.
-GitLab uses the Linux root group ID permission to create, update, or delete files in the container. CRI-O, the container runtime interface used by Kubernetes, has a default group ID of `0` for all containers.
+GitLab uses the Linux root group ID permission to create, update, or delete files in the container. Depending on the container runtime used by the Kubernetes cluster, all containers might have a default group ID of `0`.
 
 If you have a container image that does not support arbitrary user IDs, you cannot create, update, or delete files in a workspace. To create a container image that supports arbitrary user IDs, see the [OpenShift documentation](https://docs.openshift.com/container-platform/4.12/openshift_images/create-images.html#use-uid_create-images).