Document what features are broken when db_key_base is lost

This commit is contained in:
Nick Thomas 2019-02-15 11:22:37 +00:00
parent bbd0a2ce91
commit 8e69102173
No known key found for this signature in database
GPG Key ID: 2A313A47AFADACE9
1 changed files with 23 additions and 4 deletions

View File

@ -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