Commit be2f4c57 authored by 🤖 GitLab Bot 🤖's avatar 🤖 GitLab Bot 🤖

Add latest changes from gitlab-org/[email protected]

parent 2711c26b
Pipeline #129047292 passed with stages
in 62 minutes and 47 seconds
# frozen_string_literal: true
module Clusters
module Management
class CreateProjectService
CreateError = Class.new(StandardError)
attr_reader :cluster, :current_user
def initialize(cluster, current_user:)
@cluster = cluster
@current_user = current_user
end
def execute
return unless management_project_required?
ActiveRecord::Base.transaction do
project = create_management_project!
update_cluster!(project)
end
end
private
def management_project_required?
Feature.enabled?(:auto_create_cluster_management_project) && cluster.management_project.nil?
end
def project_params
{
name: project_name,
description: project_description,
namespace_id: namespace.id,
visibility_level: Gitlab::VisibilityLevel::PRIVATE
}
end
def project_name
"#{cluster.name} Cluster Management"
end
def project_description
"This project is automatically generated and will be used to manage your Kubernetes cluster. [More information](#{docs_path})"
end
def docs_path
Rails.application.routes.url_helpers.help_page_path('user/clusters/management_project')
end
def create_management_project!
::Projects::CreateService.new(current_user, project_params).execute.tap do |project|
errors = project.errors.full_messages
if errors.any?
raise CreateError.new("Failed to create project: #{errors}")
end
end
end
def update_cluster!(project)
unless cluster.update(management_project: project)
raise CreateError.new("Failed to update cluster: #{cluster.errors.full_messages}")
end
end
def namespace
case cluster.cluster_type
when 'project_type'
cluster.project.namespace
when 'group_type'
cluster.group
when 'instance_type'
instance_administrators_group
else
raise NotImplementedError
end
end
def instance_administrators_group
Gitlab::CurrentSettings.instance_administrators_group ||
raise(CreateError.new('Instance administrators group not found'))
end
end
end
end
---
title: Optimize projects_enforcing_code_owner_approval counter query performance for usage ping
merge_request: 27526
author:
type: performance
---
title: Add atomic and cleanup-on-fail parameters for Helm
merge_request: 27721
author:
type: changed
# frozen_string_literal: true
class AddIndexOnIdAndArchivedAndPendingDeleteToProjects < ActiveRecord::Migration[6.0]
include Gitlab::Database::MigrationHelpers
DOWNTIME = false
INDEX_NAME = 'index_projects_on_id_and_archived_and_pending_delete'
disable_ddl_transaction!
def up
add_concurrent_index :projects, :id, where: "archived = FALSE AND pending_delete = FALSE", name: INDEX_NAME
end
def down
remove_concurrent_index_by_name :projects, INDEX_NAME
end
end
......@@ -9627,6 +9627,8 @@ CREATE INDEX index_projects_on_creator_id_and_created_at ON public.projects USIN
CREATE INDEX index_projects_on_description_trigram ON public.projects USING gin (description public.gin_trgm_ops);
CREATE INDEX index_projects_on_id_and_archived_and_pending_delete ON public.projects USING btree (id) WHERE ((archived = false) AND (pending_delete = false));
CREATE UNIQUE INDEX index_projects_on_id_partial_for_visibility ON public.projects USING btree (id) WHERE (visibility_level = ANY (ARRAY[10, 20]));
CREATE INDEX index_projects_on_id_service_desk_enabled ON public.projects USING btree (id) WHERE (service_desk_enabled = true);
......@@ -12710,6 +12712,7 @@ INSERT INTO "schema_migrations" (version) VALUES
('20200318163148'),
('20200318164448'),
('20200318165448'),
('20200318175008'),
('20200319203901'),
('20200323075043');
......@@ -3,7 +3,7 @@
#
# For a list of all options, see https://errata-ai.github.io/vale/styles/
extends: substitution
message: Use "%s" instead of "%s".
message: 'Use "%s" instead of "%s".'
link: https://about.gitlab.com/handbook/communication/#top-misused-terms
level: error
ignorecase: true
......@@ -11,3 +11,4 @@ swap:
GitLabber: GitLab team member
self hosted: self-managed
self-hosted: self-managed
postgres: PostgreSQL
---
# Checks that version text is formatted correctly.
#
# Specifically looks for either of the following that is immediately followed on the next line
# by content, which will break rendering:
#
# - `> Introduced` (version text without a link)
# - `> [Introduced` (version text with a link)
#
# Because it excludes `-`, it doesn't look for multi-line version text, for which content
# immediately on the next line is ok. However, this will often highlight where multi-line version
# text is attempted without `-` characters.
#
# For a list of all options, see https://errata-ai.github.io/vale/styles/
extends: existence
message: '"%s" is not formatted correctly.'
link: https://docs.gitlab.com/ee/development/documentation/styleguide.html#text-for-documentation-requiring-version-text
level: error
scope: raw
raw:
- '> (- ){0}\[?Introduced.+\n.+'
......@@ -134,7 +134,7 @@ on adding these events into GitLab:
The current architecture of audit events is not prepared to receive a very high amount of records.
It may make the user interface for your project or audit logs very busy, and the disk space consumed by the
`audit_events` Postgres table will increase considerably. It's disabled by default
`audit_events` PostgreSQL table will increase considerably. It's disabled by default
to prevent performance degradations on GitLab instances with very high Git write traffic.
In an upcoming release, Audit Logs for Git push events will be enabled
......
......@@ -25,10 +25,11 @@ GitLab supports two authentication methods:
### Authentication against a local database with X.509 certificates
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/726) in
[GitLab Premium](https://about.gitlab.com/pricing/) 11.6 as an experimental
feature. Smartcard authentication against local databases may change or be
removed completely in future releases.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/726) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.6 as an experimental feature.
CAUTION: **Caution:**
Smartcard authentication against local databases may change or be removed completely in future
releases.
Smartcards with X.509 certificates can be used to authenticate with GitLab.
......
# File hooks
> Introduced in GitLab 10.6.
> Until 12.8 the feature name was Plugins.
> - Introduced in GitLab 10.6.
> - Until GitLab 12.8, the feature name was Plugins.
With custom file hooks, GitLab administrators can introduce custom integrations
without modifying GitLab's source code.
......
......@@ -21,9 +21,9 @@ verification methods:
| Database | Application data in PostgreSQL | Native | Native |
| Database | Redis | _N/A_ (*1*) | _N/A_ |
| Database | Elasticsearch | Native | Native |
| Database | Personal snippets | Postgres Replication | Postgres Replication |
| Database | Project snippets | Postgres Replication | Postgres Replication |
| Database | SSH public keys | Postgres Replication | Postgres Replication |
| Database | Personal snippets | PostgreSQL Replication | PostgreSQL Replication |
| Database | Project snippets | PostgreSQL Replication | PostgreSQL Replication |
| Database | SSH public keys | PostgreSQL Replication | PostgreSQL Replication |
| Git | Project repository | Geo with Gitaly | Gitaly Checksum |
| Git | Project wiki repository | Geo with Gitaly | Gitaly Checksum |
| Git | Project designs repository | Geo with Gitaly | Gitaly Checksum |
......
......@@ -242,7 +242,7 @@ sudo gitlab-rake gitlab:geo:check
Checking Geo ... Finished
```
When performing a Postgres major version (9 > 10) update this is expected. Follow:
When performing a PostgreSQL major version (9 > 10) update this is expected. Follow:
- [initiate-the-replication-process](database.md#step-3-initiate-the-replication-process)
- [Geo database has an outdated FDW remote schema](troubleshooting.md#geo-database-has-an-outdated-fdw-remote-schema-error)
......
......@@ -146,7 +146,7 @@ Each service in the package comes with a set of [default ports](https://docs.git
- Application servers connect to either PgBouncer directly via its [default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#pgbouncer) or via a configured Internal Load Balancer (TCP) that serves multiple PgBouncers.
- PgBouncer connects to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
- Repmgr connects to the database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
- Postgres secondaries connect to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
- PostgreSQL secondaries connect to the primary database servers [PostgreSQL default port](https://docs.gitlab.com/omnibus/package-information/defaults.html#postgresql)
- Consul servers and agents connect to each others [Consul default ports](https://docs.gitlab.com/omnibus/package-information/defaults.html#consul)
#### Required information
......@@ -899,7 +899,7 @@ after it has been restored to service.
```shell
gitlab-ctl repmgr standby unregister --node=959789412
```
##### Add a node as a standby server
From the stnadby node, run:
......@@ -916,24 +916,24 @@ after it has been restored to service.
scratch by performing a `gitlab-ctl repmgr standby setup NEW_MASTER`.
##### Add a failed master back into the cluster as a standby node
Once `repmgrd` and PostgreSQL are runnning, the node will need to follow the new
as a standby node.
```
gitlab-ctl repmgr standby follow NEW_MASTER
```
Once the node is following the new master as a standby, the node needs to be
[unregistered from the cluster on the new master node](#remove-a-standby-from-the-cluster).
Once the old master node has been unregistered from the cluster, it will need
to be setup as a new standby:
```
gitlab-ctl repmgr standby setup NEW_MASTER
```
Failure to unregister and readd the old master node can lead to subsequent failovers
not working.
......
......@@ -132,7 +132,7 @@ across NFS. The GitLab support team will not be able to assist on performance is
this configuration.
Additionally, this configuration is specifically warned against in the
[Postgres Documentation](https://www.postgresql.org/docs/current/creating-cluster.html#CREATING-CLUSTER-NFS):
[PostgreSQL Documentation](https://www.postgresql.org/docs/current/creating-cluster.html#CREATING-CLUSTER-NFS):
>PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like
>locally-connected drives. If the client or server NFS implementation does not provide standard file
......
......@@ -55,7 +55,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
gitlab_rails['gitaly_token'] = 'YOUR_TOKEN'
```
1. Setup Sidekiq's connection to Postgres:
1. Setup Sidekiq's connection to PostgreSQL:
```ruby
gitlab_rails['db_host'] = '10.10.1.30'
......@@ -66,7 +66,7 @@ you want using steps 1 and 2 from the GitLab downloads page.
gitlab_rails['auto_migrate'] = false
```
Remember to add the Sidekiq nodes to the Postgres whitelist:
Remember to add the Sidekiq nodes to the PostgreSQL whitelist:
```ruby
postgresql['trust_auth_cidr_addresses'] = %w(127.0.0.1/32 10.10.1.30/32 10.10.1.31/32 10.10.1.32/32 10.10.1.33/32 10.10.1.38/32)
......
# Web terminals
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690)
in GitLab 8.15. Only project maintainers and owners can access web terminals.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7690) in GitLab 8.15.
NOTE: **Note:**
Only project maintainers and owners can access web terminals.
With the introduction of the [Kubernetes integration](../../user/project/clusters/index.md),
GitLab gained the ability to store and use credentials for a Kubernetes cluster.
......@@ -92,8 +94,7 @@ they will receive a `Connection failed` message.
## Limiting WebSocket connection time
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8413)
in GitLab 8.17.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8413) in GitLab 8.17.
Terminal sessions use long-lived connections; by default, these may last
forever. You can configure a maximum session time in the Admin Area of your
......
......@@ -13,7 +13,7 @@ This guide talks about how to read and use these system log files.
This file lives in `/var/log/gitlab/gitlab-rails/production_json.log` for
Omnibus GitLab packages or in `/home/git/gitlab/log/production_json.log` for
installations from source. When GitLab is running in an environment
other than production, the corresponding logfile is shown here.
other than production, the corresponding log file is shown here.
It contains a structured log for Rails controller requests received from
GitLab, thanks to [Lograge](https://github.com/roidrage/lograge/). Note that
......@@ -105,7 +105,7 @@ NOTE: **Note:** Starting with GitLab 12.5, if an error occurs, an
This file lives in `/var/log/gitlab/gitlab-rails/production.log` for
Omnibus GitLab packages or in `/home/git/gitlab/log/production.log` for
installations from source. (When GitLab is running in an environment
other than production, the corresponding logfile is shown here.)
other than production, the corresponding log file is shown here.)
It contains information about all performed requests. You can see the
URL and type of request, IP address, and what parts of code were
......
......@@ -39,8 +39,8 @@ Test Connection to ensure the configuration is correct.
- **Name**: `InfluxDB`
- **Default**: Checked
- **Type**: `InfluxDB 0.9.x` (Even if you're using InfluxDB 0.10.x)
- **Url**: `https://localhost:8086` (Or the remote URL if you've installed InfluxDB
on a separate server)
- For the URL, use `https://localhost:8086`, or provide the remote URL if you've installed InfluxDB
on a separate server
- **Access**: `proxy`
- **Database**: `gitlab`
- **User**: `admin` (Or the username configured when setting up InfluxDB)
......@@ -52,7 +52,7 @@ Test Connection to ensure the configuration is correct.
If you intend to import the GitLab provided Grafana dashboards, you will need to
set up the right retention policies and continuous queries. The easiest way of
doing this is by using the [influxdb-management](https://gitlab.com/gitlab-org/influxdb-management)
doing this is by using the [InfluxDB Management](https://gitlab.com/gitlab-org/influxdb-management)
repository.
To use this repository you must first clone it:
......@@ -74,7 +74,7 @@ and then editing the `.env` file to contain the correct InfluxDB settings. Once
configured you can simply run `bundle exec rake` and the InfluxDB database will
be configured for you.
For more information see the [influxdb-management README](https://gitlab.com/gitlab-org/influxdb-management/blob/master/README.md).
For more information see the [InfluxDB Management README](https://gitlab.com/gitlab-org/influxdb-management/blob/master/README.md).
## Import Dashboards
......
......@@ -33,7 +33,7 @@ page was open. Only the first two requests per unique URL are captured.
## Request warnings
For requests exceeding pre-defined limits, a warning icon will be shown
For requests exceeding predefined limits, a warning icon will be shown
next to the failing metric, along with an explanation. In this example,
the Gitaly call duration exceeded the threshold:
......
......@@ -201,7 +201,7 @@ When Puma is used instead of Unicorn, the following metrics are available:
| `puma_running_workers` | Gauge | 12.0 | Number of booted workers |
| `puma_stale_workers` | Gauge | 12.0 | Number of old workers |
| `puma_running` | Gauge | 12.0 | Number of running threads |
| `puma_queued_connections` | Gauge | 12.0 | Number of connections in that worker's "todo" set waiting for a worker thread |
| `puma_queued_connections` | Gauge | 12.0 | Number of connections in that worker's "to do" set waiting for a worker thread |
| `puma_active_connections` | Gauge | 12.0 | Number of threads processing a request |
| `puma_pool_capacity` | Gauge | 12.0 | Number of requests the worker is capable of taking right now |
| `puma_max_threads` | Gauge | 12.0 | Maximum number of worker threads |
......
......@@ -268,42 +268,42 @@ export Prometheus metrics.
The node exporter allows you to measure various machine resources, such as
memory, disk, and CPU utilization.
[➔ Read more about the node exporter.](node_exporter.md)
[Read more about the node exporter](node_exporter.md).
### Redis exporter
The Redis exporter allows you to measure various Redis metrics.
[➔ Read more about the Redis exporter.](redis_exporter.md)
[Read more about the Redis exporter](redis_exporter.md).
### Postgres exporter
### PostgreSQL exporter
The Postgres exporter allows you to measure various PostgreSQL metrics.
The PostgreSQL exporter allows you to measure various PostgreSQL metrics.
[➔ Read more about the Postgres exporter.](postgres_exporter.md)
[Read more about the PostgreSQL exporter](postgres_exporter.md).
### PgBouncer exporter
The PgBouncer exporter allows you to measure various PgBouncer metrics.
[➔ Read more about the PgBouncer exporter.](pgbouncer_exporter.md)
[Read more about the PgBouncer exporter](pgbouncer_exporter.md).
### Registry exporter
The Registry exporter allows you to measure various Registry metrics.
[➔ Read more about the Registry exporter.](registry_exporter.md)
[Read more about the Registry exporter](registry_exporter.md).
### GitLab exporter
The GitLab exporter allows you to measure various GitLab metrics, pulled from Redis and the database.
[➔ Read more about the GitLab exporter.](gitlab_exporter.md)
[Read more about the GitLab exporter](gitlab_exporter.md).
## Configuring Prometheus to monitor Kubernetes
> Introduced in GitLab 9.0.
> Pod monitoring introduced in GitLab 9.4.
> - Introduced in GitLab 9.0.
> - Pod monitoring introduced in GitLab 9.4.
If your GitLab server is running within Kubernetes, Prometheus will collect metrics from the Nodes and [annotated Pods](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#kubernetes_sd_config) in the cluster, including performance data on each container. This is particularly helpful if your CI/CD environments run in the same cluster, as you can use the [Prometheus project integration][prometheus integration] to monitor them.
......
......@@ -22,8 +22,8 @@ To enable the PgBouncer exporter:
Prometheus will now automatically begin collecting performance data from
the PgBouncer exporter exposed under `localhost:9188`.
The PgBouncer exporter will also be enabled by default if the [pgbouncer_role][postgres roles]
is enabled.
The PgBouncer exporter will also be enabled by default if the [`pgbouncer_role`][postgres roles]
role is enabled.
[← Back to the main Prometheus page](index.md)
......
# Fast lookup of authorized SSH keys in the database
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
> - [Available in](https://gitlab.com/gitlab-org/gitlab/issues/3953) GitLab Community Edition 10.4.
NOTE: **Note:** This document describes a drop-in replacement for the
`authorized_keys` file for normal (non-deploy key) users. Consider
using [SSH certificates](ssh_certificates.md), they are even faster,
but are not a drop-in replacement.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/1631) in
> [GitLab Starter](https://about.gitlab.com/pricing/) 9.3.
>
> [Available in](https://gitlab.com/gitlab-org/gitlab/issues/3953) GitLab
> Community Edition 10.4.
Regular SSH operations become slow as the number of users grows because OpenSSH
searches for a key to authorize a user via a linear search. In the worst case,
such as when the user is not authorized to access GitLab, OpenSSH will scan the
......@@ -101,7 +98,7 @@ This is a brief overview. Please refer to the above instructions for more contex
1. [Rebuild the `authorized_keys` file](../raketasks/maintenance.md#rebuild-authorized_keys-file)
1. Enable writes to the `authorized_keys` file in Application Settings
1. Remove the `AuthorizedKeysCommand` lines from `/etc/ssh/sshd_config` or from `/assets/sshd_config` if you are using Omnibus Docker.
1. Reload sshd: `sudo service sshd reload`
1. Reload `sshd`: `sudo service sshd reload`
1. Remove the `/opt/gitlab-shell/authorized_keys` file
## Compiling a custom version of OpenSSH for CentOS 6
......@@ -187,7 +184,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
You should see a line that reads: "debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5"
If not, you may need to restart sshd (e.g. `systemctl restart sshd.service`).
If not, you may need to restart `sshd` (e.g. `systemctl restart sshd.service`).
1. *IMPORTANT!* Open a new SSH session to your server before exiting to make
sure everything is working! If you need to downgrade, simple install the
......
......@@ -31,7 +31,7 @@ If you want to see progress, replace `-xf` with `-xvf`.
### Tar pipe to another server
You can also use a tar pipe to copy data to another server. If your
`git` user has SSH access to the newserver as `[email protected]`, you
`git` user has SSH access to the new server as `[email protected]`, you
can pipe the data through SSH.
```shell
......
......@@ -33,7 +33,7 @@ uploading user SSH keys to GitLab entirely.
How to fully set up SSH certificates is outside the scope of this
document. See [OpenSSH's
PROTOCOL.certkeys](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
`PROTOCOL.certkeys`](https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?annotate=HEAD)
for how it works, and e.g. [RedHat's documentation about
it](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/sec-using_openssh_certificate_authentication).
......
......@@ -57,7 +57,7 @@ local location or even use object storage.
The packages for Omnibus GitLab installations are stored under
`/var/opt/gitlab/gitlab-rails/shared/packages/` and for source
installations under `shared/packages/` (relative to the Git homedir).
installations under `shared/packages/` (relative to the Git home directory).
To change the local storage path:
**Omnibus GitLab installations**
......
......@@ -38,7 +38,7 @@ which you can set it up:
the Pages daemon is installed, so you will have to share it via network.
- Run the Pages daemon in the same server as GitLab, listening on the same IP
but on different ports. In that case, you will have to proxy the traffic with
a loadbalancer. If you choose that route note that you should use TCP load
a load balancer. If you choose that route note that you should use TCP load
balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing) the
pages will not be able to be served with user provided certificates. For
HTTP it's OK to use HTTP or TCP load balancing.
......@@ -256,7 +256,7 @@ GitLab supports [custom domain verification](../../user/project/pages/custom_dom
When adding a custom domain, users will be required to prove they own it by
adding a GitLab-controlled verification code to the DNS records for that domain.
If your userbase is private or otherwise trusted, you can disable the
If your user base is private or otherwise trusted, you can disable the
verification requirement. Navigate to **Admin Area > Settings > Preferences** and
uncheck **Require users to prove ownership of custom domains** in the **Pages** section.
This setting is enabled by default.
......@@ -358,7 +358,7 @@ For Omnibus, normally this would be fixed by [installing a custom CA in GitLab O
but a [bug](https://gitlab.com/gitlab-org/gitlab/issues/25411) is currently preventing
that method from working. Use the following workaround:
1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
1. Append your GitLab server TLS/SSL certificate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
```shell
printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
......@@ -582,7 +582,7 @@ but commented out to help encourage others to add to it in the future. -->
### `open /etc/ssl/ca-bundle.pem: permission denied`
GitLab Pages runs inside a `chroot` jail, usually in a uniquely numbered directory like
GitLab Pages runs inside a chroot jail, usually in a uniquely numbered directory like
`/tmp/gitlab-pages-*`.
Within the jail, a bundle of trusted certificates is
......@@ -592,7 +592,7 @@ from `/opt/gitlab/embedded/ssl/certs/cacert.pem`
as part of starting up Pages.
If the permissions on the source file are incorrect (they should be `0644`) then
the file inside the `chroot` jail will also be wrong.
the file inside the chroot jail will also be wrong.
Pages will log errors in `/var/log/gitlab/gitlab-pages/current` like:
......@@ -601,7 +601,7 @@ x509: failed to load system roots and no roots provided
open /etc/ssl/ca-bundle.pem: permission denied
```
The use of a `chroot` jail makes this error misleading, as it is not
The use of a chroot jail makes this error misleading, as it is not
referring to `/etc/ssl` on the root filesystem.
The fix is to correct the source file permissions and restart Pages:
......
......@@ -35,7 +35,7 @@ which you can set it up:
the Pages daemon is installed, so you will have to share it via network.
1. Run the Pages daemon in the same server as GitLab, listening on the same IP
but on different ports. In that case, you will have to proxy the traffic with
a loadbalancer. If you choose that route note that you should use TCP load
a load balancer. If you choose that route note that you should use TCP load
balancing for HTTPS. If you use TLS-termination (HTTPS-load balancing) the
pages will not be able to be served with user provided certificates. For
HTTP it's OK to use HTTP or TCP load balancing.
......@@ -51,7 +51,7 @@ Before proceeding with the Pages configuration, make sure that:
this document we assume that to be `example.io`.
1. You have configured a **wildcard DNS record** for that domain.
1. You have installed the `zip` and `unzip` packages in the same server that
GitLab is installed since they are needed to compress/uncompress the
GitLab is installed since they are needed to compress and decompress the
Pages artifacts.
1. (Optional) You have a **wildcard certificate** for the Pages domain if you
decide to serve Pages (`*.example.io`) under HTTPS.
......@@ -388,7 +388,7 @@ Each request to view a resource in a private site is authenticated by Pages
using that token. For each request it receives, it makes a request to the GitLab
API to check that the user is authorized to read that site.
From [GitLab 12.8](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3689) onwards,
From [GitLab 12.8](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/3689) onward,
Access Control parameters for Pages are set in a configuration file, which
by convention is named `gitlab-pages-config`. The configuration file is passed to
pages using the `-config flag` or CONFIG environment variable.
......
......@@ -129,7 +129,7 @@ Done!
## LDAP Check
The LDAP check Rake task will test the bind_dn and password credentials
The LDAP check Rake task will test the bind DN and password credentials
(if configured) and will list a sample of LDAP users. This task is also
executed as part of the `gitlab:check` task, but can run independently.
See [LDAP Rake Tasks - LDAP Check](ldap.md#check) for details.
......
......@@ -184,13 +184,13 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
imapd start
```
1. The courier-authdaemon isn't started after installation. Without it, imap authentication will fail:
1. The `courier-authdaemon` isn't started after installation. Without it, IMAP authentication will fail:
```shell
sudo service courier-authdaemon start
```
You can also configure courier-authdaemon to start on boot:
You can also configure `courier-authdaemon` to start on boot:
```shell
sudo systemctl enable courier-authdaemon
......
# Repository checks
> [Introduced][ce-3232] in GitLab 8.7. It is OFF by default because it still
causes too many false alarms.
> [Introduced][ce-3232] in GitLab 8.7.
Git has a built-in mechanism, [`git fsck`][git-fsck], to verify the
integrity of all data committed to a repository. GitLab administrators
......@@ -11,6 +10,9 @@ before the check result is visible on the project admin page. If the
checks failed you can see their output on the admin log page under
'repocheck.log'.
NOTE: **Note:**
It is OFF by default because it still causes too many false alarms.
## Periodic checks
When enabled, GitLab periodically runs a repository check on all project
......
......@@ -37,7 +37,7 @@ sudo gitlab-ctl restart
The output should be similar to this:
```
```plaintext
ok: run: gitlab-workhorse: (pid 11291) 1s
ok: run: logrotate: (pid 11299) 0s
ok: run: mailroom: (pid 11306) 0s
......@@ -103,13 +103,13 @@ depend on those files.
If you have followed the official installation guide to [install GitLab from
source][install], run the following command to restart GitLab:
```
```shell
sudo service gitlab restart
```
The output should be similar to this:
```
```plaintext