FreeBSD and Debian. Installing and Configuring Gitolite
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 →
