Document what features are broken when db_key_base is lost
This commit is contained in:
parent
bbd0a2ce91
commit
8e69102173
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue