Journal Serveur Git avec Gitolite

Posté par  . Licence CC By‑SA.
Étiquettes :
30
29
mai
2017

Sommaire

Bonjour 'nal

La semaine dernière, j'ai eu l'occasion de jouer un peu avec un outil fort sympathique: Gitolite. Il permet de transformer un ordinateur avec un serveur SSH en serveur Git et de gérer les accès de plusieurs développeurs sur plusieurs dépôts Git.

Contexte

Git est un excellent gestionnaire de version.
L'un de ses points forts est de permettre de travailler de façon non centralisée. Chaque développeur possède une copie locale du dépôt et peut y faire des commits sans être connecté à un serveur. Pour échanger ses modifications avec d'autres développeurs, il est possible d'envoyer ces dernières par e-mail. Git possède des options pour exporter ses commits (ou des branches entières) avant envoi et de les réimporter à leur réception.

Mais si envoyer ses modifications par e-mail fonctionne bien pour des contributions intermittentes, cette méthode devient lourde quand on travaille en équipe et qu'on apporte beaucoup de modifications à son code.
Par chance, il suffit aux développeurs d'avoir un accès SSH commun à un ordinateur et d'y installer Git pour pouvoir s'en servir comme "serveur de référence". Chacune et chacun peut y "pousser" ses modifications et "tirer" celles des autres.

Mais la solution ci-dessus amène son lot de problèmes: Comment gérer la création de dépôts? Comment gérer les droits d'accès? Comment éviter de donner l'accès à un shell à tout le monde? C'est à ces questions que Gitolite répond. Et plutôt bien.

Installation de Gitolite

Cette opération se fait en deux étapes:

  • Installer de paquet Gitolite
  • Configurer un compte utilisateur sur le serveur pour accueillir Gitolite

Pour la première étape, si vous êtes sur Fedora, tapez la commande:

sudo dnf install -y gitolite3

Si vous êtes sur CentOS avec le dépôt EPEL installé, préférez:

sudo yum install -y gitolite3

Et si vous êtes sur Debian, tapez la commande:

sudo apt-get install gitolite3

Pour la seconde étape, on va commencer par créer un utilisateur qui va accueillir les dépôts Git:

sudo useradd git

Ensuite, on copie la clé SSH publique de l'administrateur de Gitolite dans le dossier home de ce nouveau compte:

sudo install -o git -g git </chemin/vers/ma/clé.pub> /home/git/<utilisateur>.pub

Remplacez </chemin/vers/ma/clé.pub> par le chemin vers votre clé publique et <utilisateur> par votre nom utilisateur

Avant dernière action, lancez la configuration de Gitolite pour l'utilisateur git:

sudo -u git gitolite setup -pk /home/git/<utilisateur>.pub

Enfin, supprimez la clé SSH publique qui n'est plus nécessaire:

sudo rm /home/git/<utilisateur>.pub

Pour tester si l'installation s'est bien passée, il faut un compte utilisateur possédant la clé SSH privée liée à la clé publique utilisée plus haut. Depuis ce compte, exécutez la commande:

ssh git@<mon_serveur> info

Où <mon_serveur> sera l'adresse de l'ordinateur hébergeant Gitolite.

Vous devriez avoir la réponse suivante:

hello user, this is git@my_server running gitolite3 on git 2.9.4

R W  gitolite-admin
R W  testing

C'est fait, vous avez un Gitolite tout frais et fonctionnel.

Administration

Toute la configuration de Gitolite se passe depuis le dépôt gitolit-admin de votre installation.

Pour commencer, clonez le:

git clone git@<mon_serveur>:gitolite-admin

(N'oubliez pas de remplacer <mon_serveur> par l'adresse du vôtre)

Dans le dépôt fraîchement cloné, on retrouve cette arborescence:

gitolite-admin/
├── conf
│   └── gitolite.conf
└── keydir
    └── bob.pub

Dans le dossier keydir se trouve la clé SSH publique de toutes celles et ceux qui auront accès à votre serveur Gitolite. Le nom de ces fichiers est important. Il suit la forme utilisateur.pub.
L'utilisateur indiqué dans le nom du fichier sera repris dans la configuration des dépôts git et de leurs politiques d'accès.

Dans le fichier gitolite.conf se trouve la liste des dépôts ainsi que leurs règles d'accès.

La syntaxe du fichier gitolite.conf ressemble à ceci:

repo gitolite-admin
    RW+     =   bob

repo george
    RW+     =   bob
    R       =   alice

