GITLAB常见问题总结

Troubleshooting GitLab Pages administration (FREE SELF)

原文地址

---

stage: Plan
group: Knowledge
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments

This page contains a list of issues you might encounter when administering GitLab Pages.

How to see GitLab Pages logs

You can see Pages daemon logs by running:

sudo gitlab-ctl tail gitlab-pages

You can also find the log file in /var/log/gitlab/gitlab-pages/current.

unsupported protocol scheme \"\""

If you see the following error:

{"error":"failed to connect to internal Pages API: Get \"/api/v4/internal/pages/status\": unsupported protocol scheme \"\"","level":"warning","msg":"attempted to connect to the API","time":"2021-06-23T20:03:30Z"}

It means you didn’t set the HTTP(S) protocol scheme in the Pages server settings.
To fix it:

1. Edit /etc/gitlab/gitlab.rb:

   gitlab_pages['gitlab_server'] = "https://<your_gitlab_server_public_host_and_port>"
   gitlab_pages['internal_gitlab_server'] = "https://<your_gitlab_server_private_host_and_port>" # optional, gitlab_pages['gitlab_server'] is used as default
   

2. Reconfigure GitLab:

   sudo gitlab-ctl reconfigure
   

502 error when connecting to GitLab Pages proxy when server does not listen over IPv6

In some cases, NGINX might default to using IPv6 to connect to the GitLab Pages
service even when the server does not listen over IPv6. You can identify when
this is happening if you see something similar to the log entry below in the
gitlab_pages_error.log:

2020/02/24 16:32:05 [error] 112654#0: *4982804 connect() failed (111: Connection refused) while connecting to upstream, client: 123.123.123.123, server: ~^(?<group>.*)\.pages\.example\.com$, request: "GET /-/group/project/-/jobs/1234/artifacts/artifact.txt HTTP/1.1", upstream: "http://[::1]:8090//-/group/project/-/jobs/1234/artifacts/artifact.txt", host: "group.example.com"

To resolve this, set an explicit IP and port for the GitLab Pages listen_proxy setting
to define the explicit address that the GitLab Pages daemon should listen on:

gitlab_pages['listen_proxy'] = '127.0.0.1:8090'

Intermittent 502 errors or after a few days

If you run Pages on a system that uses systemd and
tmpfiles.d,
you may encounter intermittent 502 errors trying to serve Pages with an error similar to:

dial tcp: lookup gitlab.example.com on [::1]:53: dial udp [::1]:53: connect: no route to host"

GitLab Pages creates a bind mount
inside /tmp/gitlab-pages-* that includes files like /etc/hosts.
However, systemd may clean the /tmp/ directory on a regular basis so the DNS
configuration may be lost.

To stop systemd from cleaning the Pages related content:

1. Tell tmpfiles.d to not remove the Pages /tmp directory:

   echo 'x /tmp/gitlab-pages-*' >> /etc/tmpfiles.d/gitlab-pages-jail.conf
   

2. Restart GitLab Pages:

   sudo gitlab-ctl restart gitlab-pages
   

Unable to access GitLab Pages

If you can’t access your GitLab Pages (such as receiving 502 Bad Gateway errors, or a login loop)
and in your Pages log shows this error:

"error":"retrieval context done: context deadline exceeded","host":"root.docs-cit.otenet.gr","level":"error","msg":"could not fetch domain information from a source"

1. Add the following to /etc/gitlab/gitlab.rb:

   gitlab_pages['internal_gitlab_server'] = 'http://localhost:8080'
   

2. Restart GitLab Pages:

   sudo gitlab-ctl restart gitlab-pages
   

Failed to connect to the internal GitLab API

If you see the following error:

ERRO[0010] Failed to connect to the internal GitLab API after 0.50s  error="failed to connect to internal Pages API: HTTP status: 401"

If you are Running GitLab Pages on a separate server
you must copy the /etc/gitlab/gitlab-secrets.json file
from the GitLab server to the Pages server after upgrading to GitLab 13.3,
as described in that section.

