Installer un serveur Git sur Synology

Git Server : Installer un serveur Git sur Synology

Ce billet résume la démarche à suivre pour installer un serveur Git sur Synology. Les utilisateurs autorisés pourront s'y connecter de façon transparente grâce aux clés SSH. Voilà maintenant deux ans que j'utilise GIT et je profite de ce billet pour clamer haut et fort : non, GIT n'est pas simple ! Les concepts de base se prennent rapidement en main mais plus on en apprend, plus ou découvre de nouvelles commandes subtiles qui laisse entrevoir différentes stratégies de gestion de sources. J'espère aborder cela dans les prochains billets 🙂

Installer un serveur Git sur Synology

Commençons par installer le package Git Server sur notre NAS. Ce package est fournit par le dépôt officiel de Synology. La configuration se résume à lister les futures utilisateurs autorisés à se connecter au serveur mais attention il y a une subtilité : si vous choisissez un utilisateur ayant déjà les droits de se connecter en ssh, vous devrez mettre à jour un fichier de configuration supplémentaire. En effet, pour des raisons de sécurité (ou par manque de souplesse de configuration du package de Synology) son shell sera modifié dans le fichier /etc/passwd.

Git Server utilisateurs : Installer un serveur Git sur Synology

Supposons que vous choisissiez l'utilisateur baruser et que celui-ci pouvait auparavant se connecter en ssh. Après l'avoir ajouté avec l'IHM ci-dessus de Git Server, vous constaterez que dans le fichier /etc/passwd son shell à changé :

baruser:x:1026:100:Foo:/var/services/homes/baruser:/var/packages/Git/target/bin/git-shell

Vous devez le remodifier avec /bin/sh (ou tout autre shell disponible sur votre plateforme) :

baruser:x:1026:100:Foo:/var/services/homes/baruser:/bin/sh

Autrement, l'utilisateur ne pourra plus se connecter librement en ssh et observera le message suivant à la connexion : fatal: Interactive git shell is not enabled. Si vous souhaitez justement que votre utilisateur ne puisse pas se connecter librement en ssh, ne modifier pas le fichier /etc/passwd et ajouter les fichiers de configuration qui listeront les commandes git autorisées (et uniquement celles-ci).

Création d’un répertoire partagé

L'étape suivante consiste à créer un dossier qui contiendra notre dépôt coté serveur. Pour rester dans la philosophie de Synology, le mieux est de créer un répertoire partagé : panneau de configuration > dossier partagé > créer. Il sera ainsi directement accessible depuis l'arborescence de File Station. Pour l'exemple, nous prendrons comme nom "git". L'idée est de ranger ici l'ensemble de nos dépôts distants. Pensez à donner les droits en r/w aux utilisateurs concernés pour chaque dépôt.

Création d’un dépôt coté serveur (repository)

Vous devez maintenant vous connecter en ssh avec un compte administrateur, passer en root avec sudo -i, puis créer un premier dépôt, nommé prog pour cet exemple. Le repository sera alors créé et visible dans File Station sous le répertoire /volume1/git/prog.git

git init --bare --shared /volume1/git/prog.git
Initialized empty shared Git repository in /volume1/git/test.git/

