Merge branch 'asmaa.hassan-master-patch-f1b5' into 'master'

Removing references of old versions of distribution:deply | omnibus docs

See merge request https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/7557

Merged-by: Marcin Sedlak-Jakubowski <[email protected]>
Approved-by: Evan Read <[email protected]>
Approved-by: Marcin Sedlak-Jakubowski <[email protected]>
Reviewed-by: Evan Read <[email protected]>
Co-authored-by: Achilleas Pipinellis <[email protected]>
Co-authored-by: Evan Read <[email protected]>
Co-authored-by: Asmaa Hassan <[email protected]>

Author: 4 people

doc/installation/index.md

@@ -48,8 +48,6 @@ For a complete list of settings, see the [README](../index.md#configuring) file.
 
 ### Set up the initial password
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5331) in GitLab 14.0.
-
 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,

doc/roles/index.md

@@ -70,7 +70,7 @@ Documentation on the use of the Redis Roles can be found in [Configuring Redis f
 
   *By default, enables no other services.*
 
-- **redis_replica_role** (`gitlab-ee`, [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4168) in GitLab 13.0)
+- **redis_replica_role** (`gitlab-ee`)
 
   Enables the Redis service and monitoring
 
@@ -117,8 +117,6 @@ for configuration steps.
 
 ### Monitoring Roles
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3404) in GitLab 12.1.
-
 Monitoring roles are used to set up monitoring of installations. For additional information, see the [Monitoring documentation](https://docs.gitlab.com/ee/administration/monitoring/prometheus/index.html).
 
 - **monitoring_role** (`gitlab-ce`/`gitlab-ee`)
@@ -137,7 +135,7 @@ Documentation on the usage of the PostgreSQL Roles can be found in [Configuring
 
   *By default, enables no other services.*
 
-- **patroni_role** (`gitlab-ee`, [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4851) in GitLab 13.8)
+- **patroni_role** (`gitlab-ee`)
 
   Enables the PostgreSQL, patroni, and Consul services on the machine
 
@@ -157,8 +155,6 @@ Documentation on the usage of the PostgreSQL Roles can be found in [Configuring
 
 ### GitLab Pages Roles
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4740) in GitLab 13.6.
-
 GitLab Pages roles are used to setup and configure GitLab Pages. For additional
 information, see the
 [GitLab Pages Administration documentation](https://docs.gitlab.com/ee/administration/pages/index.html)
@@ -171,8 +167,6 @@ information, see the
 
 ### Sidekiq Roles
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5365) in GitLab 14.1.
-
 Sidekiq roles are used to setup and configure Sidekiq. For additional
 information, see the
 [Sidekiq Administration documentation](https://docs.gitlab.com/ee/administration/sidekiq/index.html)
@@ -185,8 +179,6 @@ information, see the
 
 ### Spamcheck Roles
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5893) in GitLab 14.9.
-
 Spamcheck roles are used to setup and configure Spamcheck services. For additional
 information, see the
 [Spamcheck documentation](https://docs.gitlab.com/ee/administration/reporting/spamcheck.html)

doc/settings/backups.md

@@ -23,7 +23,7 @@ It is not recommended to store your configuration backup in the
 same place as your application data backup, see below.
 
 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
+configuration, just run `sudo gitlab-ctl backup-etc`. It creates a tar
 archive in `/etc/gitlab/config_backup/`. Directory and backup files will be
 readable only to root.
 
@@ -68,8 +68,6 @@ Your machines SSH host keys are stored in a separate location at `/etc/ssh/`. Be
 
 ### Limit backup lifetime for configuration backups (prune old backups)
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5102) in GitLab 13.12.
-
 GitLab configuration backups can be pruned using the same `backup_keep_time` setting that is
 [used for the GitLab application backups](https://docs.gitlab.com/ee/administration/backup_restore/backup_gitlab.html#limit-backup-lifetime-for-local-files-prune-old-backups)
 

doc/settings/configuration.md

@@ -709,9 +709,8 @@ cross-site scripting (XSS) attacks. See
 [the Mozilla documentation on CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) for more
 details.
 
-GitLab 12.2 added support for
-[CSP and nonce-source with inline JavaScript](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src).
-It is [not configured by default yet](https://gitlab.com/gitlab-org/gitlab/-/issues/30720).
+[CSP and nonce-source with inline JavaScript](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src) is available on GitLab.com.
+It is [not configured by default](https://gitlab.com/gitlab-org/gitlab/-/issues/30720) on self-managed.
 
 NOTE:
 Improperly configuring the CSP rules could prevent GitLab from working
@@ -746,8 +745,7 @@ To add a CSP:
    }
    ```
 
-   [In GitLab 14.9 and later](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80303), secure default values
-   are used for directives that aren't explicitly configured.
+   Secure default values are used for directives that aren't explicitly configured.
 
    To unset a CSP directive, set a value of `false`.
 

doc/settings/database.md

@@ -178,22 +178,14 @@ After you have these files, enable SSL:
 
 To determine whether SSL is being used by clients, you can run:
 
-In [GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/341210):
-
 ```shell
 sudo gitlab-rails dbconsole --database main
 ```
 
-In GitLab 14.1 and earlier:
-
-```shell
-sudo gitlab-rails dbconsole
-```
-
 At startup, you should see a banner as the following:
 
 ```plaintext
-psql (9.6.5)
+psql (13.14)
 SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: on)
 Type "help" for help.
 ```
@@ -480,7 +472,7 @@ To upgrade the PostgreSQL version, be sure that:
     (or update your database path).
   - Check the space available using `sudo df -h`. If the partition where the
     database resides doesn't have enough space, pass the argument `--tmp-dir $DIR`
-    to the command. GitLab 13.3 and above include an available disk space check and aborts
+    to the command. The upgrade task includes an available disk space check and aborts
     the upgrade if the requirements aren't met.
 
 After you confirm that the above checklist is satisfied, you can proceed with
@@ -1009,8 +1001,6 @@ parameters noted in the table below and then run `gitlab-ctl reconfigure`.
 
 ## Automatic database reindexing
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/249662) in GitLab 13.5.
-
 WARNING:
 This is an experimental feature that isn't enabled by default.
 
@@ -1140,23 +1130,6 @@ bandwidth. For example, at a transfer speed of 30 Mbps, and a database size of
 [PostgreSQL documentation](https://www.postgresql.org/docs/11/pgupgrade.html)
 for more.
 
-#### Disabling automatic PostgreSQL upgrades
-
-From GitLab 12.1 through GitLab 12.9, GitLab package upgrades try to upgrade
-PostgreSQL to version 10.x. In GitLab 12.10 and later, upgrades of PostgreSQL
-don't happen in an unattended manner when using Geo.
-
-Before upgrading to GitLab 12.1 through GitLab 12.9, we strongly recommend
-disabling unattended upgrades of PostgreSQL and manually upgrading PostgreSQL
-separately from upgrading the GitLab package to avoid any unintended downtime.
-
-You can disable unattended upgrades of PostgreSQL by running the following on
-all nodes running `postgresql` or `geo-postgresql`:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
 #### How to upgrade PostgreSQL when using Geo
 
 To upgrade PostgreSQL, you will need the name of the replication slot, and the
@@ -1221,24 +1194,10 @@ replication user's password.
 If you need to connect to the PostgreSQL database, you can connect as the
 application user:
 
-In [GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/341210):
-
 ```shell
 sudo gitlab-rails dbconsole --database main
 ```
 
-In GitLab 14.1 and earlier:
-
-```shell
-sudo gitlab-rails dbconsole
-```
-
-or as a PostgreSQL superuser:
-
-```shell
-sudo gitlab-psql -d gitlabhq_production
-```
-
 ## Troubleshooting
 
 ### Set `default_transaction_isolation` into `read committed`

doc/settings/environment-variables.md

@@ -52,9 +52,7 @@ registry['env'] = {
 }
 ```
 
-GitLab 11.6 and newer will attempt to use HTTP Basic
-Authentication when a username and password is included in the proxy
-URL. Older GitLab versions will omit the authentication details.
+GitLab will attempt to use HTTP Basic Authentication when a username and password is included in the proxy URL.
 
 Proxy settings use the `.` syntax for globing.
 

doc/settings/gitlab.yml.md

@@ -15,8 +15,8 @@ Some GitLab features can be customized through
 for a Linux package installation, you need to do so with `/etc/gitlab/gitlab.rb`. The
 translation works as follows. For a complete list of available options, visit the
 [`gitlab.rb.template`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template).
-New installations starting from GitLab 7.6 have
-all the options of the template listed in `/etc/gitlab/gitlab.rb` by default.
+
+All the options of the template listed in `/etc/gitlab/gitlab.rb` are avilable by default.
 
 In `gitlab.yml`, you find structure like this:
 

doc/settings/logs.md

@@ -144,8 +144,7 @@ logrotate['enable'] = false
 
 ### Logrotate `notifempty` setting
 
-Since [GitLab 13.6](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3820),
-the logrotate service runs with a non-configurable default of `notifempty`, resolving
+The logrotate service runs with a non-configurable default of `notifempty`, resolving
 the following issues:
 
 - Empty logs being rotated unnecessarily, and often many empty logs being stored.

doc/settings/nginx.md

@@ -440,18 +440,9 @@ web_server['external_users'] = ['www-data']
 
 Make sure you run `sudo gitlab-ctl reconfigure` for the changes to take effect.
 
-NOTE:
-If you are running a version older than 8.16.0, you will have to
-manually remove the Unicorn service file (`/opt/gitlab/service/unicorn`), if
-exists, for reconfigure to succeed.
-
 ### Vhost (server block)
 
-NOTE:
-GitLab 13.5 changed the default workhorse socket location from `/var/opt/gitlab/gitlab-workhorse/socket` to `/var/opt/gitlab/gitlab-workhorse/sockets/socket`. Please update the following configuration accordingly if upgrading from versions older than 13.5.
-
-Then, in your custom Passenger/NGINX installation, create the following site
-configuration file:
+In your custom Passenger/NGINX installation, create the following site configuration file:
 
 ```plaintext
 upstream gitlab-workhorse {
@@ -757,24 +748,6 @@ header with `hide_server_tokens`:
    sudo gitlab-ctl hup nginx
    ```
 
-### `502: Bad Gateway` when SELinux and external NGINX are used
-
-On Linux servers with SELinux enabled, after setting up an external NGINX, the error `502: Bad Gateway` may be observed when accessing the GitLab UI. You can also see the error in NGINX's logs:
-
-```plaintext
-connect() to unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket failed (13:Permission denied) while connecting to upstream
-```
-
-Select one of the following options to fix:
-
-- Update to GitLab 14.3 or later which contains an [updated SELinux policy](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5569).
-- Fetch and update the policy manually:
-
-  ```shell
-  wget https://gitlab.com/gitlab-org/omnibus-gitlab/-/raw/a9d6b020f81d18d778fb502c21b2c8f2265cabb4/files/gitlab-selinux/rhel/7/gitlab-13.5.0-gitlab-shell.pp
-  semodule -i gitlab-13.5.0-gitlab-shell.pp
-  ```
-
 ### `Branch 'branch_name' was not found in this project's repository` when Web IDE and external NGINX are used
 
 If you get this error, check your NGINX configuration file if you have a trailing slash in `proxy_pass` and remove it:

doc/settings/smtp.md

@@ -46,8 +46,6 @@ gitlab_rails['smtp_ca_file'] = '/path/to/your/cacert.pem'
 
 ## SMTP connection pooling
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/230717) in GitLab 13.5.
-
 You can enable SMTP connection pooling with the following setting:
 
 ```ruby
@@ -58,8 +56,6 @@ This allows Sidekiq workers to reuse SMTP connections for multiple jobs. The max
 
 ## Using encrypted credentials
 
-> - [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6276) in GitLab 14.3.
-
 Instead of storing the SMTP credentials in the configuration files as plain text, you can optionally
 use an encrypted file for the SMTP credentials. To use this feature, you first need to enable
 [GitLab encrypted configuration](https://docs.gitlab.com/ee/administration/encrypted_configuration.html).