Integrating Redmine and Gitolite

In previous posts, I described how to set up Redmine and tossed together a centralized git service. Now we want to integrate the two so that it will be easy to administer the system (actually, it becomes largely self-administering at this point). At the end of this article, a project manager should be able to start a new project, and a developer should be able to create the necessary repository for that project without any input from you, all based on permissions in Redmine.

Edit: This is the third in a four part series about gitolite and Redmine, ending with full automation. The other articles are:

Ok, let’s continue…

Redmine takes advantage of plugins to add additional capabilities. These plugins can be found on the Redmine website, starting at We will be finding one for gitolite and installing it manually into our installation of Redmine.

The one that I am going to use can be found at, although this one looks promising too:, so I’d like to do that one too. From the documentation, I could understand the following about each, as far as pros and cons:

  • The former requires that gitolite and redmine be on the same server; the latter does not.
  • The latter requires that all gitolite activities take place through redmine, the former does not, because it takes over the post-commit hooks in gitolite admin.
  • The former requires an older version of gitolite (ack!)

For now, I’m going to do the first one. There are a couple of reasons for this, not the least of which is I’ve done it before. Also, it forces us to modify the sudoers list, which is always fun, and should prove a rewarding experience for newbs. Therefore, our activities for this will be as follows:

  1. Install the old version of gitolite and set it up (this time, we’ll use dpkg-reconfigure and apt-get, so it should be relatively easy).
  2. Get a copy of the gitolite plugin.
  3. Configure the gitolite plugin.
  4. Set up the root for the redmine application with admin permissions on gitolite.
  5. Deploy the database requirements for the gitolite plugin.
  6. Restart Redmine and check the admin console for problems.

This is a big activity, so if you are unfamiliar with anything in here, plan on learning a lot. Otherwise, with the steps above, some people may already be able to move ahead without too much input from this tutorial.

Since I am fortunate enough to be working in a VM, I am able to stop and snapshot it at this point, as I’m going to be breaking gitolite, and removing lots of stuff. Snapshots allow you to move back to an earlier working state of your VM. Once again, this can easily be started with Oracle VirtualBox and a few Ubuntu ISO’s relatively quickly. I created a new snapshot called pre-gitolite-integration, and restarted the VM. Now I’m ready to work.

Install the old version of gitolite and set it up

We’re going for broke now. Remembering how the newest version of gitolite got installed, I know I only need to remove one file: /usr/local/bin/gitolite, using $ sudo rm /usr/local/bin/gitolite, and now it is uninstalled. Using $ sudo apt-get install gitolite I now have a new version.

Part way through this installation, I catch the message No adminkey given - not setting up gitolite. What I’m going to try to do is get a newly configured version running without removing my old data first and see how that works out, using dpkg-reconfigure. Before I move on, a little information about apt-get and dpkg-reconfigure. If you already know it pretty well, you can skip the rest of this paragraph, or if you really know a lot about it, you can read this paragraph and correct me in the comments. Anyhow, what Ubuntu (and its ‘parent’ distro, Debian) use for automated installation are ‘.deb’ packages. Any ‘.deb’ package that you can get your hand on can be installed with the dpkg commands, which handled the Debian package files in various ways. ‘apt-get’ allows you to download and automatically install Debian packages that have been signed on a centralized server using trusted certificates. In addition, you can create your own package repository for download with apt-get, but that is not a completely trivial activity, and is beyond the scope of this tutorial. When you use dpkg-reconfigure, you are using the dpkg commands against the Debian package to attempt reconfiguration.

