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
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.
If the package is masked, unmask it.
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,
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
sudo -H -u git gl-setup /tmp/id_rsa.pub
Remove the public key from
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¶
Clone the settings directory:
git clone git@server_name:gitolite-admin.git
Cd to the settings directory you have just created:
Copy the user's public key to
scp root@client_name:/home/username/.ssh/id_rsa.pub ./keydir/username@client_name.pub
Configure the newly created repository for the user username:
repo gitolite-admin RW+ = id_rsa repo project1 RW+ = testuser@remotehostTo 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
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¶
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
git clone ssh://git@server_name/project1.git
without password (with the public key).
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.
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
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¶
developers group to do whaterver they want with the repository, except from modifying the
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
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
repo myrep RW+ refs/tags = maindeveloper - refs/tags = @developers RW = developers
Once this is performed, only the user
developersgroup will be able to create tags, while all members of
developerswill be granted the rights to modify the repository in any other way.