§ Posté le 29/12/2012 à 17h 49m 27
Ce site me servant à héberger mes projets, il fallait un outil susceptible de permettre à la fois que les gens puisse récupérer et utiliser, et que ceux qui veulent m'aider puissent contribuer.
Les outils de ce genre ne manquent pas : cvs, subversion (svn), mercurial (hg), bazaar (bzr)… en ce qui me concerne, j'ai choisi git, parce que j'avais déjà eu l'occasion de m'en servir, et que je le trouve plutôt simple et sympa (non, l'icône n'a pas joué, cette fois(1)).
Il y a essentiellement trois moyens d'interragir avec un serveur git : par le protocole http, par un protocole dédié (« git:// »), et par ssh. En ce qui me concerne, je préfère ne pas utiliser http quand il y a un moyen plus adapté, j'ai donc rapidement écarté la première possibilité.
En revanche, les deux autres me conviennent très bien : le protocole dédié permet assez simplement de rendre les dépôts accessibles en lecture seule, et l'accès ssh permet aux utilisateurs ayant un compte sur ma machine à la fois de lire et d'écrire dans le dépôt.
Afin de ne pas forcément avoir besoin de créer un compte pour tout contributeur potentiel, il me fallait un compte utilisateur spécifique, qui n'accepterait de connexion qu'aux dépôts git, sans permettre de rien faire d'autre sur la machine, et qui ne serait pas accessible à n'importe qui.
Pour ce faire, j'ai créé le compte « guest » (son nom correspond à mon « authentification anonyme » sur le site web), qui sera le compte propriétaire de tous les dépôts git. Comme l'authentification ssh par mots de passe est désactivée, on ne peut se connecter à ce compte qu'en me fournissant une clef ssh publique.
Le shell par défaut de cet utilisateur est « /usr/bin/git-shell », un utilitaire git permettant d'accepter les commandes relatives à git, et de bloquer à peu près tout le reste(2), empêchant l'utilisateur en question de faire autre chose que contribuer aux dépôts git.
Ce compte utilisateur étant propriétaire des différents dépôts git, c'est avec lui que j'ai lancé la commande gérant le protocole dédié : « git daemon --reuseaddr --base-path=$PWD
», à lancer dans le répertoire contenant les différents projets git (dans mon cas, le répertoire personnel de cet utilisateur, qui ne servira pas à grand chose d'autre).
Il y a moyen de faire des tas de choses plus avancées, comme par exemple lancer automatiquement ce daemon au démarrage de la machine, mais dans mon cas, j'ai préféré faire simple (et relancer à la main en cas d'arrêt du serveur. C'est un portable, avec une batterie, donc ça ne devrait pas arriver trop souvent).
Je vous laisse consulter la documentation officielle pour les questions supplémentaires.
Une chose importante, quand même : bien que le daemon soit lancé, il n'exporte pas automatiquement tous les dépôts contenus dans le répertoire concerné. Il faut préciser que les dépôts sont publics en créant, dans le répertoire concerné, un fichier « git-daemon-export-ok » doit exister (à la racine du dépôt si c'est un dépôt bare, dans le répertoire .git sinon).
Vous pouvez contourner ça en passant le paramètre « --export-all
» au lancement du daemon », mais en ce qui me concerne, je préfère laisser comme ça ; ça me permet d'avoir des dépôts publics et d'autres privés.
Modifié le 05/02/2013 à 19h 45m 35
Mise à jour :
Afin de s'assurer que les autres utilisateurs aient bien la possibilité de modifier le dépôt, il faut leur donner les droits en écriture dessus.
Pour ça, git se débrouille pour gérer tout seul la première méthode, si on lui passe l'option --shared=group
lors de l'initialisation du dépôt.
Pensez bien à faire ça dès l'initialisation du dépôt, par contre, c'est plus simple que de rerégler ça après coup.