Now that that’s over, run $ sudo dpkg-reconfigure gitolite. It will ask you a few questions, first being who is the gitolite user (gitolite), the directory for the gitolite user (/var/lib/gitolite), and the ssh key for the gitolite user (/var/lib/gitolite/.ssh/ As a word of warning, when I did this, it wiped the .ssh directory and now I have to start from scratch. Thus, I wiped the directory (using rm -r) and started from scratch. First, I used ssh-keygen to create a new key in /tmp/ (see the first gitolite tutorial for more information about ssh keys) and went to work again

psalcido$ sudo rm -rf /var/lib/gitolite/*
psalcido$ sudo rm -rf /var/lib/gitolite/.gitolite*
psalcido$ ssh-keygen
psalcido$ sudo dpkg-reconfigure gitolite

And now the older version of gitolite should be set up. Copy the id_rsa file from /tmp/ into the .ssh directory for gitolite and be basically done with setup:

psalcido$ sudo cp /tmp/id_rsa /var/lib/gitolite/.ssh/id_rsa
psalcido$ sudo chmod 0600 /tmp/id_rsa /var/lib/gitolite/.ssh/id_rsa
psalcido$ sudo chown gitolite:gitolite /tmp/id_rsa /var/lib/gitolite/.ssh/id_rsa

The permissions are important, as the keys won’t work without them. You need to save this key, because it will have to be given to the redmine user (www-data, in the case of the typical Ubuntu installation).

Get a copy of the gitolite plugin

This should be second nature by now; $ git clone

Configure the gitolite plugin

In the documentation for the gitolite plugin that we will be using, it clarifies that you should do as much configuration as possible before pushing the plugin into the database, as all configuration after the fact will have to be done from the plugin configuration screen in redmine. First, we need to copy in the repo to the proper directory and remove the .git directory. We could also just check it out, but if we want, we can make modifications and check them in, thus making it possible to try to redeploy if we want to the plugin directory.

Go into the repository that you just checked out and modify init.rb as it describes in the included README.mkd file. After my modifications, it looked like this (the server that I was working with was named ansible-test, as I was working on other things when I started this tutorial).

psalcido@ansible-test:~/redmine_git_hosting$ git diff
diff --git a/init.rb b/init.rb
index 5567c40..7fd08c4 100755
--- a/init.rb
+++ b/init.rb
@@ -13,9 +13,9 @@ Redmine::Plugin.register :redmine_git_hosting do
        version '0.4.2'
        url ''
        settings :default => {
-               'httpServer' => 'localhost',
-               'gitServer' => 'localhost',
-               'gitUser' => 'git',
+               'httpServer' => 'ansible-test',
+               'gitServer' => 'ansible-test',
+               'gitUser' => 'gitolite',
                'gitRepositoryBasePath' => 'repositories/',
                'gitoliteIdentityFile' => RAILS_ROOT + '/.ssh/gitolite_admin_id_rsa',
                'gitoliteIdentityPublicKeyFile' => RAILS_ROOT + '/.ssh/',

Use git add * and git commit to commit these changes before we deploy this to the plugins directory.

The deployment is completed with the git checkout-index command. The exact command is:

psalcido$ sudo git checkout-index --prefix=/usr/share/redmine/vendor/plugins/redmine_git_hosting/ -a

Now, part of the requirements are the gitolite admin identity files that need to be installed in the rails directory. Once again, we snag the gitolite admin private key and public key and copy it over, but with naming from the gitolite configuration data.

psalcido$ sudo mkdir /usr/share/redmine/.ssh
psalcido$ sudo cp /tmp/ /usr/share/redmine/.ssh/
psalcido$ sudo cp /tmp/id_rsa /usr/share/redmine/.ssh/gitolite_admin_id_rsa
psalcido$ sudo chown -R www-data:www-data /usr/share/redmine/.ssh
psalcido$ sudo chmod 0700 /usr/share/redmine/.ssh
psalcido$ sudo chmod 0600 /usr/share/redmine/.ssh/gitolite_admin_id_rsa

Set up the root for the redmine application with admin permissions on gitolite

We are going to use the sudoers.d file set to add in new permissions for sudo for both gitolite and www-data. www-data is the user that runs all apache2 processes in our system, and if your system is set up any differently, then you will have to act accordingly. If you are not familiar with the ‘.d’ directories, they allow you to modularize your system configuration without having to do modifications to the top level config. It is difficult to automatically add lines to a configuration, so it is somewhat optimal to use the modularized versions and some configuration management software to push out the files (Puppet, Chef, Ansible).

The file that we will create will allow www-data and gitolite to do password free actions as eachother. The file will be /etc/sudoers.d/redmine-gitolite, and will contain:

# Adds necessary login activities for redmine and
# gitolite integration to work properly.

www-data    ALL=(gitolite)   NOPASSWD:ALL
gitolite    ALL=(www-data)   NOPASSWD:ALL

There are requirements for files that are handled by sudo, and the new file needs to have restrictions on read/write. The appropriate permissions are set using $ sudo chmod 0440 /etc/sudoers.d/redmine-gitolite.

Now, we test by logging in as one of the users and testing the commands back and forth:

psalcido$ sudo su - www-data
www-data$ sudo -u gitolite ls
www-data$ exit
psalcido$ sudo su - gitolite
gitolite$ sudo -u www-data ls
gitolite$ exit

Deploy the database requirements for the gitolite plugin

This is another really easy step, but it requires knowledge of rails that is not really simple to come across, but that you can find in the plugin readme documentation. The command that you need to run is internal to Ruby on Rails, and is:

sudo -u www-data env RAILS_ENV=production rake db:migrate_plugins

Now when I tried this, I kept getting the non-obvious error:

no such file to load -- lockfile

Tasks: TOP => db:migrate => environment

Which is actually telling you that the lockfile library is not installed. It is also true of the net-ssh library, and I used apt-cache search for both ‘ruby lockfile’ and ‘ruby net-ssh’ to find the following:

$ sudo apt-get install liblockfile-ruby
$ sudo apt-get install libnet-ssh2-ruby

And then the command worked.

Restart Redmine and check the admin console for problems

I restarted apache with sudo service apache2 restart, and went into the plugins directory, and ended up in settings. Everything looked ok after the changes that I made. Finally, we get to move onto testing. This involves creating a new project, adding a new repository, a new user that can use that repository who uploads a public key to redmine, and having them do a checkin. I leave this to the reader to complete, as most of the confusing work should be done, but now you understand how to do a number of new things if you didn’t know them before, especially if you are a new computer science grad who has been put into a position of system administrator, either with or against your will.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: