diff options
author | Nick Thomas <nick@gitlab.com> | 2019-02-15 14:22:37 +0300 |
---|---|---|
committer | Nick Thomas <nick@gitlab.com> | 2019-02-15 14:22:37 +0300 |
commit | 8e69102173095743f4ae421b1f73a057111787c2 (patch) | |
tree | 301e6108910c9c92d4f7a85a5b381b6795aa702a | |
parent | bbd0a2ce91f2d43350382c7ce83729f33c39c125 (diff) |
Document what features are broken when db_key_base is lost
-rw-r--r-- | doc/raketasks/backup_restore.md | 27 |
1 files changed, 23 insertions, 4 deletions
diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index 037b71a27b9..b207002b668 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -806,9 +806,22 @@ If you have failed to [back up the secrets file](#storing-configuration-files), then users with 2FA enabled will not be able to log into GitLab. In that case, you need to [disable 2FA for everyone](../security/two_factor_authentication.md#disabling-2fa-for-everyone). -In the case of CI/CD, if your project has secure variables set, you might experience -some weird behavior, like stuck jobs or 500 errors. In that case, you can try -deleting the `ci_variables` table from the database. +The secrets file is also responsible for storing the encryption key for several +columns containing sensitive information. If the key is lost, GitLab will be +unable to decrypt those columns. This will break a wide range of functionality, +including (but not restricted to): + +* [CI/CD variables](../ci/variables/README.md) +* [Kubernetes / GCP integration](../user/project/clusters/index.md) +* [Custom Pages domains](../user/project/pages/getting_started_part_three.md) +* [Project error tracking](../user/project/operations/error_tracking.md) +* [Runner authentication](../ci/runners/README.md) +* [Project mirroring](../workflow/repository_mirroring.md) +* [Web hooks](../user/project/integrations/webhooks.md) + +In the case of CI/CD, variables, you might experience some weird behavior, like +stuck jobs or 500 errors. In that case, you can try removing contents of the +`ci_group_variables` and `ci_project_variables` tables from the database. CAUTION: **Warning:** Use the following commands at your own risk, and make sure you've taken a @@ -828,9 +841,10 @@ backup beforehand. sudo -u git -H bundle exec rails dbconsole RAILS_ENV=production ``` -1. Check the `ci_variables` table: +1. Check the `ci_group_variables` and `ci_variables` tables: ```sql + SELECT * FROM public."ci_group_variables"; SELECT * FROM public."ci_variables"; ``` @@ -839,6 +853,7 @@ backup beforehand. 1. Drop the table: ```sql + DELETE FROM ci_group_variables; DELETE FROM ci_variables; ``` @@ -848,5 +863,9 @@ backup beforehand. You should now be able to visit your project, and the jobs will start running again. +A similar strategy can be employed for the remaining features - by removing the +data that cannot be decrypted, GitLab can be brought back into working order, +and the lost data can be manually replaced. + [reconfigure GitLab]: ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure [restart GitLab]: ../administration/restart_gitlab.md#installations-from-source |