Présentation de Gitolite

Gitolite est un projet open source permettant de gérer les droits sur les dépôts Git en utilisant un système d'ACL. Comme pour certains systèmes de gestion de versions tels que Subversion, il est possible de gérer les droits à différents niveaux de granularité tels que le dépôt complet ou bien certaines branches du dépôt.

Cependant, une des choses très intéressantes dans Gitolite est de pouvoir déléguer les droits d'administration à d'autres utilisateurs. L'administrateur principal de la base des dépôts pourra donc en déléguer certains à des utilisateurs enregistrés.

Le principe de fonctionnement de Gitolite est assez simple : Toute la gestion des ACL se fait dans un dépôt Git spécifique. Ce dépôt contient toute la configuration des ACLs ainsi que la gestion des utilisateurs.

Ainsi afin de pouvoir mettre à jour les droits, on utilisera des commandes telles que git add, git commit, git push, etc.

En ce qui concerne la localisation, un dépôt gitolite de référence sera déployé sur le serveur contenant tous les dépôts de références pour lesquels on souhaite mettre en place une gestion d'ACL.

Le principe de configuration des ACLs se fera donc de la manière suivante :

1. récupérer le dépôt git de référence (clone / pull / fetch) ;
2. modifier les fichiers de configuration contenus dans le dépôt Git ;
3. enregistrer les modifications dans le dépôt Git local ;
4. synchroniser le dépôt local avec le dépôt distant.

Vous l'aurez donc compris, Gitolite est un outil fait par des utilisateurs de Git pour des utilisateurs Git. Pour pouvoir bien l'utiliser il est nécessaire de bien maitriser les concepts de Git.

Site du Projet Gitolite : http://github.com/sitaramc/gitolite

Gitolite est censé pouvoir fonctionner sur n'importe quel système pouvant faire tourner Git, Perl et un serveur SSH. Pour cet article, gitolite a été testé et validé sur Redhat Enterprise et Debian Lenny.

Behind the scenes

La gestion des droits se fait donc par l'intermédiaire d'un repository Git. Comment se fait donc la mise en place des droits lorsqu'un administrateur ou un utilisateur disposant de droits lorsque celui-ci commit et push sur le repository gitolite ?

Sur le système contenant tous les repositories de référence est déployé tout un ensemble de hooks sous formes de hooks déployés dans chaque repository y compris le repository gitolite. Ces scripts seront exécutés a chaque fois qu'un événement git est appliqué sur le repository.


git@scarlett:~/repositories/gitolite-admin.git/hooks$ ls -l
total 48
-rw------- 1 git git 441 Dec 18 15:31 applypatch-msg
-rw------- 1 git git 887 Dec 18 15:31 commit-msg
-rw------- 1 git git 152 Dec 18 15:31 post-commit
-rw------- 1 git git 510 Dec 18 15:31 post-receive
-rwxr-xr-x 1 git git 1253 Dec 18 15:31 post-update
-rw------- 1 git git 387 Dec 18 15:31 pre-applypatch
-rw------- 1 git git 1706 Dec 18 15:31 pre-commit
-rw------- 1 git git 4262 Dec 18 15:31 pre-rebase
-rw------- 1 git git 1196 Dec 18 15:31 prepare-commit-msg
-rwxr-xr-x 1 git git 4963 Dec 18 15:31 update


