Quelques définitions : NFS, SAN et NAS,
Configurer le NAS DS-106e de Synology,
Installer un serveur de boot sur un NAS DS-106e de Synology.
Après avoir décrit les systèmes de gestion de version (VCS) dans un premier article, puis un second, voici le passage à la pratique. Subversion est un VCS centralisé, sucesseur de CVS dont il reprend toutes les fonctions en en corrigeant les principales lacunes.
Cet article suit et complète Configurer le NAS DS-106e de Synology. Il suppose que vous avez suivi les conseils de cet article pour configurer un environnement chrooté sur le NAS, parce que c’est dans cet environnement que vous allez installer votre serveur. Ce serait bien sûr possible dans l’environnement natif, pour lequel il existe un paquet Subversion installable par ipkg, mais il est bien plus confortable de le faire dans un environnement Linux complet (Debian dans mon cas), configurable à volonté.
Se procurer un livre sur Subversion
Si les systèmes de gestion de version sont des logiciels utiles, et même indispensables, ils ne sont pas pour autant faciles à comprendre et simples à utiliser. Se procurer un livre où c’est bien expliqué n’est pas du luxe. Vous pouvez télécharger le Subversion Book sur le site http://svnbook.org/ : il a l’avantage d’être gratuit, l’inconvénient d’être en anglais (traduit chez O’Reilly, mais alors plus gratuit), et personnellement je le trouve assez complet mais plutôt difficile d’accès pour un débutant pas forcément ingénieur système.
Aussi vous conseillerais-je le livre de Mike Manson adapté en français par Isabelle Hurbain : Subversion - Pratique du développement collaboratif avec SVN.
N’oubliez pas non plus de visiter le site officiel de Subversion.
Installer Subversion dans l’environnement chrooté du NAS
La première chose à faire est bien sûr d’installer Subversion, qui dans la Debian dont je dispose vient en deux paquets : subversion et subversion-tools. Ceci fait, il convient de se reporter à l’article précédent pour installer dans l’environnement natif les scripts qui vont permettre, lors d’accès à distance, que le client Subversion de l’utilisateur distant communique avec le serveur Subversion de l’environnement chrooté, et pas avec celui que vous auriez pu installer dans l’environnement natif. Il faut un script pour svn et un pour svnserve, sur le même modèle, il suffit de remplacer svn par svnserve à la ligne 21 :
Choisir un type de serveur : Apache ou SSH ?
Un serveur Subversion peut fonctionner avec trois types de serveurs : svn, protocole maison avec serveur svnserve, serveur Web (Apache) ou serveur svn+ssh, le protocole maison enacapsulé dans SSH. C’est cette dernière solution que j’ai choisie, plus sûre que svnserve tout seul, et peut-être plus légère qu’un serveur Web. En outre je disposais déjà du serveur SSH.
Configurer SSH sur les ordinateurs clients
Sur les machines à mon domicile, dont le NAS, j’ai configuré les serveurs ssh de façon à ce qu’ils écoutent sur un port de numéro différent du standard qui est 22 : ceci limite considérablement le nombre d’attaques par scan de port. Cela se fait en écrivant dans le fichier /etc/ssh/sshd_config :
au lieu de Port 22
de la configuration par défaut.
Ceci va obliger les clients à s’adapter à ce numéro de port. Il est bien sûr toujours possible, avant toute tentative de connexion au serveur considéré, d’entrer la commande :
qui fera l’adaptation voulue, mais il est plus commode et plus élégant de créer dans son répertoire sur l’ordinateur client un fichier de configuration .ssh/config qui pourra comporter l’entrée suivante :
Ce sera toujours ça de moins à taper.
Créer le dépôt Subversion
Comme le dit fort bien le livre, il faut maintenant créer un goupe subversion
et y enrôler les utilisateurs ; attention à la commande usermod, il faut répéter les noms des groupes auxquels chaque utilisateur appartient déjà, sinon il en sera retiré, et si c’était l’appartenance à ce groupe (admin par exemple) qui lui conférait dans /etc/sudoers les privilèges système pour utiliser sudo, il y aura du grabuge, et le livre n’a pas prévenu :
Création du dépôt, auquel on confère les appartenances et les permissions qui conviennent, en l’occurrence le groupe propriétaire est subversion, le dépôt est accessible en lecture et en écriture aux membres du groupe, le sticky bit (1 dans les arguments de chmod) est positionné pour éviter que soient créés dans le dépôt des fichiers qui n’appartiendraient pas au groupe :
Voilà, si tout s’est bien passé, le dépôt est fonctionnel et accessible, il n’y a plus qu’à l’utiliser.
Créer un projet Subversion
Je me place maintenant sur l’ordinateur client, dans le répertoire qui abrite les fichiers qui constituent le projet à déposer aux bons soins du serveur Subversion. Il est prudent de commencer par détruire tous les fichiers temporaires que l’on ne souhaite pas retrouver dans le dépôt, cela évitera d’avoir à les en retirer un par un ultérieurement. Et il n’y a plus qu’à agir ; si le projet s’appelle SecuritePratique (et en général le répertoire sera lui-même nommé SecuritePratique) cela donne (sur une seule ligne) :
Cette commande (sur une seule ligne) créera dans le dépôt Svn_Home sur la machine désignée par l’identifiant svn1 dans le fichier .ssh/config un projet SecuritePratique, et y archivera tous les fichiers du répertoire duquel est lancé la commande, y compris les sous-répertoires et leur contenu.
Une fois cela fait, la chose à faire est de renommer le répertoire d’origine de SecuritePratique en SecuritePratique.old et de créer à partir de l’archive une copie neuve et fraîche du projet, ainsi :
C’est le moyen d’avoir tout bien configuré comme il faut dans un sous-répertoire .svn.
Télécharger le contenu du projet
Sur une autre machine je souhaite installer une copie du projet SecuritePratique ; voici :
Cette commande crée, à l’endroit d’où elle est émise, un répertoire SecuritePratique qui contient les fichiers du projet.
Voilà, Subversion est un système centralisé, avec les inconvénients signalés dans l’article précédent, mais ausi ses avantages ; en effet, sous réserve de pouvoir accéder au site qui l’héberge, le dépôt unique et central est commode, parce qu’avec les systèmes décentralisés on est quand même souvent en train de faire des synchronisations dans tous les sens, avec le risque de se tromper de sens, et ainsi de créer des situations délicates à réparer.
Bonne Subversion !