Gitlab promox turnkey image version 17.1 from 6th April first login issue (not a duplicate)

[lycano]

Description

When using the latest turnkey gitlab turnkey CT image downloaded via templates debian-11-turnkey-gitlab_17.1-1_amd64.tar.gz I'm not able to login with root. When creating a new admin user via console you can login but wont be able to visit runners page nor save any changes done to settings. It would result in 500 internal server error.

How to reproduce

1. Download turnkey template in proxmox debian-11-turnkey-gitlab_17.1-1_amd64.tar.gz
2. Create CT with image
3. Run the container and follow instructions
4. Set Gitlab Root password
5. Try to login to gitlab with root:
6. Get gitlab 500 internal server error page

Check issue

Run gitlab-rake gitlab:doctor:secrets VERBOSE=1 via ssh console and see that ApplicationSettings failure exists

ApplicationSetting failures: 1
D, [2023-04-09T13:40:44.055247 #1733] DEBUG -- :   - ApplicationSetting[1]: runners_registration_token, error_tracking_access_token

Side-Issue

• Gitlab version 15.10.0 is installed which has a security issue. Needed to do apt update && apt upgrade after applying fixes.
• After applying fixes version check was disabled. used gitlab-rails runner 'ApplicationSetting.last.update(version_check_enabled: true)' to enable them again

How to fix first time login issue

The commit for file conf.d/main implements resetting the runner token but is not enough. The command from the closed issue #1342 needs to be applied after deleting ApplicationSetting.first

The following commands fixed the first time login issue for me. After that i could login and rake doctor:secrets didnt gave me errors. Please note that I had 15.10.0 installed at the time beeing that was installed with the image and did not yet upgrade to latest 15.10.2.

$ export LC_ALL=C.UTF-8
$ echo -e 'ApplicationSetting.first.delete\n' | gitlab-rails console -e production
cat <<EOF | gitlab-rails dbconsole --database main
UPDATE projects SET runners_token = null, runners_token_encrypted = null;
UPDATE namespaces SET runners_token = null, runners_token_encrypted = null;
UPDATE application_settings SET runners_registration_token_encrypted = null;
UPDATE application_settings SET encrypted_ci_jwt_signing_key = null;
UPDATE ci_runners SET token = null, token_encrypted = null;
TRUNCATE integrations, chat_names, issue_tracker_data, jira_tracker_data, slack_integrations, web_hooks, zentao_tracker_data, web_hook_logs, dingtalk_tracker_data, slack_integrations_scopes;
EOF
$ gitlab-rails runner -e production "ApplicationSetting.current.reset_runners_registration_token!"
$ /usr/lib/inithooks/bin/gitlab.py --email="your@mail.com" --domain="your.externail-domain.com"

Running gitlab-rails runner -e production "ApplicationSetting.current.reset_runners_registration_token!" without deleting first application-setting results in /opt/gitlab/embedded/lib/ruby/gems/3.0.0/gems/encryptor-3.0.0/lib/encryptor.rb:98:in final': OpenSSL::Cipher::CipherError`. So the combination of the two is needed to fix this in my opinion.

Additional Suggestion

I assume the target audience for turnkey-gitlab is most likely in the private sector. When setting up the instance signup should be disabled. I recommend adding gitlab-rails runner 'ApplicationSetting.last.update(signup_enabled: false)' to conf.d/main would be a security improvement.

When finishing setting up the instance some can always enable this setting later.

[JedMeister]

Argh! Still issues with GitLab... :(

Thanks for such a detailed post. We'll need to circle back to this one and apply your fixes.

[scarolan]

Gitlab is an absolute beast of an app, just look at the hundreds of items it touches during the Chef run.

Confirmed that @lycano fix worked for me. You, sir, are the real MVP

[marcos-mendez]

Can I pay you with Love?

Thanks thanks thanks!!!!

[gabbler97]

A fix would be good for that HTTP 500 error. 👍 :)

[Matjaz-B]

So....
I've stumbled arround this issue. I have fresh Welcome to Turnkey-gitlab, TurnKey GNU/Linux 17.1 I also got HTTP 500 after login. After that 100% CPU, MEM, SWAP utilization.

The gitlab version is way old (15.10). Upgrade seems to be quite difficult. Therefore I'll just start from clean debian and install gitlab.

Thanks anyway!

[JedMeister]

Yes, GitLab is a serious PITA to maintain. It's a beast of a thing with so many moving parts, huge resource requirements and takes ages to build.

Our plan is to update it (applying the latest fixes as detailed) when we get to it, but historically it takes a ton of effort to maintain and then it breaks again... Hence why we haven't prioritised it. If it continues to be as hard to maintain as it has been, we'll likely just drop it as an appliance. As you guys all note, it's not much value as it is.

With the new CI integration in Gitea (not yet included in TurnKey build - but will be in v18.0), that gives it mostly feature parity with GitLab and it uses much less resources, is much more responsive and is a breeze to maintain (I have been running it myself for a few years now). So using that instead would be my recommendation.

But if you're sure you want GitLab, then either installing it yourself from scratch, or doing a clean install to the current appliance are good options.