Gitolite via HTTP & SSH with no admin access

The issue I ran into was how to setup gitolite to work via HTTP and SSH on a server for which I have no administrative access. What this means is that I cannot change apache configuration. What follows is what made it work for me. It may not work for you. Caveat Emptor.

Assumptions

• Your apache admins are cool and allow the necessary things to work in .htaccess files.
• Your apache admins are also cool by having things setup so that apache serves things out of your home directory using suexec.
• Basically, I’m assuming you are using a shared hosting server on Dreamhost.

Notes

• There really isn’t anything special here. This is just HTTP Backend and Gitolite, Gitweb, SSH, HTTP Backend but modified a bit to do two things:
  • Work in an environment in which I have no administrative access to the server in question
  • Keep all the gitolite stuff safely contained in a subdirectory of my user’s home directory
• All the interesting work happens in the HTTP section below. Everything in the SSH section is just standard stuff. I just point it out here for completeness.

Install Gitolite for HTTP access

• Use the non-root method from the HTTP Backend documentation, but with the following modifications:

  • In step 1, don’t do cd ~apache. Instead just do cd. This means that your GITOLITE_HTTP_HOME variable in Step 2 will be:

    GITOLITE_HTTP_HOME=~/gitolite-home

  • Replace step 4 with this:

    After the gl-system-install step, add these to the top of ~/gitolite-home/share/gitolite/conf/example.gitolite.rc

    $ENV{GIT_HTTP_BACKEND} = "/usr/libexec/git-core/git-http-backend";
            # or wherever you have that file; note: NO trailing slash
    $ENV{PATH} .= ":$ENV{GITOLITE_HTTP_HOME}/gitolite-home/bin";
            # note the ".=" here, not "=".  Also trust me on the value, we're going to change GITOLITE_HTTP_HOME later.

    Now, find the line that looks like this:

    $PROJECTS_LIST = $ENV{HOME} . "/projects.list";

    And change it to this:

    $PROJECTS_LIST = $ENV{HOME} . "/gitolite-home/projects.list";

    Also, find the line that looks like this:

    $REPO_BASE="repositories";

    And change it to this:

    $REPO_BASE="gitolite-home/repositories";

  • Don’t do the last step (“IMPORTANT: fix up ownerships”)
  • Do NOT go on to the “setup apache” section.
• Now, cd to the webroot for your site. For me this is a sibling directory to gitolite-home. So, cd ~/example.com.

• Now create an .htaccess file with the follwing in it (remember, your admins are cool, right?):

  RewriteEngine On
  RewriteCond %{REQUEST_URI} ^/git/(.*/(HEAD|info/refs|objects/(info/[^/]+|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))|git-(upload|receive)-pack))$ [OR]
  RewriteCond %{REQUEST_URI} ^/git/(info|expand)$
  RewriteRule git/(.*) gitAdmin/gitolite-http-backend.cgi/ [L,E=SCRIPT_URL:/$1]

  A couple of things to note:

  1. If you are using ADCs or wildcard repos with gitolite, you’ll need to update the second RewriteCond to add the verbs you want to support via HTTP. This is an exercise for the reader.
  2. This doesn’t even attempt to get gitweb working. That is left as an exercise as well.
  3. Don’t stop here. An astute reader will note references to gitAdmin and a cgi in the above. We haven’t created that yet. That comes next.

• Now, create a subdirectory in your webroot called gitAdmin:

  mkdir ~/example.com/gitAdmin
  cd ~/example.com/gitAdmin

• Create a new file called gitolite-http-backend.cgi in this direcotry and put the following into it:

  #!/bin/bash
  GIT_HTTP_EXPORT_ALL= GITOLITE_HTTP_HOME=/home/user GIT_PROJECT_ROOT=/home/user/gitolite-home/repositories PATH_INFO=$SCRIPT_URL /home/user/gitolite-home/bin/gl-auth-command

  Notes:

  1. Make sure you update your paths appropriately. For example, your stuff probably doesn’t live under /home/user/...
  2. You’ll notice that this is where we change what GITOLITE_HTTP_HOME points to.

• For good measure, let’s make that cgi executable:

  $ chmod +x gitolite-http-backend.cgi