Other reasons may include network connectivity issues between your
GitLab server and your Pages server such as firewall configurations or closed ports.
For example, if there is a connection timeout:

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)"

Pages cannot communicate with an instance of the GitLab API

If you use the default value for domain_config_source=auto and run multiple instances of GitLab
Pages, you may see intermittent 502 error responses while serving Pages content. You may also see
the following warning in the Pages logs:

WARN[0010] Pages cannot communicate with an instance of the GitLab API. Please sync your gitlab-secrets.json file https://gitlab.com/gitlab-org/gitlab-pages/-/issues/535#workaround. error="pages endpoint unauthorized"

This can happen if your gitlab-secrets.json file is out of date between GitLab Rails and GitLab
Pages. Follow steps 8-10 of Running GitLab Pages on a separate server,
in all of your GitLab Pages instances.

Intermittent 502 errors when using an AWS Network Load Balancer and GitLab Pages

Connections will time out when using a Network Load Balancer with client IP preservation enabled and the request is looped back to the source server.
This can happen to GitLab instances with multiple servers
running both the core GitLab application and GitLab Pages. This can also happen when a single
container is running both the core GitLab application and GitLab Pages.

AWS recommends using an IP target type
to resolve this issue.

Turning off client IP preservation
may resolve this issue when the core GitLab application and GitLab Pages run on the same host or
container.

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.
The Pages daemon uses the securecookie library to get random strings via crypto/rand in Go.
This requires the getrandom system call or /dev/urandom to be available on the host OS.
Upgrading to an officially supported operating system 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:

1. On the left sidebar, select Search or go to.
2. Select Admin Area.
3. On the left sidebar, select Applications > GitLab Pages.
4. Edit the application.
5. Under Scopes, ensure that the api scope is selected.
6. Save your changes.

When running a separate Pages server,
this setting needs to be configured on the main GitLab server.

Workaround in case no wildcard DNS entry can be set

If the wildcard DNS prerequisite can’t be met, you can still use GitLab Pages in a limited fashion:

1. Move
   all projects you need to use Pages with into a single group namespace, for example pages.
2. Configure a DNS entry without the *.-wildcard, for example pages.example.io.
3. Configure pages_external_url http://example.io/ in your gitlab.rb file.
   Omit the group namespace here, because it automatically is prepended by GitLab.

Pages daemon fails with permission denied errors

If /tmp is mounted with noexec, the Pages daemon fails to start with an error like:

{"error":"fork/exec /gitlab-pages: permission denied","level":"fatal","msg":"could not create pages daemon","time":"2021-02-02T21:54:34Z"}

In this case, change TMPDIR to a location that is not mounted with noexec. Add the following to
/etc/gitlab/gitlab.rb:

gitlab_pages['env'] = {'TMPDIR' => '<new_tmp_path>'}

Once added, reconfigure with sudo gitlab-ctl reconfigure and restart GitLab with
sudo gitlab-ctl restart.

The redirect URI included is not valid. when using Pages Access Control

You may see this error if pages_external_url was updated at some point of time. Verify the following:

1. Check the System OAuth application:

   1. On the left sidebar, select Search or go to.
   2. Select Admin Area.
   3. Select Applications and then Add new application.
   4. Ensure the Callback URL/Redirect URI is using the protocol (HTTP or HTTPS) that
      pages_external_url is configured to use.

2. The domain and path components of Redirect URI are valid: they should look like projects.<pages_external_url>/auth.

500 error cannot serve from disk

If you get a 500 response from Pages and encounter an error similar to:

ERRO[0145] cannot serve from disk                        error="gitlab: disk access is disabled via enable-disk=false" project_id=27 source_path="file:///shared/pages/@hashed/67/06/670671cd97404156226e507973f2ab8330d3022ca96e0c93bdbdb320c41adcaf/pages_deployments/14/artifacts.zip" source_type=zip

