[[public:heberger_ses_services|< Retour à l'index]] ====== Repositories git/gitolite ====== Il s'agit ici d'un objectif double: * centraliser ses codes sources, tout en conservant leur historique et variantes * rester dans un contexte 100% privé et sous contrôle (par rapport à github par exemple) * gérer sans limitation l'accès aux projets pour différents développeurs ayant des droits spécifiques C'est utile à titre individuel pour développer depuis plusieurs postes (ex. poste fixe et pc portable), mais aussi pour permettre de sous-traiter facilement et sans devoir donner accès à davantage qu'il ne le faut. L'outil opensource gitolite permet d'imposer ce controle d'accès sous une forme très simple, mais il ne se substitue ni à un bug tracking, ni à un système de "pull request" (soummission contrôlée de modifications par un tiers). Ce n'est donc pas un remplacement d'outils beaucoup plus complexes de gestion de projet tels que github ou gitlab. Mais c'est précisément aussi son intérêt: rester simple et efficace pour de petites équipes. ===== Principes ===== ''git'' est le système de versioning de source le plus utilisé et probablement le plus performant à l'heure actuelle. Il repose sur une approche distribuée de "patches" (modifications incrémentales) stockés sous forme arborescente. Voyez [[doc:formations:git|cette page]] pour une introduction progressive et plus précise à l'usage de git. On appelle un "repository" un lieu commun qui permet à un ou plusieurs développeurs de récupérer et pousser des modifications dans des projets git, mais cette notion même de "dépot" est subjective. En effet, ajouter un ou plusieurs "remote", n'est rien d'autre qu'indiquer un ou plusieurs lieu tiers où se trouvent des *copies* de l'arborescence que l'on a chez soi, qui servent de points de comparaison et d'approvisionnement pour d'autres développeurs. Et précisément, git excelle pour comparer, réconcilier et créer diverses versions d'un projet. Sans aller hors-sujet, et dans tous les cas, il est utile d'avoir un "dépot central" qui sert de point d'échange principal pour le code source d'un projet. Cela sert aussi comme sauvegarde lorsqu'il se trouve sur un serveur indépendant du poste client. Enfin, cela sert beaucoup lorsqu'une partie d'une mission doit être soummise à un développeur tiers. === Fonctionnement === Le protocole que nous utilisons ici pour ''git'' est SSH (sécurisé et crypté). Mais contrairement à l'habitude, nous n'allons pas donner un accès SSH "habituel" aux développeurs sur le serveur. En cela, ''gitolite'' est une extension intelligente du protocole SSH, qui permet d'intercepter toutes les commandes SSH envoyées, afin de vérifier les droits entrants du développeurs, pour imposer des règles définies simplement, et ne laisser passer que les commandes ''git'' habituelles. :!: de ce fait, les projets git vont être géré indirectement par l'utilisateur associé à gitolite sur le serveur, et seulement lui. Cet utilisateur ne sera pas utilisé interactivement, et encore moins depuis l'extérieur. ====== Mise en place ====== ===== Installation ===== Astuce: sur votre poste client, si besoin, simplifiez-vous l'accès au bon serveur, port et (futur) utilisateur, en ajoutant un alias vers le bon serveur et le bon port dans votre [[doc:formations:hebergement:serveur:ssh#configurer_des_option_selon_l_utilisateur|~/.ssh/config]]. On crée maintenant sur le serveur un utilisateur ''gitolite'' dédié et on installe le gestionnaires (notez que l'on passe ici par la version la plus récente de https://gitolite.com/gitolite et non la version ''apt''): ssh root@repos apt update && apt install git adduser --system --shell /bin/bash --group --home /home/gitolite gitolite --gecos 'git handler' sudo su - gitolite git clone https://github.com/sitaramc/gitolite mkdir -p bin .gitolite/logs gitolite/install -to $HOME/bin exit exit Depuis son poste client, on finalise l'installation, avec sa clé publique SSH (clé d'administrateur gitolite, qui sera nommée ici ''jeremie.pub'', à changer bien sûr pour être plus explicite): cat ~/.ssh/id_rsa.pub | ssh root@repos 'sudo -H -u gitolite bash -c "cat > /tmp/jeremie.pub; cd /home/gitolite; bin/gitolite setup -pk /tmp/jeremie.pub"' ===== Configuration initiale ===== Tout accès SSH sur gitolite@repos est volontairement intercepté par gitolite: ce n'est pas un compte interactif, il ne fera que des opérations git. Par défaut, un accès standard retourne la liste des projets du dépot, avec les droits que l'on a dessus, par exemple: $ ssh gitolite@repos hello jeremie, this is gitolite@git.mondomaine.com running gitolite3 v3.6.11-4-gef9ab68 on git 2.17.1 R W gitolite-admin R W testing Connection to files.tecrd.com closed. ===== Gestion des utilisateurs de gitolite ===== Au delà de vous-mêmes, vous pourez ajouter/retirer des utilisateurs identifiés par leur clé SSH publique, et leur donner des droits projet par projet. **Cette configuration passe elle-même par git**: les changements de configurations seront donc suivies et historisées! Depuis son poste client, on commence par récupérer le projet suivant: git clone gitolite@repos:gitolite-admin cd gitolite-admin/ Là se trouvent actuellement seulement deux fichiers: * ''conf/gitolite.conf'' * ''keydir/jeremie.pub'' Le fichier ''gitolite.conf'' permet de configurer les droits associés à chacune des clés SSH publiques stockées dans le dossier ''keydir''. ==== Ajout d'un utilisateur à gitolite ==== Pour ajouter un utilisateur ''marcel'' qui vous aurait donné sa clé SSH publique ''/tmp/marcel.pub'', on l'ajoute d'abord dans le repository ''gitolite'' (sur votre poste, pas sur le serveur) : cp /tmp/marcel.pub keydir/ git add keydir git commit -m "ajout de marcel" git push origin master Mais jusque là, il n'aura pas davantage de droits sur les projet git! ==== Configuration des droits des utilisateurs ==== Pour lui donner un droit de lecture seule et sur un projet nommé ''prj'' pour lequel vous auriez un accès complet, il faudra ajouter ou modifier le paragraphe correspondant dans le fichier ''conf/gitolite.conf'', et le soummettre par git: repo gitolite-admin RW+ = jeremie repo testing RW+ = @all repo prj RW+ = jeremie R = marcel Note: le fait de pousser cette modification de ''gitolite.conf'' va initialiser le projet du coté du serveur. Il suffira donc d'un simple ''git clone gitolite@repos:prj'' pour le récupérer localement. La logique simple de gitolite implique que pour ajouter un utilisateur, ou configurer ses droits il suffit d'avoir soi-même le droit d'écriture sur sur le projet ''gitolite'': pour marcel, ce serait fait avec la modification de ce paragraphe: repo gitolite-admin RW+ = gitolite RW+ = marcel Des droits complexes sont possibles avec ''gitolite'', comme la gestion groupée ou l'interdiction pour une personne de faire un ''push'' sur la branche ''master'' (voyez [[https://github.com/sitaramc/gitolite#access-rule-examples|cette section]] par exemple). ===== Création d'un projet ===== ==== Nouveau projet ==== Pour créer un nouveau projet, il faut d'abord le déclarer dans ''gitolite-admin/conf/gitolite.conf'', avec les droits associés: repo RW+ = jeremie ==== Projet local à importer dans gitolite ==== S'il existe déjà, ou bien si l'on a créé le projet côté client, par exemple: mkdir REPONAME cd REPONAME git init git add . git commit -m 'initial commit' -a Alors il faut le rattacher au serveur gitolite: git remote add origin gitolite@repos:REPONAME git push origin master Si le remote existe déjà, pensez à ''git remote rename origin gitolite@repos:REPONAME'' (voir la documentation/aide git). ==== Import de dépots existants dans gitolite ==== ([[https://gitolite.com/gitolite/basic-admin#appendix-1-bringing-existing-repos-into-gitolite|source]]) Il est possible et utile d'intégrer directement des dépots existants sous gitolite, en les copiant directement sur le serveur dans le dossier ''/home/gitolite/repositories''. Il faut vérifier que chacun des nom de projets finit bien avec l'extension ''.git'' . Puis vérifier les droits de ces fichiers: ''sudo chown -R gitolite:gitolite /home/gitolite/repositories'' Ensuite on les notifie à gitolite: sudo su - gitolite gitolite compile gitolite setup --hooks-only gitolite trigger POST_COMPILE Et finalement, il faudra ajouter un paragraphe associé à chaque projet dans ''conf/gitolite.conf'', avec les droits attendus. ===== Annexe ===== ==== Remarque importante sur les noms de clés SSH ==== :!: Si vous rencontrez des problèmes pour faire reconnaitre un utilisateur, il y a une caractéristique à savoir, parfois vicieuse, dans la gestion des clés SSH par gitolite: si la clé de l'utilisateur est sous la forme "joe@fqdn" et que "fqdn" est bien un FQDN valide (nom de domaine internet complet et valable), alors il faut spécifier le nom "joe@fqdn" dans le fichier ''gitolite.conf''. C'est-à-dire que "joe@here.or.there" sera valide là où "joe@here" ne l'est pas! Dans le cas d'un email mal formé, on peut cependant spécifier l'utilisateur par son nom seulement ("joe" ici, mais ce n'est pas idéal). Explications [[https://stackoverflow.com/questions/13957954/gitolite-usernames-in-authorized-keys-file|ici]] ("l'idée du @suffix est de permettre à l'administrateur d'ajouter facilement plusieurs clés pour un même utilisateur"). ==== Configuration coté client de son .ssh/config pour gitolite ==== A propos de SSH, voyez les bénéfices de configurer votre ''$HOME/.ssh/config'' sur [[https://wiki.tecrd.com/doku.php?id=doc:formations:hebergement:serveur:ssh#options_du_cote_client|la page ssh]]. ====== Usage de git ====== C'est (pour le moment) hors sujet par rapport à ce guide. Mentionnons seulement quelques éléments utiles à mettre dans son ''~/.gitconfig'': [merge] tool = meld ff = no commit = no [color] ui = true [color "status"] changed = red bold untracked = red bold added = green bold [alias] loga = log --all --decorate --oneline --graph d = difftool -y Dans son "prompt" unix, on peut aussi ajouter la branche sur laquelle on travaille, c'est pratique pour éviter les erreurs de manupipulation. Pour cela on peut modifier ou ajouter cette ligne dans son ''~/.bashrc'': PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[00;32m\] \w\[\033[01;30m\]$(__git_ps1)\[\033[00m\]\n\$ '