GitLab log in issues still plaguing us :(

[JedMeister]

Despite thinking that we'd finally fixed the (ongoing) initial GitLab log in issues - it seems that even in the latest v18.1 release it's still an issue... :(

Marcos has provided some info, ideas & thoughts on the forums. Another user has also provided info on the workaround they used.

When we rebuild GitLab - #2007 - we should have another look at this too...

[OnGle]

This issue is caused because of a password that does not meet the gitlab requirements is accepted by the gitlab inithook.

Requirements are outlined here:
https://docs.gitlab.com/ee/user/profile/user_passwords.html

[JedMeister]

Thanks @OnGle - I think that is likely a factor, but I'm pretty sure that I tested myself and was able to reproduce the issue. Using the info shared in forum links I posted above, that resolved it.

Although did you rebuild and test? If it worked for you that's certainly a strange one! If it is to do with a "bad" password via the inithook, perhaps there is a way that we could check against GitLab's blacklist? (Like we do on the Nextcloud app).

[OnGle]

Pretty sure I rebuild and tested, and was not able to reproduce with a password that did match it's requirements, but it's been a while so I don't remember any other exact details

[JedMeister]

Ok, well if that's the case, we definitely need to check the password the user sets on firstboot. Seeing as GitLab has quite specific password requirements we should probably be doing that anyway...

According to the GitLab docs if setting the password fails, it will output the error message "Password must not contain commonly used combinations of words and letters." Although, it's not completely clear to me whether that's just via the web UI or what?

We're currently (re)setting the GL root user password via a rake task. If that is giving an error and/or non-zero exist code, instead of just echoing the error message and exiting with the error code (as we do now), we need to do something like what we do in the Nextcloud inithook.

If for some reason the rake task doesn't give an error/exit code, then we could try the rails console. We could use a ruby script via rails runner. FYI there is a note that disabling auto complete makes it quicker too. Although, the GitLab rails console docs note:

The Rails console interacts directly with GitLab. In many cases, there are no handrails to prevent you from permanently modifying, corrupting or destroying production data.

Perhaps the best way to go is to use the API?! We would need to start GitLab to interact with it, but if we start that early in the first boot process, perhaps that might even be the quickest way to set it? Plus of all the options (other than via the web UI) that is probably most likely to give us an error message.

Anyway, it needs further testing/development...

[OnGle]

Great ideas, shouldn't be too difficult to handle this!