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

This commit is contained in:
Asmaa Hassan 2024-04-23 20:34:58 +00:00 committed by Marcin Sedlak-Jakubowski
parent 82c190a3e9
commit 80728911e4
11 changed files with 17 additions and 106 deletions

View File

@ -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,

View File

@ -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)

View File

@ -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)

View File

@ -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`.

View File

@ -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`

View File

@ -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.

View File

@ -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:

View File

@ -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.

View File

@ -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:

View File

@ -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).

View File

@ -106,7 +106,7 @@ This error is thrown when `/etc/gitlab/gitlab.rb` configuration file contains
configuration that is invalid or unsupported. Double check that there are no
typos or that the configuration file does not contain obsolete configuration.
You can check the latest available configuration by using `sudo gitlab-ctl diff-config` (Command available starting with GitLab 8.17) or check the latest [`gitlab.rb.template`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template).
You can check the latest available configuration by using `sudo gitlab-ctl diff-config` or check the latest [`gitlab.rb.template`](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template).
## GitLab is unreachable in my browser
@ -166,7 +166,7 @@ get their security context messed up. You can fix this by running `sudo
gitlab-ctl reconfigure`, which sets the `gitlab_shell_t` security context on
`/var/opt/gitlab/.ssh`.
In GitLab 10.0 this behavior was improved by setting the context permanently using
To improve this behavior, we set the context permanently using
`semanage`. The runtime dependency `policycoreutils-python` has been added to the
RPM package for RHEL based operating systems in order to ensure the `semanage`
command is available.
@ -537,7 +537,7 @@ how to override the default headers.
## Extension missing pg_trgm
Starting from GitLab 8.6, [GitLab requires](https://docs.gitlab.com/ee/install/requirements.html#postgresql-requirements)
[GitLab requires](https://docs.gitlab.com/ee/install/requirements.html#postgresql-requirements)
the PostgreSQL extension `pg_trgm`.
If you are using Omnibus GitLab package with the bundled database, the extension
should be automatically enabled when you upgrade.
@ -641,7 +641,7 @@ will need to switch to using `no_root_squash` in your NFS exports on the NFS ser
This applies to operating systems using systemd (e.g. Ubuntu 18.04+, CentOS, etc.).
Since GitLab 11.2, the `gitlab-runsvdir` starts during the `multi-user.target`
`gitlab-runsvdir` starts during the `multi-user.target`
instead of `basic.target`. If you are having trouble starting this service
after upgrading GitLab, you may need to check that your system has properly
booted all the required services for `multi-user.target` via the command: