I migrated one of my GitLabs from a Debian 9 VM to a Debian 11 VM by backup and restore following the Docs:
This was straightforward. However the one thing i’m wondering about is the warning message i get in the restore phase about the regeneration of the authorized_key file. If i understood it right, this file speeds up the system when looking for authorized keys. But what about the warning? Is there anything that can go wrong here?
Any hints?
Could you post the exact error/warning message that you saw on screen? I believe when I’ve restored Gitlab recently, it asks about this and you have an option y/n to do it. I always choose yes at this point. Is that what you did?
Sorry i don’t remember the exact warning message anymore. I think it was a yes/no option presented during restore. The Docs state i can force regeneration:
Depending on your case, you might want to run the restore command with one or more of the following options:
...
force=yes: Doesn’t ask if the authorized_keys file should get regenerated, and assumes ‘yes’ for warning about database tables being removed, enabling the Write to authorized_keys file setting, and updating LDAP providers.
So my question is: if there is a warning, why? What might go wrong?
The authorized_keys file tells SSH that if a server’s public key is in this file, it’s known to be good and it’s okay to connect. When a key changes, SSH will notice that the one the remote server has is no longer the one that you previously authorized and it’ll alert you. The purpose of alerting you about a key change is so that you can make a decision about whether you should proceed with connecting or not.
If you have a process in place to maintain that file with known good keys, then you probably don’t want GitLab to regenerate it. You want whatever your process is to handle it. But if you don’t handle that authorized_keys file yourself, then it’s more than likely safe – and definitely easiest – to say “yes” and let GitLab regenerate the file for you.