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 :
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".
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
Avec gitolite, tout fonctionne avec SSH et les clés. Ainsi la base de données des utilisateurs est présentée sous la forme d'une liste de clés SSH dans un répertoire versionnés dans le repositories gitolite-admin.
Nous allons donc ajouter un utilisateur gituser dans la base des utilisateurs gitolite.
La première étape est donc de générer l'utilisateur gituser en créant les clefs.
ptitoliv@workstations:~$ 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): gituser
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in gituser.
Your public key has been saved in gituser.pub.
The key fingerprint is:
03:4a:a9:c0:b0:ff:46:f5:b0:1d:a0:96:be:75:cd:89 ptitoliv@workstation
The key's randomart image is:
+--[ RSA 1024]----+
|. . |
|o. + . |
|o. * + . |
| o = o * = . |
| o + o E + |
| o o . . |
| + |
| . |
| |
+-----------------+
ptitoliv@debian-vm:~$
Pour ajouter, l'utilisateur il suffit de copier la clé publique dans le répertoire keydir du repository local gitolite-admin. Ne pas oublier que le nom de la clé doit être au format "username".pub.
ptitoliv@workstation:~/gitolite-admin/keydir$ cp /home/ptitoliv/gituser.pub .
ptitoliv@workstation:~/gitolite-admin/keydir$ ls -l
total 8
-rw-r--r-- 1 ptitoliv ptitoliv 400 déc 20 02:39 gitoliteadm.pub
-rw-r--r-- 1 ptitoliv ptitoliv 228 déc 20 14:57 gituser.pub
ptitoliv@workstation:~/gitolite-admin/keydir$
On ajoute ensuite la clé dans le repository gitolite-admin :
ptitoliv@debian-vm:~/gitolite-admin/keydir$ git add gituser.pub
ptitoliv@debian-vm:~/gitolite-admin/keydir$ git commit -m "Ajout de l'utilisateur gituser"
Created commit e07bd81: Ajout de l'utilisateur gituser
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 keydir/gituser.pub
L'utilisateur est à présent "commité" dans le repository local gitolite-admin. Cependant il n'est pas encore présent sur le repository sur le serveur de référence. Il faur donc pusher la branche master du repository gitolite-admin sur le serveur de référence.
ptitoliv@workstation:~/gitolite-admin/keydir$ git push origin master
Counting objects: 6, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 569 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To gitolite:gitolite-admin
d885d48..ced7b36 master -> master
Already on "master"
WARNING: pubkey gituser.pub exists but user gituser not in config
Les modifications ont donc été pushé sur le repository de référence. Côté serveur, les hooks ont été exécutés afin de prendre en compte ce nouvel utilisateur. On le voit très bien grâce au message de warning retourné par le hook.
Ce message est normal étant donné que nous n'avons déclaré aucune ACL pour cet utilisateur. Ceci est la prochaine étape.
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.
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.
On commence à présent à remplir le repository depuis le profil du développeur.
dev@devstation:~$ mkdir monprojet
dev@devstation:~$ cd monprojet/
dev@devstation:~/monprojet$ git init
Initialized empty Git repository in /home/dev/monprojet/.git/
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 :
.gitolite.rcVoici donc ce que ca donne pour notre repository :
dev@serveurgit:~/monprojet$ git remote add origin ssh://gitolite/monprojet-kitu.git
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.
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 :
Généralement, la gestion des droits sur les SCM est centralisée et sous la responsabilité de l'administrateur du repository. Cela peut être problématique en cas d'indisponibilité de cette personne en cas de demande de modifications des droits sur un repository.
Un des points forts de gitolite est justement donc de pouvoir déléguer les droits sur un repository existant à un autre utilisateur gitolite enregistré autre que l'administrateur gitolite.
Nous allons donc voir dans cette dernière partie avec un exemple concret de délégations de droits qui est la meilleure manière d'expliquer la délégations de droits sur gitolite.
Nous allons donc considérer un utilisateur alice enregistré dans la base des utilisateurs gitolite et nous allons lui déléguer les droits d'administration sur le repository monprojet-kitu.
La méthode la plus conseillée pour gérer les délégations de droits est de regrouper les repositories dans des groupes et d'activer la délégation des droits sur un groupe de repositories.
Nous allons donc créer un groupe alice_repos dans lequel nous allons mettre le repository monprojet-kitu.
Tout va se faire en tant qu'administrateur gitolite, seul utilisateur à avoir l'accès à la branche master qui gère les droits de tous les repositories.
Après avoir fait un update de la branche master si nécessaire, on édite le fichier conf/gitolite.conf.
#Rajout du groupe
@alice_repos = monprojet-kitu
Ce code permet donc de créer le groupe alice_repos et de rajouter le repository dedans. Si l'on souhaite inclure un autre repository, il suffit de le rajouter à la suite.
Une fois le groupe déclaré, il faut procéder à la délégation des droits. Sous gitolite, il faut donc déléguer des droits en écriture sur une partie du repository gitolite. Il faut donc rajouter dans le bloc de déclaration du repository, l'instruction suivante :
repo gitolite-admin
RW alice_repos = alice
Fonctionnellement, cela signifie que l'on délègue à alice la possibilité de gérer les droits pour tous les repositories membre du groupe alice_repos. Cependant, si l'on se rapelle bien gitolite est avant tout un repository git avec des hooks particuliers. Si l'on se concentre donc sur ce qui est fait niveau git avec cette configuration, on se rend compte qu'en fait on vient de donner à alice des droits sur unr branche portant le nom du groupe.
Les droits des repositories du groupe seront gérées dans une branche portant le même nom que le groupe et dont les droits d'accès sont fixés par les ACLs gitolite
Une fois les modifications faites dans le fichier gitolite.conf, ne pas oublier de commiter et de pusher les modifications sur le serveur de référence.
Nous sommes à présent connectés en tant qu'alice (A savoir dans un compte utilisateur ayant accès à la clé privée pour le compte alice gitolite).
La première étape est de récupérer le repository gitolite-admin en tant qu'alice. Etant donné qu' l'administrateur a attribué des droits à alice, il est possible de faire un clone. (Opération impossible sans aucun droit sur ce repository).
devalice@devstation:~$ git clone ssh://git@serveur-git/gitolite-admin
Initialized empty Git repository in /home/devalice/gitolite-admin/.git/
remote: Counting objects: 86, done.
remote: Compressing objects: 100% (66/66), done.
Receiving objects: 100% (86/86), 7.74 KiB, done.
Resolving deltas: 100% (13/13), done.
remote: Total 86 (delta 13), reused 0 (delta 0)
L'étape suivante consiste à créer une branche dans le repository gitolite-admin correspondante au groupe pour lequel alice à les droits et se positionner dessus.
devalice@devstation:~/gitolite-admin$ git branch alice_repos
devalice@devstation:~/gitolite-admin$ git checkout alice_repos
Switched to branch 'alice_repos'
A présent il faut créer le fichier de configuration décrivant les droits établis par alice. Pour créer ce fichier, il faut respecter certaines contraintes pour que celui-ci soit validé par gitolite :
Pour notre exemple, cela donne donc les commandes suivantes :
devalice@devstation:~/gitolite-admin$ mkdir -p conf/fragments
Puis on créé un fichier nommé alice_repos.conf contenant les droits sur les repositories comme par exemple :
repo monprojet-kitu
RW+ = alice
R = @all
Avec cette on configuration, on donne tous les droits à alice et les droits en lecture pour tout le monde. Une fois le fichier sauvé, il faut le committer dans la branche. Si le fichier n'existait pas il faut l'ajouter avant à l'aborescence git.
devalice@devstation:~/gitolite-admin$ git add conf/fragments/alice_repos.conf
devalice@devstation:~/gitolite-admin$ git commit conf/fragments/alice_repos.conf -m "Add rights by alice"
La dernière étape consiste à pusher les modifications sur le serveur déférence afin de générer les ACLs. Attention par contre à pusher la branche de délégation et non la branche master.
devalice@devstation:~/gitolite-admin$ git push origin alice_repos
Lors du push les nouvelles ACLs sont générées en tentant compte de ces droits délégués.
Important : Il est possible de déclarer des droits à la fois dans la branche master mais aussi dans une branche de délégation. Dans ce cas la, les droits s'ajoutent.