Commit 8e691021 authored by Nick Thomas's avatar Nick Thomas

Document what features are broken when db_key_base is lost

parent bbd0a2ce
...@@ -806,9 +806,22 @@ If you have failed to [back up the secrets file](#storing-configuration-files), ...@@ -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, 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). 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 The secrets file is also responsible for storing the encryption key for several
some weird behavior, like stuck jobs or 500 errors. In that case, you can try columns containing sensitive information. If the key is lost, GitLab will be
deleting the `ci_variables` table from the database. 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:** CAUTION: **Warning:**
Use the following commands at your own risk, and make sure you've taken a Use the following commands at your own risk, and make sure you've taken a
...@@ -828,9 +841,10 @@ backup beforehand. ...@@ -828,9 +841,10 @@ backup beforehand.
sudo -u git -H bundle exec rails dbconsole RAILS_ENV=production 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 ```sql
SELECT * FROM public."ci_group_variables";
SELECT * FROM public."ci_variables"; SELECT * FROM public."ci_variables";
``` ```
...@@ -839,6 +853,7 @@ backup beforehand. ...@@ -839,6 +853,7 @@ backup beforehand.
1. Drop the table: 1. Drop the table:
```sql ```sql
DELETE FROM ci_group_variables;
DELETE FROM ci_variables; DELETE FROM ci_variables;
``` ```
...@@ -848,5 +863,9 @@ backup beforehand. ...@@ -848,5 +863,9 @@ backup beforehand.
You should now be able to visit your project, and the jobs will start You should now be able to visit your project, and the jobs will start
running again. 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 [reconfigure GitLab]: ../administration/restart_gitlab.md#omnibus-gitlab-reconfigure
[restart GitLab]: ../administration/restart_gitlab.md#installations-from-source [restart GitLab]: ../administration/restart_gitlab.md#installations-from-source
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment