diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-10-21 07:08:36 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-10-21 07:08:36 +0000 |
commit | 48aff82709769b098321c738f3444b9bdaa694c6 (patch) | |
tree | e00c7c43e2d9b603a5a6af576b1685e400410dee /doc/administration/pages/index.md | |
parent | 879f5329ee916a948223f8f43d77fba4da6cd028 (diff) | |
download | gitlab-ce-48aff82709769b098321c738f3444b9bdaa694c6.tar.gz |
Add latest changes from gitlab-org/gitlab@13-5-stable-eev13.5.0-rc42
Diffstat (limited to 'doc/administration/pages/index.md')
-rw-r--r-- | doc/administration/pages/index.md | 41 |
1 files changed, 28 insertions, 13 deletions
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md index 3c0030be629..9f72293a730 100644 --- a/doc/administration/pages/index.md +++ b/doc/administration/pages/index.md @@ -53,8 +53,14 @@ supporting custom domains a secondary IP is not needed. Before proceeding with the Pages configuration, you will need to: -1. Have an exclusive root domain for serving GitLab Pages. Note that you cannot - use a subdomain of your GitLab's instance domain. +1. Have a domain for Pages that is not a subdomain of your GitLab's instance domain. + + | GitLab domain | Pages domain | Does it work? | + | :---: | :---: | :---: | + | `example.com` | `example.io` | **{check-circle}** Yes | + | `example.com` | `pages.example.com` | **{dotted-circle}** No | + | `gitlab.example.com` | `pages.example.com` | **{check-circle}** Yes | + 1. Configure a **wildcard DNS record**. 1. (Optional) Have a **wildcard certificate** for that domain if you decide to serve Pages under HTTPS. @@ -235,7 +241,7 @@ control over how the Pages daemon runs and serves content in your environment. | `pages_path` | The directory on disk where pages are stored, defaults to `GITLAB-RAILS/shared/pages`. | `pages_nginx[]` | | | `enable` | Include a virtual host `server{}` block for Pages inside NGINX. Needed for NGINX to proxy traffic back to the Pages daemon. Set to `false` if the Pages daemon should directly receive all requests, for example, when using [custom domains](index.md#custom-domains). -| `FF_ENABLE_REDIRECTS` | Feature flag to enable redirects. See the [redirects documentation](../../user/project/pages/redirects.md#enable-or-disable-redirects) for more info. | +| `FF_ENABLE_REDIRECTS` | Feature flag to disable redirects (enabled by default). Read the [redirects documentation](../../user/project/pages/redirects.md#disable-redirects) for more info. | --- @@ -370,8 +376,8 @@ Pages access control is disabled by default. To enable it: 1. Users can now configure it in their [projects' settings](../../user/project/pages/pages_access_control.md). NOTE: **Important:** -For multi-node setups, in order for this setting to be effective, it has to be applied -to all the App nodes as well as the Sidekiq nodes. +For this setting to be effective with multi-node setups, it has to be applied to +all the App nodes and Sidekiq nodes. #### Disabling public access to all Pages websites @@ -397,8 +403,7 @@ redeployed. This issue will be resolved by ### Running behind a proxy Like the rest of GitLab, Pages can be used in those environments where external -internet connectivity is gated by a proxy. In order to use a proxy for GitLab -pages: +internet connectivity is gated by a proxy. To use a proxy for GitLab Pages: 1. Configure in `/etc/gitlab/gitlab.rb`: @@ -425,10 +430,6 @@ Authority (CA) in the system certificate store. For Omnibus, this is fixed by [installing a custom CA in Omnibus GitLab](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates). -## Enable redirects - -In GitLab Pages, you can [enable the redirects feature](../../user/project/pages/redirects.md#enable-or-disable-redirects) to configure rules to forward one URL to another using HTTP redirects. - ## Activate verbose logging for daemon Verbose logging was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2533) in @@ -508,7 +509,8 @@ To override the global maximum pages size for a specific group: ## Running GitLab Pages on a separate server -You can run the GitLab Pages daemon on a separate server in order to decrease the load on your main application server. +You can run the GitLab Pages daemon on a separate server to decrease the load on +your main application server. To configure GitLab Pages on a separate server: @@ -595,7 +597,7 @@ database encryption. Proceed with caution. ```ruby pages_external_url "http://<pages_server_URL>" gitlab_pages['enable'] = false - gitlab_rails['pages_enabled']=false + pages_nginx['enable'] = false gitlab_rails['pages_path'] = "/mnt/pages" ``` @@ -779,3 +781,16 @@ For example, if there is a connection timeout: ```plaintext error="failed to connect to internal Pages API: Get \"https://gitlab.example.com:3000/api/v4/internal/pages/status\": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)" ``` + +### 500 error with `securecookie: failed to generate random iv` and `Failed to save the session` + +This problem most likely results from an [out-dated operating system](https://docs.gitlab.com/omnibus/package-information/deprecated_os.html). +The [Pages daemon uses the `securecookie` library](https://gitlab.com/search?group_id=9970&project_id=734943&repository_ref=master&scope=blobs&search=securecookie&snippets=false) to get random strings via [crypto/rand in Go](https://golang.org/pkg/crypto/rand/#pkg-variables). +This requires the `getrandom` syscall or `/dev/urandom` to be available on the host OS. +Upgrading to an [officially supported operating system](https://about.gitlab.com/install/) is recommended. + +### The requested scope is invalid, malformed, or unknown + +This problem comes from the permissions of the GitLab Pages OAuth application. To fix it, go to +**Admin > Applications > GitLab Pages** and edit the application. Under **Scopes**, ensure that the +`api` scope is selected and save your changes. |