On remarquera que seuls les hooks update et post-update sont actifs (Droits d'exécution présents).

Côté authentification et application des ACLs, tout se fait en utilisant uniquement SSH. En effet la partie authentification est assurée par gitolite par un couple clé privée / clé publique spécifique à chaque utilisateur gitolite.

Sur le serveur contenant tous les repositories de référence, tout se fait avec un seul utilisateur POSIX. Tous les utilisateurs gitolite seront des utilisateurs virtuels identifiés par leur clés publique SSH sur ce compte POSIX.

Ainsi, la vérification des ACLs pour un utilsateur donné se fera par l'exécution d'une commande gitolite dès que la clé de celui-ci sera reconnue par le serveur SSH par l'intermédiaire du fichier authorized _keys du compte POSIX utilisé pour le management des repositories de référence.


# gitolite start
command="/home/git/.gitolite/src/gl-auth-command ptitoliv",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEArvCWSA9oQM+GrQbb8sdqQkgyraATjBjpTR6UrsUo1anQ2nFNf5glepKb1vyskY1FWzYTnEdQeZXD/4h2J9J/lMFdzISgZ7jpX5Y7Vzrm7tz4eKUTIKiX/E5+aANjHyj8xpatDK4BonSAJySTBc/X/9S3K58+qoRvax6Aq2FdKwgRCwb3pPa9G3et0wLDgWVaHTLlfDm+8mf3EcYK9i4wa2b1q/sSUxWwN8t/zwSVpy4/+HwUMME9wcpMerX3LLK1Rhxim7n6mr71oJY9/00lynyyqZufN1seNQxUdnDBZ194bXyqI1e2B+cgewwgXx9txBGdqadTO0YMHGZHCePbfw== ptitoliv@debian-vm
# gitolite end


La capture précédente liste toutes les clés publiques enregistrées pour le compte POSIX présenté précédemment. On remarquera, la déclaration du paramètre command exécutant la commande gitolite gl-auth-command permettant d'authentifier l'utilisateur virtuel et de vérifier ces droits.

Cette commande prend comme paramètre le nom de l'utilisateur virtuel à utiliser pour la validation des ACLs. C'est donc ici que se fait la correspondance clé <=> nom d'utilisateur gitolite. Nous verrons plus loin que la mise à jour du fichier authorized_keys se fait toute automatiquement par l'intermédiaire des hooks gitolite.

Installation de Gitolite

Pré requis

Pour installer gitolite, il faut disposer d'un serveur qui stockera tous les repositories GIT y compris le repository gitolite. C'est sur ce serveur que seront configurées et appliquées les ACLs sur les repositories.Ce serveur sera désigne dans la suite de cette article comme le serveur de référence.

Ce serveur doit être installé avec les composants suivants :

• git (de préférence > à la version 1.6.2)
• perl
• Serveur SSH

L'installation ne se faisant pas directement sur le serveur de référence, il faut également disposer d'une machine cliente disposant également de git, perl et d'un client SSH pour communiquer avec le serveur de référence.

Préparation du serveur de référence

Ajout d'un utilisateur POSIX

Comme dit précédemment, toute l'application gitolite est gérée sous un seul utilisateur POSIX. La première opération est donc de créer cet utilisateur que nous appellerons git.

serveur-git:~# adduser git

Une fois créé tous les repositories seront stockées dans le home directory de ce compte.

Mise en place de clés SSH (optionnel)

Toute l'installation de gitolite se fait par une succession de commandes SSH entre le client et le serveur. Il est donc préférable de mettre en place une authentification par clé.

La première étape est donc de créer un couple de clé sur la machine cliente qui va nous servir à nous connecter au compte git du serveur de référence sans mot de passe.


ptitoliv@workstation:~$ ssh-keygen -t rsa -b 1024
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ptitoliv/.ssh/id_rsa):
Created directory '/home/ptitoliv/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/ptitoliv/.ssh/id_rsa.
Your public key has been saved in /home/ptitoliv/.ssh/id_rsa.pub.
The key fingerprint is:
0e:1c:9a:d1:22:a4:e5:e3:d1:04:69:92:3d:d8:b3:ae ptitoliv@debian-vm
The key's randomart image is:
+--[ RSA 1024]----+
| =+o. |
|+=Bo . |
|.o=++ o |
| ..+ * . |
| .. o o S |
| . o |
| . . |
|E |
| |
+-----------------+


Une fois la clé publique générée, il faut la déployer sur le compte git du serveur de référence. Pour cela, on peut utiliser l'outil ssh-copy-id.

ptitoliv@workstation:~$ ssh-copy-id -i /home/ptitoliv/.ssh/id_rsa git@serveur-git
git@serveur-git's password:
Now try logging into the machine, with "ssh 'git@serveur-git'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.


Si ssh-copy-id n'est pas disponible, l'opération consiste juste à importé la clé publique générée dans le fichier ./ssh/authorized_keys du compte git. (Ne pas oublier de mettre les droits a 0644 sur le fichier).

Téléchargement de gitolite

Tout est prêt à présent pour installer gitolite. Afin de récupérer le logiciel, 2 méthodes sont possibles :

Téléchargement d'un des différents snapshots disponibles à l'adresse http://github.com/sitaramc/gitolite/downloads

ou bien récupération de la dernière version de développement en clonant le repository de référence sur GitHub :

ptitoliv@workstation:~$ git clone git://github.com/sitaramc/gitolite.git

ATTENTION : Le déploiement doit se faire sur la machine cliente et non le serveur de référence.

Le clone a créé un répertoire gitolite qui contient toutes les fichiers et notamment un script d'installation qui va permettre de configurer gitolite localement et de déployer cette configuration sur le serveur de référence.

Remarque : Il existe également des snapshots stables des différentes version de gitolite disponibles sur

Installation de gitolite

Le script d'installation est gl-easy-install dans le répertoire src.Il doit être lancé avec les paramètres suivants :

• Nom de l'utilisateur POSIX sur le serveur de référence
• Hostname du serveur de référence
• Nom de l'utilisateur virtuel qui sera le premier administrateur de gitolite

Lancement de l'installation Sur la workstation:

