diff options
Diffstat (limited to 'doc/administration')
17 files changed, 44 insertions, 44 deletions
diff --git a/doc/administration/auth/ldap/ldap-troubleshooting.md b/doc/administration/auth/ldap/ldap-troubleshooting.md index 1215d90134f..5e6c3443e44 100644 --- a/doc/administration/auth/ldap/ldap-troubleshooting.md +++ b/doc/administration/auth/ldap/ldap-troubleshooting.md @@ -552,7 +552,7 @@ LDAP. If the email has changed and the DN has not, GitLab finds the user with the DN and update its own record of the user's email to match the one in LDAP. -However, if the primary email _and_ the DN change in LDAP, then GitLab +However, if the primary email _and_ the DN change in LDAP, then GitLab has no way of identifying the correct LDAP record of the user and, as a result, the user is blocked. To rectify this, the user's existing profile must be updated with at least one of the new values (primary diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md index 1c1066c8e12..1aa01ae1f64 100644 --- a/doc/administration/database_load_balancing.md +++ b/doc/administration/database_load_balancing.md @@ -109,17 +109,17 @@ the following. This balances the load between `host1.example.com` and Sidekiq mostly writes to the database, which means that most of its traffic hits the primary database. -Some background jobs can use database replicas to read application state. +Some background jobs can use database replicas to read application state. This allows to offload the primary database. Load balancing is disabled by default in Sidekiq. When enabled, we can define [the data consistency](../development/sidekiq_style_guide.md#job-data-consistency-strategies) requirements for a specific job. -To enable it, define the `ENABLE_LOAD_BALANCING_FOR_SIDEKIQ` variable to the environment, as shown below. +To enable it, define the `ENABLE_LOAD_BALANCING_FOR_SIDEKIQ` variable to the environment, as shown below. For Omnibus installations: - + ```ruby gitlab_rails['env'] = {"ENABLE_LOAD_BALANCING_FOR_SIDEKIQ" => "true"} ``` diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md index 6989765dbad..a56d9dc813c 100644 --- a/doc/administration/geo/replication/datatypes.md +++ b/doc/administration/geo/replication/datatypes.md @@ -209,6 +209,6 @@ successfully, you must replicate their data using some other means. #### Limitation of verification for files in Object Storage -GitLab managed Object Storage replication support [is in beta](object_storage.md#enabling-gitlab-managed-object-storage-replication). +GitLab managed Object Storage replication support [is in beta](object_storage.md#enabling-gitlab-managed-object-storage-replication). Locally stored files are verified but remote stored files are not. diff --git a/doc/administration/geo/replication/version_specific_updates.md b/doc/administration/geo/replication/version_specific_updates.md index 557f93c3712..b8f847d163c 100644 --- a/doc/administration/geo/replication/version_specific_updates.md +++ b/doc/administration/geo/replication/version_specific_updates.md @@ -13,7 +13,7 @@ for updating Geo nodes. ## Updating to GitLab 13.11 -We found an [issue with Git clone/pull through HTTP(s)](https://gitlab.com/gitlab-org/gitlab/-/issues/330787) on Geo secondaries and on any GitLab instance if maintenance mode is enabled. This was caused by a regression in GitLab Workhorse. This is fixed in the [GitLab 13.11.4 patch release](https://about.gitlab.com/releases/2021/05/14/gitlab-13-11-4-released/). To avoid this issue, upgrade to GitLab 13.11.4 or later. +We found an [issue with Git clone/pull through HTTP(s)](https://gitlab.com/gitlab-org/gitlab/-/issues/330787) on Geo secondaries and on any GitLab instance if maintenance mode is enabled. This was caused by a regression in GitLab Workhorse. This is fixed in the [GitLab 13.11.4 patch release](https://about.gitlab.com/releases/2021/05/14/gitlab-13-11-4-released/). To avoid this issue, upgrade to GitLab 13.11.4 or later. ## Updating to GitLab 13.9 diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md index a5a6311287c..a3b48476941 100644 --- a/doc/administration/geo/setup/database.md +++ b/doc/administration/geo/setup/database.md @@ -31,17 +31,17 @@ A single instance database replication is easier to set up and still provides th as a clusterized alternative. It's useful for setups running on a single machine or trying to evaluate Geo for a future clusterized installation. -A single instance can be expanded to a clusterized version using Patroni, which is recommended for a +A single instance can be expanded to a clusterized version using Patroni, which is recommended for a highly available architecture. -Follow below the instructions on how to set up PostgreSQL replication as a single instance database. -Alternatively, you can look at the [Multi-node database replication](#multi-node-database-replication) +Follow below the instructions on how to set up PostgreSQL replication as a single instance database. +Alternatively, you can look at the [Multi-node database replication](#multi-node-database-replication) instructions on setting up replication with a Patroni cluster. ### PostgreSQL replication The GitLab **primary** node where the write operations happen connects to -the **primary** database server, and **secondary** nodes +the **primary** database server, and **secondary** nodes connect to their own database servers (which are also read-only). We recommend using [PostgreSQL replication slots](https://medium.com/@tk512/replication-slots-in-postgresql-b4b03d277c75) @@ -112,13 +112,13 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o # must be present in all application nodes. gitlab_rails['db_password'] = '<your_password_here>' ``` - + 1. Define a password for the database [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication). We will use the username defined in `/etc/gitlab/gitlab.rb` under the `postgresql['sql_replication_user']` - setting. The default value is `gitlab_replicator`, but if you changed it to something else, adapt + setting. The default value is `gitlab_replicator`, but if you changed it to something else, adapt the instructions below. - + Generate a MD5 hash of the desired password: ```shell @@ -484,12 +484,12 @@ The replication process is now complete. ### PgBouncer support (optional) [PgBouncer](https://www.pgbouncer.org/) may be used with GitLab Geo to pool -PostgreSQL connections, which can improve performance even when using in a -single instance installation. +PostgreSQL connections, which can improve performance even when using in a +single instance installation. We recommend using 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. One for the +configuration with a cluster of nodes supporting a Geo **primary** site and +two other clusters of nodes supporting a Geo **secondary** site. 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). @@ -505,7 +505,7 @@ If you still haven't [migrated from repmgr to Patroni](#migrating-from-repmgr-to Patroni is the official replication management solution for Geo. It can be used to build a highly available cluster on the **primary** and a **secondary** Geo site. -Using Patroni on a **secondary** site is optional and you don't have to use the same amount of +Using Patroni on a **secondary** site is optional and you don't have to use the same amount of nodes on each Geo site. For instructions about how to set up Patroni on the primary site, see the @@ -515,7 +515,7 @@ For instructions about how to set up Patroni on the primary site, see the In a Geo secondary site, the main PostgreSQL database is a read-only replica of the primary site’s PostgreSQL database. -If you are currently using `repmgr` on your Geo primary site, see [these instructions](#migrating-from-repmgr-to-patroni) +If you are currently using `repmgr` on your Geo primary site, see [these instructions](#migrating-from-repmgr-to-patroni) for migrating from `repmgr` to Patroni. A production-ready and secure setup requires at least: @@ -526,9 +526,9 @@ A production-ready and secure setup requires at least: - 1 internal load-balancer _(primary site only)_ The internal load balancer provides a single endpoint for connecting to the Patroni cluster's leader whenever a new leader is -elected, and it is required for enabling cascading replication from the secondary sites. +elected, and it is required for enabling cascading replication from the secondary sites. -Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni) +Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni) and other database best practices. ##### Step 1. Configure Patroni permanent replication slot on the primary site @@ -790,13 +790,13 @@ 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. -If you want to run this database in a highly available configuration, don't use the `geo_secondary_role` above. +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. A production-ready and secure setup requires at least three Consul nodes, two Patroni nodes and one PgBouncer node on the secondary site. -Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni) +Be sure to use [password credentials](../../postgresql/replication_and_failover.md#database-authorization-for-patroni) and other database best practices. #### Step 1. Configure a PgBouncer node on the secondary site diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md index 9e187424afa..62b258afcf3 100644 --- a/doc/administration/geo/setup/external_database.md +++ b/doc/administration/geo/setup/external_database.md @@ -208,8 +208,8 @@ the tracking database on port 5432. 1. Set up PostgreSQL according to the [database requirements document](../../../install/requirements.md#database). 1. Set up a `gitlab_geo` user with a password of your choice, create the `gitlabhq_geo_production` database, and make the user an owner of the database. You can see an example of this setup in the [installation from source documentation](../../../install/installation.md#6-database). -1. If you are **not** using a cloud-managed PostgreSQL database, ensure that your secondary - node can communicate with your tracking database by manually changing the +1. If you are **not** using a cloud-managed PostgreSQL database, ensure that your secondary + node can communicate with your tracking database by manually changing the `pg_hba.conf` that is associated with your tracking database. Remember to restart PostgreSQL afterwards for the changes to take effect: diff --git a/doc/administration/job_logs.md b/doc/administration/job_logs.md index d42444b4ec2..54a5bdaaf67 100644 --- a/doc/administration/job_logs.md +++ b/doc/administration/job_logs.md @@ -145,7 +145,7 @@ in `/var/opt/gitlab/gitlab-ci/builds` by Omnibus GitLab. After the job completes a background job archives the job log. The log is moved to `/var/opt/gitlab/gitlab-rails/shared/artifacts/` by default, or to object storage if configured. -In a [scaled-out architecture](reference_architectures/index.md) with Rails and Sidekiq running on more than one +In a [scaled-out architecture](reference_architectures/index.md) with Rails and Sidekiq running on more than one server, these two locations on the filesystem have to be shared using NFS. To eliminate both filesystem requirements: diff --git a/doc/administration/operations/extra_sidekiq_processes.md b/doc/administration/operations/extra_sidekiq_processes.md index b910a789d29..34bf7214441 100644 --- a/doc/administration/operations/extra_sidekiq_processes.md +++ b/doc/administration/operations/extra_sidekiq_processes.md @@ -171,7 +171,7 @@ When disabling `sidekiq_cluster`, you must copy your configuration for `sidekiq_cluster` is overridden by the options for `sidekiq` when setting `sidekiq['cluster'] = true`. -When using this feature, the service called `sidekiq` is now +When using this feature, the service called `sidekiq` is now running `sidekiq-cluster`. The [concurrency](#manage-concurrency) and other options configured diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md index a6829b90f18..15a93981ccb 100644 --- a/doc/administration/packages/container_registry.md +++ b/doc/administration/packages/container_registry.md @@ -1359,7 +1359,7 @@ For Omnibus installations: [image upgrade](#images-upgrade)) steps. You should [stop](https://docs.gitlab.com/omnibus/maintenance/#starting-and-stopping) the registry service before replacing its binary and start it right after. No registry configuration changes are required. - + #### Source installations For source installations, locate your `registry` binary and temporarily replace it with the one diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md index 55f5c977b02..f94a500746c 100644 --- a/doc/administration/reference_architectures/10k_users.md +++ b/doc/administration/reference_architectures/10k_users.md @@ -1605,7 +1605,7 @@ To configure the Praefect nodes, on each one: 1. Praefect requires to run some database migrations, much like the main GitLab application. For this you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node must be configured first before the others as follows: - + 1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true` 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: @@ -1613,7 +1613,7 @@ To configure the Praefect nodes, on each one: ```shell sudo touch /etc/gitlab/skip-auto-reconfigure ``` - + 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and to run the Praefect database migrations. diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md index 1322f05f93a..aed54b236ce 100644 --- a/doc/administration/reference_architectures/25k_users.md +++ b/doc/administration/reference_architectures/25k_users.md @@ -1623,7 +1623,7 @@ the file of the same name on this server. If this is the first Omnibus node you 1. Praefect requires to run some database migrations, much like the main GitLab application. For this you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node must be configured first before the others as follows: - + 1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true` 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: @@ -1631,7 +1631,7 @@ the file of the same name on this server. If this is the first Omnibus node you ```shell sudo touch /etc/gitlab/skip-auto-reconfigure ``` - + 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and to run the Praefect database migrations. diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md index b2d153182e9..71ca67075d3 100644 --- a/doc/administration/reference_architectures/3k_users.md +++ b/doc/administration/reference_architectures/3k_users.md @@ -829,7 +829,7 @@ in the second step, do not supply the `EXTERNAL_URL` value. username of `gitlab_replicator` (recommended). The command will request a password and a confirmation. Use the value that is output by this command in the next step as the value of `<postgresql_replication_password_hash>`: - + ```shell sudo gitlab-ctl pg-password-md5 gitlab_replicator ``` @@ -1328,7 +1328,7 @@ the file of the same name on this server. If this is the first Omnibus node you 1. Praefect requires to run some database migrations, much like the main GitLab application. For this you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node must be configured first before the others as follows: - + 1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true` 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: @@ -1336,7 +1336,7 @@ the file of the same name on this server. If this is the first Omnibus node you ```shell sudo touch /etc/gitlab/skip-auto-reconfigure ``` - + 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and to run the Praefect database migrations. diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md index 03c40eea153..51c80330329 100644 --- a/doc/administration/reference_architectures/50k_users.md +++ b/doc/administration/reference_architectures/50k_users.md @@ -1627,7 +1627,7 @@ the file of the same name on this server. If this is the first Omnibus node you 1. Praefect requires to run some database migrations, much like the main GitLab application. For this you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node must be configured first before the others as follows: - + 1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true` 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: @@ -1635,7 +1635,7 @@ the file of the same name on this server. If this is the first Omnibus node you ```shell sudo touch /etc/gitlab/skip-auto-reconfigure ``` - + 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and to run the Praefect database migrations. diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md index 563fad98f59..3456e1193bd 100644 --- a/doc/administration/reference_architectures/5k_users.md +++ b/doc/administration/reference_architectures/5k_users.md @@ -1320,7 +1320,7 @@ the file of the same name on this server. If this is the first Omnibus node you 1. Praefect requires to run some database migrations, much like the main GitLab application. For this you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node must be configured first before the others as follows: - + 1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true` 1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run: @@ -1328,7 +1328,7 @@ the file of the same name on this server. If this is the first Omnibus node you ```shell sudo touch /etc/gitlab/skip-auto-reconfigure ``` - + 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and to run the Praefect database migrations. diff --git a/doc/administration/repository_storage_paths.md b/doc/administration/repository_storage_paths.md index a1391f3e0ed..3a80b922d1a 100644 --- a/doc/administration/repository_storage_paths.md +++ b/doc/administration/repository_storage_paths.md @@ -155,5 +155,5 @@ often it is chosen. That is, `(storage weight) / (sum of all weights) * 100 = ch ## Move repositories -To move a repository to a different repository storage (for example, from `default` to `storage2`), use the +To move a repository to a different repository storage (for example, from `default` to `storage2`), use the same process as [migrating to Gitaly Cluster](gitaly/praefect.md#migrate-to-gitaly-cluster). diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md index 748bc95aa6c..04c83370b60 100644 --- a/doc/administration/troubleshooting/debug.md +++ b/doc/administration/troubleshooting/debug.md @@ -224,7 +224,7 @@ gitlab_rails['env'] = { } ``` -For source installations, set the environment variable. +For source installations, set the environment variable. Refer to [Puma Worker timeout](https://docs.gitlab.com/omnibus/settings/puma.html#worker-timeout). [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect. diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md index b6dc1907af5..c759ca4b168 100644 --- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md +++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md @@ -348,10 +348,10 @@ end puts "#{artifact_storage} bytes" ``` -### Identify deploy keys associated with blocked and non-member users +### Identify deploy keys associated with blocked and non-member users -When the user who created a deploy key is blocked or removed from the project, the key -can no longer be used to push to protected branches in a private project (see [issue #329742](https://gitlab.com/gitlab-org/gitlab/-/issues/329742)). +When the user who created a deploy key is blocked or removed from the project, the key +can no longer be used to push to protected branches in a private project (see [issue #329742](https://gitlab.com/gitlab-org/gitlab/-/issues/329742)). The following script identifies unusable deploy keys: ```ruby |