Update some installation type references for docs

Author: eread

doc/index.md

@@ -43,7 +43,7 @@ to work best with the available resources. Check out the [documentation](setting
 - [Storing Git data in an alternative directory](settings/configuration.md#store-git-data-in-an-alternative-directory)
 - [Changing the name of the Git user group](settings/configuration.md#change-the-name-of-the-git-user-or-group)
 - [Specify numeric user and group identifiers](settings/configuration.md#specify-numeric-user-and-group-identifiers)
-- [Only start Omnibus GitLab services after a given file system is mounted](settings/configuration.md#start-omnibus-gitlab-services-only-after-a-given-file-system-is-mounted)
+- [Start Linux package installation services only after a given file system is mounted](settings/configuration.md#start-linux-package-installation-services-only-after-a-given-file-system-is-mounted)
 - [Disable user and group account management](settings/configuration.md#disable-user-and-group-account-management)
 - [Disable storage directory management](settings/configuration.md#disable-storage-directories-management)
 - [Failed authentication ban](settings/configuration.md#configure-a-failed-authentication-ban)
@@ -72,9 +72,8 @@ to work best with the available resources. Check out the [documentation](setting
 - [Upgrade from Community Edition to Enterprise Edition](https://docs.gitlab.com/ee/update/package/convert_to_ee.html)
 - [Upgrade to the latest version](https://docs.gitlab.com/ee/update/package/#upgrade-using-the-official-repositories)
 - [Downgrade to an earlier version](https://docs.gitlab.com/ee/update/package/downgrade.html)
-- [Upgrade from a non-Omnibus installation to an Omnibus installation using a backup](update/convert_to_omnibus.md#upgrading-from-non-omnibus-postgresql-to-an-omnibus-installation-using-a-backup)
-- [Upgrade from non-Omnibus PostgreSQL to an Omnibus installation in-place](update/convert_to_omnibus.md#upgrading-from-non-omnibus-postgresql-to-an-omnibus-installation-in-place)
-- [Upgrade from non-Omnibus MySQL to an Omnibus installation (version 6.8+)](update/convert_to_omnibus.md#upgrading-from-non-omnibus-mysql-to-an-omnibus-installation-version-68)
+- [Upgrade from a non-Linux package PostgreSQL to a Linux package installation using a backup](update/convert_to_omnibus.md#upgrading-from-a-non-linux-package-postgresql-to-a-linux-package-installation-using-a-backup)
+- [Upgrade from a non-Linux package PostgreSQL to a Linux package installation in-place](update/convert_to_omnibus.md#upgrading-from-a-non-linux-package-postgresql-to-a-linux-package-installation-in-place)
 
 ## Troubleshooting
 

doc/installation/index.md

@@ -4,7 +4,7 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Installing GitLab with Omnibus packages **(FREE SELF)**
+# Install GitLab with the Linux package **(FREE SELF)**
 
 ## Prerequisites
 
@@ -21,7 +21,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 ## Installation and Configuration
 
-These configuration settings are commonly used when configuring Omnibus GitLab.
+These configuration settings are commonly used when configuring a Linux package installation.
 For a complete list of settings, see the [README](../index.md#configuring) file.
 
 - [Installing GitLab](https://about.gitlab.com/install/).
@@ -37,16 +37,16 @@ For a complete list of settings, see the [README](../index.md#configuring) file.
 - [Enabling GitLab Pages](https://docs.gitlab.com/ee/administration/pages/).
   - If you want HTTPS enabled, you must get wildcard certificates.
 - [Enabling Elasticsearch](https://docs.gitlab.com/ee/integration/advanced_search/elasticsearch.html).
-- [GitLab Mattermost](https://docs.gitlab.com/ee/integration/mattermost/) Set up the Mattermost messaging app that ships with Omnibus GitLab package.
+- [GitLab Mattermost](https://docs.gitlab.com/ee/integration/mattermost/). Set up the Mattermost messaging app that ships with the Linux package.
 - [GitLab Prometheus](https://docs.gitlab.com/ee/administration/monitoring/prometheus/index.html)
-  Set up the Prometheus monitoring included in the Omnibus GitLab package.
+  Set up the Prometheus monitoring included in the Linux package.
 - [GitLab High Availability Roles](../roles/index.md).
 
 ### Set up the initial password
 
-> [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5331) in Omnibus GitLab 14.0.
+> [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5331) in GitLab 14.0.
 
-By default, Omnibus GitLab automatically generates a password for the
+By default, a Linux package installation automatically generates a password for the
 initial administrator user account (`root`) and stores it to
 `/etc/gitlab/initial_root_password` for at least 24 hours. For security reasons,
 after 24 hours, this file is automatically removed by the first `gitlab-ctl reconfigure`.
@@ -93,8 +93,8 @@ To uninstall the Linux package, you can opt to either keep your data (repositori
 database, configuration) or remove all of them:
 
 1. Optional. To remove
-   [all users and groups created by Omnibus GitLab](../settings/configuration.md#disable-user-and-group-account-management)
-   before removing the GitLab package (with `apt` or `yum`):
+   [all users and groups created by the Linux package](../settings/configuration.md#disable-user-and-group-account-management)
+   before removing the package (with `apt` or `yum`):
 
    ```shell
    sudo gitlab-ctl stop && sudo gitlab-ctl remove-accounts

doc/settings/backups.md

@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Backup **(FREE SELF)**
 
-## Backup and restore Omnibus GitLab configuration
+## Backup and restore configuration on a Linux package installation
 
 It is recommended to keep a copy of `/etc/gitlab`, or at least of
 `/etc/gitlab/gitlab-secrets.json`, in a safe place. If you ever
@@ -18,7 +18,7 @@ and 'secure variables' stored in GitLab CI will be lost.
 It is not recommended to store your configuration backup in the
 same place as your application data backup, see below.
 
-All configuration for Omnibus GitLab is stored in `/etc/gitlab`. To backup your
+All configuration for Linux package installations is stored in `/etc/gitlab`. To backup your
 configuration, just run `sudo gitlab-ctl backup-etc` (introduced in GitLab 12.3). It creates a tar
 archive in `/etc/gitlab/config_backup/`. Directory and backup files will be
 readable only to root.
@@ -164,7 +164,7 @@ For details check [backup restore document](https://docs.gitlab.com/ee/raketasks
 
 ## Manually manage backup directory
 
-Omnibus GitLab creates the backup directory set with `gitlab_rails['backup_path']`. The directory is owned by the user that is running GitLab and it has strict permissions set to be accessible to only that user.
+Linux package installations create the backup directory set with `gitlab_rails['backup_path']`. The directory is owned by the user that is running GitLab and it has strict permissions set to be accessible to only that user.
 That directory will hold backup archives and they contain sensitive information.
 In some organizations permissions need to be different because of, for example, shipping the backup archives offsite.
 

doc/settings/configuration.md

@@ -4,7 +4,7 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Configuration options for the GitLab Linux package **(FREE SELF)**
+# Configuration options for Linux package installations **(FREE SELF)**
 
 To configure GitLab, set the relevant options in the `/etc/gitlab/gitlab.rb` file.
 
@@ -60,7 +60,7 @@ To change the external URL:
 
 ### Specify the external URL at the time of installation
 
-If you use the GitLab Linux package, you can set up your GitLab instance
+If you use the Linux package, you can set up your GitLab instance
 with the minimum number of commands by using the `EXTERNAL_URL` environment variable.
 If this variable is set, it is automatically detected and its value is written
 as `external_url` in the `gitlab.rb` file.
@@ -112,7 +112,7 @@ If you have any issues, see the [troubleshooting section](#relative-url-troubles
 
 ## Load external configuration file from non-root user
 
-Omnibus GitLab package loads all configuration from `/etc/gitlab/gitlab.rb` file.
+Linux package installations load all configuration from `/etc/gitlab/gitlab.rb` file.
 This file has strict file permissions and is owned by the `root` user. The reason for strict permissions
 and ownership is that `/etc/gitlab/gitlab.rb` is being executed as Ruby code by the `root` user during `gitlab-ctl reconfigure`. This means
 that users who have to write access to `/etc/gitlab/gitlab.rb` can add a configuration that is executed as code by `root`.
@@ -140,7 +140,7 @@ postgresql['internal_certificate'] = File.read('/path/to/server.crt')
 
 ## Store Git data in an alternative directory
 
-By default, Omnibus GitLab stores the Git repository data under
+By default, Linux package installations store the Git repository data under
 `/var/opt/gitlab/git-data`. The repositories are stored in a subfolder called
 `repositories`.
 
@@ -218,7 +218,7 @@ endpoint and specify the `repository_storage` attribute.
 NOTE:
 We do not recommend changing the user or group of an existing installation because it can cause unpredictable side effects.
 
-By default, Omnibus GitLab uses the user name `git` for Git GitLab Shell login,
+By default, Linux package installations use the user name `git` for Git GitLab Shell login,
 ownership of the Git data itself, and SSH URL generation on the web interface.
 Similarly, the `git` group is used for group ownership of the Git data.
 
@@ -243,7 +243,7 @@ Make sure that the new user can access the `repositories` and `uploads` director
 
 ## Specify numeric user and group identifiers
 
-Omnibus GitLab creates users for GitLab, PostgreSQL, Redis, NGINX, etc. To
+Linux package installations create users for GitLab, PostgreSQL, Redis, NGINX, etc. To
 specify the numeric identifiers for these users:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
@@ -271,7 +271,8 @@ specify the numeric identifiers for these users:
    sudo gitlab-ctl reconfigure
    ```
 
-1. Optional. If you're changing `user['uid']` and `user['gid']`, make sure to update the uid/guid of any files not managed by Omnibus directly, for example, the logs:
+1. Optional. If you're changing `user['uid']` and `user['gid']`, make sure to update the uid/guid of any files not managed by the Linux package
+   directly, for example, the logs:
 
 ```shell
 find /var/log/gitlab -uid <old_uid> | xargs -I:: chown git ::
@@ -282,14 +283,14 @@ find /var/opt/gitlab -gid <old_uid> | xargs -I:: chgrp git ::
 
 ## Disable user and group account management
 
-By default, Omnibus GitLab creates system user and group accounts,
+By default, Linux package installations create system user and group accounts,
 as well as keeping the information updated.
 These system accounts run various components of the package.
 Most users don't need to change this behavior.
 However, if your system accounts are managed by other software, for example, LDAP, you
 might need to disable account management done by the GitLab package.
 
-By default, the Omnibus GitLab package expects the following users and groups to exist:
+By default, the Linux package installations expect the following users and groups to exist:
 
 | Linux user and group | Required                                | Description                                                          |
 | -------------------- | --------------------------------------- | -------------------------------------------------------------------- |
@@ -395,15 +396,15 @@ To move an existing home directory, GitLab services need to be stopped and some
 
 ## Disable storage directories management
 
-The Omnibus GitLab package takes care of creating all the necessary directories
+The Linux package takes care of creating all the necessary directories
 with the correct ownership and permissions, as well as keeping this updated.
 
 Some of the directories hold large amounts of data so in certain setups,
 those directories are most likely mounted on an NFS (or some other) share.
 
 Some types of mounts don't allow the automatic creation of directories by the root user
 (default user for initial setup), for example, NFS with `root_squash` enabled on the
-share. To work around this, the Omnibus GitLab package attempts to create
+share. To work around this, the Linux package attempts to create
 those directories using the directory's owner user.
 
 ### Disable the `/etc/gitlab` directory management
@@ -428,7 +429,7 @@ that directory:
 If you are mounting all GitLab storage directories, each on a separate mount,
 you should completely disable the management of storage directories.
 
-The Omnibus GitLab package expects these directories to exist
+Linux package installations expect these directories to exist
 on the file system. It is up to you to create and set correct
 permissions if this setting is set.
 
@@ -465,9 +466,9 @@ To disable the management of storage directories:
    sudo gitlab-ctl reconfigure
    ```
 
-## Start Omnibus GitLab services only after a given file system is mounted
+## Start Linux package installation services only after a given file system is mounted
 
-If you want to prevent Omnibus GitLab services (NGINX, Redis, Puma, etc.)
+If you want to prevent Linux package installation services (NGINX, Redis, Puma, etc.)
 from starting before a given file system is mounted:
 
 1. Edit `/etc/gitlab/gitlab.rb`:
@@ -490,7 +491,7 @@ of each Puma process (Rails metrics). Every Puma process needs to write
 a metrics file to a temporary location for each controller request.
 Prometheus then collects all these files and processes their values.
 
-To avoid creating disk I/O, the Omnibus GitLab package uses a
+To avoid creating disk I/O, the Linux package uses a
 runtime directory.
 
 During `reconfigure`, the package check if `/run` is a `tmpfs` mount.