GitLab Pages 13.8 won't start

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?

I got the same problem.

I passed a set of fake parameters to make the GitLab Pages work temporarily:

echo "\nauth-client-id=123\nauth-client-secret=123\nauth-redirect-uri='http://projects.example.io/auth'\nauth-secret=123\nauth-server=http://localhost\n" >> /var/opt/gitlab/gitlab-pages/gitlab-pages-config
/opt/gitlab/bin/gitlab-ctl restart

Seems the Pages daemon should not check these parameters if access control is disabled but it does in 13.8.0.

2 Likes

same issue here

after adjusting the settings to:
gitlab_pages['access_control'] = true

it works again

2 Likes

This worked for me. I think that used to be the default value, so I had it left it unspecified. By explicitly setting access_control to true, the problem went away.

Thanks @bearsh for the workaround.

This is a known issue and a fix has been merged for inclusion in a future patch release.

If you’re affected by this problem but do not want the GitLab Pages Access Control to stay enabled, there is a workaround here: Omnibus generates invalid gitlab-pages-config: "auth-redirect-uri must be defined if authentication is supported" (#5954) · Issues · GitLab.org / omnibus-gitlab · GitLab.

TL;DR: Set gitlab_pages['access_control'] = false and reconfigure, then set gitlab_pages['access_control'] = false and Reconfigure.

It has been fixed in 13.8.1 now

1 Like