关于gitlab:gitlabce将https修改为http

因为一些未知的起因（猜测应该是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的缓存后实现加载了。

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

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

panjie@panjies-Mac-Pro ~ % curl -I http://gitlab.yourdomain.com:8888HTTP/1.1 302 FoundServer: nginxDate: Tue, 27 Dec 2022 04:33:50 GMTContent-Type: text/html; charset=utf-8Connection: keep-aliveCache-Control: no-cacheLocation: http://gitlab.yourdomain.com:8888/users/sign_inPragma: no-cacheX-Content-Type-Options: nosniffX-Download-Options: noopenX-Frame-Options: SAMEORIGINX-Permitted-Cross-Domain-Policies: noneX-Request-Id: 01GN8XQC4NVMGZ7VA4S5QRRX2EX-Runtime: 0.029655X-Ua-Compatible: IE=edgeX-Xss-Protection: 1; mode=blockStrict-Transport-Security: max-age=63072000Referrer-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_inHTTP/1.1 200 OKServer: nginxDate: Tue, 27 Dec 2022 04:35:02 GMTContent-Type: text/html; charset=utf-8Connection: keep-aliveVary: Accept-EncodingCache-Control: max-age=0, private, must-revalidateContent-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/cssPermissions-Policy: interest-cohort=()Pragma: no-cacheSet-Cookie: _gitlab_session=e3d88869c1f709d08bb1887a9da8fb9f; path=/; expires=Tue, 27 Dec 2022 06:35:02 GMT; HttpOnlyVary: AcceptX-Content-Type-Options: nosniffX-Download-Options: noopenX-Frame-Options: SAMEORIGINX-Permitted-Cross-Domain-Policies: noneX-Request-Id: 01GN8XSJQC57ANRBDYY8J9P8HFX-Runtime: 0.068342X-Ua-Compatible: IE=edgeX-Xss-Protection: 1; mode=blockStrict-Transport-Security: max-age=63072000Referrer-Policy: strict-origin-when-cross-origin

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

总结

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

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