Default `authorized_keys_enabled` setting to true
What does this MR do?
Sets the column default for the Application Setting authorized_keys_enabled
to true and rebuilds the authorized_keys
file.
Why was this MR needed?
https://gitlab.com/gitlab-org/gitlab-ee/issues/2738
EE installations that were upgraded to 9.3 stopped writing to the authorized_keys
file by default. The setting authorized_keys_enabled
was nil
. So additions and deletions of SSH keys had no effect on SSH operations.
When I added the setting, I mistakenly thought settings were merged with ApplicationSetting.defaults
. However, if there exists an ApplicationSetting
record, defaults
is never used.
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added - Tests
-
Added for this feature/bug -
All builds are passing
-
-
Conform by the merge request performance guides -
Conform by the style guides -
Branch has no merge conflicts with master
(if it does - rebase it please) -
Squashed related commits together
What are the relevant issue numbers?
Fixes #2738 (closed)
Merge request reports
Activity
@stanhu
Locally, I had to restart my app server after changing the column default for the setting to becomeEdit: I added a line so that if the setting is still cached astrue
. It seems like the setting was cached in memory. Will this be a problem for others?nil
, it will default totrue
. This is safe sincenil
is not allowed anymore and is set totrue
in the DB.Is it safe to add a migration to automatically rebuild the
authorized_keys
file?- Should it require downtime?
- Do we need to make GitLab.com skip it?
Edited by Michael Kozonoadded 2 commits
added 1 commit
-
c0d62a85 - Ensure
authorized_keys_enabled
defaults to true
-
c0d62a85 - Ensure
added 2 commits
- Resolved by Michael Kozono
- Resolved by Michael Kozono
- Resolved by Michael Kozono
- Resolved by Michael Kozono
mentioned in merge request !2256 (merged)