Gitolite est un projet Open Source permettant de gérer des droits sur les dépôts Git en utilisant le principe des ACL.
Gitolite utilise des utilisateurs virtuels qui sont basés sur un unique utilisateur système. Ces utilisateurs virtuels ne possèdent pas d’accès au shell de la machine. Un git shell leur permet d’effectuer les différentes commandes.
Pourquoi ai je installé GITOLITE ?
Tout simplement pour les différents projets d’OverSimple. En effet, avant d’ouvrir ce site, Julien et moi avons développer un Hotspot wifi (peut être un aperçu bientôt). Nous l’avions fait sans gestionnaire de sources, ce qui nous a posé quelques problèmes de cohésion. Après cette expérience, nous avons décidé de mettre en place un Git. La question qui s’est alors posée concernait l’emplacement de celui-ci. Sur mon serveur ? Sur un serveur commun à nous deux ? Actuellement, nous ne possédons aucun serveur en commun. J’ai donc installé Git sur ma machine personnelle. Cependant, comment faire pour que l’on puisse travailler ensemble sans que nos projets soient dans « la nature ». La meilleure solution est d’utiliser le SSH mais comme Julien ne possède pas d’accès sur ma machine, il y avait toujours un problème… Le problème fut résolu par la mise en place de GITOLITE. Grâce a GITOLITE, je peux donner à n’importe quelle personne un accès sur le projet voulu.
Installation de GITOLITE
Dans l’article concernant l’installation de git, j’ai pu mettre en place un utilisateur « Git ». Cette utilisateur trouve tout son intérêt dans l’utilisation de GITOLITE. Celui-ci n’a pas besoin de mot de passe car à chaque fois que l’on ajoutera un utilisateur virtuel celui devra fournir une clé publique. Cette clé publique sera ajoutée dans les authorization keys de l’utilisateur Git. Regardons le contenu de mon fichier (authorization keys) :
# gitolite start command="/home/git/gitolite/src/gitolite-shell pierre",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC70+f4qTYTjAAwG5jjn3emRdbX2S/OccZdYg2QHGc+OL5uW+mitSvwh0wnKJYc3QzzgQ0E/GGpJkTGpzcKaFrz21lPPbjXvUb5Qa8KP11cUCcN5SREKuQem1EMCnUQGrDS94MZ1eFyma0kWGpjWXNCfaRuBcpPfh9WJ1TzTrb0jokGKFloAlzvd0Z5GGzWAWLrTlK7wIVY3Zsvde+kxJJDZkDFm3X/maOdG3Kb/EoTAH1TtG3OkDsoMu/FUogxix6eCMo5g/xREzQxXPyXHxmjY5dCfNVvg7sXx4Ss4jBz9/8vOpbPdEHykjtHBq9L38hbcfYiss4Ab4E0IC2dP+29 pierre@portable # gitolite end |
Cette clé publique correspond à l’utilisateur Pierre.
Pour cela j’ai du générer une paire de clés pour mon utilisateur Pierre. Voici la procédure :
cd ~/.ssh ssh-keygen -t rsa -f id_rsa_git cd - scp id_rsa_git.pub monuser@leServeur:/home/monuser |
On se connecte sur notre serveur :
cp id_rsa_git.pub /home/git/pierre.pub exit |
Attention
Lors de mes recherches sur internet pour installer git & gitolite, j’ai pu m’apercevoir qu’il existe deux erreurs récurrentes sur plusieurs sites, la deuxième dépendant de la première.
Cette première erreur consiste à générer une paire de clés pour l’utilisateur Git. En plus de générer une paire de clé qui sera très peu utilisée celle-ci sera mal gardée, c’est pour cela que c’est déconseillé par la communauté Gitolite.
La deuxième erreur est d’ajouter la clé id_rsa_git.pub dans le fichier ~.ssh/authorized_keys:
cat id_rsa_git.pub >> /home/git/.ssh/authorized_keys
Lorsque nous passons à l’installation, nous avons une alerte : WARNING: keydir/git.pub duplicates a non-gitolite key, sshd will ignore it
Si on laisse cela dans l’état, nous n’utilisons pas le shell de Git mais notre shell par défaut (dans mon cas ksh pour mon serveur).
Cependant, si vous désirez que votre utilisateur accède au shell ksh, il est préférable de générer une autre paire de clés.
Installation de GITOLITE
On se connecte sur notre utilisateur git :
# su - git |
Puis on récupère GITOLITE :
git clone git://github.com/sitaramc/gitolite |
On récupère le chemin en entier :
$ gitolite/install use the following full path for gitolite: /home/git/gitolite/src/gitolite |
Puis on effectue l’installation (vous remarquerez que j’ai mis ma clé publique)
$ /home/git/gitolite/src/gitolite setup -pk /home/git/pierre.pub Initialized empty Git repository in /home/git/repositories/gitolite-admin.git/ Initialized empty Git repository in /home/git/repositories/testing.git/ |
Configuration de notre client
La configuration de GITOLITE est simple, celui-ci est gérée de la même manière qu’un dépot Git.
Configurons, maintenant, notre poste client afin que cela soit plus simple:
Éditons notre fichier de configuration SSH (vim ~/.ssh/config)
Host gitolite User git Hostname IP_DE_MON_SERVEUR port 22 identityfile ~/.ssh/pierre |
Si la configuration ci-dessous n’est pas effectuée pour se connecter au serveur, il faudrait faire :
git clone ssh://git@monServeur/gitolite-admin.git/ |
Sinon vous avez effectué la configuration du SSH, et vous pouvez utilisé soit la première ou deuxième ligne :
git clone ssh://gitolite/gitolite-admin.git/ git clone gitolite:gitolite-admin.git |
De vous à moi, je préfère largement la deuxième qui est beaucoup plus simple.
Configuration de notre GITOLITE
On regarde les fichiers récuperés sur notre poste :
ls -R gitolite-admin/ gitolite-admin/: conf keydir gitolite-admin/conf: gitolite.conf gitolite-admin/keydir: git.pub |
On peut voir le fichier gitolite.conf et le repertoire keydir.
Le fichier gitolite.conf permet la configuration des utilisateurs/groupes et les dépôts.
Le répertoire keydir contient les clés publiques des utilisateurs sous la forme nom.pub
Dans le fichier de configuration, on peut avoir plusieurs ACL pour chaque répertoire:
- RW+ : Droits de lecture, d’écriture et de suppression d’objets particuliers tels que Branches et Tags.
- RW : Droits de lecture et d’écriture (push)
- R : Droit de lecture (pull,clone,fetch)
- – : Refuser l’access (par exemple, on ajoute un groupe mais on veut refuser un utilisateur)
Pour chaque répertoire, on peut spécifier des utilisateurs, des groupes ou bien un accès public.
Ajout d’un utilisateur
Il suffit de copier la clé publique dans le répertoire keydir récupéré en local. Prenons l’exemple de Julien :
Julien me donne sa clé publique.
cp julien.pub keydir/ |
On ajoute la clé dans le répertoire :
git add julien.pub git commit -m "Ajout de l'utilisateur Julien" |
Nous venons de soumettre le projet dans le répertoire local. Afin de le rendre disponible sur le serveur de référence, il faut donc effectuer un push:
git push |
Création d’un répertoire oversimple :
Il faut ajouter dans conf/gitolite.conf :
repo oversimple RW+ = pierre julien |
Création de plusieurs répertoires pour les mêmes personnes, rien de plus simple :
repo oversimple oversimple1 oversimple2 RW+ = pierre julien |
Une fois les modifications apportées, les commandes sont toujours pareilles :
$ git add conf/gitolite.conf $ git commit -m "Ajout du répertoire oversimple" |
$ git push Counting objects: 7, done. Delta compression using up to 2 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (4/4), 398 bytes, done. Total 4 (delta 0), reused 0 (delta 0) remote: Initialized empty Git repository in /home/git/repositories/oversimple.git/ To ssh://gitolite/gitolite-admin.git 8039b66..f2b18d1 master -> master |
On peut remarquer la création de notre répertoire oversimple.git.
Création de groupe :
Julien et moi formons un groupe qui est oversimple. Pour les projets que l’on peut avoir en cours, d’autres personnes peuvent se greffer, par exemple, Éléonore.
Ajout dans la configuration :
@oversimple = pierre julien OU Exactement pareil : @oversimple = pierre @oversimple = julien repo oversimple oversimple1 oversimple2 RW+ = @oversimple repo projet1 RW+ = @oversimple RW = eleonore |
Bien sur une clé publique sera ajoutée pour Éléonore
Une fois terminée, toujours la même musique… git add, commit & push.
Pour terminer, testons un peu les différents droits. Mettons nous dans le cas d’ Éléonore, celle-ci a accès uniquement au répertoire projet1.
$ git clone leo:projet1 Cloning into 'projet1'... warning: You appear to have cloned an empty repository. |
Cela fonctionne parfaitement. Cependant, elle aimerait avoir accès au dossier oversimple.
$ git clone leo:oversimple Cloning into 'oversimple'... FATAL: R any oversimple eleonore DENIED by fallthru (or you mis-spelled the reponame) fatal: The remote end hung up unexpectedly |
On peut voir qu’elle n’y a pas accès, car elle n’est pas présente dans la configuration.
Nous avons un Git & GITOLITE opérationnel !
It’s over simple, isn’t it?