October 4, 2012 at 10:27Painless migration from Gitosis to Gitolite
Gitosis is no longer supported, and a stable release of Debian Wheezy is not far off, on which it will no longer be. 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 this and not break anything?”. This will be discussed now.
The idea is this: raise gitolite on the same user, check its operation and replace gitosis with gitolite with minimal downtime.
Since the installation is performed on one user, conflicts are possible. Therefore, it was found that during default configurations, conflicts are possible in the following places: in the folder in which the ~ / repositories repositories are located and in the ~ / .ssh / authorized_keys file, 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 such an opportunity. Although there is perl, it doesn’t matter - we will break through. A small commit corrected the situation. It is advisable to install from the source, as this 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 points. Before running gitolite setup, you need to change the parameters in the src / lib / Gitolite / Rc.pm fileGL_REPO_BASE and SSH_AUTH_KEY . For example, replace authorized_keys with authorized_keys_gitolite , and specify another folder in GL_REPO_BASE . Now you can safely continue the installation, since conflicts are excluded.
Gitolite and gitosis cannot use one instance of ssh at the same time, so let's raise the second one. To do this, copy the config to the address / 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, it is authorized_keys_gitolite) And also replace the Port parameter with another one, let it be 22222 .
Now 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 test repository git clone ssh: // git @ git-server: 22222 / testing . Next, we move on to the migration described in the gitolite manual : add keys, migrate the config, and test access rights.
The final step is to switch from gitosis to gitolite. To do this, we cut off everyone’s access 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 . Thus, the migration was successfully completed.
The bottom line: the method is quite painless, because gitolite is installed independently and the configuration can be tested in advance. The advantage of this method is that the downtime time tends to zero.
Have a good migration!
The idea is this: raise gitolite on the same user, check its operation and replace gitosis with gitolite with minimal downtime.
Since the installation is performed on one user, conflicts are possible. Therefore, it was found that during default configurations, conflicts are possible in the following places: in the folder in which the ~ / repositories repositories are located and in the ~ / .ssh / authorized_keys file, 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 such an opportunity. Although there is perl, it doesn’t matter - we will break through. A small commit corrected the situation. It is advisable to install from the source, as this 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 points. Before running gitolite setup, you need to change the parameters in the src / lib / Gitolite / Rc.pm fileGL_REPO_BASE and SSH_AUTH_KEY . For example, replace authorized_keys with authorized_keys_gitolite , and specify another folder in GL_REPO_BASE . Now you can safely continue the installation, since conflicts are excluded.
Gitolite and gitosis cannot use one instance of ssh at the same time, so let's raise the second one. To do this, copy the config to the address / 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, it is authorized_keys_gitolite) And also replace the Port parameter with another one, let it be 22222 .
Now 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 test repository git clone ssh: // git @ git-server: 22222 / testing . Next, we move on to the migration described in the gitolite manual : add keys, migrate the config, and test access rights.
The final step is to switch from gitosis to gitolite. To do this, we cut off everyone’s access 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 . Thus, the migration was successfully completed.
The bottom line: the method is quite painless, because gitolite is installed independently and the configuration can be tested in advance. The advantage of this method is that the downtime time tends to zero.
Have a good migration!