### 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](https://gitlab.zendesk.com/agent/tickets/118874)) ### 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 <details> <summary>Expand for output related to GitLab environment info</summary> <pre> 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 </pre> </details> #### Results of GitLab application Check <details> <summary>Expand for output related to the GitLab application check</summary> <pre> 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 </pre> </details> ### 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 https://gitlab.com/gitlab-org/gitlab/-/issues/217912 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 ```yaml domains: enabled: - domain1.yourpagesdomain.com - domain2.yourpagesdomain.com ``` 3. To enable on all domains ```yaml 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](https://docs.gitlab.com/ee/administration/pages/#running-gitlab-pages-on-a-separate-server) as if you were running Pages on a separate service. In summary you need to add the following to your `/etc/gitlab/gitlab.rb` ```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](https://docs.gitlab.com/ee/administration/restart_gitlab.html#omnibus-gitlab-reconfigure) 6. Check the Pages logs `sudo gitlab-ctl tail gitlab-pages` and look for this line ```shell {"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 https://gitlab.com/gitlab-org/gitlab/-/issues/217912 and related issues where we will add more related functionality to Pages and Omnibus.