Maintenant que l'utilisateur est créé, nous allons lui créer un repository pour lequel il aura tous les droits.

Pour cela, il suffit de déclarer un nouveau repository dans le fichier gitolite.conf.

On se place donc sur la machine cliente en tant qu'administrateur gitolite et on procède à l'édition de ce fichier.

ATTENTION : Ne pas oublier de resynchroniser le repository gitolite-admin à partir du serveur de référence et de vérifier de bien être sur la branche master

On rajoute donc un repository monprojet-kitu et on donne tous les droits à l'utilisateur gituser.

repo monprojet-kitu
RW+ = gituser


On commit les modifications localement :

ptitoliv@workstation:~/gitolite-admin/conf$ git add gitolite.conf
ptitoliv@workstation:~/gitolite-admin/conf$ git commit
Created commit bd103bc: Ajout du repository monprojet-kitu et configuration des droits pour l'utilisateur gituser
1 files changed, 2 insertions(+), 0 deletions(-)


Puis on pushe les modifications sur le serveur distant :
ptitoliv@workstation:~/gitolite-admin/conf$ git push origin master
Counting objects: 7, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 441 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To gitolite:gitolite-admin
ced7b36..bd103bc master -> master
Already on "master"
Initialized empty Git repository in /home/git/repositories/monprojet-kitu.git/

Une fois encore, les hooks ont fait leur travail lors du push et on procédé à la création du repository sur le serveur de référence. La liste des ACLs a également été mise à jour pour autoriser gituser à accéder à monprojet-kitu.git.

Si l'on considère les ACLs rentrées dans le fichier gitolite.conf, seul l'utilisateur gituser peut accéder au repository monprojet-kitu.git.

Pour tester ceci, nous allons tester d'agir sur ce repository depuis la station d'un développeur quelconque propriétaire de la clé privée identifiant l'utilisateur gitolite gituser.

Préparation de l'environnement utilisateur

Avant que l'utilisateur puisse utiliser gitolite, il faut intégrer la clé privée à son environnement.

Pour que la clé soit prise par défaut lorsqu'on se connecte au serveur gitolite, on rajoute le bloc de configuration suivant :

host gitolite
user git
hostname serveurgit
port 22
identityfile ~/.ssh/gituser


Test de la connexion :

dev@devstation:~/.ssh$ ssh gitolite
PTY allocation request failed on channel 0
hello gituser, the gitolite version here is (unknown)
you have the following permissions:
R W monprojet-kitu
@ @ testing
Connection to serveurgit closed.


On voit bien que c'est la commande rajoutée dans le fichier authorized_keys côté serveur qui est exécutée. Ainsi, on peut savoir a quel repository l'utilisateur à accès.

Création du repository et synchronisation

On commence à présent à remplir le repository depuis le profil du développeur.

Création et initialisation du repository local


dev@devstation:~$ mkdir monprojet
dev@devstation:~$ cd monprojet/
dev@devstation:~/monprojet$ git init
Initialized empty Git repository in /home/dev/monprojet/.git/


Déclaration du serveur de référence

A ce niveau la, le repository local est créé mais est complètement indépendant du serveur de référence. Pour faire le lien entre les 2, il faut donc déclarer la référence origin. Pour faire une référence correcte, il faut tenir compte de 3 points :

• Le hostname : Doit correspondre au hostname déclaré dans le fichier .ssh/config
• Le path sur le serveur de référence : Le chemin doit être décrit par rapport à la racine déclarée dans le fichier .gitolite.rc
• Le nom du repository : Etant donné que tous les repositories distant sont de type "bare", ne pas oublier l'extension .git à la fin

Voici donc ce que ca donne pour notre repository :
dev@serveurgit:~/monprojet$ git remote add origin ssh://gitolite/monprojet-kitu.git

Remplissage du repository et synchronisation

Tout est prêt à présent pour utiliser notre repository distant géré par gitolite.
dev@devstation:~/monprojet$ touch main.c
dev@devstation:~/monprojet$ git add main.c
dev@devstation:~/monprojet$ git commit -m "Initial Release"
[master (root-commit) cebade6] Initial Release
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 main.c
dev@devstation:~/monprojet$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://gitolite/monprojet-kitu.git
* [new branch] master -> master

Gitolite a autorisé l'utilisateur à pusher sur le serveur de référence. Tout s'est bien passé. Cependant, est que les ACLs ont vraiment été appliquées ? Testons celà avec un autre utilisateur gitolite.

Rajoutons un deuxième utilisateur dans la base gitolite :
ptitoliv@workstation:~/gitolite-admin/keydir$ git add badguy.pub
ptitoliv@workstation:~/gitolite-admin/keydir$ git commit -m "Ajout de l'utilisateur badguy"
ptitoliv@workstation:~/gitolite-admin/keydir$ git push origin master


Cet utilisateur est dans la base mais n'a aucun droit sur le repository monprojet-kitu.git.

Pour tester, remplaçons la clé de gituser par celle de badguy pour notre compte dev :
dev@devstation:~$ cat .ssh/config
host gitolite
user git
hostname debian-vm
port 22
identityfile ~/.ssh/badguy

Testons avec ssh :
dev@devstation:~$ ssh gitolite
PTY allocation request failed on channel 0
hello badguy, the gitolite version here is (unknown)
you have the following permissions:
@ @ testing
Connection to serveurgit closed.

On constate que c'est maintenant l'utilisateur badguy qui est utilisé et que les droits ont changé.

Essayons à présent d'accéder au repository :
dev@devstation:~/monprojet$ git pull
R access for monprojet-kitu DENIED to badguy
fatal: The remote end hung up unexpectedly
dev@devstation:~/monprojet$ git push origin master
W access for monprojet-kitu DENIED to badguy
fatal: The remote end hung up unexpectedly/

Les ACLs sont bien appliquées et les repositories sont bien protégés.

Modification des droits

Si l'on souhaite changer les droits ou créer d'autres repositories, rien de plus simple. Il suffit d'exécuter les opérations suivantes :

• Récupérer la dernière version du repository gitolite-admin sur le serveur de référence
• Procéder à la modification du fichier gitolite.conf
• Commiter les changements localement
• Pusher la version locale sur le repository de référence