Pour chaque dépôt on retrouve le mot clé repo suivit du nom du dépôt.
Les lignes qui suivent indiquent une règle d'accès associé à un nom d'utilisateur.

Les règles d'accès peuvent être:

  • R: Accès en lecture (clone, fetch, …)
  • W: Accès en écriture (push)
  • +: Opérations de correction (rewinds ou deletes)

D'autres règles d'accès peuvent être trouvées sur le manuel officiel.

Il est possible de créer des groupes d'utilisateurs ou de dépôts avec la syntaxe:

@staff              =   bob alice

Vous pouvez ensuite utiliser ce groupe dans votre configuration en invoquant son nom (par exemple @staff). Mais évitez de prononcer ce nom trois fois.

N'oubliez pas de "commiter" vos changements et de les pousser pour qu'ils soient pris en compte par Gitolite.

Utilisation

Chaque utilisateur ayant accès à votre serveur Gitolite peut savoir à quels dépôts il a accès et ce qu'il a le droit d'y faire. Pour cela, il lui suffit d'exécuter depuis son terminal:

ssh git@<mon_serveur> info

Voici un exemple de ce qu'il peut recevoir en réponse:

hello bob, this is git@my_server running gitolite3 on git 2.9.4

R W  gitolite-admin
R W  george

Ensuite, il suffit au développeur de cloner le dépôt dont il a besoin, de "commiter" puis de pousser ses changements.

L'URL d'un dépôt ressemble à ceci: git@mon_server:mon_dépôt

Essayons, par exemple, de cloner george:

git clone git@mon_serveur:george

Voilà, reste plus qu'à se mettre au boulot.

Aller plus loin