• Now, I’m guessing you want to access control your repos. I’m going to do this with a standard htpasswd file. Creating that file is between you and Google. But, once you have it, move on to the next step.

• You are still in ~/examples.com/gitAdmin right? Cool. Ok, now create an .htaccess file here and put the following in it:

  AuthType Basic
  AuthName "Private Git Access"
  Require valid-user
  AuthUserFile /home/user/gitolite-home/gitoliteUsers

  For that AuthUserFile, use the path to the htpasswd file that you created in the previous step. Or use some other access control mechanism that works with apache htaccess files. Whatever makes you happy.

• Now, since we’ve changed the value of GITOLITE_HTTP_HOME that will be used at runtime, we need to make a couple of simlinks so that gitolite can find its stuff.

  $ cd
  $ ln -s gitolite-home/.gitolite ./
  $ ln -s gitolite-home/.gitolite.rc ./

• Now, go off and test your HTTP access to the repos. The handy testing repository is a good candidate. Or maybe now would be a good time to clone the gitolite-admin repo. Actually, yeah. Do that.
  • If something doesn’t work and it is because you did something wrong or your apache setup doesn’t work like mine, best of luck to you. But if something doesn’t work because I forgot a step in this documentation, please let me know and I’ll get it fixed.

Ok. Take a cookie break. You deserve it.

Setup SSH access

Let’s talk briefly about SSH keys here. I’m not going to belabor the point since the documentation on this point is very good. Make sure you know what you are doing. To wit: do NOT use the same public key for the following that you use to log into the server. Since you aren’t an admin, you can lock yourself out of the server if you do. That would be bad. So, create yourself a second key pair, setup an ssh config entry that makes use of your “git” pubkey, and then use that alias in your git urls and gitolite commands from the client. This way, you can continue to log in to a shell on the server the way you always have, with your “normal” keypair.

Ok, moving on. If you don’t understand that, you probably shouldn’t be here.

• On your client machine, go to your gitolite-admin clone. Mine is at ~/git/gitolite-admin. Replace that with your path.

  $ cd ~/git/gitolite-admin

• Now put the public key that you want to use for git into the keydir directory.

  $ mkdir keydir
  $ cp ~/.ssh/gitkey.pub ./keydir/username.pub

  Obviously, you’ll want to use relevant paths and probably choose something more inspired than “username” for your SSH/Git username.

• Now, go over to your gitolite config and set it up however you’d like. Some things to consider: do you want both your HTTP user and your SSH user to have access to the admin repo? Right now your HTTP user does have access and your SSH user does not. For my purposes, I want to have equal rights over HTTP or SSH, so I added both users. I’m assuming you know how to edit a file, so I’ll just show you what mine looks like:

  $ cat conf/gitolite.conf
  @admins = httpuser username
  
  
  repo gitolite-admin
      RW+     = @admins
  
  
  repo testing
      RW+     = @all
  
  
  # And a bunch more stuff that has nothing to do with this tutorial.

• Got everything the way you like it? Cool. Add, commit, and push.

  # From the top level of the gitolite-admin repo...
  # Where origin is the HTTP url: http://example.com/git/gitolite-admin.git
  $ git add .
  $ git commit -m "Added SSH admin user key and updated config accordingly."
  $ git push

• And that should be it. You should now be able to access your repos by both HTTP and SSH.

• OPTIONAL: I like for my SSH url to be “origin” and the HTTP url to be secondary. So, this is how I shuffle them around in the gitolite-admin repo:

  $ git remote rename origin httporigin
  $ git remote add origin username@example.com:gitolite-admin.git
  $ git fetch --all -p
  $ git branch --set-upstream master origin/master

  Note that both remotes actually point to the same place:

  ... make some inconsequential change ...
  $ git push httporigin
  $ git pull  # Which uses the SSH url since we setup master to track `origin`
  ....
  Already up-to-date.

• And for extra credit: the info, expand, getperms, setperms, ADCs, etc all work via SSH:

  $ ssh username@example.com info
  hello username, the gitolite version here is v2.0.3-0-g4c1e4b2
  the gitolite config gives you the following access:
       R   W  gitolite-admin
      @R_ @W_ testing

Cool. Time for another cookie.