It means that GitLab Rails is telling GitLab Pages to serve content from a location on disk,
however, GitLab Pages was configured to disable disk access.

To enable disk access:

1. Enable disk access for GitLab Pages in /etc/gitlab/gitlab.rb:

   gitlab_pages['enable_disk'] = true
   

2. Reconfigure GitLab.

httprange: new resource 403

If you see an error similar to:

{"error":"httprange: new resource 403: \"403 Forbidden\"","host":"root.pages.example.com","level":"error","msg":"vfs.Root","path":"/pages1/","time":"2021-06-10T08:45:19Z"}

And you run pages on the separate server syncing files via NFS, it may mean that
the shared pages directory is mounted on a different path on the main GitLab server and the
GitLab Pages server.

In that case, it’s highly recommended you to configure
object storage and migrate any existing pages data to it.

Alternatively, you can mount the GitLab Pages shared directory to the same path on
both servers.

GitLab Pages doesn’t work after upgrading to GitLab 14.0 or above

GitLab 14.0 introduces a number of changes to GitLab Pages which may require manual intervention.

1. Firstly follow the migration guide.
2. Try to upgrade to GitLab 14.3 or above. Some of the issues were fixed in GitLab 14.1, 14.2 and 14.3.
3. If it doesn’t work, see GitLab Pages logs, and if you see any errors there then search them on this page.

WARNING:
In GitLab 14.0-14.2 you can temporarily enable legacy storage and configuration mechanisms.

To do that:

1. Describe the issue you’re seeing in the migration feedback issue.

2. Edit /etc/gitlab/gitlab.rb:

   gitlab_pages['use_legacy_storage'] = true
   

3. Reconfigure GitLab.

GitLab Pages deploy job fails with error “is not a recognized provider”

If the pages job succeeds but the deploy job gives the error “is not a recognized provider”:

The error message is not a recognized provider could be coming from the fog gem that GitLab uses to connect to cloud providers for object storage.

To fix that:

1. Check your gitlab.rb file. If you have gitlab_rails['pages_object_store_enabled'] enabled, but no bucket details have been configured, either:

   • Configure object storage for your Pages deployments, following the S3-compatible connection settings guide.
   • Store your deployments locally, by commenting out that line.

2. Save the changes you made to your gitlab.rb file, then reconfigure GitLab.

404 error The page you're looking for could not be found

If you get a 404 Page Not Found response from GitLab Pages:

1. Check .gitlab-ci.yml contains the job pages:.
2. Check the current project’s pipeline to confirm the job pages:deploy is being run.

Without the pages:deploy job, the updates to your GitLab Pages site are never published.

推荐几款学习编程的免费平台

免费在线开发平台（https://docs.ltpp.vip/LTPP/）

       探索编程世界的新天地，为学生和开发者精心打造的编程平台，现已盛大开启！这个平台汇集了近4000道精心设计的编程题目，覆盖了C、C++、JavaScript、TypeScript、Go、Rust、PHP、Java、Ruby、Python3以及C#等众多编程语言，为您的编程学习之旅提供了一个全面而丰富的实践环境。       
      在这里，您不仅可以查看自己的代码记录，还能轻松地在云端保存和运行代码，让编程变得更加便捷。平台还提供了私聊和群聊功能，让您可以与同行们无障碍交流，分享文件，共同进步。不仅如此，您还可以通过阅读文章、参与问答板块和在线商店，进一步拓展您的知识边界。
       为了提升您的编程技能，平台还设有每日一题、精选题单以及激动人心的编程竞赛，这些都是备考编程考试的绝佳资源。更令人兴奋的是，您还可以自定义系统UI，选择视频或图片作为背景，打造一个完全个性化的编码环境，让您的编程之旅既有趣又充满挑战。

免费公益服务器（https://docs.ltpp.vip/LTPP-SHARE/linux.html）

       作为开发者或学生，您是否经常因为搭建和维护编程环境而感到头疼？现在，您不必再为此烦恼，因为一款全新的免费公共服务器已经为您解决了所有问题。这款服务器内置了多种编程语言的编程环境，并且配备了功能强大的在线版VS Code，让您可以随时随地在线编写代码，无需进行任何复杂的配置。
