When setting up a separate Gitaly instance, secrets are not propagated correctly when "['gitlab_rails']['enable']" is false

Summary

I'm using the 2,000 users reference architecture, with a distinct Gitaly host. (https://docs.gitlab.com/ee/administration/reference_architectures/2k_users.html#configure-gitaly)

If I strictly follow the documentation, when testing Gitaly with the suggested command, I get an error message saying .gitlab_shell_secret is missing.

Steps to reproduce

Following the 2k users architecture install, or using simply a separate Gitaly instance should be enough, using Omnibus to install both Gitaly on one vm and the rest of GitLab on another vm.

What is the current bug behavior?

Error message obtained when checking my Gitaly setup:

# sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml
Checking GitLab API access: FAILED
2024/08/13 17:09:46 reading secret file: open /opt/gitlab/embedded/service/gitlab-shell/.gitlab_shell_secret: no such file or directory

What is the expected correct behavior?

If I manually link /var/opt/gitlab/gitlab-rails/etc/gitlab_shell_secret as /opt/gitlab/embedded/service/gitlab-shell/.gitlab_shell_secret, the same test comes out as a success, so this should be automated with Omnibus (or at least stated in the documentation)

Details of package version

Tested with 17.1.2-ce.0 on a Debian 12

Environment details

Debian 12 on an Openstack-based private cloud.

Configuration details

Relevant bit of gitlab.rb:

gitaly['enable'] = true

gitlab_rails['internal_api_url'] = 'https://*************'

gitaly['configuration'] = {
  listen_addr:'*************:8075',
  prometheus_listen_addr:'*************:9236',
  auth: {
    token: '***********************',
  },
  pack_objects_cache: {
     enabled: true,
  },
   storage: [
      {
         name: 'default',
         path: '/var/opt/gitlab/git-data',
      },
   ],
}