CODEWITHSUNDEEP
linuxgitlabrhel7
Schett Nico
Schett Nico

Reputation: 31

gitlab 500 errors in the admin area

How to reproduce:

  1. login as admin
  2. go into the admin menu
  3. click on overview - runners
  4. or click save in the settings

Result: 500 Error: Whoops, something went wrong on our end.

Which system is running?

RHEL 7, outbound gitlab with Nginx and passengers

Errors:

OpenSSL::Cipher::CipherError ():

lib/gitlab/crypto_helper.rb:27:in `aes256_gcm_decrypt'
app/models/concerns/token_authenticatable_strategies/encrypted.rb:55:in `get_token'
app/models/concerns/token_authenticatable_strategies/base.rb:27:in `ensure_token'
app/models/concerns/token_authenticatable_strategies/encrypted.rb:42:in `ensure_token'


ActionView::Template::Error ():
    37: 
    38:     .col-sm-6
    39:       .bs-callout
    40:         = render partial: 'ci/runner/how_to_setup_runner',
    41:                  locals: { registration_token: Gitlab::CurrentSettings.runners_registration_token,
    42:                            type: 'shared',
    43:                            reset_token_url: reset_registration_token_admin_application_settings_path }

Upvotes: 2

Views: 9292

Answers (2)

Byungjun Lee
Byungjun Lee

Reputation: 31

In the GitLab 13.0 version, it has been confirmed that the command ApplicationSetting.current.reset_runners_registration_token! is no longer supported. Previously, this command could be used to reset the registration token of GitLab CI/CD runners, but this functionality has been removed in later versions. Instead, GitLab administrators can reset the registration token of runners in the administration area of GitLab.

In GitLab versions 13.0 and later, if you attempt to use the command ApplicationSetting.current.reset_runners_registration_token!, an error message will be displayed. This is because this command is no longer supported.

Source: GitLab 13.0 release notes

To resolve this issue in GitLab versions 13.0 and later, you can follow the steps below:

gitlab-rails console
> ApplicationSetting.first.delete
> ApplicationSetting.first
=> nil

Source: GitLab issue #57038

Upvotes: 3

Joost Evertse
Joost Evertse

Reputation: 1085

I am almost sure it's a wrong decryption key that gitlab reads from /etc/gitlab/gitlab-secrets.json (omnibus install) or $GITLAB_HOME/config/secrets.yml(source based install). If you don't care about your runner_registration_token you can reset it like this from the console:

root@gitlab:/# gitlab-rails console
-------------------------------------------------------------------------------------
 GitLab:       11.5.1 (c90ae59)
 GitLab Shell: 8.4.1
 postgresql:   9.6.8
-------------------------------------------------------------------------------------
Both Deployment and its :status machine have defined a different default for "status". Use only one or the other for defining defaults to avoid unexpected behaviors.
Loading production environment (Rails 4.2.10)
irb(main):001:0> ApplicationSetting.current.reset_runners_registration_token!
=> true
irb(main):002:0>

Upvotes: 5

Related Questions