Skip to content
Snippets Groups Projects
Commit 160847ae authored by feistel's avatar feistel
Browse files

Fix vale warnings related to group: distribution

parent ac0c16e2
No related branches found
No related tags found
1 merge request!90192Fix vale warnings related to group: distribution
......@@ -149,7 +149,7 @@ To extract the HTML files of the Docs site:
docker cp gitlab-docs:/usr/share/nginx/html /srv/gitlab/
```
You will end up with a `/srv/gitlab/html/` directory that holds the documentation website.
You end up with a `/srv/gitlab/html/` directory that holds the documentation website.
1. Remove the container:
......
......@@ -24,7 +24,7 @@ file system performance, see
Starting with GitLab version 14.0, support for NFS to store Git repository data is deprecated. Technical customer support and engineering support is available for the 14.x releases. Engineering is fixing bugs and security vulnerabilities consistent with our [release and maintenance policy](../policy/maintenance.md#security-releases).
Upon the release of GitLab 15.6 technical and engineering support for using NFS to store Git repository data will be officially at end-of-life. There will be no product changes or troubleshooting provided via Engineering, Security or Paid Support channels after the release date of 15.6, regardless of your GitLab version.
Upon the release of GitLab 15.6 technical and engineering support for using NFS to store Git repository data is officially at end-of-life. There are no product changes or troubleshooting provided via Engineering, Security or Paid Support channels after the release date of 15.6, regardless of your GitLab version.
Until the release of 15.6, for customers running 14.x releases, we continue to help with Git related tickets from customers running one or more Gitaly servers with its data stored on NFS. Examples may include:
......@@ -268,9 +268,9 @@ version of a directory.
From the [Linux man page](https://linux.die.net/man/5/nfs), the important parts:
> If the nocto option is specified, the client uses a non-standard heuristic to determine when files on the server have changed.
> If the `nocto` option is specified, the client uses a non-standard heuristic to determine when files on the server have changed.
>
> Using the nocto option may improve performance for read-only mounts, but should be used only if the data on the server changes only occasionally.
> Using the `nocto` option may improve performance for read-only mounts, but should be used only if the data on the server changes only occasionally.
We have noticed this behavior in an issue about [refs not found after a push](https://gitlab.com/gitlab-org/gitlab/-/issues/326066),
where newly added loose refs can be seen as missing on a different client with a local dentry cache, as
......
......@@ -162,7 +162,7 @@ Be aware of the following specific call outs:
### Praefect PostgreSQL
It's worth noting that at this time [Praefect requires its own database server](../gitaly/praefect.md#postgresql) and
that to achieve full High Availability a third-party PostgreSQL database solution will be required.
that to achieve full High Availability a third-party PostgreSQL database solution is required.
We hope to offer a built in solutions for these restrictions in the future but in the meantime a non HA PostgreSQL server
can be set up via Omnibus GitLab, which the above specs reflect. Refer to the following issues for more information: [`omnibus-gitlab#5919`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5919) & [`gitaly#3398`](https://gitlab.com/gitlab-org/gitaly/-/issues/3398).
......@@ -232,7 +232,7 @@ The following list includes descriptions of each server and its assigned IP:
## Configure the external load balancer
In a multi-node GitLab configuration, you'll need a load balancer to route
In a multi-node GitLab configuration, you need a load balancer to route
traffic to the application servers. The specifics on which load balancer to use
or its exact configuration is beyond the scope of GitLab documentation. We assume
that if you're managing multi-node systems like GitLab, you already have a load
......@@ -245,7 +245,7 @@ This architecture has been tested and validated with [HAProxy](https://www.hapro
as the load balancer. Although other load balancers with similar feature sets
could also be used, those load balancers have not been validated.
The next question is how you will handle SSL in your environment.
The next question is how you handle SSL in your environment.
There are several different options:
- [The application node terminates SSL](#application-node-terminates-ssl).
......@@ -257,8 +257,8 @@ There are several different options:
### Application node terminates SSL
Configure your load balancer to pass connections on port 443 as `TCP` rather
than `HTTP(S)` protocol. This will pass the connection to the application node's
NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
than `HTTP(S)` protocol. This passes the connection to the application node's
NGINX service untouched. NGINX has the SSL certificate and listen on port 443.
See the [NGINX HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
for details on managing SSL certificates and configuring NGINX.
......@@ -266,10 +266,10 @@ for details on managing SSL certificates and configuring NGINX.
### Load balancer terminates SSL without backend SSL
Configure your load balancer to use the `HTTP(S)` protocol rather than `TCP`.
The load balancer will then be responsible for managing SSL certificates and
The load balancer is then responsible for managing SSL certificates and
terminating SSL.
Since communication between the load balancer and GitLab will not be secure,
Since communication between the load balancer and GitLab is not secure,
there is some additional configuration needed. See the
[NGINX proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl)
for details.
......@@ -277,12 +277,12 @@ for details.
### Load balancer terminates SSL with backend SSL
Configure your load balancers to use the 'HTTP(S)' protocol rather than 'TCP'.
The load balancers will be responsible for managing SSL certificates that
end users will see.
The load balancers are responsible for managing SSL certificates that
end users see.
Traffic will also be secure between the load balancers and NGINX in this
Traffic is also secure between the load balancers and NGINX in this
scenario. There is no need to add configuration for proxied SSL since the
connection will be secure all the way. However, configuration will need to be
connection is secure all the way. However, configuration needs to be
added to GitLab to configure SSL certificates. See
[NGINX HTTPS documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
for details on managing SSL certificates and configuring NGINX.
......@@ -292,7 +292,7 @@ for details on managing SSL certificates and configuring NGINX.
Ensure the external load balancer only routes to working services with built
in monitoring endpoints. The [readiness checks](../../user/admin_area/monitoring/health_check.md)
all require [additional configuration](../monitoring/ip_whitelist.md)
on the nodes being checked, otherwise, the external load balancer will not be able to
on the nodes being checked, otherwise, the external load balancer is not able to
connect.
### Ports
......@@ -311,11 +311,11 @@ The basic ports to be used are shown in the table below.
to pass through the `Connection` and `Upgrade` hop-by-hop headers. See the
[web terminal](../integration/terminal.md) integration guide for
more details.
- (*2*): When using HTTPS protocol for port 443, you will need to add an SSL
- (*2*): When using HTTPS protocol for port 443, you need to add an SSL
certificate to the load balancers. If you wish to terminate SSL at the
GitLab application server instead, use TCP protocol.
If you're using GitLab Pages with custom domain support you will need some
If you're using GitLab Pages with custom domain support you need some
additional port configurations.
GitLab Pages requires a separate virtual IP address. Configure DNS to point the
`pages_external_url` from `/etc/gitlab/gitlab.rb` at the new virtual IP address. See the
......@@ -337,7 +337,7 @@ GitLab Pages requires a separate virtual IP address. Configure DNS to point the
Some organizations have policies against opening SSH port 22. In this case,
it may be helpful to configure an alternate SSH hostname that allows users
to use SSH on port 443. An alternate SSH hostname will require a new virtual IP address
to use SSH on port 443. An alternate SSH hostname requires a new virtual IP address
compared to the other GitLab HTTP configuration above.
Configure DNS for an alternate SSH hostname such as `altssh.gitlab.example.com`.
......@@ -359,7 +359,7 @@ such as connections to [PgBouncer](#configure-pgbouncer) and [Praefect](#configu
It's a separate node from the External Load Balancer and shouldn't have any access externally.
The following IP will be used as an example:
The following IP is used as an example:
- `10.6.0.40`: Internal Load Balancer
......@@ -433,8 +433,8 @@ You are highly encouraged to read the [Redis Sentinel](https://redis.io/topics/s
before configuring Redis with GitLab to fully understand the topology and
architecture.
In this section, you'll be guided through configuring an external Redis instance
to be used with GitLab. The following IPs will be used as an example:
In this section, you are guided through configuring an external Redis instance
to be used with GitLab. The following IPs are used as an example:
- `10.6.0.61`: Redis Primary
- `10.6.0.62`: Redis Replica 1
......@@ -442,7 +442,7 @@ to be used with GitLab. The following IPs will be used as an example:
### Provide your own Redis instance
Managed Redis from cloud providers such as AWS ElastiCache will work. If these
Managed Redis from cloud providers such as AWS ElastiCache works. If these
services support high availability, be sure it is **not** the Redis Cluster type.
Redis version 5.0 or higher is required, as this is what ships with
......@@ -451,7 +451,7 @@ do not support an optional count argument to SPOP which is now required for
[Merge Trains](../../ci/pipelines/merge_trains.md).
Note the Redis node's IP address or hostname, port, and password (if required).
These will be necessary when configuring the
These are necessary when configuring the
[GitLab application servers](#configure-gitlab-rails) later.
### Standalone Redis using Omnibus GitLab
......@@ -617,8 +617,8 @@ You can specify multiple roles, like sentinel and Redis, as:
[roles](https://docs.gitlab.com/omnibus/roles/).
These values don't have to be changed again in `/etc/gitlab/gitlab.rb` after
a failover, as the nodes will be managed by the [Sentinels](#configure-consul-and-sentinel), and even after a
`gitlab-ctl reconfigure`, they will get their configuration restored by
a failover, as the nodes are managed by the [Sentinels](#configure-consul-and-sentinel), and even after a
`gitlab-ctl reconfigure`, they get their configuration restored by
the same Sentinels.
Advanced [configuration options](https://docs.gitlab.com/omnibus/settings/redis.html)
......@@ -633,7 +633,7 @@ are supported and can be added if needed.
## Configure Consul and Sentinel
Now that the Redis servers are all set up, let's configure the Sentinel
servers. The following IPs will be used as an example:
servers. The following IPs are used as an example:
- `10.6.0.11`: Consul/Sentinel 1
- `10.6.0.12`: Consul/Sentinel 2
......@@ -647,7 +647,7 @@ clients to report `NOAUTH Authentication required.`.
To configure the Sentinel:
1. SSH in to the server that will host Consul/Sentinel.
1. SSH in to the server that hosts Consul/Sentinel.
1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
package of your choice. Be sure to both follow _only_ installation steps 1 and 2
on the page, and to select the correct Omnibus GitLab package, with the same version
......@@ -776,7 +776,7 @@ run: sentinel: (pid 30098) 76832s; run: log: (pid 29704) 76850s
## Configure PostgreSQL
In this section, you'll be guided through configuring a highly available PostgreSQL
In this section, you are guided through configuring a highly available PostgreSQL
cluster to be used with GitLab.
### Provide your own PostgreSQL instance
......@@ -813,7 +813,7 @@ replication and failover requires:
A local PgBouncer service to be configured on each PostgreSQL node. Note that this is separate from the main PgBouncer cluster that tracks the primary.
The following IPs will be used as an example:
The following IPs are used as an example:
- `10.6.0.31`: PostgreSQL primary
- `10.6.0.32`: PostgreSQL secondary 1
......@@ -828,8 +828,8 @@ in the second step, do not supply the `EXTERNAL_URL` value.
#### PostgreSQL nodes
1. SSH in to one of the PostgreSQL nodes.
1. Generate a password hash for the PostgreSQL username/password pair. This assumes you will use the default
username of `gitlab` (recommended). The command will request a password
1. Generate a password hash for the PostgreSQL username/password pair. This assumes you use the default
username of `gitlab` (recommended). The command requests a password
and confirmation. Use the value that is output by this command in the next
step as the value of `<postgresql_password_hash>`:
......@@ -837,8 +837,8 @@ in the second step, do not supply the `EXTERNAL_URL` value.
sudo gitlab-ctl pg-password-md5 gitlab
```
1. Generate a password hash for the PgBouncer username/password pair. This assumes you will use the default
username of `pgbouncer` (recommended). The command will request a password
1. Generate a password hash for the PgBouncer username/password pair. This assumes you use the default
username of `pgbouncer` (recommended). The command requests a password
and confirmation. Use the value that is output by this command in the next
step as the value of `<pgbouncer_password_hash>`:
......@@ -846,8 +846,8 @@ in the second step, do not supply the `EXTERNAL_URL` value.
sudo gitlab-ctl pg-password-md5 pgbouncer
```
1. Generate a password hash for the PostgreSQL replication username/password pair. This assumes you will use the default
username of `gitlab_replicator` (recommended). The command will request a password
1. Generate a password hash for the PostgreSQL replication username/password pair. This assumes you use the default
username of `gitlab_replicator` (recommended). The command requests 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>`:
......@@ -855,8 +855,8 @@ in the second step, do not supply the `EXTERNAL_URL` value.
sudo gitlab-ctl pg-password-md5 gitlab_replicator
```
1. Generate a password hash for the Consul database username/password pair. This assumes you will use the default
username of `gitlab-consul` (recommended). The command will request a password
1. Generate a password hash for the Consul database username/password pair. This assumes you use the default
username of `gitlab-consul` (recommended). The command requests a password
and confirmation. Use the value that is output by this command in the next
step as the value of `<consul_password_hash>`:
......@@ -935,7 +935,7 @@ in the second step, do not supply the `EXTERNAL_URL` value.
# END user configuration
```
PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind` by default to handle conflicts.
PostgreSQL, with Patroni managing its failover, defaults to use `pg_rewind` by default to handle conflicts.
Like most failover handling methods, this has a small chance of leading to data loss.
Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
......@@ -987,7 +987,7 @@ If the 'State' column for any node doesn't say "running", check the
Now that the PostgreSQL servers are all set up, let's configure PgBouncer
for tracking and handling reads/writes to the primary database.
The following IPs will be used as an example:
The following IPs are used as an example:
- `10.6.0.21`: PgBouncer 1
- `10.6.0.22`: PgBouncer 2
......@@ -1111,9 +1111,9 @@ The recommended cluster setup includes the following components:
- 1 Praefect PostgreSQL node: Database server for Praefect. A third-party solution
is required for Praefect database connections to be made highly available.
- 1 load balancer: A load balancer is required for Praefect. The
[internal load balancer](#configure-the-internal-load-balancer) will be used.
[internal load balancer](#configure-the-internal-load-balancer) is used.
This section will detail how to configure the recommended standard setup in order.
This section details how to configure the recommended standard setup in order.
For more advanced setups refer to the [standalone Gitaly Cluster documentation](../gitaly/praefect.md).
### Configure Praefect PostgreSQL
......@@ -1125,7 +1125,7 @@ A built-in solution is being [worked on](https://gitlab.com/gitlab-org/omnibus-g
#### Praefect non-HA PostgreSQL standalone using Omnibus GitLab
The following IPs will be used as an example:
The following IPs are used as an example:
- `10.6.0.141`: Praefect PostgreSQL
......@@ -1137,8 +1137,8 @@ in the second step, do not supply the `EXTERNAL_URL` value.
1. SSH in to the Praefect PostgreSQL node.
1. Create a strong password to be used for the Praefect PostgreSQL user. Take note of this password as `<praefect_postgresql_password>`.
1. Generate the password hash for the Praefect PostgreSQL username/password pair. This assumes you will use the default
username of `praefect` (recommended). The command will request the password `<praefect_postgresql_password>`
1. Generate the password hash for the Praefect PostgreSQL username/password pair. This assumes you use the default
username of `praefect` (recommended). The command requests the password `<praefect_postgresql_password>`
and confirmation. Use the value that is output by this command in the next
step as the value of `<praefect_postgresql_password_hash>`:
......@@ -1221,7 +1221,7 @@ Once the database is set up, follow the [post configuration](#praefect-postgresq
#### Praefect PostgreSQL post-configuration
After the Praefect PostgreSQL server has been set up, you'll then need to configure the user and database for Praefect to use.
After the Praefect PostgreSQL server has been set up, you then need to configure the user and database for Praefect to use.
We recommend the user be named `praefect` and the database `praefect_production`, and these can be configured as standard in PostgreSQL.
The password for the user is the same as the one you configured earlier as `<praefect_postgresql_password>`.
......@@ -1274,12 +1274,12 @@ Praefect requires several secret tokens to secure communications across the Clus
Gitaly Cluster nodes are configured in Praefect via a `virtual storage`. Each storage contains
the details of each Gitaly node that makes up the cluster. Each storage is also given a name
and this name is used in several areas of the configuration. In this guide, the name of the storage will be
and this name is used in several areas of the configuration. In this guide, the name of the storage is
`default`. Also, this guide is geared towards new installs, if upgrading an existing environment
to use Gitaly Cluster, you may need to use a different name.
Refer to the [Praefect documentation](../gitaly/praefect.md#praefect) for more information.
The following IPs will be used as an example:
The following IPs are used as an example:
- `10.6.0.131`: Praefect 1
- `10.6.0.132`: Praefect 2
......@@ -1429,7 +1429,7 @@ For configuring Gitaly you should note the following:
- `git_data_dirs` should be configured to reflect the storage path for the specific Gitaly node
- `auth_token` should be the same as `praefect_internal_token`
The following IPs will be used as an example:
The following IPs are used as an example:
- `10.6.0.91`: Gitaly 1
- `10.6.0.92`: Gitaly 2
......@@ -1811,7 +1811,7 @@ On each node perform the following:
```
1. Specify the necessary NFS mounts in `/etc/fstab`.
The exact contents of `/etc/fstab` will depend on how you chose
The exact contents of `/etc/fstab` depends on how you chose
to configure your NFS server. See the [NFS documentation](../nfs.md)
for examples and the various options.
......@@ -1827,9 +1827,9 @@ On each node perform the following:
on the page.
1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration.
To maintain uniformity of links across nodes, the `external_url`
on the application server should point to the external URL that users will use
on the application server should point to the external URL that users use
to access GitLab. This would be the URL of the [external load balancer](#configure-the-external-load-balancer)
which will route traffic to the GitLab application server:
which routes traffic to the GitLab application server:
```ruby
external_url 'https://gitlab.example.com'
......@@ -1999,7 +1999,7 @@ On each node perform the following:
When you specify `https` in the `external_url`, as in the previous example,
GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
certificates aren't present, NGINX will fail to start. For more information, see
certificates aren't present, NGINX fails to start. For more information, see
the [NGINX documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https).
### GitLab Rails post-configuration
......
......@@ -296,7 +296,7 @@ The following table details the cost to run the different reference architecture
NOTE:
The following lists are non exhaustive. Generally, other cloud providers not listed
here will likely work with the same specs, but this hasn't been validated.
here likely work with the same specs, but this hasn't been validated.
Additionally, when it comes to other cloud provider services not listed here,
it's advised to be cautious as each implementation can be notably different
and should be tested thoroughly before production use.
......@@ -389,7 +389,7 @@ most complex:
As you implement these components, begin with a single server and then do
backups. Only after completing the first server should you proceed to the next.
Also, not implementing extra servers for GitLab doesn't necessarily mean that you'll have
Also, not implementing extra servers for GitLab doesn't necessarily mean that you have
more downtime. Depending on your needs and experience level, single servers can
have more actual perceived uptime for your users.
......@@ -410,7 +410,7 @@ is the least complex to setup. This provides a point-in-time recovery of a prede
> - Required domain knowledge: HAProxy, shared storage, distributed systems
This requires separating out GitLab into multiple application nodes with an added
[load balancer](../load_balancer.md). The load balancer will distribute traffic
[load balancer](../load_balancer.md). The load balancer distributes traffic
across GitLab application nodes. Meanwhile, each application node connects to a
shared file server and database systems on the back end. This way, if one of the
application servers fails, the workflow is not interrupted.
......@@ -434,7 +434,7 @@ to any of the [available reference architectures](#available-reference-architect
GitLab supports [zero-downtime upgrades](../../update/zero_downtime.md).
Single GitLab nodes can be updated with only a [few minutes of downtime](../../update/index.md#upgrade-based-on-installation-method).
To avoid this, we recommend to separate GitLab into several application nodes.
As long as at least one of each component is online and capable of handling the instance's usage load, your team's productivity will not be interrupted during the update.
As long as at least one of each component is online and capable of handling the instance's usage load, your team's productivity is not interrupted during the update.
### Automated database failover **(PREMIUM SELF)**
......@@ -459,8 +459,8 @@ that can also be promoted in case of disaster.
## Deviating from the suggested reference architectures
As a general guideline, the further away you move from the Reference Architectures,
the harder it will be get support for it. With any deviation, you're introducing
a layer of complexity that will add challenges to finding out where potential
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
......@@ -474,7 +474,7 @@ However, it is still an additional layer and may still add some support complexi
Other technologies, like [Docker swarm](https://docs.docker.com/engine/swarm/)
are not officially supported, but can be implemented at your own risk. In that
case, GitLab Support will not be able to help you.
case, GitLab Support is not able to help you.
## Supported modifications for lower user count HA reference architectures
......
......@@ -24,7 +24,7 @@ files must be provided:
- Only RSA keys are supported.
Optionally, you can also provide a bundle of CA certs (PEM-encoded) to be
included on each signature. This will typically be an intermediate CA.
included on each signature. This is typically an intermediate CA.
WARNING:
Be mindful of the access levels for your private keys and visibility to
......
......@@ -747,7 +747,7 @@ for how to proceed.
- [`geo_job_artifact_deleted_events`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66763)
- [`push_event_payloads`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67299)
- `ci_job_artifacts`:
- [Finalize job_id conversion to `bigint` for `ci_job_artifacts`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67774)
- [Finalize `job_id` conversion to `bigint` for `ci_job_artifacts`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67774)
- [Finalize `ci_job_artifacts` conversion to `bigint`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65601)
If the migrations are executed as part of a no-downtime deployment, there's a risk of failure due to lock conflicts with the application logic, resulting in lock timeout or deadlocks. In each case, these migrations are safe to re-run until successful:
......
......@@ -15,7 +15,7 @@ Converting from the same version of CE to EE is not explicitly necessary, and an
you are upgrading the same version (for example, CE 12.1 to EE 12.1), which is **recommended**.
WARNING:
When updating to EE from CE, avoid reverting back to CE if you plan on going to EE again in the
When updating to EE from CE, avoid reverting back to CE if you plan to go to EE again in the
future. Reverting back to CE can cause
[database issues](index.md#500-error-when-accessing-project--settings--repository)
that may require Support intervention.
......@@ -31,7 +31,7 @@ The steps can be summed up to:
```
The output should be similar to: `Installed: 13.0.4-ce.0`. In that case,
the equivalent Enterprise Edition version will be: `13.0.4-ee.0`. Write this
the equivalent Enterprise Edition version is: `13.0.4-ee.0`. Write this
value down.
**For CentOS/RHEL**
......@@ -41,7 +41,7 @@ The steps can be summed up to:
```
The output should be similar to: `gitlab-ce-13.0.4-ce.0.el8.x86_64`. In that
case, the equivalent Enterprise Edition version will be:
case, the equivalent Enterprise Edition version is:
`gitlab-ee-13.0.4-ee.0.el8.x86_64`. Write this value down.
1. Add the `gitlab-ee` [Apt or Yum repository](https://packages.gitlab.com/gitlab/gitlab-ee/install):
......@@ -58,13 +58,13 @@ The steps can be summed up to:
curl --silent "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.rpm.sh" | sudo bash
```
The above command will find your OS version and automatically set up the
The above command finds your OS version and automatically set up the
repository. If you are not comfortable installing the repository through a
piped script, you can first
[check its contents](https://packages.gitlab.com/gitlab/gitlab-ee/install).
1. Next, install the `gitlab-ee` package. Note that this will automatically
uninstall the `gitlab-ce` package on your GitLab server. `reconfigure`
1. Next, install the `gitlab-ee` package. Note that this automatically
uninstalls the `gitlab-ce` package on your GitLab server. `reconfigure`
Omnibus right after the `gitlab-ee` package is installed. **Make sure that you
install the exact same GitLab version**:
......
......@@ -41,7 +41,7 @@ cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
```
For installations using MySQL, this may require granting "LOCK TABLES"
For installations using MySQL, this may require granting `LOCK TABLES`
privileges to the GitLab user on the database version.
### 1. Stop server
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment