Question

I'm guessing this is obvious once you know it but I've been trying to grok how gitolite can intercept git requests and decide that such-and-such a user can't change branch-X...since the client's git url doesn't change.

From reading http://gitolite.com/gitolite/how.html#(5) it seems that gitolite does all its work between the server's sshd and the git deamon on the server.

So gitolite is a set of git hooks running on the server running pre-receive to see if the command is allowed?

My other question is about the user part of the git url.

Our git server lives on an AWS instance running ubuntu and we're accessing it via "ubuntu@myGitServer:/pathToRepo". We've put our AWS key in .ssh/id_dsa on all our machines to satisfy both git and AWS security.

To support the conversion to gitolite we're creating per-user ssh keys that we'll add to gitolite (and presumably to the AWS Key-Pairs list)...but would we still use the ubuntu user in the git url?

Was it helpful?

Solution

See "How do programs like gitolite work?", and check the ~ubuntu/.ssh/authorized_keys file on the gitolite server.

You will see that file is set to call the gitolite script with the user name as registered in that file.

The ssh user is always git (or whatever user you had to install gitolite, in your case, I presume 'ubuntu').
The "interception" part is actually called ssh forced command, which means the ssh session returned isn't an interactive one, but will always call a script (here the gitolite script).

That means you shouldn't have to change the git repo url.

The name of the public key you add to gitolite (through the gitolite-admin repo in gitolite-admin/keys serves to register the name of the user as a parameter to the call of the gitolite script in the ~ubuntu/.ssh/authorized_keys.

It is not a set of git hooks (except for the update hook, see below)
It is an authorization layer which stands between ssh and git.
Instead of ssh calling the git command directly, ssh calls the gitolite perl script which calls git if the user is authorized to proceed.

You can use gitolite to register special hooks for repos: see "hooks and gitolite", and hooks.
Gitolite will regsiter an update hook for all gitolite-managed repos, in order to managed VREFs hooks.


The updated Gitolite presentation by its author has an interesting schema to summarize the all process:

Gitolite process

OTHER TIPS

see http://gitolite.com/gitolite/how.html for a pretty decent explanation... (sitaram seems to be getting better at docs; he's finally started adding pictures, the bloody luddite!)s

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top