GitLab Next

Summary

After moving/transferring a project using GitLab pages from one namespace to another, visiting the new GitLab Pages URL results in a 404.

Forcing a configuration reload of the gitlab-pages daemon using the below command fixed the issue.

echo 'random-content' | tee /var/opt/gitlab/gitlab-rails/shared/pages/.update

Encountered by customer (Zendesk internal link)

Steps to reproduce

1. Create a project under one namespace using any GitLab Pages template (I used the static HTML one)
2. Run pipeline and visit the pages URL to see that the page works
3. Transfer project to another namespace
4. Run pipeline again in project
5. Visit the new pages URL to see a 404. Old pages URL also has a 404 as expected.

What is the current bug behavior?

gitlab-pages daemon doesn't reload its configuration when a project that has pages transfers between namespaces. Most likely the pages-root/.update isn't being updated.

What is the expected correct behavior?

gitlab-pages daemon should reload its configuration when a project that has pages transfers between namespaces.

Output of checks

(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)

Results of GitLab environment info

Expand for output related to GitLab environment info

System information
System:		Debian 8.11
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	2.5.3p105
Gem Version:	2.7.6
Bundler Version:1.17.3
Rake Version:	12.3.2
Redis Version:	3.2.12
Git Version:	2.18.1
Sidekiq Version:5.2.5
Go Version:	unknown
GitLab information
Version:	11.10.1-ee
Revision:	2cd7cedf96c
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	9.6.11
URL:		https://gitlab.weimeng.dev
HTTP Clone URL:	https://gitlab.weimeng.dev/some-group/some-project.git
SSH Clone URL:	git@gitlab.weimeng.dev:some-group/some-project.git
Elasticsearch:	yes
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers:
GitLab Shell
Version:	9.0.0
Repository storage paths:

• default: /var/opt/gitlab/git-data/repositories GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check

Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 9.0.0 ? ... OK (9.0.0)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK
Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 3
Try fixing it:
sudo service gitlab stop
sudo pkill -u git -f sidekiq
sleep 10 && sudo pkill -9 -u git -f sidekiq
sudo service gitlab start
Please fix the error above and rerun the checks.
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... LDAP is disabled in config/gitlab.yml
Checking LDAP ... Finished
Checking GitLab App ...
Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
2/1 ... yes
2/2 ... yes
2/3 ... yes
4/4 ... yes
8/5 ... yes
8/6 ... yes
8/7 ... yes
8/8 ... yes
8/9 ... yes
8/10 ... yes
8/11 ... yes
14/12 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.5.3 ? ... yes (2.5.3)
Git version >= 2.18.0 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 6
Elasticsearch version 5.6 - 6.x? ... yes (6.6.2)
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Potential workaround

Introduced in GitLab Pages v1.17.0 and GitLab 12.10

GitLab Pages supports using the GitLab internal API to get the domain source configuration instead of reading from disk (NFS). This will be officially supported when #217912 (closed) is delivered.

It might be possible to enable this feature on self-managed instances by following this procedure:

NOTE: This method is not verified to work and it will not be officially supported but you can try

1. Create a file .gitlab-source-config.yml
2. Add the following to enable on a subset of domains

domains:
  enabled:
    - domain1.yourpagesdomain.com
    - domain2.yourpagesdomain.com

3. To enable on all domains

domains:
  rollout:
    percentage: 100

4. You will need to generate an API access secret key, this is not well documented yet but the easiest way to do it is by following the GitLab Pages admin guide as if you were running Pages on a separate service. In summary you need to add the following to your /etc/gitlab/gitlab.rb

gitlab_pages['enable'] = true
gitlab_pages['access_control'] = true # this will generate the api_secret_key that is needed and Omnibus will pass it to the GitLab pages daemon
gitlab_pages['internal_gitlab_server'] = 'https://your.domain.com'
gitlab_pages['log_verbose'] = true # this is not needed but it may help you debug in case things don't work out.
gitlab_pages['env'] = {
	"GITLAB_SOURCE_CONFIG_FILE" =>"/path/to/.gitlab-source-config.yml"
}
# GITLAB_SOURCE_CONFIG_FILE will read this config and check the rollout, if 100 it will always try to resolve the config using the API

5. Reconfigure GitLab
6. Check the Pages logs sudo gitlab-ctl tail gitlab-pages and look for this line

{"Broken domain":"","Enabled domains":null,"Rollout %":100,"Rollout stickiness":"","level":"info","msg":"gitlab source config updated","time":"2020-06-23T03:42:31Z"}

In theory this will tell Pages to use the API to read the domain configuration. You can potentially check if it's working if you have enabled gitlab_pages['metrics_address'] you can look for gitlab_pages_domains_source_api_requests_total. You can also check the GitLab logs for requests to /api/v4/internal/pages.

Again, these steps are NOT verified using Omnibus but you are welcome to try! Please keep an eye on #217912 (closed) and related issues where we will add more related functionality to Pages and Omnibus.