Gitosis is a GIT server system which, using ssh, lets you run a central git repository in much the same way as github does. This let you manage multiple developers easier, as well as providing a convenient place to access repositories while out and about, and for deployment.
Unfortunately, gitosis is no longer maintained, and has been removed from more recent versions of the major linux distributions. This was preventing me from performing some much needed server upgrades, so it was therefore necessary to migrate to another bit of software.
Gitolite is the recommended replacement for Gitosis, and acts as a drop in replacement. Perform the migration right, and you’re users will never notice that you did anything at all.
So, in hopes that this may be useful to someone, here’s how I migrated my gitosis server over.
The initial setup
The initial server configuration was as follows:
- Debian server
- Gitosis installed as user “git”
My goal was to replace the gitosis server, still on the GIT user, so my users would not need to modify any of the remote repository paths in any checked out repositories.
Migration
Start off by taking a backup, just incase this goes horribly wrong, then…
- Belts and braces, get rid of the old gitosis update hooks and prevent any new sessions by removing the
authorized_keys
file: mv git/repositories/gitosis-admin/hooks/post-update git/repositories/gitosis-admin/hooks/post-update.old; mv git/.ssh/authorized_keys git/.ssh/authorized_keys.old
- Move the old gitosis home directory out of the way:
mv git git_old
- Install gitolite:
apt-get install gitolite
- I then needed to reconfigure gitolite so it used the same user id as the previous gitosis install:
dpkg-reconfigure gitolite
- Copy your old repositories to your newly created git directory:
cp -a git_old/repositories git/
- Gitolite had trouble using my existing public ssh keys for the admin account, probably because they were already used as login keys, or perhaps because they were in the foo@bar.pub format. Either way, the simplest thing was to generate an admin key specifically for gitolite administration.
- Generate a new key, making sure you have at least one “.” after the “@”, so that the key looks like an email address:
ssh-keygen -t rsa -C "gitoliteadmin@myserver.local" -f gitoliteadmin@myserver.local
- Make sure root, or whoever is going to admin your gitolite repo has a copy of these keys, as you’ll need them to make any configuration changes. You can simplify this somewhat by making a host alias for the gitolite admin user in the
~/.ssh/config
file
Host gitolite-admin
HostName myserver.local
User git
IdentityFile ~/.ssh/gitoliteadmin@myserver.local
- On the server, change to the git user:
su git
- Then initialise the gitolite repository, passing the location of your newly created admin key:
gl-setup /path/to/gitoliteadmin@myserver.local
- Clone the gitolite-admin repository, note the use of the
gitolite-admin
host repository: git clone git@gitolite-admin
- Convert your gitosis settings file using
gl-conf-convert
, which if you’re running this on the server, can be found in /usr/share/gitolite
. This script can be run in isolation, so it’s ok to copy it about if you need to run this on a different machine: /path/to/gl-conf-convert < /path/to/gitosis-admin/gitosis.conf >> /path/to/gitolite-admin/conf/gitolite.conf
- Now, check your
gitolite.conf
for errors, and if ok commit and push your changes. Since I had a number of keys in the format of user@machine
, I had to change the occurrence of those users in the file to just the username before the “@” character. E.g. foo@machine
becomes just foo
- Things should now be working on gitolite. You can verify that gitolite rather than gitosis is fielding your requests using ssh:
ssh git@myserver.local info
, you should see a list of the repositories on the server that your user has access to.
All being well, your migration over to gitolite should now be complete, and remotes in any existing clones of repositories on the server should still function.
Hope this helps!