Echo Area

A while back I found out how gitolite handles multiple users, by reading the manual, whilst trying to figure out how to enable SSH agent forwarding so I can semi-automatically mirror some repositories to, for instance, github. I came to the conclusion that I had to override the gitolite settings and add an extra line to my server's authorized_keys file. This seemed to work well.

Though apparently it didn't… I had noticed that I couldn't set any options through the gitolite.conf's config commands, but I thought this had something to do with not enabling the right settings to be added. I was wrong about that…

I looked at my .gitolite.rc on my server and saw that I had already set GIT_CONFIG_KEYS to ~'.*'~, so everything was allowed. I also tested adding random config values to git locally, like test.something, which also worked; so it was neither git nor gitolite that was causing the trouble.

I also noticed today that when I pushed changes to gitolite, at least to the gitolite-admin repo, that it was complaining about not being able to fingerprint some file in /tmp/. At that time I didn't think the issues were connected, since I hadn't changed much lately and pushing/pulling to my repositories seemed to go fine, apart from the config values.

After some testing I noticed that I couldn't use any config values, not even the gitweb.owner setting which I was sure would work, since I'd used that for every repo, but trying to reset them now didn't work either. So I started looking on the server. It showed me the same error as when I'd push to the gitolite-admin repo plus a message about the first line of something being too long, showing the beginnings of a line in authorized_keys.

After a lot of looking around, testing, screwing up my entire setup and looking at the gitolite source on github, I think I figured out what it's doing. Now, I don't know any perl, but is seemed to me that it splits up the authorized_keys file, checking the validity of each line in it, except for the ones it put there. This is where it was failing, since it would assume each line was just a public key and could be verified by placing it in a temporary file and fingerprinting that with ssh-keygen -l -f, and I had the ~command="…"~ part in there as well, to override gitolite's own settings to enable agent forwarding. So now I know why it was complaining and why it was always about line 1, even when I put my key on the last line in authorized_keys, but removing it would mean no ssh agent forwarding.

So I started looking at the gitolite source code again, trying to figure out where those settings of no-X11-forwarding, no-agent-forwarding, etc. were coming from and after a little while I found it. Here I also saw that it was actually looking for the AUTH_OPTIONS rc setting. I don't remember reading anything about this option, but then I'm still learning to navigate the gitolite manual. Setting that to whatever was in my authorized_keys file, but leaving out the no-agent-forwarding, fixed this latest problem.

So, now I've got my ssh agent forwarding and I can set any git config variable I want, which paves the way for writing a hook that will try to mirror a repository after receiving an update. This was certainly an interesting experience, and looking at some perl code was fun.

Oh, and I've also updated my gitolite installation, which now includes a update-description-file post-compile trigger, which takes the value from gitweb.description and puts it in the description file, so programs like cgit can use it too.