Taper ces quelques mots chaque matin n’est pas vraiment la mer à boire, mais c’est en revanche déjà plus pénible de devoir le refaire 15 fois dans la journée, lorsque surviennent des coupures réseaux qui me font perdre ma session…

J’ai décidé ce matin, de trouver une solution simple et légère pour palier le problème.

La solution

L’idée est toute bête : à chaque changement de répertoire, je stocke le nouveau répertoire courant dans un fichier à la racine de mon “home-directory”. À l’ouverture de session, je lis ce fichier s’il existe et change le répertoire courant en conséquence.

Réalisation

La réalisation se divise en deux étapes :

1. L’écriture de deux scripts simples pour sauvegarder et restaurer le répertoire courant;
2. la redéfinition de la commande “cd” pour qu’elle exécute les scripts précédents.

Les scripts

J’ai choisi de stocker mes scripts personnels dans un répertoire nommé “bin“, à la racine de mon “home”. Vous pouvez bien évidemment les mettre où bon vous semble.

Le premier script se nomme savepwd.sh, et voici son contenu :

#!/bin/bash

\cd $2
echo $PWD > ~/.savedpwd

Rien de fou ici : on change le répertoire (on préfixe cd par un antislash pour éviter d’appeler un éventuel alias; ce qui tombe bien puisque c’est ce qu’on va faire dans la deuxième partie) et on inscrit dans le fichier ~/.savedpwd le répertoire courant après changement.

On spécifie $2 pour une raison que nous verrons plus tard.

Le deuxième script se nomme loadpwd.sh et contient les lignes suivantes :

#!/bin/bash

PWDFILE=`eval ls ~/.savedpwd 2>/dev/null`

if [ -e "$PWDFILE" ]
then
        RESTORED_PWD=`cat $PWDFILE`
        \cd $RESTORED_PWD
fi

Encore une fois, rien de spécial : on teste l’existence du fichier ~/.savedpwd, et s’il existe, on remplace le répertoire courant par celui qui y est inscrit.

Les alias

Modifions maintenant le script de démarrage de session, dans mon cas il s’agit du fichier ~/.bashrc, et ajoutons les lignes suivantes :

# Restore/Save current working directory on open/close
alias cd='. ~/bin/savepwd.sh dummy'
. ~/bin/loadpwd.sh

On remplace simplement la commande “cd” par un appel au script ~/bin/savedpwd.sh et on fait un appel à ~/bin/loadpwd.sh lors du premier chargement du script.

Vous vous posez certainement la question, pourquoi ce paramètre “dummy” ? Tout simplement, si on utilisait le premier paramètre ($1) on a un bogue dans le cas où l’appelant a fait un appel à set dans sa console, et quand on appelle cd sans paramètres : en effet, set définit $1 dans la console actuelle, et devient la valeur par défaut quand le script est appelé sans paramètre.

En faisant par exemple :

$ set toto
$ cd

Au lieu de retourner à la racine du “home-directory”, on se retrouve dans le répertoire “toto“, s’il existe. En ajoutant le paramètre “dummy“, on empêche le problème de se produire en s’assurant qu’aucun paramètre par défaut n’est appelé lors de l’invocation de ~/bin/savepwd.sh.

C’est fini !

Ça y est, vous pouvez relancer votre session pour prendre en compte les modifications : dès que vous changerez de répertoire courant, celui-ci sera sauvé puis restauré lors de la prochaine ouverture de session !

J’espère en tout cas que cette astuce pourra vous servir ! N’hésitez pas à me suggérer des améliorations ou d’éventuels problèmes (sécurité, utilisation) liés à ces scripts. Bon code !

Démarrage

Nous partirons du principe que vous avec un Linux moderne (j’utilise Debian, mais la démarche devrait être similaire sur n’importe quelle autre distribution).

Installez tout d’abord les paquets nécessaires :

$ apt-get install git-core apache2

Vérifiez ensuite que git est installé :

$ git --version
git version 1.5.6.5

Si vous obtenez une sortie similaire, c’est que Git est bien installé.

Création du dépôt

Nous allons commencer par attribuer un répertoire à nos futurs dépôts Git. J’ai personnellement choisi “/home/git” mais libre à vous de choisir autre chose. Notez simplement ce chemin, car nous allons y faire référence quelques fois dans les prochaines étapes.

Tapez les commandes suivantes :

$ mkdir -p /home/git/repositories
$ chown -R www-data: /home/git

Où www-data est le nom du user sous lequel tourne le démon apache.

