关于gitlab:gitlabce将https修改为http

4次阅读

共计 2958 个字符,预计需要花费 8 分钟才能阅读完成。

因为一些未知的起因(猜测应该是 gitlab 的证书主动 renew),近期自部署的 gitlab-ce 呈现了证书问题。

索性咱们禁用 gitlab 的 https 性能,将期复原为 http。前期咱们再在部署一个 nginx 进行数据转发,而后在 nginx 上起用 https 并设置证书。这样应该就躲避了 gitlab 的证书谬误问题。

配置

gitlab-ce 的配置文件位于:/etc/gitlab/gitlab.rb中。而将 https 变更为 http 的办法很简略,只须要配置 external_url 为 http 打头即可。

- external_url 'https://gitlab.yourdomain.com:8888'
+ external_url 'http://gitlab.yourdomain.com:8888'

而后应用执行命令:sudo gitlab-ctl reconfigure使其失效。

配置尽管简略,但测试的时候却每每产生问题,导致开始狐疑人生。

测试

应用 chrome 关上地址:http://gitlab.yourdomain.com:8888,却发现产生了 307,转向的地址为:https://gitlab.yourdomain.com:8888,这会使得咱们开始狐疑后面的配置是否失效了。

即便开启了 chrome 或 firefox 的禁用缓存性能,拜访原地址依然是 307。这是因为禁用缓存性能并没有禁用浏览器的redirects,所以如果在浏览器上间接进行测试,则须要先清空浏览器的缓存。

比方咱们将地址输出地址栏后,而后关上控制台,接着左键点住刷新按钮:

抉择 清空缓存并且硬加载(Empty cache and hard reload),此时便能够禁用 chrome 的 redirects 的缓存后实现加载了。

其实除了应用浏览器间接测试外,更靠谱的办法是应用一些脚本,比方 curlcurl 反对应用 -I 参数来显示返回的状态码及响应头。

雷同的地址,如果 curl 并没有返回 307 而浏览器却是 307 则能够确认是浏览器的缓存问题而不是 gitlab 的配置问题了。

panjie@panjies-Mac-Pro ~ % curl -I http://gitlab.yourdomain.com:8888
HTTP/1.1 302 Found
Server: nginx
Date: Tue, 27 Dec 2022 04:33:50 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Cache-Control: no-cache
Location: http://gitlab.yourdomain.com:8888/users/sign_in
Pragma: no-cache
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01GN8XQC4NVMGZ7VA4S5QRRX2E
X-Runtime: 0.029655
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

此时首页返回 302,回跳地址为:http://gitlab.yourdomain.com:8888/users/sign_in,持续申请该地址:

panjie@panjies-Mac-Pro ~ % curl -I http://gitlab.yourdomain.com:8888/users/sign_in
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 27 Dec 2022 04:35:02 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: max-age=0, private, must-revalidate
Content-Security-Policy: 
Etag: W/"7aefc583df813a9b66e476d0c11736b1"
Link: </assets/application_utilities-f86a7caa76c1a2f00550828a9303a66e38d2f043e5f21c2bade17a6ddafe50ab.css>; rel=preload; as=style; type=text/css,</assets/application-f8ba2470fbf1e30f2ce64d34705b8e6615ac964ea84163c8a6adaaf8a91f9eac.css>; rel=preload; as=style; type=text/css,</assets/highlight/themes/white-14ba9f209d5cc375d065606896b08ef3d4dc7be19e5b5800958b390d7ab2bd40.css>; rel=preload; as=style; type=text/css
Permissions-Policy: interest-cohort=()
Pragma: no-cache
Set-Cookie: _gitlab_session=e3d88869c1f709d08bb1887a9da8fb9f; path=/; expires=Tue, 27 Dec 2022 06:35:02 GMT; HttpOnly
Vary: Accept
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Request-Id: 01GN8XSJQC57ANRBDYY8J9P8HF
X-Runtime: 0.068342
X-Ua-Compatible: IE=edge
X-Xss-Protection: 1; mode=block
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

可见状态码为 200,非 307。此时便能够请释怀的去钻研浏览器的缓存问题了。

总结

始终认为浏览器的禁用缓存用禁用所有缓存,没想到 redirects 却是始终走的缓存。这导致原本一个非常简单,早早就曾经解决的问题最终却破费了大略一天的工夫。有时候就是这样,一旦陷入了某个常识陷阱,凭着本能爬出来便会显示非常不容易。而咱们一旦爬出来,当前再有此类问题时,大脑便会产生踊跃的信号来通知你历史上咱们已经陷入过。

所以在教学过程中,根据本人的教训来设置更好的设置陷阱也是优化教学的一个方向。

正文完
 0