Add latest changes from gitlab-org/gitlab@master

16 files changed, 217 insertions, 248 deletions

diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index 35554e77ad5..5c6fc370052 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -40,8 +40,8 @@ By default, Gitaly is run on the same server as Gitaly clients and is
 [configured as above](#configure-gitaly). Single-server installations are best served by
 this default configuration used by:
 
-- [Omnibus GitLab](https://docs.gitlab.com/omnibus/).
-- The GitLab [source installation guide](../../install/installation.md).
+- [Linux package installations](https://docs.gitlab.com/omnibus/).
+- [Self-compiled installations](../../install/installation.md).
 
 However, Gitaly can be deployed to its own server, which can benefit GitLab installations that span
 multiple machines.
@@ -112,12 +112,11 @@ You can use as few as one server with one repository storage if desired.
 
 ### Install Gitaly
 
-Install Gitaly on each Gitaly server using either Omnibus GitLab or install it from source:
+Install Gitaly on each Gitaly server using either:
 
-- For Omnibus GitLab, [download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-  package you want but **do not** provide the `EXTERNAL_URL=` value.
-- To install from source, follow the steps at
-  [Install Gitaly](../../install/installation.md#install-gitaly).
+- A Linux package installation. [Download and install](https://about.gitlab.com/install/) the Linux package you want
+  but **do not** provide the `EXTERNAL_URL=` value.
+- A self-compiled installation. Follow the steps at [Install Gitaly](../../install/installation.md#install-gitaly).
 
 ### Configure Gitaly servers
 
@@ -880,7 +879,7 @@ to `gitaly['configuration'][:cgroups]` in `/etc/gitlab/gitlab.rb`:
 
 - `mountpoint` is where the parent cgroup directory is mounted. Defaults to `/sys/fs/cgroup`.
 - `hierarchy_root` is the parent cgroup under which Gitaly creates groups, and
-   is expected to be owned by the user and group Gitaly runs as. Omnibus GitLab
+   is expected to be owned by the user and group Gitaly runs as. A Linux package installation
    creates the set of directories `mountpoint/<cpu|memory>/hierarchy_root`
    when Gitaly starts.
 - `memory_bytes` is the total memory limit that is imposed collectively on all
@@ -939,7 +938,7 @@ in `/etc/gitlab/gitlab.rb`:
    commands to these cgroups.
 - `cgroups_mountpoint` is where the parent cgroup directory is mounted. Defaults to `/sys/fs/cgroup`.
 - `cgroups_hierarchy_root` is the parent cgroup under which Gitaly creates groups, and
-   is expected to be owned by the user and group Gitaly runs as. Omnibus GitLab
+   is expected to be owned by the user and group Gitaly runs as. A Linux package installation
    creates the set of directories `mountpoint/<cpu|memory>/hierarchy_root`
    when Gitaly starts.
 - `cgroups_memory_enabled` enables or disables the memory limit on cgroups.
@@ -1388,7 +1387,7 @@ objects even if the project doesn't have malicious intent.
 Instance administrators can override consistency checks if they must
 process repositories that do not pass consistency checks.
 
-For Omnibus GitLab installations, edit `/etc/gitlab/gitlab.rb` and set the
+For Linux package installations, edit `/etc/gitlab/gitlab.rb` and set the
 following keys (in this example, to disable the `hasDotgit` consistency check):
 
 - In [GitLab 15.10](https://gitlab.com/gitlab-org/gitaly/-/issues/4754) and later:
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index d5d022ecaba..2a3c3da24b3 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -12,7 +12,7 @@ It is used by GitLab to read and write Git data.
 Gitaly is present in every GitLab installation and coordinates Git repository
 storage and retrieval. Gitaly can be:
 
-- A background service operating on a single instance Omnibus GitLab (all of
+- A background service operating on a single instance Linux package installation (all of
   GitLab on one machine).
 - Separated onto its own instance and configured in a full cluster configuration,
   depending on scaling and availability requirements.
@@ -164,11 +164,11 @@ E --> F
 
 ### Configure Gitaly
 
-Gitaly comes pre-configured with Omnibus GitLab, which is a configuration
+Gitaly comes pre-configured with a Linux package installation, which is a configuration
 [suitable for up to 1000 users](../reference_architectures/1k_users.md). For:
 
-- Omnibus GitLab installations for up to 2000 users, see [specific Gitaly configuration instructions](../reference_architectures/2k_users.md#configure-gitaly).
-- Source installations or custom Gitaly installations, see [Configure Gitaly](configure_gitaly.md).
+- Linux package installations for up to 2000 users, see [specific Gitaly configuration instructions](../reference_architectures/2k_users.md#configure-gitaly).
+- Self-compiled installations or custom Gitaly installations, see [Configure Gitaly](configure_gitaly.md).
 
 GitLab installations for more than 2000 active users performing daily Git write operation may be
 best suited by using Gitaly Cluster.
@@ -595,7 +595,7 @@ Direct access to Git uses code in GitLab known as the "Rugged patches".
 
 Before Gitaly existed, what are now Gitaly clients accessed Git repositories directly, either:
 
-- On a local disk in the case of a single-machine Omnibus GitLab installation.
+- On a local disk in the case of a single-machine Linux package installation.
 - Using NFS in the case of a horizontally-scaled GitLab installation.
 
 In addition to running plain `git` commands, GitLab used a Ruby library called
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index d5c01d4e1c1..f80a5192c55 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -90,7 +90,7 @@ GitLab application database.
 
 ## Setup Instructions
 
-If you [installed](https://about.gitlab.com/install/) GitLab using the Omnibus GitLab package
+If you [installed](https://about.gitlab.com/install/) GitLab using the Linux package
 (highly recommended), follow the steps below:
 
 1. [Preparation](#preparation)
@@ -107,7 +107,7 @@ Before beginning, you should already have a working GitLab instance.
 [Learn how to install GitLab](https://about.gitlab.com/install/).
 
 Provision a PostgreSQL server. You should use the PostgreSQL that is shipped
-with Omnibus GitLab and use it to configure the PostgreSQL database. You can use an
+with the Linux package and use it to configure the PostgreSQL database. You can use an
 external PostgreSQL server (version 11 or newer) but you must set it up [manually](#manual-database-setup).
 
 Prepare all your new nodes by [installing GitLab](https://about.gitlab.com/install/). You need:
@@ -159,7 +159,7 @@ with secure tokens as you complete the setup process.
 We note in the instructions below where these secrets are required.
 
 NOTE:
-Omnibus GitLab installations can use `gitlab-secrets.json` for `GITLAB_SHELL_SECRET_TOKEN`.
+Linux package installations can use `gitlab-secrets.json` for `GITLAB_SHELL_SECRET_TOKEN`.
 
 ### Customize time server setting
 
@@ -178,7 +178,7 @@ The replication state is internal to each instance of GitLab and should
 not be replicated.
 
 These instructions help set up a single PostgreSQL database, which creates a single point of failure. To avoid this, you can configure your own clustered
-PostgreSQL. Support for PostgreSQL replication and failover using Omnibus GitLab is proposed in [epic 7814](https://gitlab.com/groups/gitlab-org/-/epics/7814).
+PostgreSQL. Support for PostgreSQL replication and failover using the Linux package is proposed in [epic 7814](https://gitlab.com/groups/gitlab-org/-/epics/7814).
 Clustered database support for other databases (for example, Praefect and Geo databases) is proposed in
 [issue 7292](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
 
@@ -198,7 +198,7 @@ Setting up PostgreSQL creates empty Praefect tables. For more information, see t
 #### Running GitLab and Praefect databases on the same server
 
 The GitLab application database and the Praefect database can be run on the same server. However, Praefect should have
-its own database server when using Omnibus GitLab PostgreSQL. If there is a failover, Praefect isn't aware and starts to
+its own database server when using PostgreSQL from the Linux package. If there is a failover, Praefect isn't aware and starts to
 fail as the database it's trying to use would either:
 
 - Be unavailable.
@@ -213,10 +213,10 @@ To complete this section you need:
   - A PostgreSQL user with permissions to manage the database server
 
 In this section, we configure the PostgreSQL database. This can be used for both external
-and Omnibus-provided PostgreSQL server.
+and Linux package-provided PostgreSQL server.
 
 To run the following instructions, you can use the Praefect node, where `psql` is installed
-by Omnibus GitLab (`/opt/gitlab/embedded/bin/psql`). If you are using the Omnibus-provided
+by the Linux package (`/opt/gitlab/embedded/bin/psql`). If you are using the Linux package-provided
 PostgreSQL you can use `gitlab-psql` on the PostgreSQL node instead:
 
 1. Create a new user `praefect` to be used by Praefect:
@@ -233,11 +233,11 @@ PostgreSQL you can use `gitlab-psql` on the PostgreSQL node instead:
    CREATE DATABASE praefect_production WITH OWNER praefect ENCODING UTF8;
    ```
 
-For using Omnibus-provided PgBouncer you need to take the following additional steps. We strongly
-recommend using the PostgreSQL that is shipped with Omnibus as the backend. The following
-instructions only work on Omnibus-provided PostgreSQL:
+When using the Linux package-provided PgBouncer, you need to take the following additional steps. We strongly
+recommend using the PostgreSQL that is shipped with the Linux package as the backend. The following
+instructions only work on the Linux package-provided PostgreSQL:
 
-1. For Omnibus-provided PgBouncer, you need to use the hash of `praefect` password instead the of the
+1. For the Linux package-provided PgBouncer, you need to use the hash of `praefect` password instead the of the
    actual password:
 
    ```sql
@@ -247,7 +247,7 @@ instructions only work on Omnibus-provided PostgreSQL:
    Replace `<PRAEFECT_SQL_PASSWORD_HASH>` with the hash of the password you generated in the
    preparation step. It is prefixed with `md5` literal.
 
-1. The PgBouncer that is shipped with Omnibus is configured to use [`auth_query`](https://www.pgbouncer.org/config.html#generic-settings)
+1. The PgBouncer that is shipped with the Linux package is configured to use [`auth_query`](https://www.pgbouncer.org/config.html#generic-settings)
    and uses `pg_shadow_lookup` function. You need to create this function in `praefect_production`
    database:
 
@@ -447,7 +447,7 @@ praefect['configuration'] = {
 With this configuration, Praefect uses PgBouncer for both connection types.
 
 NOTE:
-Omnibus GitLab handles the authentication requirements (using `auth_query`), but if you are preparing
+Linux package installations handle the authentication requirements (using `auth_query`), but if you are preparing
 your databases manually and configuring an external PgBouncer, you must include `praefect` user and
 its password in the file used by PgBouncer. For example, `userlist.txt` if the [`auth_file`](https://www.pgbouncer.org/config.html#auth_file)
 configuration option is set. For more details, consult the PgBouncer documentation.
@@ -758,9 +758,9 @@ Note the following:
   }
   ```
 
-To configure Praefect with TLS:
+Configure Praefect with TLS.
 
-**For Omnibus GitLab**
+For Linux package installations:
 
 1. Create certificates for Praefect servers.
 
@@ -811,7 +811,7 @@ To configure Praefect with TLS:
 
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
-**For installations from source**
+For self-compiled installations:
 
 1. Create certificates for Praefect servers.
 1. On the Praefect servers, create the `/etc/gitlab/ssl` directory and copy your key and certificate
diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md
index 81b3faf859e..aa04c9a92c4 100644
--- a/doc/administration/gitaly/reference.md
+++ b/doc/administration/gitaly/reference.md
@@ -7,11 +7,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Gitaly reference **(FREE SELF)**
 
 Gitaly is configured via a [TOML](https://github.com/toml-lang/toml)
-configuration file. Unlike installations from source, in Omnibus GitLab, you
-would not edit this file directly. For Omnibus GitLab installations, the default file location is `/var/opt/gitlab/gitaly/config.toml`.
+configuration file. Unlike self-compiled installations, in Linux package installations you
+would not edit this file directly. For Linux package installations, the default file location is `/var/opt/gitlab/gitaly/config.toml`.
 
-The configuration file is passed as an argument to the `gitaly` executable, which is usually done by either Omnibus
-GitLab or your [init](https://en.wikipedia.org/wiki/Init) script.
+The configuration file is passed as an argument to the `gitaly` executable, which is usually done by either your Linux
+package installation or your [init](https://en.wikipedia.org/wiki/Init) script.
 
 An [example configuration file](https://gitlab.com/gitlab-org/gitaly/blob/master/config.toml.example)
 can be found in the Gitaly project.
diff --git a/doc/administration/gitaly/troubleshooting.md b/doc/administration/gitaly/troubleshooting.md
index d383ebfe3e8..afef787e9c3 100644
--- a/doc/administration/gitaly/troubleshooting.md
+++ b/doc/administration/gitaly/troubleshooting.md
@@ -86,7 +86,7 @@ check for an SSL or TLS problem:
 ```
 
 Check whether `Verify return code` field indicates a
-[known Omnibus GitLab configuration problem](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
+[known Linux package installation configuration problem](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
 
 If `openssl` succeeds but `gitlab-rake gitlab:gitaly:check` fails,
 check [certificate requirements](configure_gitaly.md#certificate-requirements) for Gitaly.
@@ -94,7 +94,7 @@ check [certificate requirements](configure_gitaly.md#certificate-requirements) f
 ### Server side gRPC logs
 
 gRPC tracing can also be enabled in Gitaly itself with the `GODEBUG=http2debug`
-environment variable. To set this in an Omnibus GitLab install:
+environment variable. To set this in a Linux package installation:
 
 1. Add the following to your `gitlab.rb` file:
 
diff --git a/doc/administration/integration/plantuml.md b/doc/administration/integration/plantuml.md
index bb72d7070be..9c5e07eedaa 100644
--- a/doc/administration/integration/plantuml.md
+++ b/doc/administration/integration/plantuml.md
@@ -320,7 +320,7 @@ these steps:
 
 - For PlantUML servers running v1.2020.9 and above, such as [plantuml.com](https://plantuml.com),
   you must set the `PLANTUML_ENCODING` environment variable to enable the `deflate`
-  compression. In Omnibus GitLab, you can set this value in `/etc/gitlab.rb` with
+  compression. In Linux package installations, you can set this value in `/etc/gitlab.rb` with
   this command:
 
   ```ruby
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index bea389a8f0a..e5920520be7 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -87,16 +87,14 @@ it's safe to enable support for these headers globally. If you prefer a
 narrower set of rules, you can restrict it to URLs ending with `/terminal.ws`.
 This approach may still result in a few false positives.
 
-If you installed from source, or have made any configuration changes to your
-Omnibus installation before upgrading to 8.15, you may need to make some changes
-to your configuration. Read
+If you self-compiled your installation, you may need to make some changes to your configuration. Read
 [Upgrading Community Edition and Enterprise Edition from source](../../update/upgrading_from_source.md#nginx-configuration)
 for more details.
 
 To disable web terminal support in GitLab, stop passing
 the `Connection` and `Upgrade` hop-by-hop headers in the *first* HTTP reverse
 proxy in the chain. For most users, this is the NGINX server bundled with
-Omnibus GitLab, in which case, you need to:
+Linux package installations. In this case, you need to:
 
 - Find the `nginx['proxy_set_headers']` section of your `gitlab.rb` file
 - Ensure the whole block is uncommented, and then comment out or remove the
diff --git a/doc/administration/logs/index.md b/doc/administration/logs/index.md
index 3533237f946..8dcb25e22df 100644
--- a/doc/administration/logs/index.md
+++ b/doc/administration/logs/index.md
@@ -14,7 +14,7 @@ This guide talks about how to read and use these system log files.
 
 Read more about the log system and using the logs:
 
-- [Customize logging on Omnibus GitLab installations](https://docs.gitlab.com/omnibus/settings/logs.html)
+- [Customize logging on Linux package installations](https://docs.gitlab.com/omnibus/settings/logs.html)
 including adjusting log retention, log forwarding,
 switching logs from JSON to plain text logging, and more.
 - [How to parse and analyze JSON logs](../logs/log_parsing.md).
@@ -88,7 +88,7 @@ except those captured by `runit`.
 | [Alertmanager logs](#alertmanager-logs)         | **{dotted-circle}** No  | **{check-circle}** Yes  |
 | [crond logs](#crond-logs)                       | **{dotted-circle}** No  | **{check-circle}** Yes  |
 | [Gitaly](#gitaly-logs)                          | **{check-circle}** Yes  | **{check-circle}** Yes  |
-| [GitLab Exporter for Omnibus](#gitlab-exporter) | **{dotted-circle}** No  | **{check-circle}** Yes  |
+| [GitLab Exporter for Linux package installations](#gitlab-exporter) | **{dotted-circle}** No  | **{check-circle}** Yes  |
 | [GitLab Pages logs](#pages-logs)                | **{check-circle}** Yes  | **{check-circle}** Yes  |
 | GitLab Rails                                    | **{check-circle}** Yes  | **{dotted-circle}** No  |
 | [GitLab Shell logs](#gitlab-shelllog)           | **{check-circle}** Yes  | **{dotted-circle}** No  |
@@ -107,10 +107,10 @@ except those captured by `runit`.
 
 ## `production_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/production_json.log`
-- Installations from source: `/home/git/gitlab/log/production_json.log`
+- `/var/log/gitlab/gitlab-rails/production_json.log` on Linux package installations.
+- `/home/git/gitlab/log/production_json.log` on self-compiled installations.
 
 It contains a structured log for Rails controller requests received from
 GitLab, thanks to [Lograge](https://github.com/roidrage/lograge/).
@@ -264,10 +264,10 @@ Starting with GitLab 12.5, if an error occurs, an
 
 ## `production.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/production.log`
-- Installations from source: `/home/git/gitlab/log/production.log`
+- `/var/log/gitlab/gitlab-rails/production.log` on Linux package installations.
+- `/home/git/gitlab/log/production.log` on self-compiled installations.
 
 It contains information about all performed requests. You can see the
 URL and type of request, IP address, and what parts of code were
@@ -300,10 +300,10 @@ The request was processed by `Projects::TreeController`.
 
 ## `api_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/api_json.log`
-- Installations from source: `/home/git/gitlab/log/api_json.log`
+- `/var/log/gitlab/gitlab-rails/api_json.log` on Linux package installations.
+- `/home/git/gitlab/log/api_json.log` on self-compiled installations.
 
 It helps you see requests made directly to the API. For example:
 
@@ -354,10 +354,10 @@ process on Redis or external HTTP, not only the serialization process.
 
 > [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111046) in GitLab 15.10.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/application.log`
-- Installations from source: `/home/git/gitlab/log/application.log`
+- `/var/log/gitlab/gitlab-rails/application.log` on Linux package installations.
+- `/home/git/gitlab/log/application.log` on self-compiled installations.
 
 It contains a less structured version of the logs in
 [`application_json.log`](#application_jsonlog), like this example:
@@ -374,10 +374,10 @@ October 07, 2014 11:25: Project "project133" was removed
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/22812) in GitLab 12.7.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/application_json.log`
-- Installations from source: `/home/git/gitlab/log/application_json.log`
+- `/var/log/gitlab/gitlab-rails/application_json.log` on Linux package installations.
+- `/home/git/gitlab/log/application_json.log` on self-compiled installations.
 
 It helps you discover events happening in your instance such as user creation
 and project deletion. For example:
@@ -399,10 +399,10 @@ and project deletion. For example:
 
 ## `integrations_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/integrations_json.log`
-- Installations from source: `/home/git/gitlab/log/integrations_json.log`
+- `/var/log/gitlab/gitlab-rails/integrations_json.log` on Linux package installations.
+- `/home/git/gitlab/log/integrations_json.log` on self-compiled installations.
 
 It contains information about [integration](../../user/project/integrations/index.md)
 activities, such as Jira, Asana, and irker services. It uses JSON format,
@@ -434,19 +434,19 @@ like this example:
 
 > [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/kubernetes.log`
-- Installations from source: `/home/git/gitlab/log/kubernetes.log`
+- `/var/log/gitlab/gitlab-rails/kubernetes.log` on Linux package installations.
+- `/home/git/gitlab/log/kubernetes.log` on self-compiled installations.
 
 It logs information related to [certificate-based clusters](../../user/project/clusters/index.md), such as connectivity errors. Each line contains JSON that can be ingested by services like Elasticsearch and Splunk.
 
 ## `git_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/git_json.log`
-- Installations from source: `/home/git/gitlab/log/git_json.log`
+- `/var/log/gitlab/gitlab-rails/git_json.log` on Linux package installations.
+- `/home/git/gitlab/log/git_json.log` on self-compiled installations.
 
 After GitLab version 12.2, this file was renamed from `githost.log` to
 `git_json.log` and stored in JSON format.
@@ -472,10 +472,10 @@ NOTE:
 GitLab Free tracks a small number of different audit events.
 GitLab Premium tracks many more.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/audit_json.log`
-- Installations from source: `/home/git/gitlab/log/audit_json.log`
+- `/var/log/gitlab/gitlab-rails/audit_json.log` on Linux package installations.
+- `/home/git/gitlab/log/audit_json.log` on self-compiled installations.
 
 Changes to group or project settings and memberships (`target_details`)
 are logged to this file. For example:
@@ -499,18 +499,15 @@ are logged to this file. For example:
 
 ## Sidekiq logs
 
-NOTE:
-In Omnibus GitLab `12.10` or earlier, the Sidekiq log is at `/var/log/gitlab/gitlab-rails/sidekiq.log`.
-
-For Omnibus GitLab installations, some Sidekiq logs are in `/var/log/gitlab/sidekiq/current`
+For Linux package installations, some Sidekiq logs are in `/var/log/gitlab/sidekiq/current`
 and as follows.
 
 ### `sidekiq.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/sidekiq/current`
-- Installations from source: `/home/git/gitlab/log/sidekiq.log`
+- `/var/log/gitlab/sidekiq/current` on Linux package installations.
+- `/home/git/gitlab/log/sidekiq.log` on self-compiled installations.
 
 GitLab uses background jobs for processing tasks which can take a long
 time. All information about processing these jobs are written down to
@@ -549,7 +546,7 @@ Sidekiq. For example:
 }
 ```
 
-For Omnibus GitLab installations, add the configuration option:
+For Linux package installations, add the configuration option:
 
 ```ruby
 sidekiq['log_format'] = 'json'
@@ -568,10 +565,10 @@ For installations from source, edit the `gitlab.yml` and set the Sidekiq
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26586) in GitLab 12.9.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/sidekiq_client.log`
-- Installations from source: `/home/git/gitlab/log/sidekiq_client.log`
+- `/var/log/gitlab/gitlab-rails/sidekiq_client.log` on Linux package installations.
+- `/home/git/gitlab/log/sidekiq_client.log` on self-compiled installations.
 
 This file contains logging information about jobs before Sidekiq starts
 processing them, such as before being enqueued.
@@ -585,8 +582,6 @@ you've configured this for Sidekiq as mentioned above.
 GitLab Shell is used by GitLab for executing Git commands and provide SSH
 access to Git repositories.
 
-### For GitLab versions 12.10 and up
-
 Information containing `git-{upload-pack,receive-pack}` requests is at
 `/var/log/gitlab/gitlab-shell/gitlab-shell.log`. Information about hooks to
 GitLab Shell from Gitaly is at `/var/log/gitlab/gitaly/current`.
@@ -640,55 +635,18 @@ Example log entries for `/var/log/gitlab/gitaly/current`:
 }
 ```
 
-### For GitLab versions 12.5 through 12.9
-
-For GitLab 12.5 to 12.9, depending on your installation method, this
-file is located at:
-
-- Omnibus GitLab: `/var/log/gitlab/gitaly/gitlab-shell.log`
-- Installation from source: `/home/git/gitaly/gitlab-shell.log`
-
-Example log entries:
-
-```json
-{
-  "method": "POST",
-  "url": "http://127.0.0.1:8080/api/v4/internal/post_receive",
-  "duration": 0.031809164,
-  "gitaly_embedded": true,
-  "pid": 27056,
-  "level": "info",
-  "msg": "finished HTTP request",
-  "time": "2020-04-17T16:24:38+00:00"
-}
-```
-
-### For GitLab 12.5 and earlier
-
-For GitLab 12.5 and earlier, the file is at `/var/log/gitlab/gitlab-shell/gitlab-shell.log`.
-
-Example log entries:
-
-```plaintext
-I, [2015-02-13T06:17:00.671315 #9291]  INFO -- : Adding project root/example.git at </var/opt/gitlab/git-data/repositories/root/dcdcdcdcd.git>.
-I, [2015-02-13T06:17:00.679433 #9291]  INFO -- : Moving existing hooks directory and symlinking global hooks directory for /var/opt/gitlab/git-data/repositories/root/example.git.
-```
-
-User clone/fetch activity using SSH transport appears in this log as
-`executing git command <gitaly-upload-pack...`.
-
 ## Gitaly logs
 
 This file is in `/var/log/gitlab/gitaly/current` and is produced by [runit](http://smarden.org/runit/).
-`runit` is packaged with Omnibus GitLab and a brief explanation of its purpose
-is available [in the Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/architecture/#runit).
+`runit` is packaged with the Linux package and a brief explanation of its purpose
+is available [in the Linux package documentation](https://docs.gitlab.com/omnibus/architecture/#runit).
 [Log files are rotated](http://smarden.org/runit/svlogd.8.html), renamed in
 Unix timestamp format, and `gzip`-compressed (like `@1584057562.s`).
 
 ### `grpc.log`
 
-This file is at `/var/log/gitlab/gitlab-rails/grpc.log` for Omnibus GitLab
-packages. Native [gRPC](https://grpc.io/) logging used by Gitaly.
+This file is at `/var/log/gitlab/gitlab-rails/grpc.log` for Linux
+package installations. Native [gRPC](https://grpc.io/) logging used by Gitaly.
 
 ### `gitaly_hooks.log`
 
@@ -700,34 +658,34 @@ failures received during processing of the responses from GitLab API.
 
 ### `puma_stdout.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/puma/puma_stdout.log`
-- Installations from source: `/home/git/gitlab/log/puma_stdout.log`
+- `/var/log/gitlab/puma/puma_stdout.log` on Linux package installations.
+- `/home/git/gitlab/log/puma_stdout.log` on self-compiled installations.
 
 ### `puma_stderr.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/puma/puma_stderr.log`
-- Installations from source: `/home/git/gitlab/log/puma_stderr.log`
+- `/var/log/gitlab/puma/puma_stderr.log` on Linux package installations.
+- `/home/git/gitlab/log/puma_stderr.log` on self-compiled installations.
 
 ## `repocheck.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/repocheck.log`
-- Installations from source: `/home/git/gitlab/log/repocheck.log`
+- `/var/log/gitlab/gitlab-rails/repocheck.log` on Linux package installations.
+- `/home/git/gitlab/log/repocheck.log` on self-compiled installations.
 
 It logs information whenever a [repository check is run](../repository_checks.md)
 on a project.
 
 ## `importer.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/importer.log`
-- Installations from source: `/home/git/gitlab/log/importer.log`
+- `/var/log/gitlab/gitlab-rails/importer.log` on Linux package installations.
+- `/home/git/gitlab/log/importer.log` on self-compiled installations.
 
 This file logs the progress of [project imports and migrations](../../user/project/import/index.md).
 
@@ -735,10 +693,10 @@ This file logs the progress of [project imports and migrations](../../user/proje
 
 > Introduced in GitLab 13.1.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/exporter.log`
-- Installations from source: `/home/git/gitlab/log/exporter.log`
+- `/var/log/gitlab/gitlab-rails/exporter.log` on Linux package installations.
+- `/home/git/gitlab/log/exporter.log` on self-compiled installations.
 
 It logs the progress of the export process.
 
@@ -746,10 +704,10 @@ It logs the progress of the export process.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/59587) in GitLab 13.7.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/features_json.log`
-- Installations from source: `/home/git/gitlab/log/features_json.log`
+- `/var/log/gitlab/gitlab-rails/features_json.log` on Linux package installations.
+- `/home/git/gitlab/log/features_json.log` on self-compiled installations.
 
 The modification events from [Feature flags in development of GitLab](../../development/feature_flags/index.md)
 are recorded in this file. For example:
@@ -771,10 +729,10 @@ are recorded in this file. For example:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/384180) in GitLab 15.9.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/ci_resource_group_json.log`
-- Installations from source: `/home/git/gitlab/log/ci_resource_group_json.log`
+- `/var/log/gitlab/gitlab-rails/ci_resource_group_json.log` on Linux package installations.
+- `/home/git/gitlab/log/ci_resource_group_json.log` on self-compiled installations.
 
 It contains information about [resource group](../../ci/resource_groups/index.md) acquisition. For example:
 
@@ -789,10 +747,10 @@ The examples show the `resource_group_id`, `processable_id`, `message`, and `suc
 
 > Introduced in GitLab 12.0.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/auth.log`
-- Installations from source: `/home/git/gitlab/log/auth.log`
+- `/var/log/gitlab/gitlab-rails/auth.log` on Linux package installations.
+- `/home/git/gitlab/log/auth.log` on self-compiled installations.
 
 This log records:
 
@@ -803,10 +761,10 @@ This log records:
 
 ## `auth_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/auth_json.log`
-- Installations from source: `/home/git/gitlab/log/auth_json.log`
+- `/var/log/gitlab/gitlab-rails/auth_json.log` on Linux package installations.
+- `/home/git/gitlab/log/auth_json.log` on self-compiled installations.
 
 This file contains the JSON version of the logs in `auth.log`, for example:
 
@@ -827,10 +785,10 @@ This file contains the JSON version of the logs in `auth.log`, for example:
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/59587) in GitLab 12.0.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/graphql_json.log`
-- Installations from source: `/home/git/gitlab/log/graphql_json.log`
+- `/var/log/gitlab/gitlab-rails/graphql_json.log` on Linux package installations.
+- `/home/git/gitlab/log/graphql_json.log` on self-compiled installations.
 
 GraphQL queries are recorded in the file. For example:
 
@@ -842,10 +800,10 @@ GraphQL queries are recorded in the file. For example:
 
 > Introduced in GitLab 12.3.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/migrations.log`
-- Installations from source: `/home/git/gitlab/log/migrations.log`
+- `/var/log/gitlab/gitlab-rails/migrations.log` on Linux package installations.
+- `/home/git/gitlab/log/migrations.log` on self-compiled installations.
 
 This file logs the progress of [database migrations](../raketasks/maintenance.md#display-status-of-database-migrations).
 
@@ -853,19 +811,19 @@ This file logs the progress of [database migrations](../raketasks/maintenance.md
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/19186) in GitLab 12.6.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/mailroom/current`
-- Installations from source: `/home/git/gitlab/log/mail_room_json.log`
+- `/var/log/gitlab/mailroom/current` on Linux package installations.
+- `/home/git/gitlab/log/mail_room_json.log` on self-compiled installations.
 
 This structured log file records internal activity in the `mail_room` gem.
 Its name and path are configurable, so the name and path may not match the above.
 
 ## Reconfigure logs
 
-Reconfigure log files are in `/var/log/gitlab/reconfigure` for Omnibus GitLab
-packages. Installations from source don't have reconfigure logs. A reconfigure log
-is populated whenever `gitlab-ctl reconfigure` is run manually or as part of an upgrade.
+Reconfigure log files are in `/var/log/gitlab/reconfigure` for Linux package installations. Self-compiled installations
+don't have reconfigure logs. A reconfigure log is populated whenever `gitlab-ctl reconfigure` is run manually or as part
+of an upgrade.
 
 Reconfigure logs files are named according to the UNIX timestamp of when the reconfigure
 was initiated, such as `1509705644.log`
@@ -875,34 +833,32 @@ was initiated, such as `1509705644.log`
 If Prometheus metrics and the Sidekiq Exporter are both enabled, Sidekiq
 starts a Web server and listen to the defined port (default:
 `8082`). By default, Sidekiq Exporter access logs are disabled but can
-be enabled based on your installation method:
+be enabled:
 
-- Omnibus GitLab: Use the `sidekiq['exporter_log_enabled'] = true`
-  option in `/etc/gitlab/gitlab.rb`
-- Installations from source: Use the `sidekiq_exporter.log_enabled` option
-  in `gitlab.yml`
+- Use the `sidekiq['exporter_log_enabled'] = true` option in `/etc/gitlab/gitlab.rb` on Linux package installations.
+- Use the `sidekiq_exporter.log_enabled` option in `gitlab.yml` on self-compiled installations.
 
 When enabled, depending on your installation method, this file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/sidekiq_exporter.log`
-- Installations from source: `/home/git/gitlab/log/sidekiq_exporter.log`
+- `/var/log/gitlab/gitlab-rails/sidekiq_exporter.log` on Linux package installations.
+- `/home/git/gitlab/log/sidekiq_exporter.log` on self-compiled installations.
 
 If Prometheus metrics and the Web Exporter are both enabled, Puma
 starts a Web server and listen to the defined port (default: `8083`), and access logs
 are generated in a location based on your installation method:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/web_exporter.log`
-- Installations from source: `/home/git/gitlab/log/web_exporter.log`
+- `/var/log/gitlab/gitlab-rails/web_exporter.log` on Linux package installations.
+- `/home/git/gitlab/log/web_exporter.log` on self-compiled installations.
 
 ## `database_load_balancing.log` **(PREMIUM SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/15442) in GitLab 12.3.
 
 Contains details of GitLab [Database Load Balancing](../postgresql/database_load_balancing.md).
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/database_load_balancing.log`
-- Installations from source: `/home/git/gitlab/log/database_load_balancing.log`
+- `/var/log/gitlab/gitlab-rails/database_load_balancing.log` on Linux package installations.
+- `/home/git/gitlab/log/database_load_balancing.log` on self-compiled installations.
 
 ## `zoekt.log` **(PREMIUM SELF)**
 
@@ -912,21 +868,20 @@ This file logs information related to the
 [Exact code search](../../user/search/exact_code_search.md) feature which is
 powered by Zoekt.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/zoekt.log`
-- Installations from source: `/home/git/gitlab/log/zoekt.log`
+- `/var/log/gitlab/gitlab-rails/zoekt.log` on Linux package installations.
+- `/home/git/gitlab/log/zoekt.log` on self-compiled installations.
 
 ## `elasticsearch.log` **(PREMIUM SELF)**
 
 > Introduced in GitLab 12.6.
 
 This file logs information related to the Elasticsearch Integration, including
-errors during indexing or searching Elasticsearch. Depending on your installation
-method, this file is located at:
+errors during indexing or searching Elasticsearch. This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/elasticsearch.log`
-- Installations from source: `/home/git/gitlab/log/elasticsearch.log`
+- `/var/log/gitlab/gitlab-rails/elasticsearch.log` on Linux package installations.
+- `/home/git/gitlab/log/elasticsearch.log` on self-compiled installations.
 
 Each line contains JSON that can be ingested by services like Elasticsearch and Splunk.
 Line breaks have been added to the following example line for clarity:
@@ -952,10 +907,10 @@ Line breaks have been added to the following example line for clarity:
 This file logs the information about exceptions being tracked by
 `Gitlab::ErrorTracking`, which provides a standard and consistent way of
 [processing rescued exceptions](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/logging.md#exception-handling).
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/exceptions_json.log`
-- Installations from source: `/home/git/gitlab/log/exceptions_json.log`
+- `/var/log/gitlab/gitlab-rails/exceptions_json.log` on Linux package installations.
+- `/home/git/gitlab/log/exceptions_json.log` on self-compiled installations.
 
 Each line contains JSON that can be ingested by Elasticsearch. For example:
 
@@ -980,10 +935,10 @@ Each line contains JSON that can be ingested by Elasticsearch. For example:
 
 > Introduced in GitLab 13.0.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/service_measurement.log`
-- Installations from source: `/home/git/gitlab/log/service_measurement.log`
+- `/var/log/gitlab/gitlab-rails/service_measurement.log` on Linux package installations.
+- `/home/git/gitlab/log/service_measurement.log` on self-compiled installations.
 
 It contains only a single structured log with measurements for each service execution.
 It contains measurements such as the number of SQL calls, `execution_time`, `gc_stats`, and `memory usage`.
@@ -1013,10 +968,10 @@ This message shows that Geo detected that a repository update was needed for pro
 
 ## `update_mirror_service_json.log`
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/update_mirror_service_json.log`
-- Installations from source: `/home/git/gitlab/log/update_mirror_service_json.log`
+- `/var/log/gitlab/gitlab-rails/update_mirror_service_json.log` on Linux package installations.
+- `/home/git/gitlab/log/update_mirror_service_json.log` on self-compiled installations.
 
 This file contains information about LFS errors that occurred during project mirroring.
 While we work to move other project mirroring errors into this log, the [general log](#productionlog)
@@ -1041,18 +996,18 @@ can be used.
 The `llm.log` file logs information related to
 [AI features](../../user/ai_features.md).
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/llm.log`
-- Installations from source: `/home/git/gitlab/log/llm.log`
+- `/var/log/gitlab/gitlab-rails/llm.log` on Linux package installations.
+- `/home/git/gitlab/log/llm.log` on self-compiled installations.
 
 ## Registry logs
 
-For Omnibus GitLab installations, Container Registry logs are in `/var/log/gitlab/registry/current`.
+For Linux package installations, Container Registry logs are in `/var/log/gitlab/registry/current`.
 
 ## NGINX logs
 
-For Omnibus GitLab installations, NGINX logs are in:
+For Linux package installations, NGINX logs are in:
 
 - `/var/log/gitlab/nginx/gitlab_access.log`: A log of requests made to GitLab
 - `/var/log/gitlab/nginx/gitlab_error.log`: A log of NGINX errors for GitLab
@@ -1075,7 +1030,7 @@ for sensitive query string parameters such as secret tokens.
 
 ## Pages logs
 
-For Omnibus GitLab installations, Pages logs are in `/var/log/gitlab/gitlab-pages/current`.
+For Linux package installations, Pages logs are in `/var/log/gitlab/gitlab-pages/current`.
 
 For example:
 
@@ -1104,67 +1059,67 @@ For example:
 
 ## Mattermost logs
 
-For Omnibus GitLab installations, Mattermost logs are in these locations:
+For Linux package installations, Mattermost logs are in these locations:
 
 - `/var/log/gitlab/mattermost/mattermost.log`
 - `/var/log/gitlab/mattermost/current`
 
 ## Workhorse logs
 
-For Omnibus GitLab installations, Workhorse logs are in `/var/log/gitlab/gitlab-workhorse/current`.
+For Linux package installations, Workhorse logs are in `/var/log/gitlab/gitlab-workhorse/current`.
 
 ## PgBouncer logs
 
-For Omnibus GitLab installations, PgBouncer logs are in `/var/log/gitlab/pgbouncer/current`.
+For Linux package installations, PgBouncer logs are in `/var/log/gitlab/pgbouncer/current`.
 
 ## PostgreSQL logs
 
-For Omnibus GitLab installations, PostgreSQL logs are in `/var/log/gitlab/postgresql/current`.
+For Linux package installations, PostgreSQL logs are in `/var/log/gitlab/postgresql/current`.
 
 ## Prometheus logs
 
-For Omnibus GitLab installations, Prometheus logs are in `/var/log/gitlab/prometheus/current`.
+For Linux package installations, Prometheus logs are in `/var/log/gitlab/prometheus/current`.
 
 ## Redis logs
 
-For Omnibus GitLab installations, Redis logs are in `/var/log/gitlab/redis/current`.
+For Linux package installations, Redis logs are in `/var/log/gitlab/redis/current`.
 
 ## Alertmanager logs
 
-For Omnibus GitLab installations, Alertmanager logs are in `/var/log/gitlab/alertmanager/current`.
+For Linux package installations, Alertmanager logs are in `/var/log/gitlab/alertmanager/current`.
 
 <!-- vale gitlab.Spelling = NO -->
 
 ## crond logs
 
-For Omnibus GitLab installations, crond logs are in `/var/log/gitlab/crond/`.
+For Linux package installations, crond logs are in `/var/log/gitlab/crond/`.
 
 <!-- vale gitlab.Spelling = YES -->
 
 ## Grafana logs
 
-For Omnibus GitLab installations, Grafana logs are in `/var/log/gitlab/grafana/current`.
+For Linux package installations, Grafana logs are in `/var/log/gitlab/grafana/current`.
 
 ## LogRotate logs
 
-For Omnibus GitLab installations, `logrotate` logs are in `/var/log/gitlab/logrotate/current`.
+For Linux package installations, `logrotate` logs are in `/var/log/gitlab/logrotate/current`.
 
 ## GitLab Monitor logs
 
-For Omnibus GitLab installations, GitLab Monitor logs are in `/var/log/gitlab/gitlab-monitor/`.
+For Linux package installations, GitLab Monitor logs are in `/var/log/gitlab/gitlab-monitor/`.
 
 ## GitLab Exporter
 
-For Omnibus GitLab installations, GitLab Exporter logs are in `/var/log/gitlab/gitlab-exporter/current`.
+For Linux package installations, GitLab Exporter logs are in `/var/log/gitlab/gitlab-exporter/current`.
 
 ## GitLab agent server
 
-For Omnibus GitLab installations, GitLab agent server logs are
+For Linux package installations, GitLab agent server logs are
 in `/var/log/gitlab/gitlab-kas/current`.
 
 ## Praefect logs
 
-For Omnibus GitLab installations, Praefect logs are in `/var/log/gitlab/praefect/`.
+For Linux package installations, Praefect logs are in `/var/log/gitlab/praefect/`.
 
 GitLab also tracks [Prometheus metrics for Praefect](../gitaly/monitoring.md#monitor-gitaly-cluster).
 
@@ -1180,10 +1135,10 @@ This log is populated when a [GitLab backup is created](../../raketasks/backup_r
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48149) in GitLab 13.7.
 
-Depending on your installation method, this file is located at:
+This file is located at:
 
-- Omnibus GitLab: `/var/log/gitlab/gitlab-rails/performance_bar_json.log`
-- Installations from source: `/home/git/gitlab/log/performance_bar_json.log`
+- `/var/log/gitlab/gitlab-rails/performance_bar_json.log` on Linux package installations.
+- `/home/git/gitlab/log/performance_bar_json.log` on self-compiled installations.
 
 Performance bar statistics (currently only duration of SQL queries) are recorded
 in that file. For example:
diff --git a/doc/administration/logs/log_parsing.md b/doc/administration/logs/log_parsing.md
index d9520ea9bc0..21ce3d7f17f 100644
--- a/doc/administration/logs/log_parsing.md
+++ b/doc/administration/logs/log_parsing.md
@@ -24,7 +24,7 @@ include use cases targeted for parsing GitLab log files.
 ## Parsing Logs
 
 The examples listed below address their respective log files by
-their relative Omnibus paths and default filenames.
+their relative Linux package installation paths and default filenames.
 Find the respective full paths in the [GitLab logs sections](../logs/index.md#production_jsonlog).
 
 ### General Commands
diff --git a/doc/administration/server_hooks.md b/doc/administration/server_hooks.md
index 5bd52007bba..82360581504 100644
--- a/doc/administration/server_hooks.md
+++ b/doc/administration/server_hooks.md
@@ -38,7 +38,7 @@ alternatives to server hooks include:
 Prerequisites:
 
 - The [storage name](gitaly/configure_gitaly.md#gitlab-requires-a-default-repository-storage), path to the Gitaly configuration file
-  (default is `/var/opt/gitlab/gitaly/config.toml` on Omnibus GitLab instances), and the
+  (default is `/var/opt/gitlab/gitaly/config.toml` on Linux package instances), and the
   [repository relative path](repository_storage_types.md#from-project-name-to-hashed-path) for the repository.
 
 To set server hooks for a repository:
@@ -79,8 +79,8 @@ To create server hooks for a repository:
      [Translate hashed storage paths](repository_storage_types.md#translate-hashed-storage-paths) for information on
      interpreting the relative path.
    - If you are not using [hashed storage](repository_storage_types.md#hashed-storage):
-     - For Omnibus GitLab installations, the path is usually `/var/opt/gitlab/git-data/repositories/<group>/<project>.git`.
-     - For an installation from source, the path is usually `/home/git/repositories/<group>/<project>.git`.
+     - For Linux package installations, the path is usually `/var/opt/gitlab/git-data/repositories/<group>/<project>.git`.
+     - For self-compiled installations, the path is usually `/home/git/repositories/<group>/<project>.git`.
 1. On the file system, create a new directory in the correct location called `custom_hooks`.
 1. In the new `custom_hooks` directory:
    - To create a single server hook, create a file with a name that matches the hook type. For example, for a
@@ -129,7 +129,7 @@ To create a Git hook that applies to all repositories, set a global server hook.
 
 Before creating a global server hook, you must choose a directory for it.
 
-For Omnibus GitLab installations, the directory is set in `gitlab.rb` under `gitaly['configuration'][:hooks][:custom_hooks_dir]`. You can either:
+For Linux package installations, the directory is set in `gitlab.rb` under `gitaly['configuration'][:hooks][:custom_hooks_dir]`. You can either:
 
 - Use the default suggestion of the `/var/opt/gitlab/gitaly/custom_hooks` directory by uncommenting it.
 - Add your own setting.
diff --git a/doc/administration/smime_signing_email.md b/doc/administration/smime_signing_email.md
index 0620a68f1f4..5748c4d32d4 100644
--- a/doc/administration/smime_signing_email.md
+++ b/doc/administration/smime_signing_email.md
@@ -30,7 +30,7 @@ WARNING:
 Be mindful of the access levels for your private keys and visibility to
 third parties.
 
-**For Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and adapt the file paths:
 
@@ -46,7 +46,7 @@ third parties.
 
 The key must be readable by the GitLab system user (`git` by default).
 
-**For installations from source:**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml`:
 
diff --git a/doc/administration/terraform_state.md b/doc/administration/terraform_state.md
index 2da6916c313..84f596dacf2 100644
--- a/doc/administration/terraform_state.md
+++ b/doc/administration/terraform_state.md
@@ -13,7 +13,7 @@ files. The files are encrypted before being stored. This feature is enabled by d
 
 The storage location of these files defaults to:
 
-- `/var/opt/gitlab/gitlab-rails/shared/terraform_state` for Omnibus GitLab installations.
+- `/var/opt/gitlab/gitlab-rails/shared/terraform_state` for Linux package installations.
 - `/home/git/gitlab/shared/terraform_state` for source installations.
 
 These locations can be configured using the options described below.
@@ -40,7 +40,7 @@ Prerequisite:
 
 - You must be an administrator.
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -50,7 +50,7 @@ Prerequisite:
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) 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:
 
@@ -66,7 +66,7 @@ Prerequisite:
 The default configuration uses local storage. To change the location where
 Terraform state files are stored locally, follow the steps below.
 
-**In Omnibus installations:**
+For Linux package installations:
 
 1. To change the storage path for example to `/mnt/storage/terraform_state`, edit
    `/etc/gitlab/gitlab.rb` and add the following line:
@@ -77,7 +77,7 @@ Terraform state files are stored locally, follow the steps below.
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 1. To change the storage path for example to `/mnt/storage/terraform_state`, edit
    `/home/git/gitlab/config/gitlab.yml` and add or amend the following lines:
@@ -103,7 +103,7 @@ This configuration relies on valid credentials to be configured already.
 The following settings are:
 
 - Nested under `terraform_state:` and then `object_store:` on source installations.
-- Prefixed by `terraform_state_object_store_` on Omnibus GitLab installations.
+- Prefixed by `terraform_state_object_store_` on Linux package installations.
 
 | Setting | Description | Default |
 |---------|-------------|---------|
@@ -120,15 +120,15 @@ It's not possible to migrate Terraform state files from object storage back to l
 so proceed with caution. [An issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/350187)
 to change this behavior.
 
-To migrate Terraform state files to object storage, follow the instructions below.
+To migrate Terraform state files to object storage:
 
-- For Omnibus package installations:
+- For Linux package installations:
 
   ```shell
   gitlab-rake gitlab:terraform_states:migrate
   ```
 
-- For source installations:
+- For self-compiled installations:
 
   ```shell
   sudo -u git -H bundle exec rake gitlab:terraform_states:migrate RAILS_ENV=production
@@ -152,9 +152,9 @@ For GitLab 13.8 and earlier versions, you can use a workaround for the Rake task
 You can optionally track progress and verify that all Terraform state files migrated successfully using the
 [PostgreSQL console](https://docs.gitlab.com/omnibus/settings/database.html#connecting-to-the-bundled-postgresql-database):
 
-- `sudo gitlab-rails dbconsole` for Omnibus GitLab 14.1 and earlier.
-- `sudo gitlab-rails dbconsole --database main` for Omnibus GitLab 14.2 and later.
-- `sudo -u git -H psql -d gitlabhq_production` for source-installed instances.
+- `sudo gitlab-rails dbconsole` for Linux package installations running GitLab 14.1 and earlier.
+- `sudo gitlab-rails dbconsole --database main` for Linux package installations running GitLab 14.2 and later.
+- `sudo -u git -H psql -d gitlabhq_production` for self-compiled installations.
 
 Verify `objectstg` below (where `file_store=2`) has count of all states:
 
diff --git a/doc/administration/timezone.md b/doc/administration/timezone.md
index b0dc995c684..e0f70cecb43 100644
--- a/doc/administration/timezone.md
+++ b/doc/administration/timezone.md
@@ -18,12 +18,13 @@ Uncomment and customize if you want to change the default time zone of the GitLa
 
 To see all available time zones, run `bundle exec rake time:zones:all`.
 
-For Omnibus installations, run `gitlab-rake time:zones:all`.
+For Linux package installations, run `gitlab-rake time:zones:all`.
 
 NOTE:
-This Rake task does not list time zones in TZInfo format required by Omnibus GitLab during a reconfigure: [#27209](https://gitlab.com/gitlab-org/gitlab/-/issues/27209).
+This Rake task does not list time zones in TZInfo format required by a Linux package installation during a reconfigure. For more information,
+see [issue 27209](https://gitlab.com/gitlab-org/gitlab/-/issues/27209).
 
-## Changing time zone in Omnibus installations
+## Changing time zone in Linux package installations
 
 GitLab defaults its time zone to UTC. It has a global time zone configuration parameter in `/etc/gitlab/gitlab.rb`.
 
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index dd311ba26cb..99f19821916 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -23,7 +23,7 @@ For historical reasons, uploads for the whole instance (for example the [favicon
 which by default is `uploads/-/system`. Changing the base
 directory on an existing GitLab installation is strongly discouraged.
 
-**In Omnibus GitLab installations:**
+For Linux package installations:
 
 _The uploads are stored by default in `/var/opt/gitlab/gitlab-rails/uploads`._
 
@@ -38,7 +38,7 @@ _The uploads are stored by default in `/var/opt/gitlab/gitlab-rails/uploads`._
 
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
-**In installations from source:**
+For self-compiled installations:
 
 _The uploads are stored by default in
 `/home/git/gitlab/public/uploads`._
@@ -68,7 +68,8 @@ In GitLab 13.2 and later, you should use the
 [consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 This section describes the earlier configuration format.
 
-For source installations the following settings are nested under `uploads:` and then `object_store:`. On Omnibus GitLab installs they are prefixed by `uploads_object_store_`.
+For self-compiled installations, the following settings are nested under `uploads:` and then `object_store:`. On Linux
+package installations, they are prefixed by `uploads_object_store_`.
 
 | Setting | Description | Default |
 |---------|-------------|---------|
@@ -81,7 +82,7 @@ For source installations the following settings are nested under `uploads:` and
 
 See [the available connection settings for different providers](object_storage.md#configure-the-connection-settings).
 
-**In Omnibus installations:**
+For Linux package installations:
 
 _The uploads are stored by default in
 `/var/opt/gitlab/gitlab-rails/uploads`._
@@ -113,7 +114,7 @@ _The uploads are stored by default in
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Migrate any existing local uploads to the object storage with the [`gitlab:uploads:migrate:all` Rake task](raketasks/uploads/migrate.md).
 
-**In installations from source:**
+For self-compiled installations:
 
 _The uploads are stored by default in
 `/home/git/gitlab/public/uploads`._
diff --git a/doc/administration/user_settings.md b/doc/administration/user_settings.md
index 2df7f882223..c4b00d05f9d 100644
--- a/doc/administration/user_settings.md
+++ b/doc/administration/user_settings.md
@@ -18,9 +18,9 @@ ability to create top-level groups (does not affect existing users' setting), Gi
   - The [application setting API](../api/settings.md#change-application-settings).
 - In GitLab 15.4 and earlier, in a configuration file by following the steps in this section.
 
-To disable new users' ability to create top-level groups using the configuration file:
+To disable new users' ability to create top-level groups using the configuration file.
 
-**Omnibus GitLab installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -30,7 +30,7 @@ To disable new users' ability to create top-level groups using the configuration
 
 1. [Reconfigure and restart GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation).
 
-**Source installations**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml` and uncomment the following line:
 
@@ -50,9 +50,9 @@ Administrators can:
 ## Prevent users from changing their usernames
 
 By default, new users can change their usernames. To disable your users'
-ability to change their usernames:
+ability to change their usernames.
 
-**Omnibus GitLab installations**
+For Linux package installations:
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following line:
 
@@ -62,7 +62,7 @@ ability to change their usernames:
 
 1. [Reconfigure and restart GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation).
 
-**Source installations**
+For self-compiled installations:
 
 1. Edit `config/gitlab.yml` and uncomment the following line:
 
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 155b32e4a2a..9fffc3129f4 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -155,6 +155,21 @@ These three variables will be removed in GitLab 17.0.
 
 </div>
 
+<div class="deprecation breaking-change" data-milestone="17.0">
+
+### Deprecate Windows CMD in GitLab Runner
+
+<div class="deprecation-notes">
+- Announced in: GitLab <span class="milestone">16.1</span>
+- End of Support: GitLab <span class="milestone">17.0</span>
+- This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/414864).
+</div>
+
+In GitLab 11.11 the Windows Batch executor, the CMD shell was deprecated in GitLab Runner in favor of PowerShell. Since then, the CMD shell has continued to be supported in GitLab Runner. However this has resulted in additional complexity for both the engineering team and customers using the Runner on Windows. We plan to fully remove support for Windows CMD from GitLab Runner in 17.0. Customers should plan to use PowerShell when using the runner on Windows with the shell executor. Customers can provide feedback or ask questions in the removal issue, [issue 29479](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29479).
+
+</div>
+
 <div class="deprecation " data-milestone="17.0">
 
 ### Deprecate legacy shell escaping and quoting runner shell executor