There is a process called lockgit which respawns itself continually. We thought it might be some part of gitlab gone awry, so we shut down and eventually uninstalled (Omnibus) gitlab-ee 13.7.1.
We are running OpenSUSE 15.3
Even after removing a directory associated with lockgit (/tmp/.lockgit) and killing the process, lockgit eventually respawns. Bottom line - the server instance is trashed.
Now, there’s still respository data from 13.7.1 ee which we were testing, but it’s in its hashed form in /var/opt/gitlab/git-data/repositories.
How can we extract those repositories and recover their original names in an automated way.
We’ve figured out that we can clone the repository as non-mirror and check-out its contents and thereby infer its former name.
Can anyone help us?
You should still have backups under /var/opt/gitlab/backups - use the latest one to restore your data. Make a new server, install Gitlab-EE 13.7.1 on it, and then copy back /etc/gitlab/gitlab.rb and /etc/gitlab/gitlab-secrets.json. Run reconfigure to get a basic instance running. Copy the backup to /var/opt/gitlab/backups on the server and run the restore process as per the Gitlab restore docs. The procedure above is summarised from those docs.
You can use repository commands to check what belongs to a package, so under OpenSUSE:
rpm -ql gitlab-ee
you could have looked to see if lockgit was a part of it - it won’t be. So this would have saved you the uninstall and problems you are experiencing now. Once you’ve ascertained it’s not belonging to Gitlab, you know at this point your server was compromised. This is the only explanation for that process, especially since it’s persistent in respawning.
Thank-you for your advice. We are in the process of executing it.
I agree that we should have checked the package.
Also agree that the server was compromised.
Restore appears to have been mostly successful, although we encountered a message about an inconsistency when the restore process was untarring.