← All posts

FreeBSD and Debian. Installing and Configuring Gitolite

Git logo

Following up on my article FreeBSD and Debian. Installing and Configuring Gitosis, I want to talk about Gitolite. It is a tool with similar functionality, but it offers a few more features, such as access control for branches and tags, and is a little easier to use. And unlike Gitosis, it is still maintained.

We’ll assume that you have already created a user and group named “git” and installed Git on the server.

Gitolite

Sometimes you want projects to have “production” branches and “release” tags, with access restricted to certain users. For example, developers should have access only to the “master” branch and their own branches created on the server, while “production” should be off-limits to them so they don’t accidentally merge anything bad into it.

Git has started becoming very popular in corporate environments, which usually have additional access control requirements. Gitolite was originally created to help meet those requirements. But it turns out to be just as useful in the open source world: the Fedora project uses gitolite to manage access to its package repositories. And there are more than 10,000 of those repositories! Apparently, this is the largest gitolite installation anywhere. Gitolite lets you specify access permissions not only for repositories, but also for branches or tag names within each repository. In other words, you can specify that certain people (or groups of people) can push certain “refs” (branches or tags), while others cannot. Pro Git - Pro Git 4.8 Git on the Server: Gitolite

Installing Gitolite

FreeBSD:

cd /usr/ports/devel/gitolite
make install clean

Debian:

sudo apt-get install gitolite

From source:

git clone git://github.com/sitaramc/gitolite.git
sudo ./src/gl-system-install

Configuring Gitolite

First, we need to create a key on the local machine and copy it to the server:

ssh-keygen -C "<username>" -t rsa
... укажите путь до файла ключей "/home/<username>/.ssh/git.<hostname>"
scp ~/.ssh/git.<hostname>.pub <username>@<hostname>:<username>.pub

Now add the following to your local “.ssh/config”:


Host git.<hostname>
    User git
    Hostname <hostname>
    Port 22
    IdentityFile ~/.ssh/git.<hostname>

Next, log in to the server and initialize gitolite:

sudo su - git
gl-setup /home/<username>/<username>.pub

In newer versions, do it this way:


sudo su - git
gitolite setup -pk /home/<username>/<username>.pub

Let’s go back to the local machine and try connecting:


ssh git.<hostname> -T
>> hello <username>, this is gitolite v2.3-0-g01e789a running on git 1.7.9.3
>> the gitolite config gives you the following access:
>>      R   W     gitolite-admin
>>     @R_ @W_    testing

If you get a response roughly like this, listing repositories and permissions, everything is fine—let’s continue!

Users, Macros, and Permissions with Refex

Now let’s clone the “gitolite-admin” repository locally and edit the configuration file:

git clone git@git.<hostname>:gitolite-admin gitolite-admin

In the resulting repository, you will see a “keydir” directory, which stores all the public keys of users who have access to any repositories. To add a user, you need to place the public key they generated in the “keydir” directory.

There is also a “conf” directory in “gitolite-admin”, containing the “gitolite.conf” configuration file with the following contents:


repo    gitolite-admin
        RW+     =   <username>, <another-username>

repo    testing
        RW+     =   @all

The contents make it clear how to specify repositories, permissions, and users. There is also a special macro, “@all”, which includes all users from “keydir”.

You can create your own macros and use them later:


@admins    = <username> <username2>
@developers = @admins <username3>  # Some comment
@staff      = @admins @developers

repo    gitolite-admin
        RW+     =   @admins

repo    project
        RW+     =   @developers

Permission capabilities:

  • “R” - read-only access to refs;
  • “RW” - read and write access to refs (including creating new ones);
  • “RW+” - read, write (including overwriting existing refs), and delete access to refs;
  • “-” - no access;

Refex are regular expressions for remote branches, tags, and files:


repo  project
    RW+                           = @leaders
    -    production               = @all
    R    refs/heads/experimantal  = @all
    -    refs/heads/experimantal  = @all
    -    refs/tags/rc2000b        = @all
    RW+                           = @all

If you do not explicitly specify the “refs/” prefix, gitolite prepends “refs/heads/” itself, so “- production = @all” is equivalent to “- refs/heads/production = @all”.

Permissions for Branches, Tags, and Files

We’ve finally reached the most interesting part! As an example, let’s give @leaders access to everything, while giving @developers read-only access to the “production” branch and “rc*” tags (without allowing them to create such tags).


repo  project
    RW+ NAME/                 = @leaders
    RW+                       = @leaders

    # Ветка production (с двумя способами ввода)
    R   production            = @developers
    -   refs/heads/production = @developers

    # Теги rc*
    R   refs/tags/rc.*        = @developers
    -   refs/tags/rc.*        = @developers

    # Также вы можете указать конкретные файлы:
    R   NAME/.gitignore       = @developers
    -   NAME/.gitignore       = @developers

    RW+ NAME/                 = @developers
    RW+                       = @developers

The order of the rules matters, because they are checked sequentially!

Creating a Repository

To create a new repository, log in to the server and run:


sudo su - git
cd ~/repositories
mkdir someproject.git && cd someproject.git/
git init --bare
>> Initialized empty Git repository in /home/git/repositories/someproject.git/

Now let’s open “gitolite-admin/conf/gitolite.conf” and add the repository we need:


repo    gitolite-admin
        RW+     =   <username>

repo    someproject
        RW+     =   <username>

For the settings to take effect, you need to push your changes to the server:


git commit -am "Added the 'someproject' repo"
git push origin master

Then you can get your repository:


cd ~
git clone git@gitolite:someproject.git someproject

# или, если у вас уже есть проект
cd ~/someproject
git remote add origin git@gitolite:someproject.git

That’s all. I also recommend reading the article Getting to Know gitolite

Comments are closed. Read the original discussion in Russian →