Installer un serveur dédié sous Ubuntu Serveur
Date de publication : 09 décembre 2011.
IX. Le versionning avec git et gitolite
IX. Le versionning avec git et gitolite
git/gitolite est un outils de gestion de version décentralisé comparable à subversion ou CVS. Il permet de conserver un historique des modifications réalisées sur un ensemble de données, vous offrant ainsi la possibilité de récupérer un ou plusieurs fichiers pour une version définie.
Pour installer cette outils, il sera nécessaire de disposer de notre utilisateur monadmin afin administrateur des dépôts et de l'utilisateur usergit (que l'on va créer) comme hébergeur des dépôt.
Tout d'abord, installons git :
sudo apt-get install git-core
|
git/gitolite utilise l'accès ssh afin de gérer le versionning. Bien que nous allons créer un utilisateur dédié, gitolite émulera des comptes différents en fonction des utilisateurs, nous permettant ainsi une très bonne traçabilité tout en restant sécurisé.
Créons notre utilisateur et donnons lui accès à ssh
 |
Attention : veillez à modifier correctement la configuration de ssh, sous peine de perdre tout accès à votre serveur et de recommencer ce tutoriel du début.
|
sudo nano /etc/ssh/sshd_config
|
AllowUsers monadmin usergit # nous rajoutons usergit au(x) utilisateur(s) déjà autorisé(s)
|
Redémarrons le service ssh afin que l'accès à notre nouvel utilisateur soit pris en compte.
sudo /etc/init.d/ssh restart
|
Reconnectons nous en ssh avec notre utilisateur monadmin afin de générer une clé ssh pour administrater les dépôts (via la commande su monadmin ou en se reconnectant avec l'utilisateur monadmin).
 |
Afin de sécurisé votre clé ssh, pensez à choisir une "passphrase" suffisamment complexe (30 caractères maximum).
|
Nous disposons maintenant de notre clé ssh.
Afin que cette clé soit accessible pour l'utilisateur usergit, nous allons la copier vers son répertoire et le rendre propriétaire de cette dernière.
sudo cp /home/benadmin/.ssh/id_rsa.pub /home/usergit/admin.pub
sudo chown usergit:usergit /home/usergit/admin.pub
|
Notre clé étant prête à l'emploi, nous allons nous connecter avec l'utilisateur usergit.
gitolite n'appartient pas aux dépôt Universe de ubuntu, en effet, il exploite directement les possibilités de git et, par conséquent, est accessible depuis un dépôt git :
git clone git://github.com/sitaramc/gitolite
|
Vous constaterez que vous disposez maintenant d'un répertoire gitolite. Poursuivons la configuration avec le script d'installation :
gitolite/src/gl-system-install
|
Il est probable qu'à la suite de cette commande, un message vous indique que des chemins sont manquant dans la variable d'environnement $PATH. Vous pouvez les rajouter manuellement ou plus simplement rebooter la machine, la variable sera ainsi mise à jour.
|
Si cela n'était pas le cas, vous pouvez également modifier la variable $PATH suivant cette commande :
echo "PATH=$HOME/bin:$PATH" >> /home/usergit/.bashrc
|
Informons également gitolite de notre accès admin :
Nous disposons maintenant d'un accès à git/gitolite depuis le compte admin (monadmin). Loggons nous avec cet utilisateur afin de réaliser l'administration de gitolite.
Nous récupérons en premier lieu la configuration de gitolite.
git clone ssh://usergit@monsite.fr:1234/gitolite-admin
|
Comme vous pouvez le constatez, la configuration de gitolite-admin se comporte en dépôt git. Ainsi nous récupérons les sources, réalisons nos modifications et validons.
La configuration de gitolite-admin se résume principalement à un fichier gitolite-admin/conf/gitolite.conf ainsi qu'à un répertoire de clés ssh gitolite-admin/keydir/. Ce qui fait la force de git/gitolite est sa simplicité de paramétrage comme vous allez le constatez.
Editons le fichier conf/gitolite.conf, vous devriez trouver le résultat suivant :
nano /home/monadmin/gitolite-admin/conf/gitolite.conf
|
repo gitolite-admin
RW+ = admin
repo testing
RW+ = @all
|
Quelques explications s'imposent :
La syntaxe de ce fichier est relativement simple. Pour chaque dépôt doit correspondre la ligne repo Nom_du_depot suivis des droits d'accès :
# Définition d'un groupe d'utilisateurs
# le groupe @all existe par défaut sans que l'on ait besoin de le préciser. Bien entendu, tous les utilisateurs appartiennent à ce groupe.
@group1 = Alain_provist Alex_Terrieur Alain_Terrieur
repo gitolite-admin # ne jamais retirer ce dépôt (il est fortement recommandé de ne pas le modifier également)
RW+ = admin
# Définition du dépôt mon_depot
repo mon_depot
R = @all # R correspond au droit en lecture (git clone, etc)
RW = user1 @group1 # RW autorise les accès en lecture et écriture (git clone, push, etc)
RW+ = admin # RW+ idem que RW mais permet en plus des actions d'administration comme supprimer des étapes du projet
[...]
|
Les dépôts existants sont ceux présent dans ce fichier. En d'autres termes, en supprimant les lignes correspondant au dépôt testing, nous supprimons également le dépôt lui-même.
Plaçons nous dans la situation suivante :
Nous souhaitons, en plus du dépôt gitolite-admin, un dépôt super-projet accessible en lecture à tous et en lecture/écriture pour vous (au boulot et à la maison) ainsi que votre ami Jerry Golet.
De plus, nous n'avons pas besoin du dépôt testing, nous allons donc le retirer.
Voici à quoi devrait ressembler alors votre fichier :
@group1 = moi jerry-golet
repo gitolite-admin # ne jamais retirer ce dépôt (il est fortement recommandé de ne pas le modifier également)
RW+ = admin
# Définition du dépôt mon_depot
repo mon_depot
R = @all # R correspond au droit en lecture (git clone, etc)
RW = @group1 # RW autorise les accès en lecture et écriture (git clone, push, etc)
RW+ = admin moi # RW+ idem que RW mais permet en plus des actions d'administration comme supprimer des étapes du projet
[...]
|
Certes, cela vous semble bien, mais... qu'en est-il de votre localisation ? De même, nous n'avons précisé aucune clé ssh correspondant à nos utilisateurs
Pour cela, rien de plus simple. Pour chaque utilisateur, nous devons générer une clé ssh sur son poste client (via ssh-keygen par exemple), l'uploader dans le répertoire gitolite-admin/keydir/ de usergit sur notre serveur et la renommer sous le format nom-utilisateur.pub .
Qu'en est-il de la localisation ? J'y viens. En effet, comme nous l'avons vu tout à l'heure vous disposez de deux localisations avec deux ordinateurs différents pour travailler sur votre projet. Vous aurez donc deux clé ssh.
Afin de prendre en compte cette spécificité, vous devez renommer vos clés en moi@home.pub et moi@work.pub
En effet, le nommage de la clé se compose ainsi :
nom-utilisateur@lieu.pub
- nom-utilisateur : doit correspondre au nom donné dans notre fichier gitolite.conf
- @lieu : (facultatif) permet de préciser un lieu/une machine, ainsi nous pouvons avoir plusieurs clés ssh pour un même utilisateur (attention, prenez soin de ne pas y mettre de '.' )
- .pub : il s'agit de l'extension traditionnelle, elle est a conserver
Pour reprendre notre exemple, vous devriez avoir les fichiers suivants dans votre répertoire gitolite-admin/keydir/ :
moi@home.pub
moi@work.pub
jerry-golet.pub
admin.pub (qui devrait déjà être présent)
Nous venons d'achever la configuration, il ne nous reste plus qu'à valider nos modifications et à les renvoyer :
cd /home/monadmin/gitolite-admin
git add .
git commit -m "configuration initiale gitolite"
git push
|
git/gitolite est maintenant pleinement opérationnel.
|
Pour tout nouveau dépôt, il est souhaitable de réaliser les actions suivantes sur le poste client avant tout ajout de fichier :
git clone ssh://usergit@monsite:1234/mon-nouveau-depot
cd mon-nouveau-depot
git push origin master
En effet, la dernière ligne permettra de définir l'emplacement de base dans le dépôt. L'utilisation de 'git push' suffit dès à présent quelque soit la machine.
Bon versionning !
|
Copyright © 2011 Benjamin GAGNEUX.
Aucune reproduction, même partielle, ne peut être faite
de ce site ni de l'ensemble de son contenu : textes, documents, images, etc.
sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à
trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.
