summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2019-10-23 09:06:03 +0000
committerGitLab Bot <gitlab-bot@gitlab.com>2019-10-23 09:06:03 +0000
commitb3e4ec8e8adf4fe96c982124e91b6a05021a9cda (patch)
tree5fda0011a7cc7de000186e465e61f893d478a1c8 /doc
parent90cdc9391171e1be29b2b57a2e2aad0c02c2a7a9 (diff)
downloadgitlab-ce-b3e4ec8e8adf4fe96c982124e91b6a05021a9cda.tar.gz
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r--doc/administration/gitaly/index.md36
-rw-r--r--doc/administration/high_availability/consul.md17
-rw-r--r--doc/development/chatops_on_gitlabcom.md2
-rw-r--r--doc/development/testing_guide/best_practices.md13
-rw-r--r--doc/security/webhooks.md19
-rw-r--r--doc/user/application_security/license_compliance/index.md15
6 files changed, 69 insertions, 33 deletions
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md
index 5037e5034c8..50db86a8e2c 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/index.md
@@ -142,11 +142,6 @@ the Gitaly server. The easiest way to accomplish this is to copy `/etc/gitlab/gi
from an existing GitLab server to the Gitaly server. Without this shared secret,
Git operations in GitLab will result in an API error.
-NOTE: **Note:**
-In most or all cases, the storage paths below end in `/repositories` which is
-not the case with `path` in `git_data_dirs` of Omnibus GitLab installations.
-Check the directory layout on your Gitaly server to be sure.
-
**For Omnibus GitLab**
1. Edit `/etc/gitlab/gitlab.rb`:
@@ -193,24 +188,26 @@ Check the directory layout on your Gitaly server to be sure.
On `gitaly1.internal`:
```
- gitaly['storage'] = [
- { 'name' => 'default' },
- { 'name' => 'storage1' },
- ]
+ git_data_dirs({
+ 'default' => {
+ 'path' => '/var/opt/gitlab/git-data'
+ },
+ 'storage1' => {
+ 'path' => '/mnt/gitlab/git-data'
+ },
+ })
```
On `gitaly2.internal`:
```
- gitaly['storage'] = [
- { 'name' => 'storage2' },
- ]
+ git_data_dirs({
+ 'storage2' => {
+ 'path' => '/srv/gitlab/git-data'
+ },
+ })
```
- NOTE: **Note:**
- In some cases, you'll have to set `path` for `gitaly['storage']` in the
- format `'path' => '/mnt/gitlab/<storage name>/repositories'`.
-
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
**For installations from source**
@@ -236,9 +233,11 @@ Check the directory layout on your Gitaly server to be sure.
```toml
[[storage]]
name = 'default'
+ path = '/var/opt/gitlab/git-data/repositories'
[[storage]]
name = 'storage1'
+ path = '/mnt/gitlab/git-data/repositories'
```
On `gitaly2.internal`:
@@ -246,12 +245,9 @@ Check the directory layout on your Gitaly server to be sure.
```toml
[[storage]]
name = 'storage2'
+ path = '/srv/gitlab/git-data/repositories'
```
- NOTE: **Note:**
- In some cases, you'll have to set `path` for each `[[storage]]` in the
- format `path = '/mnt/gitlab/<storage name>/repositories'`.
-
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
### 4. Converting clients to use the Gitaly server
diff --git a/doc/administration/high_availability/consul.md b/doc/administration/high_availability/consul.md
index b01419200cc..392b9b76c31 100644
--- a/doc/administration/high_availability/consul.md
+++ b/doc/administration/high_availability/consul.md
@@ -102,6 +102,23 @@ To be safe, we recommend you only restart one server agent at a time to ensure t
For larger clusters, it is possible to restart multiple agents at a time. See the [Consul consensus document](https://www.consul.io/docs/internals/consensus.html#deployment-table) for how many failures it can tolerate. This will be the number of simulateneous restarts it can sustain.
+## Upgrades for bundled Consul
+
+Nodes running GitLab-bundled Consul should be:
+
+- Members of a healthy cluster prior to upgrading the GitLab Omnibus package.
+- Upgraded one node at a time.
+
+NOTE: **NOTE:**
+Running `curl http://127.0.0.1:8500/v1/health/state/critical` from any Consul node will identify existing health issues in the cluster. The command will return an empty array if the cluster is healthy.
+
+Consul clusters communicate using the raft protocol. If the current leader goes offline, there needs to be a leader election. A leader node must exist to facilitate synchronization across the cluster. If too many nodes go offline at the same time, the cluster will lose quorum and not elect a leader due to [broken consensus](https://www.consul.io/docs/internals/consensus.html).
+
+Consult the [troubleshooting section](#troubleshooting) if the cluster is not able to recover after the upgrade. The [outage recovery](#outage-recovery) may be of particular interest.
+
+NOTE: **NOTE:**
+GitLab only uses Consul to store transient data that is easily regenerated. If the bundled Consul was not used by any process other than GitLab itself, then [rebuilding the cluster from scratch](#recreate-from-scratch) is fine.
+
## Troubleshooting
### Consul server agents unable to communicate
diff --git a/doc/development/chatops_on_gitlabcom.md b/doc/development/chatops_on_gitlabcom.md
index 8a313a120f1..456dd1d4b4b 100644
--- a/doc/development/chatops_on_gitlabcom.md
+++ b/doc/development/chatops_on_gitlabcom.md
@@ -14,7 +14,7 @@ tasks such as:
To request access to Chatops on GitLab.com:
1. Log into <https://ops.gitlab.net/users/sign_in> **using the same username** as for GitLab.com (you may have to rename it).
-1. Ask [an owner/maintainer in the `chatops` project](https://gitlab.com/gitlab-com/chatops/-/project_members?search=&sort=access_level_desc) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
+1. Ask [a project member in the `chatops` project](https://ops.gitlab.net/gitlab-com/chatops/-/project_members) to add you by running `/chatops run member add <username> gitlab-com/chatops --ops`.
## See also
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 32e079f915c..70945cdaacb 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -357,9 +357,16 @@ However, if a spec makes direct Redis calls, it should mark itself with the
`:clean_gitlab_redis_queues` traits as appropriate.
Sidekiq jobs are typically not run in specs, but this behaviour can be altered
-in each spec through the use of `perform_enqueued_jobs` blocks. Any spec that
-causes Sidekiq jobs to be pushed to Redis should use the `:sidekiq` trait, to
-ensure that they are removed once the spec completes.
+in each spec through the use of `perform_enqueued_jobs` blocks.
+Any spec that causes Sidekiq jobs to be pushed to Redis should use the
+`:sidekiq_inline` trait, to ensure that they are removed once the spec completes.
+
+The `:sidekiq_might_not_need_inline` trait was added when [Sidekiq inline mode was
+changed to fake mode](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31662)
+to all the examples that needed Sidekiq to actually process jobs. Examples with
+this trait should be either fixed to not rely on Sidekiq processing jobs, or their
+`:sidekiq_might_not_need_inline` trait should be updated to `:sidekiq_inline` if the
+processing of background jobs is needed/expected.
#### Filesystem
diff --git a/doc/security/webhooks.md b/doc/security/webhooks.md
index b9af1ac108f..cb9ad2b694c 100644
--- a/doc/security/webhooks.md
+++ b/doc/security/webhooks.md
@@ -9,19 +9,24 @@ local network, these may be vulnerable to exploitation via Webhooks.
With [Webhooks](../user/project/integrations/webhooks.md), you and your project
maintainers and owners can set up URLs to be triggered when specific changes
-occur in your projects. Normally, these requests are sent to external web services
-specifically set up for this purpose, that process the request and its attached
-data in some appropriate way.
+occur in your projects. Normally, these requests are sent to external web
+services specifically set up for this purpose, that process the request and its
+attached data in some appropriate way.
Things get hairy, however, when a Webhook is set up with a URL that doesn't
point to an external, but to an internal service, that may do something
completely unintended when the webhook is triggered and the POST request is
sent.
-Because Webhook requests are made by the GitLab server itself, these have
-complete access to everything running on the server (`http://localhost:123`) or
-within the server's local network (`http://192.168.1.12:345`), even if these
-services are otherwise protected and inaccessible from the outside world.
+Webhook requests are made by the GitLab server itself and use a single
+(optional) secret token per hook for authorization (instead of a user or
+repo-specific token). As a result, these may have broader access than
+intended to everything running on the server hosting the webhook (which
+may include the GitLab server or API itself, e.g., `http://localhost:123`).
+Depending on the called webhook, this may also result in network access
+to other servers within that webhook server's local network (e.g.,
+`http://192.168.1.12:345`), even if these services are otherwise protected
+and inaccessible from the outside world.
If a web service does not require authentication, Webhooks can be used to
trigger destructive commands by getting the GitLab server to make POST requests
diff --git a/doc/user/application_security/license_compliance/index.md b/doc/user/application_security/license_compliance/index.md
index 75a3b33e32e..c67e66dae5d 100644
--- a/doc/user/application_security/license_compliance/index.md
+++ b/doc/user/application_security/license_compliance/index.md
@@ -94,8 +94,19 @@ always take the latest License Compliance artifact available. Behind the scenes,
[GitLab License Compliance Docker image](https://gitlab.com/gitlab-org/security-products/license-management)
is used to detect the languages/frameworks and in turn analyzes the licenses.
-The License Compliance settings can be changed through environment variables by using the
-[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. These variables are documented in the [License Compliance documentation](https://gitlab.com/gitlab-org/security-products/license-management#settings).
+The License Compliance settings can be changed through [environment variables](#available-variables) by using the
+[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
+
+### Available variables
+
+License Compliance can be configured using environment variables.
+
+| Environment variable | Required | Description |
+|-----------------------|----------|-------------|
+| `MAVEN_CLI_OPTS` | no | Additional arguments for the mvn executable. If not supplied, defaults to `-DskipTests`. |
+| `LM_JAVA_VERSION` | no | Version of Java. If set to `11`, Maven and Gradle use Java 11 instead of Java 8. |
+| `LM_PYTHON_VERSION` | no | Version of Python. If set to `3`, dependencies are installed using Python 3 instead of Python 2.7. |
+| `SETUP_CMD` | no | Custom setup for the dependency installation. (experimental) |
### Installing custom dependencies