随时随地，云端编码
       无论您身在何处，只要有网络连接，就可以通过浏览器访问这款公共服务器，开始您的编程之旅。这种云端编码的便利性，让您的学习或开发工作不再受限于特定的设备或环境。
丰富的编程语言支持
       服务器支持包括C、C++、JavaScript、TypeScript、Go、Rust、PHP、Java、Ruby、Python3以及C#等在内的多种主流编程语言，满足不同开发者和学生的需求。无论您是初学者还是资深开发者，都能找到适合自己的编程环境。
在线版VS Code，高效开发
       内置的在线版VS Code提供了与本地VS Code相似的编辑体验，包括代码高亮、智能提示、代码调试等功能，让您即使在云端也能享受到高效的开发体验。
数据隐私和安全提醒
       虽然服务器是免费的，但为了保护您的数据隐私和安全，我们建议您不要上传任何敏感或重要的数据。这款服务器更适合用于学习和实验，而非存储重要信息。

免费公益MYSQL（https://docs.ltpp.vip/LTPP-SHARE/mysql.html）

       作为一名开发者或学生，数据库环境的搭建和维护往往是一个复杂且耗时的过程。但不用担心，现在有一款免费的MySQL服务器，专为解决您的烦恼而设计，让数据库的使用变得简单而高效。
性能卓越，满足需求
       虽然它是免费的，但性能绝不打折。服务器提供了稳定且高效的数据库服务，能够满足大多数开发和学习场景的需求。
在线phpMyAdmin，管理更便捷
       内置的在线phpMyAdmin管理面板，提供了一个直观且功能强大的用户界面，让您可以轻松地查看、编辑和管理数据库。
数据隐私提醒，安全第一
       正如您所知，这是一项公共资源，因此我们强烈建议不要上传任何敏感或重要的数据。请将此服务器仅用于学习和实验目的，以确保您的数据安全。

免费在线WEB代码编辑器（https://docs.ltpp.vip/LTPP-WEB-IDE/）

       无论你是开发者还是学生，编程环境的搭建和管理可能会占用你宝贵的时间和精力。现在，有一款强大的免费在线代码编辑器，支持多种编程语言，让您可以随时随地编写和运行代码，提升编程效率，专注于创意和开发。
多语言支持，无缝切换
       这款在线代码编辑器支持包括C、C++、JavaScript、TypeScript、Go、Rust、PHP、Java、Ruby、Python3以及C#在内的多种编程语言，无论您的项目需要哪种语言，都能在这里找到支持。
在线运行，快速定位问题
       您可以在编写代码的同时，即时运行并查看结果，快速定位并解决问题，提高开发效率。
代码高亮与智能提示
       编辑器提供代码高亮和智能提示功能，帮助您更快地编写代码，减少错误，提升编码质量。

免费二维码生成器（https://docs.ltpp.vip/LTPP-QRCODE/）

       二维码（QR Code）是一种二维条码，能够存储更多信息，并且可以通过智能手机等设备快速扫描识别。它广泛应用于各种场景，如：
企业宣传
       企业可以通过二维码分享公司网站、产品信息、服务介绍等。
活动推广
       活动组织者可以创建二维码，参与者扫描后可以直接访问活动详情、报名链接或获取电子门票。
个人信息分享
       个人可以生成包含联系方式、社交媒体链接、个人简历等信息的二维码。
电子商务
       商家使用二维码进行商品追踪、促销活动、在线支付等。
教育
       教师可以创建二维码，学生扫描后可以直接访问学习资料或在线课程。
交通出行
       二维码用于公共交通的票务系统，乘客扫描二维码即可进出站或支付车费。        功能强大的二维码生成器通常具备用户界面友好，操作简单，即使是初学者也能快速上手和生成的二维码可以在各种设备和操作系统上扫描识别的特点。