Require Omnibus GitLab instead of GitLab Omnibus

- Adds new Vale substitution.
- Corrects existing errors.
- Fixes links to renamed section.

doc/.vale/gitlab/Substitutions.yml

@@ -10,6 +10,7 @@ level: error
 ignorecase: true
 swap:
   GitLabber: GitLab team member
+  gitlab omnibus: Omnibus GitLab
   param: parameter
   params: parameters
   postgres: PostgreSQL

doc/administration/external_database.md

@@ -5,7 +5,7 @@ managed service for PostgreSQL. For example, AWS offers a managed Relational
 Database Service (RDS) that runs PostgreSQL.
 
 Alternatively, you may opt to manage your own PostgreSQL instance or cluster
-separate from the GitLab Omnibus package.
+separate from the Omnibus GitLab package.
 
 If you use a cloud-managed service, or provide your own PostgreSQL instance:
 

doc/administration/geo/replication/database.md

@@ -461,7 +461,7 @@ The replication process is now complete.
 PostgreSQL connections. We recommend using PgBouncer if you use GitLab in a
 high-availability configuration with a cluster of nodes supporting a Geo
 **primary** node and another cluster of nodes supporting a Geo **secondary** node. For more
-information, see [High Availability with GitLab Omnibus](../../high_availability/database.md#high-availability-with-gitlab-omnibus-premium-only).
+information, see [High Availability with Omnibus GitLab](../../high_availability/database.md#high-availability-with-omnibus-gitlab-premium-only).
 
 For a Geo **secondary** node to work properly with PgBouncer in front of the database,
 it will need a separate read-only user to make [PostgreSQL FDW queries](https://www.postgresql.org/docs/9.6/postgres-fdw.html)

doc/administration/geo/replication/troubleshooting.md

@@ -854,7 +854,7 @@ Make sure you follow the [Geo database replication](database.md) instructions fo
 
 ### Geo database version (...) does not match latest migration (...)
 
-If you are using GitLab Omnibus installation, something might have failed during upgrade. You can:
+If you are using Omnibus GitLab installation, something might have failed during upgrade. You can:
 
 - Run `sudo gitlab-ctl reconfigure`.
 - Manually trigger the database migration by running: `sudo gitlab-rake geo:db:migrate` as root on the **secondary** node.

doc/administration/gitaly/praefect.md

@@ -55,7 +55,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 (PostgreSQL 9.6 or newer). Configuration through
-the GitLab Omnibus distribution is not yet supported. Follow this
+the Omnibus GitLab distribution is not yet supported. Follow this
 [issue](https://gitlab.com/gitlab-org/gitaly/issues/2476) for updates.
 
 Prepare all your new nodes by [installing
@@ -114,7 +114,7 @@ To complete this section you will need:
   - An SQL user with permissions to create databases
 
 During this section, we will configure the PostgreSQL server, from the Praefect
-node, using `psql` which is installed by GitLab Omnibus.
+node, using `psql` which is installed by Omnibus GitLab.
 
 1. SSH into the **Praefect** node and login as root:
 

doc/administration/high_availability/consul.md

@@ -7,14 +7,14 @@ type: reference
 As part of its High Availability stack, GitLab Premium includes a bundled version of [Consul](https://www.consul.io/) that can be managed through `/etc/gitlab/gitlab.rb`. Consul is a service networking solution. When it comes to [GitLab Architecture](../../development/architecture.md), Consul utilization is supported for configuring:
 
 1. [Monitoring in Scaled and Highly Available environments](monitoring_node.md)
-1. [PostgreSQL High Availability with Omnibus](database.md#high-availability-with-gitlab-omnibus-premium-only)
+1. [PostgreSQL High Availability with Omnibus](database.md#high-availability-with-omnibus-gitlab-premium-only)
 
 A Consul cluster consists of multiple server agents, as well as client agents that run on other nodes which need to talk to the Consul cluster.
 
 ## Prerequisites
 
 First, make sure to [download/install](https://about.gitlab.com/install/)
-GitLab Omnibus **on each node**.
+Omnibus GitLab **on each node**.
 
 Choose an installation method, then make sure you complete steps:
 
@@ -110,7 +110,7 @@ For larger clusters, it is possible to restart multiple agents at a time. See th
 
 Nodes running GitLab-bundled Consul should be:
 
-- Members of a healthy cluster prior to upgrading the GitLab Omnibus package.
+- Members of a healthy cluster prior to upgrading the Omnibus GitLab package.
 - Upgraded one node at a time.
 
 NOTE: **NOTE:**

doc/administration/high_availability/database.md

@@ -30,10 +30,10 @@ This section is relevant for [Scalable and Highly Available Setups](../scaling/i
 
 If you want to use your own deployed PostgreSQL instance(s),
 see [Provide your own PostgreSQL instance](#provide-your-own-postgresql-instance-core-only)
-for more details. However, you can use the GitLab Omnibus package to easily
+for more details. However, you can use the Omnibus GitLab package to easily
 deploy the bundled PostgreSQL.
 
-### Standalone PostgreSQL using GitLab Omnibus **(CORE ONLY)**
+### Standalone PostgreSQL using Omnibus GitLab **(CORE ONLY)**
 
 1. SSH into the PostgreSQL server.
 1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
@@ -92,7 +92,7 @@ deploy the bundled PostgreSQL.
 Advanced configuration options are supported and can be added if
 needed.
 
-### High Availability with GitLab Omnibus **(PREMIUM ONLY)**
+### High Availability with Omnibus GitLab **(PREMIUM ONLY)**
 
 > Important notes:
 >
@@ -271,7 +271,7 @@ Few notes on the service itself:
 #### Installing Omnibus GitLab
 
 First, make sure to [download/install](https://about.gitlab.com/install/)
-GitLab Omnibus **on each node**.
+Omnibus GitLab **on each node**.
 
 Make sure you install the necessary dependencies from step 1,
 add GitLab package repository from step 2.
@@ -1091,7 +1091,7 @@ If you're running into an issue with a component not outlined here, be sure to c
 
 ## Configure using Omnibus
 
-**Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#high-availability-with-gitlab-omnibus-premium-only).
+**Note**: We recommend that you follow the instructions here for a full [PostgreSQL cluster](#high-availability-with-omnibus-gitlab-premium-only).
 If you are reading this section due to an old bookmark, you can find that old documentation [in the repository](https://gitlab.com/gitlab-org/gitlab/blob/v10.1.4/doc/administration/high_availability/database.md#configure-using-omnibus).
 
 Read more on high-availability configuration:

doc/administration/high_availability/gitlab.md

@@ -34,7 +34,7 @@ is recommended over [NFS](nfs.md) wherever possible for improved performance.
    mkdir -p /var/opt/gitlab/.ssh /var/opt/gitlab/gitlab-rails/uploads /var/opt/gitlab/gitlab-rails/shared /var/opt/gitlab/gitlab-ci/builds /var/opt/gitlab/git-data
    ```
 
-1. Download/install GitLab Omnibus using **steps 1 and 2** from
+1. Download/install Omnibus GitLab using **steps 1 and 2** from
    [GitLab downloads](https://about.gitlab.com/install/). Do not complete other
    steps on the download page.
 1. Create/edit `/etc/gitlab/gitlab.rb` and use the following configuration.

doc/administration/high_availability/monitoring_node.md

@@ -8,9 +8,9 @@ type: reference
 
 You can configure a Prometheus node to monitor GitLab.
 
-## Standalone Monitoring node using GitLab Omnibus
+## Standalone Monitoring node using Omnibus GitLab
 
-The GitLab Omnibus package can be used to configure a standalone Monitoring node running [Prometheus](../monitoring/prometheus/index.md) and [Grafana](../monitoring/performance/grafana_configuration.md).
+The Omnibus GitLab package can be used to configure a standalone Monitoring node running [Prometheus](../monitoring/prometheus/index.md) and [Grafana](../monitoring/performance/grafana_configuration.md).
 The monitoring node is not highly available. See [Scaling and High Availability](../scaling/index.md)
 for an overview of GitLab scaling and high availability options.
 

doc/administration/high_availability/nfs.md

@@ -271,7 +271,7 @@ following are the 4 locations need to be shared:
 
 Other GitLab directories should not be shared between nodes. They contain
 node-specific files and GitLab code that does not need to be shared. To ship
-logs to a central location consider using remote syslog. GitLab Omnibus packages
+logs to a central location consider using remote syslog. Omnibus GitLab packages
 provide configuration for [UDP log shipping](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-shipping-gitlab-enterprise-edition-only).
 
 Having multiple NFS mounts will require manually making sure the data directories

doc/administration/high_availability/redis.md

@@ -33,12 +33,12 @@ This section is relevant for [Scalable and Highly Available Setups](../scaling/i
 
 If you want to use your own deployed Redis instance(s),
 see [Provide your own Redis instance](#provide-your-own-redis-instance-core-only)
-for more details. However, you can use the GitLab Omnibus package to easily
+for more details. However, you can use the Omnibus GitLab package to easily
 deploy the bundled Redis.
 
-### Standalone Redis using GitLab Omnibus **(CORE ONLY)**
+### Standalone Redis using Omnibus GitLab **(CORE ONLY)**
 
-The GitLab Omnibus package can be used to configure a standalone Redis server.
+The Omnibus GitLab package can be used to configure a standalone Redis server.
 In this configuration Redis is not highly available, and represents a single
 point of failure. However, in a scaled environment the objective is to allow
 the environment to handle more users or to increase throughput. Redis itself
@@ -91,7 +91,7 @@ needed.
 Continue configuration of other components by going back to the
 [Scaling](../scaling/index.md#components-provided-by-omnibus-gitlab) page.
 
-### High Availability with GitLab Omnibus **(PREMIUM ONLY)**
+### High Availability with Omnibus GitLab **(PREMIUM ONLY)**
 
 > Experimental Redis Sentinel support was [introduced in GitLab 8.11](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/1877).
 Starting with 8.14, Redis Sentinel is no longer experimental.

doc/administration/monitoring/performance/grafana_configuration.md

@@ -15,7 +15,7 @@ services.
 
 ## Installation
 
-[GitLab Omnibus can help you install Grafana (recommended)](https://docs.gitlab.com/omnibus/settings/grafana.html)
+[Omnibus GitLab can help you install Grafana (recommended)](https://docs.gitlab.com/omnibus/settings/grafana.html)
 or Grafana supplies package repositories (Yum/Apt) for easy installation.
 See [Grafana installation documentation](https://grafana.com/docs/grafana/latest/installation/)
 for detailed steps.

doc/administration/monitoring/prometheus/index.md

@@ -49,7 +49,7 @@ To disable Prometheus and all of its exporters, as well as any added in the futu
 ### Changing the port and address Prometheus listens on
 
 NOTE: **Note:**
-The following change was added in [GitLab Omnibus 8.17](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/1261). Although possible,
+The following change was added in [Omnibus GitLab 8.17](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/1261). Although possible,
 it's not recommended to change the port Prometheus listens
 on, as this might affect or conflict with other services running on the GitLab
 server. Proceed at your own risk.
@@ -80,7 +80,7 @@ To change the address/port that Prometheus listens on:
 
 ### Adding custom scrape configs
 
-You can configure additional scrape targets for the GitLab Omnibus-bundled
+You can configure additional scrape targets for the Omnibus GitLab-bundled
 Prometheus by editing `prometheus['scrape_configs']` in `/etc/gitlab/gitlab.rb`
 using the [Prometheus scrape target configuration](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#%3Cscrape_config%3E)
 syntax.

doc/administration/pages/index.md

@@ -352,7 +352,7 @@ This usually results in this error:
 For installation from source this can be fixed by installing the custom Certificate
 Authority (CA) in the system certificate store.
 
-For Omnibus, normally this would be fixed by [installing a custom CA in GitLab Omnibus](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates)
+For Omnibus, normally this would be fixed by [installing a custom CA in Omnibus GitLab](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates)
 but a [bug](https://gitlab.com/gitlab-org/gitlab/issues/25411) is currently preventing
 that method from working. Use the following workaround:
 
@@ -363,14 +363,14 @@ that method from working. Use the following workaround:
    echo -n | openssl s_client -connect gitlab-domain-example.com:443  | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
    ```
 
-1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances:
+1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For Omnibus GitLab instances:
 
    ```shell
    sudo gitlab-ctl restart gitlab-pages
    ```
 
 CAUTION: **Caution:**
-Some GitLab Omnibus upgrades will revert this workaround and you'll need to apply it again.
+Some Omnibus GitLab upgrades will revert this workaround and you'll need to apply it again.
 
 ## Activate verbose logging for daemon
 

doc/administration/timezone.md

@@ -15,7 +15,7 @@ To see all available time zones, run `bundle exec rake time:zones:all`.
 For Omnibus installations, run `gitlab-rake time:zones:all`.
 
 NOTE: **Note:**
-Currently, this Rake task does not list timezones in TZInfo format required by GitLab Omnibus during a reconfigure: [#58672](https://gitlab.com/gitlab-org/gitlab-foss/issues/58672).
+Currently, this Rake task does not list timezones in TZInfo format required by Omnibus GitLab during a reconfigure: [#58672](https://gitlab.com/gitlab-org/gitlab-foss/issues/58672).
 
 ## Changing time zone in Omnibus installations
 

doc/development/contributing/merge_request_workflow.md

@@ -17,7 +17,7 @@ wireframes of the proposed feature if it will also change the UI.
 Merge requests should be submitted to the appropriate project at GitLab.com, for example
 [GitLab](https://gitlab.com/gitlab-org/gitlab/-/merge_requests),
 [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests),
-[GitLab Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests), etc.
+[Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests), etc.
 
 If you are new to GitLab development (or web development in general), see the
 [I want to contribute!](index.md#i-want-to-contribute) section to get started with

doc/development/testing_guide/testing_levels.md

@@ -467,7 +467,7 @@ Formal definitions:
 
 GitLab consists of [multiple pieces](../architecture.md#components) such as [GitLab Shell](https://gitlab.com/gitlab-org/gitlab-shell), [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse),
 [Gitaly](https://gitlab.com/gitlab-org/gitaly), [GitLab Pages](https://gitlab.com/gitlab-org/gitlab-pages), [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner), and GitLab Rails. All theses pieces
-are configured and packaged by [GitLab Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab).
+are configured and packaged by [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab).
 
 The QA framework and instance-level scenarios are [part of GitLab Rails](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/qa) so that
 they're always in-sync with the codebase (especially the views).

doc/install/README.md

@@ -66,7 +66,7 @@ GitLab maintains a set of official Docker images based on the Omnibus GitLab pac
 
 ## Installing GitLab from source
 
-If the GitLab Omnibus package is not available in your distribution, you can
+If the Omnibus GitLab package is not available in your distribution, you can
 install GitLab from source: Useful for unsupported systems like *BSD. For an
 overview of the directory structure, read the [structure documentation](structure.md).
 

doc/integration/README.md

@@ -83,7 +83,7 @@ at Super User also has relevant information.
 **Omnibus Trusted Chain**
 
 [Install the self signed certificate or custom certificate authorities](https://docs.gitlab.com/omnibus/common_installation_problems/README.html#using-self-signed-certificate-or-custom-certificate-authorities)
-in to GitLab Omnibus.
+in to Omnibus GitLab.
 
 It is enough to concatenate the certificate to the main trusted certificate
 however it may be overwritten during upgrades:

doc/integration/elasticsearch.md

@@ -48,12 +48,12 @@ For indexing Git repository data, GitLab uses an [indexer written in Go](https:/
 
 The way you install the Go indexer depends on your version of GitLab:
 
-- For GitLab Omnibus 11.8 and above, see [GitLab Omnibus](#gitlab-omnibus).
-- For installations from source or older versions of GitLab Omnibus, install the indexer [From Source](#from-source).
+- For Omnibus GitLab 11.8 and above, see [Omnibus GitLab](#omnibus-gitlab).
+- For installations from source or older versions of Omnibus GitLab, install the indexer [From Source](#from-source).
 
-### GitLab Omnibus
+### Omnibus GitLab
 
-Since GitLab 11.8 the Go indexer is included in GitLab Omnibus.
+Since GitLab 11.8 the Go indexer is included in Omnibus GitLab.
 The former Ruby-based indexer was removed in [GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/issues/6481).
 
 ### From source

doc/integration/recaptcha.md

@@ -27,7 +27,7 @@ configuration variable:
 proxy_set_header X-GitLab-Show-Login-Captcha 1;
 ```
 
-In GitLab Omnibus, this can be configured via `/etc/gitlab/gitlab.rb`:
+In Omnibus GitLab, this can be configured via `/etc/gitlab/gitlab.rb`:
 
 ```ruby
 nginx['proxy_set_headers'] = { 'X-GitLab-Show-Login-Captcha' => 1 }