Le gain apporté par les gestionnaires de configuration distribués n’est plus à démontrer. Dans ce domaine, les projets libres montrent la voie, et en utilisent presque tous un, que ce soit Git, Mercurial, etc.

Cela fait maintenant quelques temps que je teste Git, y compris au travail en interface avec SVN, notre gestionnaire de configuration d’entreprise.

Pour aller plus loin dans cette utilisation, il fallait envisager de remplacer (ou de doubler) le serveur SVN central par un repository Git central (« bare repository« ). La contrainte imposée par mon administrateur système préféré étant d’avoir le même système de gestion des droits d’accès, centralisé sur notre serveur LDAP (où chaque projet est associé à un groupe d’utilisateurs).

Voici différentes pistes que nous avons envisagées pour ce faire :

Utiliser un hébergement dédié

Une première solution est d’externaliser l’hébergement des sources des projets (sur GitHub par exemple). Pour avoir des dépôts privés, la solution payante. Nous ne souhaitons pas externaliser la gestion des sources, et cette solution ne s’interface pas avec LDAP. Elle a été écartée d’office, mais peut être intéressante.

Gitosis ou Gitolite

Ces deux outils sont basés sur le même principe :

  • le serveur connaît les clés SSH publiques des utilisateurs autorisés
  • à la connexion de l’utilisateur, le serveur vérifie si la machine se connectant correspond à une de ces clés : si oui, on lui associe les droits correspondants sur les différents dépôts hébergés

Cette approche est intéressante, et elle a le mérite d’éviter d’avoir à saisir un login/mot de passe : l’identification et la gestion des droits est transparente côté utilisateur (dès lors que les clés SSH sont correctement configurées sur sa machine).

Pour les détails de mise en oeuvre, je vous renvoie à ce tutoriel complet.

Malgré l’intérêt et la facilité de mise en oeuvre, elle est également écartée car elle ne répond malheureusement pas au cahier des charges : elle ne peut être facilement couplée à un serveur LDAP, ce qui oblige dans notre cas à gérer les droits et les clés SSH de manière séparée.

Droits du système

Une autre approche est d’utiliser les droits du système (à base d’Unix) :

  • chaque projet est accessible en lecture/écriture au groupe, et en lecture seule (ou non accessible) aux autres
  • les membres du projets sont également membres du groupe Unix correspondant, ce qui leur permet de faire des mises à jour du dépôt

Ce système peut partiellement être couplé avec le serveur LDAP pour l’identification, au moyen de systèmes comme PAM LDAP. Ce système a cependant des défauts :

  • ce mécanisme est assez complexe à mettre en oeuvre (en particulier pour synchroniser à la fois les utilisateurs et les groupes avec le serveur LDAP)
  • il offre moins de souplesse de configuration : pour un même projet, on ne peut avoir en même temps des utilisateurs identifiés ayant les droits en lecture/écriture, en lecture seule, et sans aucun droit sur le projet

Par ailleurs, il ne permet l’accès extérieur que si on ouvre les accès SSH sur internet (ce que nous voulons éviter, même dans la DMZ).

Présentation des dépôts par un serveur web

Cette idée nous est venue de ce chapitre du livre ProGit. En particulier, il explique que depuis Git 1.6.6, il est possible d’utiliser des scripts CGI pour accélérer le traitement des requêtes et « émuler » le comportement du protocole « git:// » et ainsi ne pas trop perdre en performances à cause de la couche http(s).

Concernant notre problématique de gestion des droits avec LDAP, elle est automatiquement résolue par la possibilité des serveurs Apache de gérer l’identification grâce à LDAP.

Pour ceux qui seraient tentés par l’aventure, voici la configuration expliquée de « git.conf » que nous ajoutons à la configuration de notre serveur Apache 2 (qu’il faut bien évidemment adapter à vos besoins) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# Variables d'environnement pour Git
SetEnv GIT_PROJECT_ROOT /home/git/repositories
SetEnv GIT_HTTP_EXPORT_ALL
 
# Déclaration du VirtualHost Git
<VirtualHost git.courtine.org>
    DocumentRoot /home/git/repositories
    ServerName git.courtine.org
    ErrorLog /var/log/httpd/git.error.log
    LogLevel warn
    CustomLog /var/log/httpd/git.access.log combined
    ServerSignature On
    SSLEngine off
    Options Indexes FollowSymLinks MultiViews
 
    # Scripts CGI de git
    ScriptAlias / /usr/libexec/git-core/git-http-backend/
 
    # Dès la racine du serveur Git, on demande au minimum un utilisateur valide
    <Location "/">
        AuthBasicProvider ldap # Identification déléguée à LDAP
        AuthType Basic
        AuthzLDAPAuthoritative on # Autorisation d'accès uniquement par LDAP
        AuthName "Git server"
        AuthLDAPURL "ldap://ldap.courtine.org:389/CN=users,DC=courtine,DC=org" NONE # Adresse (et filtre) du serveur LDAP
        AuthLDAPBindDN "CN=git,CN=users,DC=courtine,DC=org" # Utilisateur effectuant les recherches dans l'annuaire
        AuthLDAPBindPassword gitPassword # Mot de passe de cet utilisateur
        require valid-user # Obligation d'identification valide
        Order deny,allow
        allow from 192.168.0 # Obligation de connexion depuis le réseau local
    </Location>
 
    # Les droits peuvent être restreints pour chaque dépôt (obligation d'appartenir à un groupe)
    <Location "/projet.git">
        require ldap-group CN=Groupe projet,OU=projets,DC=courtine,DC=org
    </Location>
</VirtualHost>

Conclusion

Ce système présente de nombreux avantages, et c’est pourquoi nous l’avons adopté :

  • Il est complètement intégré au SI, l’identification et la gestion des droits sur les dépôts étant intégralement confiée au serveur LDAP, ce qui répond complètement au cahier des charges
  • elle permet une gestion complète des droits (lecture seule, lecture/écriture, aucune autorisation)
  • elle peut être ouverte sur internet si on a besoin d’un accès externe, via un proxy http dans la DMZ (le https étant recommandé pour des raisons évidentes de sécurité), sans ouvrir d’autre protocole que le http(s)

Pour tordre le cou aux idée reçues, avec le « git http backend« , les benchmarks que j’ai effectués n’ont pas montré de différence flagrante de débit entre « git+ssh:// » et « https:// » (tests évidemment effectués pour un même dépôt, et sur le même serveur).

A titre d’exemple, le clonage complet d’un projet qui compte plus de 1800 commits pour 17 Mo de sources (librairies exclues) via « http:// » prend 25 secondes. Par pudeur, je tairai le temps que met SVN à récupérer le dernier commit uniquement du « trunk » de ce même projet…

Enfin, avec Git, on évite enfin définitivement ce genre de choses

Gitorious

[Mise à jour le 24/11/2010] Sur la suggestion d’Olivier Lamy, je rajoute Gitorious.

C’est un autre hébergeur de dépôt Git, basé sur le même principe que GitHub (hébergement gratuit des projets Open Source). Mais Gitorious est également lui-même un projet Open Source, développé en Ruby on Rails que l’on peut installer dans son système d’information. Voici un tutoriel complet sur cette possibilité.

N’ayant pas testé, je ne sais pas ce que donne cette solution par rapport à notre problématique initiale de couplage LDAP, mais l’interface de gestion de cette application web est très agréable.