Pensez à mettre à jour les droits utilisateurs sur le dépôt (via l'IHM, pas en mode console).

Vérification de votre client

Chaque client git doit être identifié, n'oubliez donc pas de vérifier votre identité via le fichier .gitconfig normalement dans votre répertoire home. Ce fichier peut contenir également bien d'autres paramètres spécifiques à l'utilisateur.

Vous pouvez mettre à jour ce fichier de configuration directement en ligne de commande :

git config --global user.name "foobar"
git config --global user.email "foo.bar@gmail.com"

Pour une configuration beaucoup plus avancée, je vous invite à découvrir ce fichier de config :

Clone d’un dépôt coté client

Sur votre poste client, se rendre dans le répertoire qui contiendra le clone du dépôt serveur. Sous Windows, pour le mode console Git Bash est certainement la meilleure option. Il en existe d'autres, notamment des clients disposants d'une interface graphique.

git clone foobar@192.168.0.xx:/volume1/git/prog.git
Cloning into 'prog'...
The authenticity of host '192.168.0.xx (192.168.0.xx)' can't be established.
ECDSA key fingerprint is SHA256:VxgyoNhxVu9j+VrF9FFthuN9eZvVrZknOlhOGV3Obl4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.xx' (ECDSA) to the list of known hosts.
foo@192.168.0.xx's password:
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
ls -l
drwxr-xr-x 1 Foobar 197121 0 avr. 6 15:10 prog/

Nous n'avons pas encore configuré les clés ssh, il est donc normal que le mot de passe de l'utilisateur nous soit demandé. A noter que le protocole n'est pas précisé, c'est par défaut ssh.

Test de bon fonctionnement

Histoire de vérifier que tout fonctionne bien, créez un fichier hello.txt sur votre poste en local :

pwd
/c/demo/GIT_SYNO_REPO/prog
echo Hello > hello.txt
git status
On branch master
Initial commit
Untracked files:
(use "git add ..." to include in what will be committed)
hello.txt
nothing added to commit but untracked files present (use "git add" to track)

La commande git status nous montre que ce fichier n'appartient pas au dépôt local, il faut donc l'ajouter.

git add hello.txt
git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: hello.txt

La commande git status nous montre cette fois ci que le fichier est connu mais pas encore synchronisé avec le repo local, il faut donc le commit grâce à la commande git commit (qui synchronisera l'ensemble des fichiers et répertoires en attente de synchronisation, ici un seul fichier donc)

git commit -m "Ceci est le message du commit du fichier hello.txt"
[master (root-commit) dce6a30] Commit du fichier hello.txt
1 file changed, 1 insertion(+)
create mode 100644 hello.txt
git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working directory clean

Cette fois-ci, tous nos fichiers de travail sont synchronisés avec notre dépot local et celui-ci est en avance d'un commit par rapport au dépot distant (où plus précisément par rapport à l'image du dépôt distant qui est en fait en local et qui peut être mis à jour avec git fetch). Pour mettre à jour le repo distant :

git push origin master # Ou 'git push'
foo@192.168.0.xx's password:
Counting objects: 3, done.
Writing objects: 100% (3/3), 233 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To foo@192.168.0.xx:/volume1/git/prog.git
* [new branch] master -> master
git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Notre dépôt local est enfin synchronisé avec notre dépôt distant, tout fonctionne bien !

Configuration des clés SSH

De toute évidence, imposer aux utilisateurs de taper leur mot de passe à chaque échange avec le serveur n'est pas pratique. La solution la plus courante est de passer par les clés SSH qui serviront à l'authentification de façon automatique.

Dans en premier temps il faut mettre à jour la configuration ssh sur notre Synology :

  • éditer le fichier /etc/ssh/sshd_config, s'assurer que les éléments ci-dessous ne soient pas commentés.

  • redémarrer le service ssh : synoservicectl --restart sshd

Concernant la génération des clés, pour les utilisateurs Mac et Linux, il me semble inutile de détailler cette partie. En revanche, pour les utilisateurs Windows utilisant Putty, une petite subtilité m'ayant fait perdre du temps, je partage les actions à mener exactement.

  • Créer un répertoire .ssh dans votre home (C:\Users\<nom_utilisateur\.ssh)
  • Lancer Git Bash, exécuter ssh-keygen.exe et générer les clés privée et publique (pas de passphrase dans un premier temps)
  • Télécharger PuttyGen, charger la clé privée (format open-ssh) et sauvegarder une nouvelle clé privée (format Putty .ppk) dans le repertoire .ssh
  • La subtilité : sélectionner et copier directement la clé publique depuis l'interface PuttyGen !
  • Coller cette clé sur le serveur, dans le fichier authorized_keys (dans le répertoire .ssh du home de l'utilisateur, à créer si n'existe pas)
  • Vérifier les droits : 700 pour le dossier .ssh, 600 pour authorized_keys, avec le owner votre utilisateur (si trop permissif ssh refusera d'utiliser les clés)
  • Configurer une session Putty en mettant votre login directement et votre clé privée .ppk
  • Tester de vous connecter : aucun mot de passe ne devrait vous être demandé

Concernant la subtilité, j'ai en effet naïvement pensé qu'en prenant la clé publique à partir du fichier généré par ssh-keygen je n'aurais pas de problème. Et pourtant... j'avoue ne pas forcément bien comprendre car la seule différence entre les deux clés publiques c'est un commentaire ! Toujours est-il qui si vous copiez la clé publique générée par ssh-keygen vous aurez le message d'erreur : Server refused our key. Visiblement la clé privée générée avec Putty ne fonctionne qu'avec la clé publique disponible dans l'interface.

Si vous voulez plus de sécurité vous pouvez mettre une passphrase mais alors un mot de passe sera demandé et il faudra soit installer un ssh-agent pour vous évitez de retaper le mot de passe soit ajouter quelques options de paramétrage dans votre .gitconfig. Si vous avez confiance sur le fait que personne ne volera votre clé privé vous pouvez laisser la passphrase vide.

Une fois cette étape validée, git ne devrait plus nous demander notre mot de passe !

git pull origin master
The authenticity of host '192.168.0.XX (192.168.0.XX)' can't be established.
ECDSA key fingerprint is SHA256:VxgyoNhxVu9j+VrF9FFthuN9eZvTrZknOlhOGV3Obl4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.0.XX' (ECDSA) to the list of known hosts.
From ssh://192.168.0.XX:/volume1/git/prog
* branch            master     -> FETCH_HEAD
Already up-to-date.

Si vous tombez sur le message key_load_public: invalid format, relisez bien la procédure ci-dessus 😉

J'espère que cet article vous a aidé, installer un serveur Git sur Synology vous permettra de ne plus dépendre de Github d'une part et de vous lancer dans la mise en place d'un vrai process d'entreprise. Prochaine étape : Jenkins !

C'est avec grand plaisir que je lirai et répondrai à vos commentaires !

Installer un serveur Git sur Synology

3 réponses

  1. Merci pour cet article.
    Je suis, moi même, sur le point d’acheter un synology pour pouvoir mettre en ligne les sites et applications web que je réalise et tester différents déploiements de technologies (java,node.js)
    Je l’ajoute dans mon bookmark en attendant.

  2. Bon choix, Synology c’est bien 🙂 Les packages node.js v4 et java 8 sont dispo, et globalement avec Docker maintenant c’est la porte ouverte à installer tout ce que l’on veut ! Je viens de voir que le package Gitlab offciel était en fait une image docker justement.

  3. Bon, je déconseille GitLab sur Syno, ça sent le sapin xD En résumé, il y a des fuites mémoires avec Ruby et c’est difficile de bien paramétrer le conteneur Docker, j’ai posté sur le forum syno (https://forum.synology.com/enu/viewtopic.php?f=258&t=100502&start=15) mais toujours pas de réponse. A mon avis, un Bitbucket (utilisant Tomcat) sera tout aussi bien !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *