71 lines
3.7 KiB
Markdown
71 lines
3.7 KiB
Markdown
A while back I found out how
|
|
[gitolite](https://github.com/sitaramc/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](http://github.com). 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](http://hjemli.net/git/cgit/) can use it too.
|
|
|
|
[[!tag git gitolite configuration ssh]]
|