Quelques liens utiles:

  • # hors sujet

    Posté par  . Évalué à 3. Dernière modification le 29 mai 2017 à 22:39.

    Je m’apprête à lire ce journal qui a l’air très intéressant mais si un modo peut corriger la faute qui se trouve à la première ligne et qui fait très mal…

  • # Fossil = github tout en un

    Posté par  . Évalué à 5.

    Et moi je suis impressionné par une récente découverte, Fossil.

    Fossil =

    • DVCS
    • gestionnaire de tickets intégré et versionné,
    • wiki (intégré et versionné),
    • notes techniques (doc marquée dans le temps),
    • interface web,
    • un simple exécutable, donc super facile à héberger,
    • tout dans une seule base SQLite

    Par le développeur de SQLite (pour le projet SQLite).

    • [^] # Re: Fossil = github tout en un

      Posté par  . Évalué à 5. Dernière modification le 29 mai 2017 à 23:07.

      J'aime aussi bien son interface très simple, je trouve juste dommage que les devs ne l'ont pas lié à GIT par exemple, plutôt que d'utiliser leur propre système, sinon, je l'aurais de suite adopté.

      • [^] # Re: Fossil = github tout en un

        Posté par  . Évalué à 4.

        je trouve juste dommage que les devs ne l'ont pas lié à GIT par exemple, plutôt que d'utiliser leur propre système

        Si tu lis l’anglais, lis le comparatif du troisième lien du commentaire, tu devrais comprendre pourquoi ce n’est en rien « dommage », ce sont deux visions parfaitement opposées du développement logiciel.

        Si je comprends bien ce ne sont rien d’autre que les auteurs de SQLite qui ont développé Fossil… pour le développement de SQLite… donc pourquoi ne pas utiliser… SQLite :)

    • [^] # Re: Fossil = github tout en un

      Posté par  . Évalué à 4.

      Super le comparatif ! J’ai bien aimé :

      One commentator has mused that Git records history according to the victors, whereas Fossil records history as it actually happened.

    • [^] # Re: Fossil = github tout en un

      Posté par  . Évalué à 7.

      Tu compares 2 outils radicalement différents: un gestionnaire de version et une forge logicielle complète, qui n'a besoin d'aucun autre outil.
      Les deux ont leur intérêt, honnêtement.

      • [^] # Re: Fossil = github tout en un

        Posté par  . Évalué à 5.

        Non, Fossil est bien comparable à Git, puisque c'est un gestionnaire de version décentralisé. Il se trouve que Fossil intègre beaucoup plus de choses à cette notion, ce qui le rapproche en effet d'une forge logicielle décentralisée, mais on a typiquement un seul projet sur Fossil.

        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

  • # et sans (trop de) dépendances en plus!

    Posté par  . Évalué à 6.

    Merci pour la découverte, vraiment!

    D'habitude, ce type d'outils est blindé de dépendances, ou alors il faut des forges complètes… qui ne s'utilisent donc pas en ligne de commande (ou alors, c'est pas fréquent/connu, après tout, je me considère pas expert).

    Ici, il n'y a que git (logique), ssh-server (idem), et perl… le dernier était de toute façon installé sur tous les systèmes que j'ai vus, et, contrairement à python, installer (sur Debian) le paquet perl ne tire pas une chiée de paquets "obligatoirement recommandés" si je puis dire.
    Accessoirement, git (sur Debian) dépends de perl de toute façon…

    Probable que je vais adopter, même pour quand je suis seul à taffer: après tout, ça permets de se faire son propre serveur sans se galérer à aller sur un serveur pour jouer au clonage inversé… Merci donc.

  • # étape suivante: gitlab

    Posté par  . Évalué à 4.

    Gitolite est vraiment un outil intéressant car il est facile à utiliser et à installer. Mais en pratique, il lui manque beaucoup trop de fonctionnalités (par exemple les Merge Request), et on finit par le remplacer par gitlab, qui est bien plus complet.

    • [^] # Re: étape suivante: gitlab

      Posté par  (Mastodon) . Évalué à 2.

      Ou Gitea (ou Gogs), qui a l'avantage d'être bien plus léger que Gitlab…

    • [^] # Re: étape suivante: gitlab

      Posté par  . Évalué à 3.

      Au boulot, j'ai installé Redmine et Gitolite. Et dans Redmine je peux afficher les dépôts, fermer les demandes selon les messages de commit, etc.

      Ça reste moins sympa que Github/Gitlab mais ça marche. Et ça me permet d'avoir des projets Redmine sans dépôt associé, pour des projets qui ne sont pas du code, pour utiliser jute la gestion de tickets, roadmap et tout. Je sais pas si c'est possible dans Gitlab. J'imagine qu'on peut toujours ne pas utiliser le dépôt, mais c'est peut-être pas naturel à présenter à un partenaire non développeur, question interface.

      Et Gitolite et Redmine sont dans Jessie alors que pour Gitlab, il faut attendre Stretch pour avoir un paquet.

      Si je devais faire le choix aujourd'hui et si Gitlab était dans Debian stable, je pense que je prendrais Gitlab.

    • [^] # Re: étape suivante: gitlab

      Posté par  . Évalué à 3.

      Mais gitolite ne nécessite pas de navigateur web pour être utilisé. Pour moi, c'est un putain de bon point.

  • # Gogs, cgit

    Posté par  (site web personnel) . Évalué à 1.

    Gitlab, ca consomme de trop en CPU/RAM, j'ai fait tourne cgit sur un routeur mips sous openwrt, c'etait relativement rapide pour peu que les repos etaient sur un disque dur en USB.

    Autrelent, Gogs en Go a l'air aussi rapide.

  • # gitblit

    Posté par  (site web personnel) . Évalué à 1.

    tres leger

    juste un jar et 1 ficher de config et ca gere le ldap, le kerberos, l authent , le ssh …..
    et un interface rustique mais plus sympa que les git de base, moins bien que gitlab, mais gitblit garde le format git donc un rsync et on a tout :)

  • # Patch

    Posté par  (site web personnel) . Évalué à 2.

    Je rejoins les avis exprimés : D’une part ça fonctionne très bien ; il manque l’accès anonyme, mais c’est contournable par la diffusion d’une clef « privée » dédiée à l’accès anonyme. D’autre part, c’est un peu limité, notamment pour ce qui est du feedback communautaire, et je vais prochainement basculer vers Gitea.

    Avec Debian Jessie, pour que ça fonctionne pour moi, j’ai du modifier le fichier /usr/share/gitolite3/triggers/post-compile/ssh-authkeys, à la ligne 118 :

    118c118
<     _die "fingerprinting failed for '$f'" unless $fp =~ /([0-9a-f][0-9a-f](:[0-9a-f][0-9a-f])+)/;
---
>     _die "fingerprinting failed for '$f'" unless $fp =~ /([0-9a-f][0-9a-f](:[0-9a-f][0-9a-f])+)/ or $fp =~ m(SHA256:([A-ZA-z0-9+/]+));

    Ceci apparemment à cause d’un changement de format des clefs OpenSSH :
    https://github.com/sitaramc/gitolite/commit/ed807a40c6683960e357bc995b3acf721ec088b4

    • [^] # Re: Patch

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Si je me souviens bien, le projet gitolite laisse l'outil git-daemon gérer les accès anonyme. Il fallait coordonner les droits de lecture des répertoires entre les deux outils.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.