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…

  1. 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
  2. Move the old gitosis home directory out of the way: mv git git_old
  3. Install gitolite: apt-get install gitolite
  4. I then needed to reconfigure gitolite so it used the same user id as the previous gitosis install: dpkg-reconfigure gitolite
  5. Copy your old repositories to your newly created git directory: cp -a git_old/repositories git/
  6. 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.
    1. 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
    2. 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

  7. On the server, change to the git user: su git
  8. Then initialise the gitolite repository, passing the location of your newly created admin key: gl-setup /path/to/gitoliteadmin@myserver.local
  9. Clone the gitolite-admin repository, note the use of the gitolite-admin host repository: git clone git@gitolite-admin
  10. 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
  11. 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
  12. 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!

idno Idno is a modern #indieweb self hosted open source social networking platform. The project was started by Ben Werdmuller, who you may remember from such projects as Elgg, it makes use of a lot of cool technologies and has some very interesting features on the roadmap.

I recently got stuck into the project myself; as a former core Elgg developer myself, it seemed an obvious platform to look at when I wanted to PRISM break my social media activity, and move to a POSSE modal for Facebook and Twitter etc. It also forms the base to a couple of cool client projects that I’m working on.

The project is really starting to pick up speed, and you can see my social stream over at mapkyca.com.

Ben has done a really nice job at building the initial platform, and I can’t wait to see how the project develops!

opengraphlogoThe Open Graph protocol is a way of providing rich content information for pages when shared on social networks.

This is quite powerful, and there’s a lot you can do with it, but at the basic level it provides a way for content creators to control how the share stub looks when shared on networks like Facebook or Google+. Support for this has been missing from Elgg for a while, so I dusted off some old code and built a plugin to add support!

The Elgg Open Graph plugin adds Open Graph meta headers to your Elgg site (with reasonable defaults), and provides a framework for you to add specific open graph headers to object pages and specific URLS.

» Visit the project on Github…