19. Gitolite + Git configuration

Gitolite is a nice tool which allows you to manage Git repositories from a single user account; ssh keys are used to change access to the said repositories. It provides more flexibility compared to gitosis.

Gitolite manages several repositories under a single user account, using SSH keys for user identification. Final users do not need accounts on the server, as they will enter it from the one and only common account and thus will not be granted the privileges to run random command they might want to.

Installing gitolite

If the package is masked, unmask it.

emerge dev-vcs/gitolite-gentoo

Once gitolite is installed, the 'git' user will be created (with no password and /var/lib/gitolite/ as home).

Setting up gitolite

Generate a key for root

su
ssh-keygen -t rsa

Two files will be created,

/root/.ssh/id_rsa.pub 
/root/.ssh/id_rsa

which are the public/private rsa key pair.

Create a configuration repository

Copy the public key:

cp /root/.ssh/id_rsa.pub /tmp/id_rsa.pub

Initiate gitolite:

sudo -H -u git gl-setup /tmp/id_rsa.pub

Remove the public key from /tmp:

rm /tmp/id_rsa.pub

If you expect to use git-web, change permissions for the directory so that the repository is not accessed freely through the web:

chmod 700 /var/lib/gitolite/repositories/gitolite-admin.git

Configure the repository for the user

Cd to /tmp:

cd /tmp

Clone the settings directory:

git clone git@server_name:gitolite-admin.git

Cd to the settings directory you have just created:

cd gitolite-admin

Copy the user's public key to /tmp/gitolite-admin/keydir:

scp root@client_name:/home/username/.ssh/id_rsa.pub ./keydir/username@client_name.pub

Configure the newly created repository for the user username:

vi conf/gitolite.conf

repo     gitolite-admin
         RW+     =     id_rsa

repo     project1
         RW+     =     testuser@remotehost
To specify the access rights, choose some of the following:
  • R - read only
  • RW - read and write commits; rewind forbidden (push --force)
  • RW+ - full access
  • RWC - permission to create a branch
  • RWD - permission to delete a branch
  • - deny writing access
Those may apply to:
  • master@ - branches
  • ref/tags - tags (versions)
  • NAME/filename - file/directory names

To create a group, use the following syntax:

@groupname = user1 user2 user3

The same syntax is used to group branches, like:

@importantbranches = master$ developer$ test$

repo testing
    RW @importantbranches = @groupname
    -  @importantbranches = @groupname
    RW+                   = @groupname

Сommit for configuration:

git commit -am "Granted full access for testuser@remotehost to project1" 

Save the repository with settings:

git push origin master

Create a new repository

With gitosis, you had to create your repositories first with --bare init; no need to do this in gitolite - just add the repo to the configuration file.

The user will be able to access to it on their computer, via ssh,

git clone ssh://git@server_name/project1.git

without password (with the public key).

Checking sshd

sshd daemon must be started.

The 'git' user must be granted access to /etc/ssh/sshd_config via ssh.

Configure the Git daemon

vi /etc/conf.d/git-daemon

GITDAEMON_OPTS="--syslog --port=9418 --base-path=/var/lib/gitolite/repositories/ --export-all" 
GIT_USER="apache" 

Should any problems arise when restarting, reset the port number from --port=9418 to another value, restart the Git daemon, change the port number back and restart the daemon again.

/etc/init.d/git-daemon restart

Restarting the Git daemon: issues

The problem of port reopening may occur when restarting the daemon, which will be recorded in /var/log/message as something like:

git-daemon[pid]: unable to allocate any listen sockets on host (null) port 9418

To avoid this, append the --reuseaddr option to GITDAEMON_OPTS.

Generating a key for a user

Please execute on the user's computer, as the user username:

ssh-keygen -t rsa

Two keys will be created in the user's .ssh directory,

id_rsa
id_rsa.pub

the private one and the public one (the latter has the .pub extension).

If the public key is stored in the keys directory of the gitolite settings repository on the server and if all necessary permissions are set in conf/gitolite.conf file, the user will get access to the repositories on the server.

Repository access permissions: examples

Allowing the developers group to do whaterver they want with the repository, except from modifying the master branch:

repo myrep
    -    master$ = @developers
    RW+          = @developers

Forbidding rewind for the master branch; generally it means that the developers group will be able to commit and to commit only to the master branch:

repo myrep
     RW  master$ = @developers

If you want the developers group to be able to do anything with the repository, except from creating tags; tags will be created by maindeveloper only:

repo myrep
     RW+ refs/tags = maindeveloper
     -   refs/tags = @developers
     RW            = developers

Once this is performed, only the user maindeveloper from the developers group will be able to create tags, while all members of developers will be granted the rights to modify the repository in any other way.
Thank you!