Merge branch 'enable-force-write-auth-keys-restore' into 'master'

Enable the ability to use the force env for rebuilding authorized_keys during a restore

See merge request gitlab-org/gitlab-ce!21896

3 files changed, 50 insertions, 3 deletions

diff --git a/changelogs/unreleased/enable-force-write-auth-keys-restore.yml b/changelogs/unreleased/enable-force-write-auth-keys-restore.yml
new file mode 100644
index 00000000000..f6c83cc7950
--- /dev/null
+++ b/changelogs/unreleased/enable-force-write-auth-keys-restore.yml
@@ -0,0 +1,5 @@
+---
+title: Enable the ability to use the force env for rebuilding authorized_keys during a restore
+merge_request: 21896
+author:
+type: fixed
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md
index 1d29f6d4e43..98fce7efb0b 100644
--- a/doc/raketasks/backup_restore.md
+++ b/doc/raketasks/backup_restore.md
@@ -523,7 +523,7 @@ more of the following options:
 
 - `BACKUP=timestamp_of_backup` - Required if more than one backup exists.
   Read what the [backup timestamp is about](#backup-timestamp).
-- `force=yes` - Does not ask if the authorized_keys file should get regenerated and assumes 'yes' for warning that database tables will be removed.
+- `force=yes` - Does not ask if the authorized_keys file should get regenerated and assumes 'yes' for warning that database tables will be removed, enabling the "Write to authorized_keys file" setting, and updating LDAP providers.
 
 If you are restoring into directories that are mountpoints you will need to make
 sure these directories are empty before attempting a restore. Otherwise GitLab
diff --git a/lib/tasks/gitlab/shell.rake b/lib/tasks/gitlab/shell.rake
index 4fcbbbf8c9d..0ebc6f00793 100644
--- a/lib/tasks/gitlab/shell.rake
+++ b/lib/tasks/gitlab/shell.rake
@@ -92,9 +92,11 @@ namespace :gitlab do
   def setup
     warn_user_is_not_gitlab
 
+    ensure_write_to_authorized_keys_is_enabled
+
     unless ENV['force'] == 'yes'
-      puts "This will rebuild an authorized_keys file."
-      puts "You will lose any data stored in authorized_keys file."
+      puts "This task will now rebuild the authorized_keys file."
+      puts "You will lose any data stored in the authorized_keys file."
       ask_to_continue
       puts ""
     end
@@ -118,4 +120,44 @@ namespace :gitlab do
     puts "Quitting...".color(:red)
     exit 1
   end
+
+  def ensure_write_to_authorized_keys_is_enabled
+    return if Gitlab::CurrentSettings.current_application_settings.authorized_keys_enabled
+
+    puts authorized_keys_is_disabled_warning
+
+    unless ENV['force'] == 'yes'
+      puts 'Do you want to permanently enable the "Write to authorized_keys file" setting now?'
+      ask_to_continue
+    end
+
+    puts 'Enabling the "Write to authorized_keys file" setting...'
+    Gitlab::CurrentSettings.current_application_settings.update!(authorized_keys_enabled: true)
+
+    puts 'Successfully enabled "Write to authorized_keys file"!'
+    puts ''
+  end
+
+  def authorized_keys_is_disabled_warning
+    <<-MSG.strip_heredoc
+      WARNING
+
+      The "Write to authorized_keys file" setting is disabled, which prevents
+      the file from being rebuilt!
+
+      It should be enabled for most GitLab installations. Large installations
+      may wish to disable it as part of speeding up SSH operations.
+
+      See https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html
+
+      If you did not intentionally disable this option in Admin Area > Settings,
+      then you may have been affected by the 9.3.0 bug in which the new setting
+      was disabled by default.
+
+      https://gitlab.com/gitlab-org/gitlab-ee/issues/2738
+
+      It was reverted in 9.3.1 and fixed in 9.3.3, however, if Settings were
+      saved while the setting was unchecked, then it is still disabled.
+    MSG
+  end
 end