ptitoliv@workstation:~/gitolite$ src/gl-easy-install git debian-vm gitoliteadm


Une fois l'installer lancé, celui-ci va exécuter les étapes suivantes :

• Création d'un couple de clé pour l'administrateur gitolite. Ces clés serviront à authentifier l'administrateur gitolite pour mettre à jour les ACLs et la base des utilisateurs.
• Déploiement de gitolite sur le serveur final
• Configuration générale de gitolite. Il sera demander à l'administrateur de configurer tous les paramètres généraux de gitolite tels que la localisation des repositories, les droits UNIX des fichiers par défaut, la journalisation etc. etc. Le fichier une fois configuré sera pushé sur le serveur de référence
• Création du repository d'administration gitolite-admin sur le serveur de référence
• Clone du repository gitolite-admin depuis le serveur de référence sur la machine cliente locale

Si tout s'est bien passé gitolite est à présent installé et utilisable.

Résultat de l'installation

Si toute la phase d'installation s'est bien déroulée, différents composants ont été installés sur le serveur de référence et sur la machine cliente.

Sur le client

L'installation à cloné le repository gitolite-admin déployé sur le serveur de référence contenant toute la configuration (ACLs + utilisateurs)
ptitoliv@workstation:~/gitolite-admin$ ls -l
total 8
drwxr-xr-x 2 ptitoliv ptitoliv 4096 Dec 19 22:14 conf
drwxr-xr-x 2 ptitoliv ptitoliv 4096 Dec 19 22:14 keydir

Le répertoire conf contient le fichier gitolite.conf dans lequel sont décrites les ACLs par repository. Voici le fichier de configuration par défaut :

#gitolite conf
# please see conf/example.conf for details on syntax and features
repo gitolite-admin
RW+ = gitoliteadm
repo testing
RW+ = @all


La configuration fonctionne de la manière suivante : On déclare un bloc de configuration avec le mot clé repo suivi du nom du chemin complet du repository git sur le serveur de référence. Le chemin est établi par rapport à la racine de l'arborescence git distante.

Pour chaque repository,on peut avoir plusieurs ACLs. Les droits possibles sont les suivants :

• R : Droits en lecture(pull / clone / fetch)
• RW : Droits de lecture et d'écriture(push)
• RW+ : Droits de lecture, d'ecriture et de suppression d'objets particuliers (Branches, Tags)

Pour chaque droit on peut affecter des utilisateurs,des groupes d'utilisateurs ou bien tout le monde avec le mot clé @all.

Actuellement, il y a donc l'utilisateur gitoliteadm (Créé pendant l'installation) qui a tous les droits sur le repository gitolite-admin. C'est donc l'administrateur. Il y a également un repository testing sur lequel tout le monde à les droits.

Le répertoire keydir quant à lui contient la base des utilisateurs mais sous une forme particulière :

ptitoliv@workstation:~/gitolite-admin/keydir$ ls -l
total 4
-rw-r--r-- 1 ptitoliv ptitoliv 400 Dec 19 22:14 gitoliteadm.pub

La base des utilisateurs est en fait une liste de clés SSH publiques. Le nom de la clé doit être du format "username".pub pour que gitolite puisse l'utiliser par l'intermédiaire des hooks.

Sur le serveur de référence

L'installer à déployé dans le home directory de l'utilisateur git les éléments suivants :

git@serveur-git:~$ ls -al
drwxr-xr-x 6 git git 4096 Dec 19 22:27 .
drwxr-xr-x 6 root root 4096 Dec 19 21:41 ..
-rw------- 1 git git 366 Dec 19 22:27 .bash_history
-rw-r--r-- 1 git git 220 Dec 19 21:41 .bash_logout
-rw-r--r-- 1 git git 3116 Dec 19 21:41 .bashrc
drwxr-xr-x 7 git git 4096 Dec 19 21:49 .gitolite
-rw-r--r-- 1 git git 3291 Dec 19 21:49 .gitolite.rc
-rw-r--r-- 1 git git 675 Dec 19 21:41 .profile
drwx------ 2 git git 4096 Dec 19 22:19 .ssh
drwxr-xr-x 5 git git 4096 Dec 19 21:48 gitolite-install
-rw-r----- 1 git git 0 Dec 19 21:49 projects.list
drwxr-xr-x 4 git git 4096 Dec 19 21:49 repositories


Les éléments importants sont :

• .gitolite : Environnement d'exécution de gitolite.Contient tous les hooks, et la base des ACLs extraite du repository gitolite-admin utilisée pour les autorisations d'accès
• .gitolite.rc : Fichier de configuration générale de gitolite
• gitolite-install : Répertoire contenant toute l'installation de gitolite. Utilisé pour la première installation et les upgrades/li>
• .ssh : Répertoire contenant toutes les clés publiques des utilisateurs enregistrés pour utiliser gitolite.
• repositories : Répertoire contenant tous les repositories administrés ainsi que le repository gitolite-admin
• projects.list : Fichier utilisé pour l'interface WEB GitWeb

