signup_enabled: false in gitlab.yml doesn't work

It occurs, that no matter what setting is set (or not set at all) of signup_enabled in gitlab.yml, Home page always shows signup form, and it works!

I think related to https://github.com/gitlabhq/gitlabhq/issues/8589

mentioned in issue #978 (closed)

Status changed to closed

Fixed in master https://gitlab.com/gitlab-org/gitlab-ce/commit/5e0497758276660989cda53f86346954b53a17ad

This fix in master, didn't solve the problema. I still can see signup form and create new users, even with expilcitly defined signup_enabled: false

Status changed to reopened

/cc @dzaporozhets @sytses

I've tested this and it seems that the variable in the gitlab.yml currently does not work. But the setting on the admin page works fine. You can enable and disable the signup perfectly.

Would removing this setting from the gitlab.yml be a fix? This would prevent users from trying to set it like they did before. This probably needs to be mentioned in the release blog post if you decide to go that way.

The setting on the admin page overrides the one on gitlab.yml

right. so no matter what you set the variable in the gitlab.yml to, it'll be overwritten by the setting on the admin page. This makes sense for me. But then i don't see the point of keeping the variable in the gitlab.yml.

@haynes it is there for backwards compatibility, if there is nothing set in the admin interface the gitlab.yml value is taken before the default

@sytses But isn't there always a value set in the admin interface? I mean it's a boolean setting.
It should always be either false or true on the admin interface.
I think keeping it in the 1_settings.rb would be enough for a fallback if something like that is really needed.

@haynes When you first start GitLab it takes the settings from gitlab.yml and stores them in the database. After this it ignores them.

@haynes thank you, it solved my issue. I just wanted to get rid of signup form, and didn't new about admin area settings. Its kind'a new feature o version 7.7, or I've missed it in previous versions?

Status changed to closed

@sytses this is only true in one case. Gitlab has never been started before and the variable is set to false.

By default the variable is commented out in gitlab.yml and gitlab takes the initial value from config/initializers/1_settings.rb
Which sets it to true if the variable is nil.

So the only effect from removing it from the gitlab.yml would be that it is always true on the very first start.
Given that the variable in gitlab.yml only works once and only if set to false i think it should be removed from the gitlab.yml file in order to prevent confusion for new users.

edit: the gitlab.yml also says this: "# default: false -"
this is wrong with the current code in config/initializers/1_settings.rb
default is true.

edit2: same applies for the signin_enabled variable

@haynes Yes, if you don't have it set it will change. This is intentional and we document this in the release blogpost.

@sytses hmm.. still confusing in my opinion. Maybe adding a comment to the 2 variables could help to prevent confusion?
Something like:
# This variable is deprecated as of gitlab 7.7. Please use the Admin Settings page to change the value in the future.

@haynes We'll just remove the variables from the template gitlab.yml, the problem is that we can't change the existing installations.

@sytses that's exactly what i wanted to propose. I guess we didn't understand each other correctly for a while. Thanks for your patience :)
While we can't change existing installations, if the template gitlab.yml doesn't contain the variables anymore after an update at least it'll be a bit more visible that the variables aren't needed anymore.
And it will prevent new users who install gitlab after the 7.7 release for the first time to get confused.
Theoretically you could also use an sed command to remove or edit the variable in the gitlab.yml but that would probably bring other issues.

@haynes No problem and in the blog post we just recommend to people to remove these lines manually after their installation is upgraded.

I hate to go back to an old ticket, but we have switched from source install to Omnibus and something like this is happening to us constantly. /etc/gitlab.rb has:

gitlab_rails['gitlab_signup_enabled'] = false

But signup enables itself every time we upgrade. We disable it through the admin web interface and it stays off until the next upgrade. Currently we're on 9.4.5 and it happened again while going from 9.4.4 to 9.4.5.

What's even creepier is that the signup option enables itself on its own several hours after an upgrade. I have manually disabled it, but less than 24 hours later it had enabled itself again.

Is this the wrong option for newer versions?

Update: This is creepy. Signup enables itself every day, and every day we switch it off again. What kinds of cronjobs in an Omnibus installation could be causing this?

I've gone through the database, and the 'application_settings' table switches signup_enabled to true every day at 20:30. It turns out there was a cronjob left over from the source installation that tried to take LVM snapshots of the whole machine. But instead of only taking snapshots, it also did an /etc/init.d/gitlab stop and start. This probably messed up the config, overwriting the Omnibus installation's settings with some of the source one's defaults.

Moral of the story: Either change your DB passwords when you move to Omnibus or make absolutely sure every single file and directory of the previous installation has been nuked.