Painless migration from Gitosis to Gitolite
Gitosis is no longer supported, and the stable release of Debian Wheezy, on which it will no longer be, is not far off. Therefore, it was decided to migrate to gitolite. Despite the fact that there is a corresponding manual , it does not give an answer to the question - “How to do it and not break anything?”. This is now and will be discussed.
The idea is this: to raise gitolite on the same user, check its operation and replace gitosis with gitolite with minimal downtime.
Since the installation is conducted on a single user, conflicts are possible. Therefore, it was found that with default configurations, conflicts are possible in the following places: in the folder where the repositories are located ~ / repositories and in the file ~ / .ssh / authorized_keys , which is automatically generated by these applications. In the first case, it is possible to change the default path, but for the second case, the author of gitolite did not provide for such a possibility. Although there is perl, it does not matter - break through. A small commit fixed the situation. Installation is advisable to make from source, because it gives more flexibility. An alternative way is to rebuild the package, but then the advantage associated with simply updating the package is lost. So the first option is preferable.
I will not paint the full installation, as it has already been done for me, and I will describe only specific moments. Before running gitolite setup, you need to change the GL_REPO_BASE and SSH_AUTH_KEY parameters in the src / lib / Gitolite / Rc.pm file . For example, replace authorized_keys with authorized_keys_gitolite , and in GL_REPO_BASE we specify another folder. Now you can safely continue the installation, since conflicts are excluded.
')
Gitolite and gitosis cannot simultaneously use one copy of ssh, therefore we will raise the second. To do this, copy the config to / etc / ssh / sshd_config, say in / etc / ssh / sshd_config_gitolite, and change the latter.
You should uncomment the AuthorizedKeysFile field in it and register the file that was specified earlier in the gitolite config (in our case, authorized_keys_gitolite ). And also replace the Port parameter with another one, let it be 22222 .
Now we run ssh in debug mode sudo / usr / sbin / sshd -ddd -f / etc / ssh / sshd_config_gitolite and check its operation. To do this, we clone the git clone test repository ssh: // git @ git-server: 22222 / testing . Next, go to the migration, which is described in the gitolite manual : add keys, migrate the config and test access rights.
The last step is to switch from gitosis to gitolite. To do this, we cut off the access to all to git (so that there are no new changes) by moving the .ssh / authorized_keys file to another location. Then there are two ways: either copy the repositories from ~ / repositories to ~ / repo or make symlinks on them. After moving the repositories run gitolite setup , as described in the manual. The last step is to replace SSH_AUTH_KEY with the default value and rename the authorized_keys_gitolite file to authorized_keys . Therefore, the migration was successfully completed.
What is the result: the method is fairly painless, because the installation of gitolite is done independently and the configuration can be tested in advance. The advantage of this method is that time downtime goes to zero.
Successful migration!
The idea is this: to raise gitolite on the same user, check its operation and replace gitosis with gitolite with minimal downtime.
Since the installation is conducted on a single user, conflicts are possible. Therefore, it was found that with default configurations, conflicts are possible in the following places: in the folder where the repositories are located ~ / repositories and in the file ~ / .ssh / authorized_keys , which is automatically generated by these applications. In the first case, it is possible to change the default path, but for the second case, the author of gitolite did not provide for such a possibility. Although there is perl, it does not matter - break through. A small commit fixed the situation. Installation is advisable to make from source, because it gives more flexibility. An alternative way is to rebuild the package, but then the advantage associated with simply updating the package is lost. So the first option is preferable.
I will not paint the full installation, as it has already been done for me, and I will describe only specific moments. Before running gitolite setup, you need to change the GL_REPO_BASE and SSH_AUTH_KEY parameters in the src / lib / Gitolite / Rc.pm file . For example, replace authorized_keys with authorized_keys_gitolite , and in GL_REPO_BASE we specify another folder. Now you can safely continue the installation, since conflicts are excluded.
')
Gitolite and gitosis cannot simultaneously use one copy of ssh, therefore we will raise the second. To do this, copy the config to / etc / ssh / sshd_config, say in / etc / ssh / sshd_config_gitolite, and change the latter.
You should uncomment the AuthorizedKeysFile field in it and register the file that was specified earlier in the gitolite config (in our case, authorized_keys_gitolite ). And also replace the Port parameter with another one, let it be 22222 .
Now we run ssh in debug mode sudo / usr / sbin / sshd -ddd -f / etc / ssh / sshd_config_gitolite and check its operation. To do this, we clone the git clone test repository ssh: // git @ git-server: 22222 / testing . Next, go to the migration, which is described in the gitolite manual : add keys, migrate the config and test access rights.
The last step is to switch from gitosis to gitolite. To do this, we cut off the access to all to git (so that there are no new changes) by moving the .ssh / authorized_keys file to another location. Then there are two ways: either copy the repositories from ~ / repositories to ~ / repo or make symlinks on them. After moving the repositories run gitolite setup , as described in the manual. The last step is to replace SSH_AUTH_KEY with the default value and rename the authorized_keys_gitolite file to authorized_keys . Therefore, the migration was successfully completed.
What is the result: the method is fairly painless, because the installation of gitolite is done independently and the configuration can be tested in advance. The advantage of this method is that time downtime goes to zero.
Successful migration!
Source: https://habr.com/ru/post/153385/
All Articles