After upgrading to 13.8, the GitLab Pages server won’t start. The obvious feedback is a 502 Bad Gateway error when browsing to a pages link, but gitlab-ctl status
returns a clearer answer:
run: alertmanager: (pid 15809) 1867s; run: log: (pid 1731) 832925s
run: crond: (pid 15818) 1867s; run: log: (pid 1749) 832925s
down: gitlab-pages: 1s, normally up, want up; run: log: (pid 1736) 832925s
run: gitlab-workhorse: (pid 16016) 1853s; run: log: (pid 1745) 832925s
(I trimmed out a lof of extra lines of services running fine. Important one is gitlab-pages is down)
Looking at the gitlab-pages log file, I see this output:
{"level":"info","msg":"GitLab Pages Daemon","revision":"e4ddf96","time":"2021-01-23T08:10:07-05:00","version":"1.34.0"}
{"level":"info","msg":"URL: https://gitlab.com/gitlab-org/gitlab-pages","time":"2021-01-23T08:10:07-05:00"}
{"level":"fatal","msg":"auth-client-id must be defined if authentication is supported","time":"2021-01-23T08:10:07-05:00"}
So, I checked out the config file for pages:
/var/opt/gitlab-gitlab-pages/gitlab-pages-config
pages-domain=my-domain.com
pages-root=/var/opt/gitlab/gitlab-rails/shared/pages
daemon-uid=998
daemon-gid=998
daemon-inplace-chroot=false
api-secret-key=/var/opt/gitlab/gitlab-pages/.gitlab_pages_secret
auth-secret=[0-9a-f]+
listen-proxy=localhost:8090
log-format=json
log-verbose
artifacts-server=https://my-domain.com/api/v4
artifacts-server-timeout=10
gitlab-server=https://my-domain.com
(I replaced my actual domain with a fake one and hid the auth-secret, of course)
Configuration uses 1 IP, different ports
It’s not clear from that config output, but I used a single machine to host both the GitLab server and the GitLab pages server. Pages is configured to use http, while the GitLab server uses https. This may be related to the problem.
Possible Related Issue
I have been watching the GitLab Pages "custom domain" options always appear on project (should be disabled)) (#5930) · Issues · GitLab.org / omnibus-gitlab · GitLab issue, because that was affecting my server previously. The main behavior of that bug appears to be fixed in 13.8, and the workarounds listed there don’t fix this new problem (or cause it; it happens either way).
Has anybody seen this? Does anybody know what value to supply for auth-client-id?