From bdac46cc9a0980d07172528f39e412d190f04719 Mon Sep 17 00:00:00 2001
From: Evan Read <eread@gitlab.com>
Date: Mon, 12 Jun 2023 09:26:09 +0000
Subject: [PATCH] Update Geo admin docs to use new install types terminology
---
doc/administration/auth/oidc.md | 2 +-
doc/administration/consul.md | 2 +-
.../geo/disaster_recovery/index.md | 3 +-
.../runbooks/planned_failover_multi_node.md | 12 ++--
.../runbooks/planned_failover_single_node.md | 12 ++--
doc/administration/geo/index.md | 9 +--
.../geo/replication/configuration.md | 2 +-
.../geo/replication/disable_geo.md | 2 +-
.../geo/replication/geo_validation_tests.md | 2 +-
.../geo/replication/multiple_servers.md | 4 +-
.../geo/replication/security_review.md | 6 +-
.../geo/replication/troubleshooting.md | 18 +++---
.../replication/version_specific_upgrades.md | 56 +++++++++----------
.../geo/secondary_proxy/index.md | 3 +-
doc/administration/geo/setup/database.md | 45 ++++++++-------
.../geo/setup/external_database.md | 18 +++---
doc/administration/geo/setup/index.md | 4 +-
doc/administration/get_started.md | 2 +-
.../reference_architectures/index.md | 31 +++++-----
.../service_ping/troubleshooting.md | 2 +-
doc/install/aws/manual_install_aws.md | 18 +++---
doc/install/docker.md | 2 +-
doc/install/google_cloud_platform/index.md | 8 +--
doc/install/requirements.md | 4 +-
doc/integration/mattermost/index.md | 30 +++++-----
doc/policy/maintenance.md | 6 +-
26 files changed, 153 insertions(+), 150 deletions(-)
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index 88c9a66944134..620bf1fa8c4db 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -197,7 +197,7 @@ by the client. You are redirected to GitLab and signed in.
## Example configurations
The following configurations illustrate how to set up OpenID with
-different providers when using the GitLab Linux package installation.
+different providers when using the Linux package installation.
### Configure Google
diff --git a/doc/administration/consul.md b/doc/administration/consul.md
index 3257c197445dc..c5b1cc0ed2a3d 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 GitLab Linux package.
+- Members of a healthy cluster prior to upgrading the 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/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index 24a91a7a9c58a..4757c730c7bfc 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -681,7 +681,8 @@ Data that was created on the primary while the secondary was paused is lost.
If you are running GitLab 14.5 and later:
-1. For each node outside of the **secondary** Kubernetes cluster using Omnibus such as PostgreSQL or Gitaly, SSH into the node and run one of the following commands:
+1. For each node (such as PostgreSQL or Gitaly) outside of the **secondary** Kubernetes cluster using the Linux
+ package, SSH into the node and run one of the following commands:
- To promote the **secondary** site node external to the Kubernetes cluster to primary:
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
index 501227f254a82..22637ad84bca4 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_multi_node.md
@@ -13,11 +13,11 @@ This runbook is an [Experiment](../../../../policy/experiment-beta-support.md#ex
## Geo planned failover for a multi-node configuration
-| Component | Configuration |
-|-------------|-----------------|
-| PostgreSQL | Omnibus-managed |
-| Geo site | Multi-node |
-| Secondaries | One |
+| Component | Configuration |
+|:------------|:-----------------------------|
+| PostgreSQL | Managed by the Linux package |
+| Geo site | Multi-node |
+| Secondaries | One |
This runbook guides you through a planned failover of a multi-node Geo site
with one secondary. The following [2000 user reference architecture](../../../../administration/reference_architectures/2k_users.md) is assumed:
@@ -205,7 +205,7 @@ follow these steps to avoid unnecessary data loss:
NOTE:
(**CentOS only**) In CentOS 6 or older, it is challenging to prevent GitLab from being
- started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
+ started if the machine reboots isn't available (see [issue 3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
NOTE:
diff --git a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
index 18d5aa4d130b6..ecece40f85aa9 100644
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
@@ -13,11 +13,11 @@ This runbook is an [Experiment](../../../../policy/experiment-beta-support.md#ex
## Geo planned failover for a single-node configuration
-| Component | Configuration |
-|-------------|-----------------|
-| PostgreSQL | Omnibus-managed |
-| Geo site | Single-node |
-| Secondaries | One |
+| Component | Configuration |
+|:------------|:-----------------------------|
+| PostgreSQL | Managed by the Linux package |
+| Geo site | Single-node |
+| Secondaries | One |
This runbook guides you through a planned failover of a single-node Geo site
with one secondary. The following general architecture is assumed:
@@ -190,7 +190,7 @@ follow these steps to avoid unnecessary data loss:
NOTE:
(**CentOS only**) In CentOS 6 or older, there is no easy way to prevent GitLab from being
- started if the machine reboots isn't available (see [Omnibus GitLab issue #3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
+ started if the machine reboots isn't available (see [issue 3058](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/3058)).
It may be safest to uninstall the GitLab package completely with `sudo yum remove gitlab-ee`.
NOTE:
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index da00ddc5cfbc6..e29ebb1bb64ff 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -246,10 +246,11 @@ secondary. If the site is paused, be sure to resume before promoting. This
issue has been fixed in GitLab 13.4 and later.
WARNING:
-Pausing and resuming of replication is only supported for Geo installations using an
-Omnibus GitLab-managed database. External databases are not supported.
+Pausing and resuming of replication is only supported for Geo installations using a
+Linux package-managed database. External databases are not supported.
-In some circumstances, like during [upgrades](replication/upgrading_the_geo_sites.md) or a [planned failover](disaster_recovery/planned_failover.md), it is desirable to pause replication between the primary and secondary.
+In some circumstances, like during [upgrades](replication/upgrading_the_geo_sites.md) or a
+[planned failover](disaster_recovery/planned_failover.md), it is desirable to pause replication between the primary and secondary.
Pausing and resuming replication is done via a command line tool from the node in the secondary site where the `postgresql` service is enabled.
@@ -331,7 +332,7 @@ For answers to common questions, see the [Geo FAQ](replication/faq.md).
## Log files
-Geo stores structured log messages in a `geo.log` file. For Omnibus GitLab
+Geo stores structured log messages in a `geo.log` file. For Linux package
installations, this file is at `/var/log/gitlab/gitlab-rails/geo.log`.
This file contains information about when Geo attempts to sync repositories and files. Each line in the file contains a separate JSON entry that can be ingested into. For example, Elasticsearch or Splunk.
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index 5fa6df393b9ac..5aee9bc5b83e3 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -12,7 +12,7 @@ type: howto
NOTE:
This is the final step in setting up a **secondary** Geo site. Stages of the
setup process must be completed in the documented order.
-If not, [complete all prior stages](../setup/index.md#using-omnibus-gitlab) before proceeding.
+If not, [complete all prior stages](../setup/index.md#using-linux-package-installations) before proceeding.
Make sure you [set up the database replication](../setup/database.md), and [configured fast lookup of authorized SSH keys](../../operations/fast_ssh_key_lookup.md) in **both primary and secondary sites**.
diff --git a/doc/administration/geo/replication/disable_geo.md b/doc/administration/geo/replication/disable_geo.md
index c42130a62a7bf..bb47b8a352446 100644
--- a/doc/administration/geo/replication/disable_geo.md
+++ b/doc/administration/geo/replication/disable_geo.md
@@ -7,7 +7,7 @@ type: howto
# Disabling Geo **(PREMIUM SELF)**
-If you want to revert to a regular Omnibus setup after a test, or you have encountered a Disaster Recovery
+If you want to revert to a regular Linux package installation setup after a test, or you have encountered a Disaster Recovery
situation and you want to disable Geo momentarily, you can use these instructions to disable your
Geo setup.
diff --git a/doc/administration/geo/replication/geo_validation_tests.md b/doc/administration/geo/replication/geo_validation_tests.md
index 97c10b3ec0ada..7897635e78f6b 100644
--- a/doc/administration/geo/replication/geo_validation_tests.md
+++ b/doc/administration/geo/replication/geo_validation_tests.md
@@ -143,7 +143,7 @@ The following are PostgreSQL upgrade validation tests we performed.
we tested fresh installations of GitLab 13.3 with PostgreSQL 12 enabled and Geo installed.
- Outcome: Setting up a Geo secondary required manual intervention because the `recovery.conf` file
is no longer supported in PostgreSQL 12. We do not recommend deploying Geo with PostgreSQL 12 until
- the appropriate changes have been made to Omnibus and verified.
+ the appropriate changes have been made to the Linux package and verified.
- Follow up issues:
- [Update `replicate-geo-database` to support PostgreSQL 12](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5575)
- [Remove PostgreSQL 12 check in `replicate-geo-database` for 14.0](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5576)
diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md
index ca4f1c36e693c..54213139fb4c7 100644
--- a/doc/administration/geo/replication/multiple_servers.md
+++ b/doc/administration/geo/replication/multiple_servers.md
@@ -35,7 +35,7 @@ The **primary** and **secondary** Geo sites must be able to communicate to each
Because of the additional complexity involved in setting up this configuration
for PostgreSQL and Redis, it is not covered by this Geo multi-node documentation.
-For more information on setting up a multi-node PostgreSQL cluster and Redis cluster using the Omnibus GitLab package, see:
+For more information on setting up a multi-node PostgreSQL cluster and Redis cluster using the Linux package, see:
- [Geo multi-node database replication](../setup/database.md#multi-node-database-replication)
- [Redis multi-node documentation](../../redis/replication_and_failover.md)
@@ -260,7 +260,7 @@ then make the following modifications:
```
NOTE:
-If you had set up PostgreSQL cluster using the omnibus package and had set
+If you had set up PostgreSQL cluster using the Linux package and had set
`postgresql['sql_user_password'] = 'md5 digest of secret'`, keep in
mind that `gitlab_rails['db_password']` and `geo_secondary['db_password']`
contains the plaintext passwords. This is used to let the Rails
diff --git a/doc/administration/geo/replication/security_review.md b/doc/administration/geo/replication/security_review.md
index 92eff2faf60c4..e099c2b2e9db2 100644
--- a/doc/administration/geo/replication/security_review.md
+++ b/doc/administration/geo/replication/security_review.md
@@ -127,9 +127,9 @@ from [owasp.org](https://owasp.org/).
### What details regarding required OS components and lockâ€down needs have been defined?
-- The supported installation method (Omnibus) packages most components itself.
+- The supported Linux package installation method packages most components itself.
- There are significant dependencies on the system-installed OpenSSH daemon (Geo
- requires users to set up custom authentication methods) and the omnibus or
+ requires users to set up custom authentication methods) and the Linux package-provided or
system-provided PostgreSQL daemon (it must be configured to listen on TCP,
additional users and replication slots must be added, etc).
- The process for dealing with security updates (for example, if there is a
@@ -237,7 +237,7 @@ from [owasp.org](https://owasp.org/).
- In transit, data should be encrypted, although the application does permit
communication to proceed unencrypted. The two main transits are the **secondary** site's
replication process for PostgreSQL, and for Git repositories/files. Both should
- be protected using TLS, with the keys for that managed via Omnibus per existing
+ be protected using TLS, with the keys for that managed by the Linux package per existing
configuration for end-user access to GitLab.
### What capabilities exist to detect the leakage of sensitive data?
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 7244222d2fc54..1766b1bef8b05 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -210,8 +210,8 @@ Geo finds the current Puma or Sidekiq node's Geo [site](../glossary.md) name in
1. Get the "Geo node name" (there is
[an issue to rename the settings to "Geo site name"](https://gitlab.com/gitlab-org/gitlab/-/issues/335944)):
- - Omnibus GitLab: Get the `gitlab_rails['geo_node_name']` setting.
- - GitLab Helm Charts: Get the `global.geo.nodeName` setting (see [Charts with GitLab Geo](https://docs.gitlab.com/charts/advanced/geo/index.html)).
+ - Linux package: get the `gitlab_rails['geo_node_name']` setting.
+ - GitLab Helm charts: get the `global.geo.nodeName` setting (see [Charts with GitLab Geo](https://docs.gitlab.com/charts/advanced/geo/index.html)).
1. If that is not defined, then get the `external_url` setting.
This name is used to look up the Geo site with the same **Name** in the **Geo Sites**
@@ -600,7 +600,7 @@ To help us resolve this problem, consider commenting on
### Message: `FATAL: could not connect to the primary server: server certificate for "PostgreSQL" does not match host name`
-This happens because the PostgreSQL certificate that the Omnibus GitLab package automatically creates contains
+This happens because the PostgreSQL certificate that the Linux package automatically creates contains
the Common Name `PostgreSQL`, but the replication is connecting to a different host and GitLab attempts to use
the `verify-full` SSL mode by default.
@@ -1158,7 +1158,7 @@ get_ctl_options': invalid option: --force (OptionParser::InvalidOption)
```
This can happen with XFS or file systems that list files in lexical order, because the
-load order of the Omnibus GitLab command files can be different than expected, and a global function would get redefined.
+load order of the Linux package command files can be different than expected, and a global function would get redefined.
More details can be found in [the related issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6076).
The workaround is to manually run the preflight checks and promote the database, by running
@@ -1208,7 +1208,7 @@ This section documents common error messages reported in the Admin Area on the w
GitLab cannot find or doesn't have permission to access the `database_geo.yml` configuration file.
-In an Omnibus GitLab installation, the file should be in `/var/opt/gitlab/gitlab-rails/etc`.
+In a Linux package installation, the file should be in `/var/opt/gitlab/gitlab-rails/etc`.
If it doesn't exist or inadvertent changes have been made to it, run `sudo gitlab-ctl reconfigure` to restore it to its correct state.
If this path is mounted on a remote volume, ensure your volume configuration
@@ -1241,7 +1241,7 @@ This error message indicates that the replica database in the **secondary** site
To restore the database and resume replication, you can do one of the following:
- [Reset the Geo secondary site replication](#resetting-geo-secondary-site-replication).
-- [Set up a new secondary Geo Omnibus instance](../setup/index.md#using-omnibus-gitlab).
+- [Set up a new Geo secondary using the Linux package](../setup/index.md#using-linux-package-installations).
If you set up a new secondary from scratch, you must also [remove the old site from the Geo cluster](remove_geo_site.md#removing-secondary-geo-sites).
@@ -1260,7 +1260,7 @@ Make sure you follow the [Geo database replication](../setup/database.md) instru
### Geo database version (...) does not match latest migration (...)
-If you are using Omnibus GitLab installation, something might have failed during upgrade. You can:
+If you are using the Linux package installation, something might have failed during upgrade. You can:
- Run `sudo gitlab-ctl reconfigure`.
- Manually trigger the database migration by running: `sudo gitlab-rake db:migrate:geo` as root on the **secondary** site.
@@ -1361,7 +1361,9 @@ If you have installed GitLab using the Linux package (Omnibus) and have configur
- `15.6.0`-`15.6.3`
- `15.7.0`-`15.7.1`
-This is due to [a bug introduced in the included version of cURL](https://github.com/curl/curl/issues/10122) shipped with Omnibus GitLab 15.4.6 and later. You are encouraged to upgrade to a later version where this has been [fixed](https://about.gitlab.com/releases/2023/01/09/security-release-gitlab-15-7-2-released/).
+This is due to [a bug introduced in the included version of cURL](https://github.com/curl/curl/issues/10122) shipped with
+the Linux package 15.4.6 and later. You should upgrade to a later version where this has been
+[fixed](https://about.gitlab.com/releases/2023/01/09/security-release-gitlab-15-7-2-released/).
The bug causes all wildcard domains (`.example.com`) to be ignored except for the last on in the `no_proxy` environment variable list. Therefore, if for any reason you cannot upgrade to a newer version, you can work around the issue by moving your wildcard domain to the end of the list:
diff --git a/doc/administration/geo/replication/version_specific_upgrades.md b/doc/administration/geo/replication/version_specific_upgrades.md
index f8e013a877648..c0215c4551c5d 100644
--- a/doc/administration/geo/replication/version_specific_upgrades.md
+++ b/doc/administration/geo/replication/version_specific_upgrades.md
@@ -253,16 +253,16 @@ upgrade to GitLab 13.4 or later.
## Upgrading to GitLab 13.0
Upgrading to GitLab 13.0 requires GitLab 12.10 to already be using PostgreSQL
-version 11. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+version 11. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
## Upgrading to GitLab 12.10
GitLab 12.10 doesn't attempt to upgrade the embedded PostgreSQL server when
using Geo, because the PostgreSQL upgrade requires downtime for secondaries
while reinitializing streaming replication. It must be upgraded manually. For
-the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
## Upgrading to GitLab 12.9
@@ -273,8 +273,8 @@ The issue is fixed in GitLab 12.9.4. Upgrade to GitLab 12.9.4 or later.
By default, GitLab 12.9 attempts to upgrade the embedded PostgreSQL server
version from 9.6 to 10.12, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
You can temporarily disable this behavior by running the following before
upgrading:
@@ -287,8 +287,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
By default, GitLab 12.8 attempts to upgrade the embedded PostgreSQL server
version from 9.6 to 10.12, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
You can temporarily disable this behavior by running the following before
upgrading:
@@ -307,8 +307,8 @@ shipped in 12.7.5.
By default, GitLab 12.7 attempts to upgrade the embedded PostgreSQL server
version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
You can temporarily disable this behavior by running the following before
upgrading:
@@ -321,8 +321,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
By default, GitLab 12.6 attempts to upgrade the embedded PostgreSQL server
version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
You can temporarily disable this behavior by running the following before
upgrading:
@@ -335,8 +335,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
By default, GitLab 12.5 attempts to upgrade the embedded PostgreSQL server
version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
You can temporarily disable this behavior by running the following before
upgrading:
@@ -349,8 +349,8 @@ sudo touch /etc/gitlab/disable-postgresql-upgrade
By default, GitLab 12.4 attempts to upgrade the embedded PostgreSQL server
version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+reinitializing streaming replication. For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
You can temporarily disable this behavior by running the following before
upgrading:
@@ -365,13 +365,13 @@ WARNING:
If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
GitLab 12.4 or later. By default, GitLab 12.3 attempts to upgrade the embedded
PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+fail. For more information, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
## Upgrading to GitLab 12.2
@@ -379,13 +379,13 @@ WARNING:
If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
GitLab 12.4 or later. By default, GitLab 12.2 attempts to upgrade the embedded
PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+fail. For more information, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
GitLab 12.2 includes the following minor PostgreSQL upgrades:
@@ -410,13 +410,13 @@ WARNING:
If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
GitLab 12.4 or later. By default, GitLab 12.1 attempts to upgrade the embedded
PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+fail. For more information, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see the
-[Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
+For the recommended procedure, see how
+[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
## Upgrading to GitLab 12.0
diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index 1ca86a6a55d44..3081d1c248593 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -182,7 +182,8 @@ Secondary proxying is enabled by default in GitLab 15.1 on a secondary site even
Additionally, the `gitlab-workhorse` service polls `/api/v4/geo/proxy` every 10 seconds. In GitLab 15.2 and later, it is only polled once, if Geo is not enabled. Prior to GitLab 15.2, you can stop this polling by disabling secondary proxying.
-You can disable the secondary proxying on each Geo site, separately, by following these steps with Omnibus-based packages:
+You can disable the secondary proxying on each Geo site separately by following these steps on a Linux package
+installation:
1. SSH into each application node (serving user traffic directly) on your secondary Geo site
and add the following environment variable:
diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index cf0c40dbbc58b..31d0fbdffe07f 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -12,14 +12,13 @@ GitLab database to a secondary site's database. You may have to change some
values, based on attributes including your database's setup and size.
NOTE:
-If your GitLab installation uses external (not managed by Omnibus GitLab)
-PostgreSQL instances, the Omnibus roles cannot perform all necessary
-configuration steps. In this case, use the [Geo with external PostgreSQL instances](external_database.md)
-process instead.
+If your GitLab installation uses external PostgreSQL instances (not managed by a Linux package installation),
+the roles cannot perform all necessary configuration steps. In this case, use the
+[Geo with external PostgreSQL instances](external_database.md) process instead.
NOTE:
The stages of the setup process must be completed in the documented order.
-If not, [complete all prior stages](../setup/index.md#using-omnibus-gitlab) before proceeding.
+If not, [complete all prior stages](../setup/index.md#using-linux-package-installations) before proceeding.
Ensure the **secondary** site is running the same version of GitLab Enterprise Edition as the **primary** site. Confirm you have added a license for a [Premium or Ultimate subscription](https://about.gitlab.com/pricing/) to your **primary** site.
@@ -51,10 +50,10 @@ recover. See below for more details.
The following guide assumes that:
-- You are using Omnibus and therefore you are using PostgreSQL 12 or later,
+- You are using the Linux package (so are using PostgreSQL 12 or later),
which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/12/app-pgbasebackup.html).
- You have a **primary** site already set up (the GitLab server you are
- replicating from), running Omnibus' PostgreSQL (or equivalent version), and
+ replicating from), running PostgreSQL (or equivalent version) managed by your Linux package installation, and
you have a new **secondary** site set up with the same
[versions of PostgreSQL](../index.md#requirements-for-running-geo),
OS, and GitLab on all sites.
@@ -140,7 +139,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
```
- If you are using an external database not managed by Omnibus GitLab, you need
+ If you are using an external database not managed by your Linux package installation, you need
to create the `gitlab_replicator` user and define a password for that user manually:
```sql
@@ -205,7 +204,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
NOTE:
If you need to use `0.0.0.0` or `*` as the `listen_address`, you also must add
`127.0.0.1/32` to the `postgresql['md5_auth_cidr_addresses']` setting, to allow Rails to connect through
- `127.0.0.1`. For more information, see [omnibus-5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
+ `127.0.0.1`. For more information, see [issue 5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
Depending on your network configuration, the suggested addresses may
be incorrect. If your **primary** site and **secondary** sites connect over a local
@@ -374,7 +373,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
to the private key, which is **only** present on the **primary** site.
1. Test that the `gitlab-psql` user can connect to the **primary** site's database
- (the default Omnibus database name is `gitlabhq_production`):
+ (the default database name is `gitlabhq_production` on a Linux package installation):
```shell
sudo \
@@ -456,8 +455,8 @@ Below is a script that connects the database on the **secondary** site to
the database on the **primary** site. This script replicates the database and creates the
needed files for streaming replication.
-The directories used are the defaults that are set up in Omnibus. If you have
-changed any defaults, configure the script accordingly, replacing any directories and paths.
+The directories used are the defaults that are set up in a Linux package installation. If you have
+changed any defaults, configure the script accordingly (replacing any directories and paths).
WARNING:
Make sure to run this on the **secondary** site as it removes all PostgreSQL's
@@ -537,12 +536,12 @@ You should use PgBouncer if you use GitLab in a highly available
configuration with a cluster of nodes supporting a Geo **primary** site and
two other clusters of nodes supporting a Geo **secondary** site. You need two PgBouncer nodes: one for the
main database and the other for the tracking database. For more information,
-see [High Availability with Omnibus GitLab](../../postgresql/replication_and_failover.md).
+see [the relevant documentation](../../postgresql/replication_and_failover.md).
### Changing the replication password
To change the password for the [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication)
-when using Omnibus-managed PostgreSQL instances:
+when using PostgreSQL instances managed by a Linux package installation:
On the GitLab Geo **primary** site:
@@ -628,7 +627,7 @@ to `gitlab.rb` where `<slot_name>` is the name of the replication slot for your
### Migrating a single PostgreSQL node to Patroni
-Before the introduction of Patroni, Geo had no Omnibus support for HA setups on the **secondary** site.
+Before the introduction of Patroni, Geo had no support for Linux package installations for HA setups on the **secondary** site.
With Patroni, this support is now possible. To migrate the existing PostgreSQL to Patroni:
@@ -639,7 +638,7 @@ With Patroni, this support is now possible. To migrate the existing PostgreSQL t
1. [Configure a Standby Cluster](#step-4-configure-a-standby-cluster-on-the-secondary-site)
on that single node machine.
-You end up with a “Standby Cluster†with a single node. That allows you to add additional Patroni nodes by following the same instructions above.
+You end up with a _Standby Cluster_ with a single node. That allows you to add additional Patroni nodes by following the same instructions above.
### Patroni support
@@ -649,7 +648,7 @@ Using Patroni on a **secondary** site is optional and you don't have to use the
nodes on each Geo site.
For instructions on how to set up Patroni on the primary site, see the
-[PostgreSQL replication and failover with Omnibus GitLab](../../postgresql/replication_and_failover.md#patroni) page.
+[relevant documentation](../../postgresql/replication_and_failover.md#patroni).
#### Configuring Patroni cluster for a Geo secondary site
@@ -743,8 +742,8 @@ Leader is elected on the primary site, you should set up a TCP internal load
balancer. This load balancer provides a single endpoint for connecting to the Patroni
cluster's Leader.
-The Omnibus GitLab packages do not include a Load Balancer. Here's how you
-could do it with [HAProxy](https://www.haproxy.org/).
+Linux packages do not include a Load Balancer. Here's how you could do it with
+[HAProxy](https://www.haproxy.org/).
The following IPs and names are used as an example:
@@ -787,7 +786,7 @@ three Consul nodes and a minimum of one PgBouncer node. However, it is recommend
one PgBouncer node per database node. An internal load balancer (TCP) is required when there is
more than one PgBouncer service node. The internal load balancer provides a single
endpoint for connecting to the PgBouncer cluster. For more information,
-see [High Availability with Omnibus GitLab](../../postgresql/replication_and_failover.md).
+see [the relevant documentation](../../postgresql/replication_and_failover.md).
On each node running a PgBouncer instance on the **secondary** site:
@@ -921,7 +920,7 @@ For each node running a Patroni instance on the secondary site:
### Migrating a single tracking database node to Patroni
-Before the introduction of Patroni, Geo provided no Omnibus support for HA setups on
+Before the introduction of Patroni, Geo provided no support for Linux package installations for HA setups on
the secondary site.
With Patroni, it's now possible to support HA setups. However, some restrictions in Patroni
@@ -935,7 +934,7 @@ synchronization is required.
**Secondary** sites use a separate PostgreSQL installation as a tracking database to
keep track of replication status and automatically recover from potential replication issues.
-Omnibus automatically configures a tracking database when `roles(['geo_secondary_role'])` is set.
+The Linux package automatically configures a tracking database when `roles(['geo_secondary_role'])` is set.
If you want to run this database in a highly available configuration, don't use the `geo_secondary_role` above.
Instead, follow the instructions below.
@@ -945,7 +944,7 @@ If you want to run the Geo tracking database on a single node, see [Configure th
A production-ready and secure setup for the tracking PostgreSQL DB requires at least three Consul nodes: two
Patroni nodes, and one PgBouncer node on the secondary site.
-Because of [omnibus-6587](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6587), Consul can't track multiple
+Because of [issue 6587](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6587), Consul can't track multiple
services, so these must be different than the nodes used for the Standby Cluster database.
Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni)
diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index 65ea2e6e5af56..0ca1356246b07 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -6,17 +6,17 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Geo with external PostgreSQL instances **(PREMIUM SELF)**
-This document is relevant if you are using a PostgreSQL instance that is *not
-managed by Omnibus*. This includes cloud-managed instances like Amazon RDS, or
+This document is relevant if you are using a PostgreSQL instance that is not
+managed by the Linux package. This includes cloud-managed instances like Amazon RDS, or
manually installed and configured PostgreSQL instances.
Ensure that you are using one of the PostgreSQL versions that
-[Omnibus ships with](../../package_information/postgresql_versions.md)
+the [Linux package ships with](../../package_information/postgresql_versions.md)
to [avoid version mismatches](../index.md#requirements-for-running-geo)
in case a Geo site has to be rebuilt.
NOTE:
-We strongly recommend running Omnibus-managed instances as they are actively
+We strongly recommend running instances installed using the Linux package as they are actively
developed and tested. We aim to be compatible with most external
(not managed by Omnibus) databases but we do not guarantee compatibility.
@@ -62,8 +62,8 @@ developed and tested. We aim to be compatible with most external
To set up an external database, you can either:
-- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example Amazon RDS, or bare metal not managed by Omnibus).
-- Perform the Omnibus configuration manually as follows.
+- Set up [streaming replication](https://www.postgresql.org/docs/12/warm-standby.html#STREAMING-REPLICATION-SLOTS) yourself (for example Amazon RDS, or bare metal not managed by the Linux package).
+- Manually perform the configuration of your Linux package installations as follows.
#### Leverage your cloud provider's tools to replicate the primary database
@@ -142,7 +142,7 @@ hot_standby = on
### Configure **secondary** site to use the external read-replica
-With Omnibus, the
+With Linux package installations, the
[`geo_secondary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles)
has three main functions:
@@ -185,9 +185,9 @@ To configure the connection to the external read-replica database and enable Log
**Secondary** sites use a separate PostgreSQL installation as a tracking
database to keep track of replication status and automatically recover from
-potential replication issues. Omnibus automatically configures a tracking database
+potential replication issues. The Linux package automatically configures a tracking database
when `roles ['geo_secondary_role']` is set.
-If you want to run this database external to Omnibus GitLab, use the following instructions.
+If you want to run this database external to your Linux package installation, use the following instructions.
If you are using a cloud-managed service for the tracking database, you may need
to grant additional roles to your tracking database user (by default, this is
diff --git a/doc/administration/geo/setup/index.md b/doc/administration/geo/setup/index.md
index 94df58cc9ebce..e401f07795f72 100644
--- a/doc/administration/geo/setup/index.md
+++ b/doc/administration/geo/setup/index.md
@@ -21,9 +21,9 @@ type: howto
- Confirm the **primary** and **secondary** site storage configurations match. If the primary Geo site uses object storage, the secondary Geo site must use it too. For more information, see [Geo with Object storage](../replication/object_storage.md).
- Ensure clocks are synchronized between the **primary** site and the **secondary** site. Synchronized clocks are required for Geo to function correctly. For example, if the clock drift between the **primary** and **secondary** sites exceeds 1 minute, replication fails.
-## Using Omnibus GitLab
+## Using Linux package installations
-If you installed GitLab using the Omnibus packages (highly recommended), the process for setting up Geo depends on whether you need to set up
+If you installed GitLab using the Linux package (highly recommended), the process for setting up Geo depends on whether you need to set up
a single-node Geo site or a multi-node Geo site.
### Single-node Geo sites
diff --git a/doc/administration/get_started.md b/doc/administration/get_started.md
index 26848f454b547..60291732a200e 100644
--- a/doc/administration/get_started.md
+++ b/doc/administration/get_started.md
@@ -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 the GitLab Linux package.
+- Using the 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/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 2afa0fb233a61..08aeb14945466 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -167,7 +167,7 @@ These reference architectures were built and tested on Google Cloud Platform (GC
[Intel Xeon E5 v3 (Haswell)](https://cloud.google.com/compute/docs/cpu-platforms)
CPU platform as a lowest common denominator baseline ([Sysbench benchmark](https://gitlab.com/gitlab-org/quality/performance/-/wikis/Reference-Architectures/GCP-CPU-Benchmarks)).
-Newer, similarly-sized CPUs are supported and may have improved performance as a result. For Omnibus GitLab environments,
+Newer, similarly-sized CPUs are supported and may have improved performance as a result. For Linux package environments,
ARM-based equivalents are also supported.
NOTE:
@@ -240,7 +240,7 @@ for more information and guidance.
that to achieve full High Availability, a third-party PostgreSQL database solution is required.
We hope to offer a built-in solution for these restrictions in the future. In the meantime, a non-HA PostgreSQL server
-can be set up using Omnibus GitLab as the specifications reflect. Refer to the following issues for more information:
+can be set up using the Linux package as the specifications reflect. Refer to the following issues for more information:
- [`omnibus-gitlab#7292`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
- [`gitaly#3398`](https://gitlab.com/gitlab-org/gitaly/-/issues/3398).
@@ -325,8 +325,8 @@ Additionally, the following cloud provider services are validated and supported
If you choose to use a third party external service:
-1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
-1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. Note that the HA Linux package PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
+1. The number of nodes required to achieve HA may differ depending on the service compared to the Linux package and doesn't need to match accordingly.
1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
1. If [GitLab Geo](../geo/index.md) is to be used the service will need to support Cross Region replication
@@ -357,8 +357,8 @@ the harder it is to get support for it. With any deviation, you're introducing
a layer of complexity that adds challenges to finding out where potential
issues might lie.
-The reference architectures use the official GitLab Linux packages (Omnibus
-GitLab) or [Helm Charts](https://docs.gitlab.com/charts/) to install and configure the various components. The components are
+The reference architectures use the official Linux packages or [Helm Charts](https://docs.gitlab.com/charts/) to
+install and configure the various components. The components are
installed on separate machines (virtualized or bare metal), with machine hardware
requirements listed in the "Configuration" column and equivalent VM standard sizes listed
in GCP/AWS/Azure columns of each [available reference architecture](#available-reference-architectures).
@@ -418,9 +418,10 @@ Testing occurs against all reference architectures and cloud providers in an aut
Network latency on the test environments between components on all Cloud Providers were measured at <5 ms. This is shared as an observation and not as an implicit recommendation.
-We aim to have a "test smart" approach where architectures tested have a good range that can also apply to others. Testing focuses on 10k Omnibus on GCP as the testing has shown this is a good bellwether for the other architectures and cloud providers as well as Cloud Native Hybrids.
+We aim to have a "test smart" approach where architectures tested have a good range that can also apply to others. Testing focuses on a 10k Linux package
+installation on GCP as the testing has shown this is a good bellwether for the other architectures and cloud providers as well as Cloud Native Hybrids.
-The Standard Reference Architectures are designed to be platform-agnostic, with everything being run on VMs via [Omnibus GitLab](https://docs.gitlab.com/omnibus/). While testing occurs primarily on GCP, ad-hoc testing has shown that they perform similarly on hardware with equivalent specs on other Cloud Providers or if run on premises (bare-metal).
+The Standard Reference Architectures are designed to be platform-agnostic, with everything being run on VMs through [the Linux package](https://docs.gitlab.com/omnibus/). While testing occurs primarily on GCP, ad-hoc testing has shown that they perform similarly on hardware with equivalent specs on other Cloud Providers or if run on premises (bare-metal).
Testing on these reference architectures is performed with the
[GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance)
@@ -472,11 +473,11 @@ table.test-coverage th {
<th style="text-align: center" colspan="2" scope="colgroup">Azure</th>
</tr>
<tr>
- <th scope="col">Omnibus</th>
+ <th scope="col">Linux package</th>
<th scope="col">Cloud Native Hybrid</th>
- <th scope="col">Omnibus</th>
+ <th scope="col">Linux package</th>
<th scope="col">Cloud Native Hybrid</th>
- <th scope="col">Omnibus</th>
+ <th scope="col">Linux package</th>
</tr>
<tr>
<th scope="row">1k</th>
@@ -538,7 +539,7 @@ table.test-coverage th {
## Cost to run
-As a starting point, the following table details initial costs for the different reference architectures across GCP, AWS, and Azure via Omnibus.
+As a starting point, the following table details initial costs for the different reference architectures across GCP, AWS, and Azure through the Linux package.
NOTE:
Due to the nature of Cloud Native Hybrid, it's not possible to give a static cost calculation.
@@ -555,9 +556,9 @@ Bare-metal costs are also not included here as it varies widely depending on eac
<th style="text-align: center" scope="colgroup">Azure</th>
</tr>
<tr>
- <th scope="col">Omnibus</th>
- <th scope="col">Omnibus</th>
- <th scope="col">Omnibus</th>
+ <th scope="col">Linux package</th>
+ <th scope="col">Linux package</th>
+ <th scope="col">Linux package</th>
</tr>
<tr>
<th scope="row">1k</th>
diff --git a/doc/development/service_ping/troubleshooting.md b/doc/development/service_ping/troubleshooting.md
index 74e826a220817..57c4408ca84ff 100644
--- a/doc/development/service_ping/troubleshooting.md
+++ b/doc/development/service_ping/troubleshooting.md
@@ -71,7 +71,7 @@ checking the configuration file of your GitLab instance:
settings. The configuration file in which Service Ping can be disabled depends
on your installation and deployment method, but is typically one of the following:
- - `/etc/gitlab/gitlab.rb` for Omnibus GitLab Linux Package and Docker.
+ - `/etc/gitlab/gitlab.rb` for Linux package installations and Docker.
- `charts.yaml` for GitLab Helm and cloud-native Kubernetes deployments.
- `gitlab.yml` for GitLab installations from source.
diff --git a/doc/install/aws/manual_install_aws.md b/doc/install/aws/manual_install_aws.md
index bd81e0583b58b..92375fff59e91 100644
--- a/doc/install/aws/manual_install_aws.md
+++ b/doc/install/aws/manual_install_aws.md
@@ -8,23 +8,23 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Installing a GitLab POC on Amazon Web Services (AWS) **(FREE SELF)**
-This page offers a walkthrough of a common configuration for GitLab on AWS using the official GitLab Linux package. You should customize it to accommodate your needs.
+This page offers a walkthrough of a common configuration for GitLab on AWS using the official Linux package. You should customize it to accommodate your needs.
NOTE:
-For organizations with 1,000 users or less, the recommended AWS installation method is to launch an EC2 single box [Omnibus Installation](https://about.gitlab.com/install/) and implement a snapshot strategy for backing up the data. See the [1,000 user reference architecture](../../administration/reference_architectures/1k_users.md) for more information.
+For organizations with 1,000 users or less, the recommended AWS installation method is to launch an EC2 single box [Linux package installation](https://about.gitlab.com/install/) and implement a snapshot strategy for backing up the data. See the [1,000 user reference architecture](../../administration/reference_architectures/1k_users.md) for more information.
## Getting started for production-grade GitLab
NOTE:
This document is an installation guide for a proof of concept instance. It is not a reference architecture and it does not result in a highly available configuration.
-Following this guide exactly results in a proof of concept instance that roughly equates to a **scaled down** version of a **two availability zone implementation** of the **Non-HA** [Omnibus 2000 User Reference Architecture](../../administration/reference_architectures/2k_users.md). The 2K reference architecture is not HA because it is primarily intended to provide some scaling while keeping costs and complexity low. The [3000 User Reference Architecture](../../administration/reference_architectures/3k_users.md) is the smallest size that is GitLab HA. It has additional service roles to achieve HA, most notably it uses Gitaly Cluster to achieve HA for Git repository storage and specifies triple redundancy.
+Following this guide exactly results in a proof of concept instance that roughly equates to a **scaled down** version of a **two availability zone implementation** of the **Non-HA** [2000 User Reference Architecture](../../administration/reference_architectures/2k_users.md). The 2K reference architecture is not HA because it is primarily intended to provide some scaling while keeping costs and complexity low. The [3000 User Reference Architecture](../../administration/reference_architectures/3k_users.md) is the smallest size that is GitLab HA. It has additional service roles to achieve HA, most notably it uses Gitaly Cluster to achieve HA for Git repository storage and specifies triple redundancy.
-GitLab maintains and tests two main types of Reference Architectures. The **Omnibus architectures** are implemented on instance compute while **Cloud Native Hybrid architectures** maximize the use of a Kubernetes cluster. Cloud Native Hybrid reference architecture specifications are addendum sections to the Reference Architecture size pages that start by describing the Omnibus architecture. For example, the 3000 User Cloud Native Reference Architecture is in the subsection titled [Cloud Native Hybrid reference architecture with Helm Charts (alternative)](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) in the 3000 User Reference Architecture page.
+GitLab maintains and tests two main types of Reference Architectures. The **Linux package architectures** are implemented on instance compute while **Cloud Native Hybrid architectures** maximize the use of a Kubernetes cluster. Cloud Native Hybrid reference architecture specifications are addendum sections to the Reference Architecture size pages that start by describing the Linux package architecture. For example, the 3000 User Cloud Native Reference Architecture is in the subsection titled [Cloud Native Hybrid reference architecture with Helm Charts (alternative)](../../administration/reference_architectures/3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) in the 3000 User Reference Architecture page.
-### Getting started for production-grade Omnibus GitLab
+### Getting started for production-grade Linux package installations
-The Infrastructure as Code tooling [GitLab Environment Tool (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/tree/main) is the best place to start for building Omnibus GitLab on AWS and most especially if you are targeting an HA setup. While it does not automate everything, it does complete complex setups like Gitaly Cluster for you. GET is open source so anyone can build on top of it and contribute improvements to it.
+The Infrastructure as Code tooling [GitLab Environment Tool (GET)](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/tree/main) is the best place to start for building using the Linux package on AWS and most especially if you are targeting an HA setup. While it does not automate everything, it does complete complex setups like Gitaly Cluster for you. GET is open source so anyone can build on top of it and contribute improvements to it.
### Getting started for production-grade Cloud Native Hybrid GitLab
@@ -32,7 +32,7 @@ For the Cloud Native Hybrid architectures there are two Infrastructure as Code o
## Introduction
-For the most part, we make use of Omnibus GitLab in our setup, but we also leverage native AWS services. Instead of using the Omnibus bundled PostgreSQL and Redis, we use Amazon RDS and ElastiCache.
+For the most part, we make use of the Linux package in our setup, but we also leverage native AWS services. Instead of using the Linux package-bundled PostgreSQL and Redis, we use Amazon RDS and ElastiCache.
In this guide, we go through a multi-node setup where we start by
configuring our Virtual Private Cloud and subnets to later integrate
@@ -783,7 +783,7 @@ For GitLab 12.1 and earlier, use `gitlab-rake gitlab:backup:create`.
To restore GitLab, first review the [restore documentation](../../raketasks/backup_restore.md#restore-gitlab),
and primarily the restore prerequisites. Then, follow the steps under the
-[Omnibus installations section](../../raketasks/restore_gitlab.md#restore-for-omnibus-gitlab-installations).
+[Linux package installations section](../../raketasks/restore_gitlab.md#restore-for-omnibus-gitlab-installations).
## Updating GitLab
@@ -831,7 +831,7 @@ to request additional material:
GitLab supports several different types of clustering.
- [Geo replication](../../administration/geo/index.md):
Geo is the solution for widely distributed development teams.
-- [Omnibus GitLab](https://docs.gitlab.com/omnibus/) - Everything you must know
+- [Linux package](https://docs.gitlab.com/omnibus/) - Everything you must know
about administering your GitLab instance.
- [Add a license](../../user/admin_area/license.md):
Activate all GitLab Enterprise Edition functionality with a license.
diff --git a/doc/install/docker.md b/doc/install/docker.md
index 0d5b0e5d7b0aa..ab1aec98b1670 100644
--- a/doc/install/docker.md
+++ b/doc/install/docker.md
@@ -783,7 +783,7 @@ can't create Thread: Operation not permitted
This error occurs when running a container built with newer `glibc` versions on a
[host that doesn't have support for the new clone3 function](https://github.com/moby/moby/issues/42680). In GitLab 16.0 and later, the container image includes
-the Ubuntu 22.04 GitLab Linux package which is built with this newer `glibc`.
+the Ubuntu 22.04 Linux package which is built with this newer `glibc`.
This problem is fixed with newer container runtime tools like [Docker 20.10.10](https://github.com/moby/moby/pull/42836).
diff --git a/doc/install/google_cloud_platform/index.md b/doc/install/google_cloud_platform/index.md
index e492b5d75ce70..7b90d4ad19c6d 100644
--- a/doc/install/google_cloud_platform/index.md
+++ b/doc/install/google_cloud_platform/index.md
@@ -7,7 +7,7 @@ description: 'Learn how to install a GitLab instance on Google Cloud Platform.'
# Installing GitLab on Google Cloud Platform **(FREE SELF)**
-You can install GitLab on a [Google Cloud Platform (GCP)](https://cloud.google.com/) using the official GitLab Linux package. You should customize it to accommodate your needs.
+You can install GitLab on a [Google Cloud Platform (GCP)](https://cloud.google.com/) using the official Linux package. You should customize it to accommodate your needs.
NOTE:
To deploy production-ready GitLab on
@@ -92,7 +92,7 @@ here's how you configure GitLab to be aware of the change:
In the future you might want to set up [connecting with an SSH key](https://cloud.google.com/compute/docs/instances/connecting-to-instance)
instead.
-1. Edit the configuration file of Omnibus GitLab using your favorite text editor:
+1. Edit the configuration file of the Linux package using your favorite text editor:
```shell
sudo vim /etc/gitlab/gitlab.rb
@@ -123,14 +123,14 @@ Although not needed, it's strongly recommended to secure GitLab with a
### Configuring the email SMTP settings
You must configure the email SMTP settings correctly otherwise GitLab cannot send notification emails, like comments, and password changes.
-Check the [Omnibus documentation](https://docs.gitlab.com/omnibus/settings/smtp.html#smtp-settings) how to do so.
+Check the [Linux package documentation](https://docs.gitlab.com/omnibus/settings/smtp.html#smtp-settings) how to do so.
## Further reading
GitLab can be configured to authenticate with other OAuth providers, like LDAP,
SAML, and Kerberos. Here are some documents you might be interested in reading:
-- [Omnibus GitLab documentation](https://docs.gitlab.com/omnibus/)
+- [Linux package documentation](https://docs.gitlab.com/omnibus/)
- [Integration documentation](../../integration/index.md)
- [GitLab Pages configuration](../../administration/pages/index.md)
- [GitLab Container Registry configuration](../../administration/packages/container_registry.md)
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index 4a7c96d13300c..64dfd3e6044bd 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -155,10 +155,10 @@ of GitLab Support or other GitLab engineers.
## Puma settings
The recommended settings for Puma are determined by the infrastructure on which it's running.
-The GitLab Linux package defaults to the recommended Puma settings. Regardless of installation method, you can
+The Linux package defaults to the recommended Puma settings. Regardless of installation method, you can
tune the Puma settings:
-- If you're using the GitLab Linux package, see [Puma settings](../administration/operations/puma.md)
+- If you're using the Linux package, see [Puma settings](../administration/operations/puma.md)
for instructions on changing the Puma settings.
- If you're using the GitLab Helm chart, see the
[`webservice` chart](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
diff --git a/doc/integration/mattermost/index.md b/doc/integration/mattermost/index.md
index e1183f62225f4..0f9192f9a84aa 100644
--- a/doc/integration/mattermost/index.md
+++ b/doc/integration/mattermost/index.md
@@ -10,7 +10,7 @@ NOTE:
This document applies to GitLab 11.0 and later.
You can run a [GitLab Mattermost](https://gitlab.com/gitlab-org/gitlab-mattermost)
-service on your GitLab server. Mattermost is not part of the single application that GitLab is. There is a good integration between [Mattermost and GitLab](https://mattermost.com/solutions/mattermost-gitlab/), and our Omnibus installer allows you to easily install it. But it is a separate application from a separate company.
+service on your GitLab server. Mattermost is not part of the single application that GitLab is. There is a good integration between [Mattermost and GitLab](https://mattermost.com/solutions/mattermost-gitlab/), and our Linux package allows you to easily install it. But it is a separate application from a separate company.
## Prerequisites
@@ -38,7 +38,7 @@ GitLab Mattermost is disabled by default. To enable it:
1. Confirm that GitLab Mattermost is reachable at `https://mattermost.example.com` and authorized to connect to GitLab. Authorizing Mattermost with GitLab allows users to use GitLab as an SSO provider.
-The Omnibus GitLab package attempts to automatically authorize GitLab Mattermost with GitLab if the applications are running on the same server.
+The Linux package attempts to automatically authorize GitLab Mattermost with GitLab if the applications are running on the same server.
Automatic authorization requires access to the GitLab database. If the GitLab database is not available
you need to manually authorize GitLab Mattermost for access to GitLab using the process described in the [Authorize GitLab Mattermost section](#authorize-gitlab-mattermost).
@@ -86,7 +86,7 @@ Once the configuration is set, run `sudo gitlab-ctl reconfigure` to apply the ch
## Running GitLab Mattermost on its own server
If you want to run GitLab and GitLab Mattermost on two separate servers the GitLab services are still set up on your GitLab Mattermost server, but they do not accept user requests or
-consume system resources. You can use the following settings and configuration details on the GitLab Mattermost server to effectively disable the GitLab service bundled into the Omnibus package.
+consume system resources. You can use the following settings and configuration details on the GitLab Mattermost server to effectively disable the GitLab service bundled into the Linux package.
```ruby
mattermost_external_url 'http://mattermost.example.com'
@@ -142,7 +142,7 @@ Save the changes and then run `sudo gitlab-ctl reconfigure`. If there are no err
## Specify numeric user and group identifiers
-Omnibus GitLab creates a user and group `mattermost`. You can specify the
+The Linux pacakage creates a user and group `mattermost`. You can specify the
numeric identifiers for these users in `/etc/gitlab/gitlab.rb` as follows:
```ruby
@@ -167,7 +167,7 @@ Run `sudo gitlab-ctl reconfigure` to apply the changes.
## Connecting to the bundled PostgreSQL database
-If you need to connect to the bundled PostgreSQL database and are using the default Omnibus GitLab database configuration, you can connect as
+If you need to connect to the bundled PostgreSQL database and are using the default Linux package database configuration, you can connect as
the PostgreSQL superuser:
```shell
@@ -176,14 +176,14 @@ sudo gitlab-psql -d mattermost_production
## Back up GitLab Mattermost
-GitLab Mattermost is not included in the regular [Omnibus GitLab backup](../../raketasks/backup_restore.md) Rake task.
+GitLab Mattermost is not included in the regular [Linux package backup](../../raketasks/backup_restore.md) Rake task.
The general Mattermost [backup and disaster recovery](https://docs.mattermost.com/deploy/backup-disaster-recovery.html) documentation can be used as a guide
on what needs to be backed up.
### Back up the bundled PostgreSQL database
-If you need to back up the bundled PostgreSQL database and are using the default Omnibus GitLab database configuration, you can back up using this command:
+If you need to back up the bundled PostgreSQL database and are using the default Linux package database configuration, you can back up using this command:
```shell
sudo -i -u gitlab-psql -- /opt/gitlab/embedded/bin/pg_dump -h /var/opt/gitlab/postgresql mattermost_production | gzip > mattermost_dbdump_$(date --rfc-3339=date).sql.gz
@@ -286,8 +286,6 @@ Password:
## Configuring GitLab and Mattermost integrations
-As of 12.3, the Mattermost GitLab plugin is shipped with Omnibus GitLab: [Mattermost Plugin for GitLab documentation](https://github.com/mattermost/mattermost-plugin-gitlab).
-
You can use the plugin to subscribe Mattermost to receive notifications about issues, merge requests, and pull requests as well as personal notifications regarding merge request reviews, unread messages, and task assignments. If you want to use slash commands to perform actions
such as creating and viewing issues, or to trigger deployments use GitLab [Mattermost slash commands](../../user/project/integrations/mattermost_slash_commands.md).
@@ -359,22 +357,22 @@ When upgrading the Mattermost version, it is essential to check the
[Important Upgrade Notes](https://docs.mattermost.com/administration/important-upgrade-notes.html)
for Mattermost to address any changes or migrations that need to be performed.
-Starting with GitLab 11.0, GitLab Mattermost can be upgraded through the regular Omnibus GitLab update process. When upgrading previous versions of
+Starting with GitLab 11.0, GitLab Mattermost can be upgraded through the regular Linux package update process. When upgrading previous versions of
GitLab, the update process can only be used if Mattermost configuration settings have not been changed outside of GitLab. That is, no changes to the Mattermost `config.json`
file have been made - either directly or via the Mattermost **System Console**, which saves changes to `config.json`.
-If you are upgrading to at least GitLab 11.0 or have only configured Mattermost using `gitlab.rb`, you can upgrade GitLab using Omnibus and then run `gitlab-ctl reconfigure` to upgrade GitLab Mattermost to the latest version.
+If you are upgrading to at least GitLab 11.0 or have only configured Mattermost using `gitlab.rb`, you can upgrade GitLab using the Linux package and then run `gitlab-ctl reconfigure` to upgrade GitLab Mattermost to the latest version.
If this is not the case, there are two options:
1. Update [`gitlab.rb`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L706)
with the changes done to `config.json`. This might require adding some parameters as not all
- settings in `config.json` are available in `gitlab.rb`. Once complete, Omnibus GitLab should be
+ settings in `config.json` are available in `gitlab.rb`. Once complete, the Linux package should be
able to upgrade GitLab Mattermost from one version to the next.
-1. Migrate Mattermost outside of the directory controlled by Omnibus GitLab so it can be administered
+1. Migrate Mattermost outside of the directory controlled by the Linux package so it can be administered
and upgraded independently. Follow the [Mattermost Migration Guide](https://docs.mattermost.com/administration/migrating.html)
to move your Mattermost configuration settings and data to another directory or server independent
- from Omnibus GitLab.
+ from the Linux package.
For a complete list of upgrade notices and special considerations for older versions, see the [Mattermost documentation](https://docs.mattermost.com/administration/important-upgrade-notes.html).
@@ -387,7 +385,7 @@ GitLab 15.10 ships with Mattermost 7.8. Before upgrading, [connect to the bundle
GitLab 14.6 ships with Mattermost 6.1 including potentially long running database migrations for Mattermost 6.0. For information about upgrading and for ways to reduce the downtime caused by those migrations, read the [Important Upgrade Notes](https://docs.mattermost.com/administration/important-upgrade-notes.html) for both versions. If you need to perform any manual migrations, [connect to the bundled PostgreSQL database](#connecting-to-the-bundled-postgresql-database).
NOTE:
-The Mattermost upgrade notes refer to different impacts when used with a PostgreSQL versus a MySQL database. The GitLab Mattermost included with the GitLab Linux packages uses a PostgreSQL database.
+The Mattermost upgrade notes refer to different impacts when used with a PostgreSQL versus a MySQL database. The GitLab Mattermost included with the Linux package uses a PostgreSQL database.
## Upgrading GitLab Mattermost from versions prior to 11.0
@@ -492,7 +490,7 @@ If you encounter any issues [visit the GitLab Mattermost troubleshooting forum](
### Upgrading GitLab Mattermost outside of GitLab
-If you choose to upgrade Mattermost outside of the Omnibus GitLab automation, [follow this guide](https://docs.mattermost.com/administration/upgrade.html).
+If you choose to upgrade Mattermost outside of the Linux package automation, [follow this guide](https://docs.mattermost.com/administration/upgrade.html).
## OAuth 2.0 sequence diagram
diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md
index eed9f006bfac6..7970f9711e6c3 100644
--- a/doc/policy/maintenance.md
+++ b/doc/policy/maintenance.md
@@ -53,13 +53,13 @@ cases you must consider. Follow the
between versions.
NOTE:
-Version specific changes in Omnibus GitLab Linux packages can be found in [the Omnibus GitLab documentation](../update/package/index.md#version-specific-changes).
+Version specific changes in Linux packages can be found in [the Linux package documentation](../update/package/index.md#version-specific-changes).
NOTE:
-Instructions are available for downloading an Omnibus GitLab Linux package locally and [manually installing](../update/package/index.md#upgrade-using-a-manually-downloaded-package) it.
+Instructions are available for downloading the Linux package locally and [manually installing](../update/package/index.md#upgrade-using-a-manually-downloaded-package) it.
NOTE:
-A step-by-step guide to [upgrading the Omnibus-bundled PostgreSQL is documented separately](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
+A step-by-step guide to [upgrading the Linux package-bundled PostgreSQL is documented separately](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server).
## Upgrading major versions
--
GitLab