Nous placerons tous les dépôts Git dans le répertoire /home/git/repositories. Dans notre exemple, nous créons un dépôt nommé “depot.git” :

$ cd /home/git/repositories
$ mkdir depot.git
$ cd depot.git
$ git init --bare
$ git update-server-info

La commande “git init --bare” créé un dépôt Git “bare”, c’est à dire un dépôt qui ne possède pas de copie de travail : c’est un dépôt de “stockage” uniquement; vous n’y ferez jamais de commit mais seulement des “push” ou des “pull”.

La commande “git update-server-info” met à jour les données du serveur dans le dépôt, pour lui permettre d’être accédé à distance.

Vous devrez répéter cette dernière étape pour chaque dépôt que vous souhaiterez créer. Notez que vous pouvez également créer une arborescence de répertoires pour organiser plus finement les dépôts.

Paramétrage d’Apache

Nous devons ensuite informer Apache de la présence de nos dépôts Git. Pour ce faire, nous créons un fichier nommé “git” dans le répertoire “/etc/apache2/sites-available” qui contient les paramètres suivants :

Alias /git/ "/home/git/repositories/"

<Directory /home/git/repositories>
        DAV on
        Options Indexes FollowSymLinks MultiViews
        AllowOverride None
        Order allow,deny
        allow from all
        AuthType Basic
        AuthName "Git"
        AuthUserFile /home/git/passwd
        Require valid-user
</Directory>

Nous définissons une authentification de type “identifiant/mot de passe” mais libre à vous de choisir une autre méthode d’authentification.

Nous supposons ici que le serveur apache possède déjà au moins un “virtual host”. Si vous souhaitez par exemple limiter l’accès à un “virtual host” en particulier (utile dans le cas où l’on souhaite forcer le passage en HTTPS par exemple), il suffit d’imbriquer le code ci-dessus dans la déclaration de ce “virtual host”.

Lorsqu’une personne tentera d’accéder au sous répertoire “/git/” de notre serveur web, elle devra saisir un identifiant et un mot de passe ayant été renseigné dans le fichier “/home/git/passwd“.

Créons maintenant ce fichier grâce à la commande suivante :

$ htpasswd -c /home/git/passwd <login utilisateur>

Le programme vous invite à saisir un mot de passe pour votre utilisateur. Créez autant d’utilisateurs que vous le souhaitez à l’aide de la même commande (omettez le paramètre “-c” lors des fois suivantes).

Vérifiez que l’utilisateur www-data ait accès à ce fichier, uniquement en lecture.

Vous n’avez plus qu’à activer le site, les modules dav et dav_fs puis à redémarrer apache pour mettre en ligne le dépôt :

$ a2ensite git
$ a2enmod dav
$ a2enmod dav_fs
$ /etc/init.d/apache2 restart

Le dépôt devrait désormais, être accessible.

Un petit test pour la route

Testons l’accès au dépôt depuis un autre poste sur le réseau. Vous pouvez bien évidemment utiliser un poste Windows ou Linux, graphique ou en ligne de commande.

Pour la simplicité de l’exemple (et parce que j’adore ça), nous utiliserons la ligne de commande :

$ git clone http://notre_serveur/git/depot.git

Cette commande devrait réussir et créer un répertoire nommé “depot” dans le répertoire courant.

Ignorez l’avertissement qui dit que le dépôt est vide : cela est tout à fait normal.

Remarque : si vous avez choisi d’héberger votre dépôt en HTTPS, git refusera peut-être de s’y connecter si votre certificat n’est pas signé par une autorité de certification reconnue. Vous pouvez définir la variable d’environnement “GIT_SSL_NO_VERIFY=1” pour ignorer l’erreur temporairement. Ne vous servez évidemment pas de cette variable comme solution à long terme !

Conclusion

La mise en place d’un serveur Git accessible sous Apache est donc plutôt simple. Notre configuration ici est minimale et pourrait encore être améliorée, notamment en permettant une affectation des droits plus précise pour les différents dépôts au sein d’Apache.

Vos recherches sur l’Internet vous auront peut-être conduit à d’autres solutions, utilisant gitosis ou encore ssh. Ces approches proposent d’autres modes d’authentification (par certificat ou en ssh avec un compte sur le système) qui peuvent être très intéressantes mais je n’ai personnellement pas réussi à les faire fonctionner correctement pour l’instant. Si vous avez des ressources à partager à ce sujet, n’hésitez pas à me les transmettre

J’espère en tout cas que cet article vous aura été utile, et comme d’habitude, n’hésitez pas à me faire part de vos commentaires !