Geo: gitlab-rake gitlab:geo:check incorrectly shows database is not configured
When running the command gitlab-rake gitlab:geo:check
on a Postgres node that is part of a Patroni cluster, the command will output the following:
Checking Geo ...
GitLab Geo secondary database is correctly configured ... no
Try fixing it:
Check if you enabled the `geo_secondary_role` or `geo_postgresql` in the gitlab.rb config file.
For more information see:
doc/gitlab-geo/database.md
Database replication enabled? ... yes
Database replication working? ... yes
GitLab Geo HTTP(S) connectivity ...
* Can connect to the primary node ... yes
GitLab Geo is available ...
GitLab Geo is enabled ... yes
This machine's Geo node name matches a database record ... yes, found a secondary node named "staging-ref-europe"
HTTP/HTTPS repository cloning is enabled ... yes
Machine clock is synchronized ... yes
Git user has default SSH configuration? ... yes
OpenSSH configured to use AuthorizedKeysCommand ... warning
Reason:
OpenSSH configuration file points to a different AuthorizedKeysCommand
Try fixing it:
We were expecting AuthorizedKeysCommand to be: /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-keys-check git %u %k
but instead it is: /usr/bin/google_authorized_keys
If you made a custom command, make sure it behaves according to GitLab's Documentation
For more information see:
doc/administration/operations/fast_ssh_key_lookup.md
warning
Reason:
OpenSSH configuration file points to a different AuthorizedKeysCommandUser
Try fixing it:
We were expecting AuthorizedKeysCommandUser to be: git
but instead it is: root
Fix your OpenSSH configuration file pointing to the correct user
For more information see:
doc/administration/operations/fast_ssh_key_lookup.md
GitLab configured to disable writing to authorized_keys file ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Checking Geo ... Finished
The Geo UI will also still show that the secondary site is Healthy
.
The role geo_secondary_role
is only supposed to be used in single node setups and the role geo_postgresql
is only used to enable the tracking database, this is actually enabled on the node I ran this on, but this wouldn't always be the case depending on the user setup. The command looks to be incorrectly detecting the use of geo_postgresql
however, this also seems like a bad point to fail on as the geo_postgresql
doesn't need to be enabled on every node.