Tous ces éléments sont synchronisés entre le serveur de référence et les machines clients depuis lesquelle se fait l'administration de gitolite, le tout synchronisé par l'intermédiaire du repository gitolite-admin. Le seul élément sur lequel l'administrateur agit est ce repository, tout le reste étant géré par les hooks.

Configuration de Gitolite

Nous pouvons à présent commencer à utiliser gitolite pour administrer les repositories du serveur de référence. Comme pour l'installation, tout va se faire à partir d'une machine cliente par l'intermédiaire d'actions "GIT" sur le repository gitolite-admin.

L'administrateur va donc faire des clones, des add, des push, des pull et des commit sur ce repository et c'est lors de la synchronisation avec le repository distant que les droits seront mis en oeuvre.

L'administrateur va donc utiliser ce repository pour toutes les taches d'administration courantes tels que la gestion des utilisateurs, des repositoires et des droits sur ceux-ci.

Note : Gitolite ne prends en compte que les objets de la branche master. Avant de faire toute modification dans le repository gitolite-admin, il est important de vérifier que l'on se trouve sur cette branche.

On verra plus tard l'utilisation des branches dans le répertoire gitolite-admin qui servent pour la délégation de droits.

Avant d'entreprendre toute action d'administration, la première chose à faire est de récupérer le repository gitolite-admin sur une machine cliente. Pour celà il faut avoir les droits d'accès à ce repository.

Ici, nous allons utiliser le compte gitoliteadm créé pendant l'installation qui est administrateur de gitolite. Il faut donc disposer de sa clé privée pour s'authentifier sur gitolite.

Normalement, l'installer a déposé cette clé dans le repertoire .ssh de l'utilisateur POSIX depuis lequel l'installation a été faite.

ptitoliv@workstation:~$ ls -al .ssh/gitolite*
-rw------- 1 ptitoliv ptitoliv 1675 déc 19 21:21 .ssh/gitoliteadm
-rw-r--r-- 1 ptitoliv ptitoliv 400 déc 19 21:21 .ssh/gitoliteadm.pub


Nous allons donc utiliser cette clé pour synchroniser le repository gitolite-admin.

2 cas sont possibles :

Le repository gitolite-admin n'existe pas en local

Il faut donc le cloner :
ptitoliv@workstation:~$ git clone ssh://git@serveur-git/home/git/repositories/gitolite-admin.git


Note : Il faut le chemin complet vers le repositories. De plus étant donné que tous les repositories sont de type "bare", le nom du répertoire est toujours suffixé par ".git".

Le repository gitolite-admin existe en local

Il faut le synchroniser depuis le serveur distant :

ptitoliv@serveur-git:~/gitolite-admin$ git pull origin master

Nous disposons donc localement du repository gitolite-admin "up-to-date" dans lequel on va pouvoir travailler.

Avec la commande git-clone, il n'est pas possible de spécifier la clé à utiliser. Pour contourner ce problème, il faut utiliser le fichier .ssh/config du home directory depuis lequel on travaille.

host gitolite
user git
hostname serveur-git
port 22
identityfile ~/.ssh/gitoliteadm


Remarque : Ce fichier est automatiquement configuré pour l'administrateur gitolite lors de l'installation.

Si tout s'est bien passé, le repository gitolite-admin est disponible en local :

ptitoliv@workstation:~$ ls -al gitolite-admin/
total 20
drwxr-xr-x 5 ptitoliv ptitoliv 4096 Dec 20 02:39 .
drwxr-xr-x 9 ptitoliv ptitoliv 4096 Dec 20 02:46 ..
drwxr-xr-x 8 ptitoliv ptitoliv 4096 Dec 20 02:41 .git
drwxr-xr-x 2 ptitoliv ptitoliv 4096 Dec 20 02:39 conf
drwxr-xr-x 2 ptitoliv ptitoliv 4096 Dec 20 02:39 keydir


Conclusion

Cet article vous à donc présenté l'outil gitolite et les bases de son fonctionnement et j'en ai présenté ici qu'une partie. Il existe en effet des fonctionnalités très intéressantes comme par exemple la gestion des droits avancées permettant de définir des ACLs par branche qui peut se révéler intéressante pour une gestion des droits très fine.

Pour conclure tiens à remercier JAG (il se reconnaitra) pour m'avoir présenté gitolie et participé à l'intégration de cet outil au sein du projet auquel je participe.

Bonne utilisation de gitolite.