Ferlet Patrice (patrice.ferlet@wanadoo.fr)
Aide à la maintenance d'un projet
sur serveur CVS simplifiée
Configuration SSH pour le CVS Tuxfamily
Je remercie en particulier Creis et "SurcouF" (rien à voir avec le magasin :o)) pour leur grande aide à m'aider à comprendre le fonctionnement du SSH. Les admins sont sur irc.tuxfamily.org #tuxfamily et Surcouf sur eu.undernet.org canal #linuxfr. Je suis pour ma part sur ces deux canaux et sur #free3d de l'irc undernet.
Et bien sûr, merci à la Tuxfamily pour nous offrir tant d'options sur leur hébergement.
J'ai passé deux jours à tenter des manipulations, avec un nombre de bêtises équivalent à des heures d'arrachage de cheveux organisées, et je ne compte pas la soirée passée à tenter de faire marcher SSH...
Tout ça pour en arriver à me dire qu'un document résumant la base des commandes serait nécessaire pour pouvoir commencer à travailler rapidement, sans avoir à apprendre un manuel complet sur CVS et SSH pour simplement faire un développement.
La première partie va tenter de vous faire bien comprendre le concept de CVS. Et comprendre ce qu'il se passe lors d'une modification. Ensuite nous allons configurer SSH sur votre machine, sans trop entrer dans le détail. Puis nous verrons les bases à connaître pour utiliser CVS et nous finirons par une liste de commandes génériques.
En dernier lieu nous verrons deux séquences de travail, la création d'un module et le développement sur ce module.
Bonne lecture et surtout bonne chance !
CVS est un serveur, vous allez vous y connecter et lui envoyer des requêtes, des fichiers ... Vous allez récupérer une version, travailler dessus puis mettre à jour vos fichiers au fur et à mesure. Le tout en récupérant les mises à jour des autres programmeurs du projet. Ceci évite le "montage sur les pieds" et l'incohérence du code, les modifications seront rassemblées automatiquement.
Vu que nous allons travailler sur le CVS tuxfamily, qui est interrogeable via SSH, j'ai voulut configurer ma connection pour ne pas taper mon mot de passe tuxfamily à chaque coup... et cela etait non sans mal ! Heureusement "Surcouf" m'a donné un sacrés coup de main, avec Creis (admin de la tuxfamily). Et grâce à leur coup de main, la configuration me semble plutôt simple (évidemment pour la base).
SSH permet de faire un echange d'information entre vous et le serveur avec une securité accrue, ceci grâce à un systeme de cryptographie et d'authentification via un systeme de paire de clefs privé et publique. Voilà pour l'information. Mais ca ne va pas être si dur, croyez moi.
Lorsque vous travaillez sur un projet, les modifications ne se font qu'en local, jusqu'à ce que vous fassiez un "commit1" qui aura pour effet d'envoyer vos modifications sur la version "public" du CVS. Si un autre programmeur modifie le même fichier, alors CVS va vous prévenir, et va rassembler vos modifications dans le même fichier. Si jamais une erreur risque d'entraver le bon fonctionnement du projet, CVS va vous faire un rapport d'erreur et va vous demander de corriger ceci.
Il est aussi possible de créer des versions parallèles, des "branches", et de mettre à jour la version principale à partir de ces versions parallèles ou bien de deux versions parallèles entre elles, vous pouvez aussi récupérer un version antérieur, une version créée par un autre développeur, voir "qui" a modifier "quoi" etc...
Tout d'abord il vous faudra installer SSH (openSSH étant en général installé avec les distributions Linux les plus récentes) si cela n'est pas déjà fait. Ensuite nous allons vérifier votre version du protocole SSH, ceci est simple, allez voir le fichier ssh_config via:
$ vi /etc/ssh/ssh_configet vous y trouverez normalement une ligne "Protocol" suivit de deux nombres "1,2" ou "2,1". Vous devez mettre la valeur à "2,1" pour être en SSH2.
Maintenant nous allons générer votre paire de clefs SSH, en tapant la commande:
$ ssh-keygen -t rsa -d 1024Ceci étant fait, vous avez alors à taper une "passphrase" qui peut être vide. Attention tout de même, une passphrase vide vous évitera de devoir la retaper lors de votre prochaine session SSH mais cela n'est pas très sécurisée.
Vos clefs sont alors générées. Avant tout, il faut créer un fichier nommé "authorized_keys"
qui contiendra le contenu de la clef publique générée.
Faisons ainsi:
$ cat $HOME/.ssh/id_rsa.pub >> $HOME/.ssh/authorized_keysIl faut maintenant les envoyer sur le serveur distant, en l'occurrence votre FTP Tuxfamily. Ouvrez un client FTP et allez sur votre compte, vous allez voir vos différents projets en cours, c'est à dire vos espaces Web et votre espace CVS. Restez ici et créez un répertoire .ssh sur votre FTP. Ensuite entrez dans ce répertoire et copiez le fichier authorized_keys à l'intérieur. Vérifiez en passant que les droits en lecture sont adéquats, c'est à dire que tout le monde puisse la lire.
Désormais il ne reste plus qu'à lancer une session SSH sur votre machine. Ceci se résume en 2 commandes. Tout d'abord (au cas où) il faut "killer" tous les processus ssh-agent si vous en avez lancé un. Sachez qu'il faut toujours verifier que aucun autre agent ssh soit lancé car Gnome et d'autres environnements lancent un agent.
$ killall ssh-agentPuis nous allons lancer les 2 commandes qui vont permettre à votre machine de communiquer avec CVS via SSH.
$ ssh-agent $SHELL $ ssh-add $HOME/.ssh/id_rsaCeci fait, vous n'avez qu'à configurer les deux variables du CVS comme ceci:
$ export CVSROOT=:ext:user@cvs.tuxfamily.org:/cvsroot/nom_du_projet $ export CVS_RSH=sshoù "user" est votre login Tuxfamily et "nom_du_projet" le nom de votre projet CVS. SURTOUT n'oubliez pas le ":ext:" qui est necessaire pour la communication entre vous et le CVS via SSH.
Voilà, si tout va bien vous pouvez tenter la commande "ssh -2 user@cvs.tuxfamily.org" pour tester la bonne mise en place de votre configuration SSH.
Si tout s'est bien passé, vous n'aurez pas à taper votre mot de passe à chaque commande CVS que vous ferez par la suite. A chaque fois que vous voudrez utiliser cvs, il faudra ouvrir une session SSH:
$ ssh-agent $SHELL $ ssh-add $HOME/.ssh/id_rsaet toute les commandes cvs devront être tapées dans le même SHELL.
Pour éviter de devoir ouvrir une session à la main à chaque session, ajoutez ces lignes dans le fichier .bashrc (merci Creis pour le script bash):
if [ -f .ssh-agent ] then . .ssh-agent else killall ssh-agent ssh-agent > .ssh-agent ssh-add ~/.ssh/id_rsa fi
IMPORTANT: Notez bien votre passphrase, elle vous sera demandée lors du login de votre bash.
Si vous voulez passer cette partie de configuration SSH, c'est votre droit, vous n'aurez alors qu'à configurer vos variables de session CVS ainsi:
$ export CVSROOT=user@cvs.tuxfamily.org:/cvsroot/nom_du_projet $ export CVS_RSH=sshici, plus besoin de "l'option" ext. Vous pouvez alors interroger cvs mais votre mot de passe tucxfamily sera demandé à chaque commande. Pas pratique, et pas rapide...
Créons un répertoire nommé CVS et entrons dans ce répertoire :
$ mkdir CVS $ cd CVSCe répertoire sera votre "repository" (depôt) local.
$ mkdir TRUC $ cvs import TRUC Patrice initialimportant! TRUC sera alors le projet (module), "Patrice" sera le concepteur et "initial" désigne la version (release) du projet. En général on met "initial" pour créer un projet. Si jamais on met un slash (/) dans le nom TRUC alors on crée un répertoire, faite très attention à ce genre d'erreur!
$ cvs co TRUC
$ cd TRUC $ cvs add foo.cOui mais voilà , il fait partie du cvs en local , il n'est pas encore sur le serveur CVS, pour ceci il suffit de faire un commit ... :
$ cvs ci foo.cou tout simplement un commit sur le répertoire complet en oubliant surtout pas de remonter d'un niveau via "cd .." pour être au dessus de votre répertoire TEST:
$ cvs ci TRUCVous venez de mettre à jour le module TRUC tout entier. Pour ne pas me tromper, j'utilise la touche Tabulation pour faire apparaitre le nom du repertoire.
Cette commande ne doit être executée seulement que lorsque vous êtes sûr du bon fonctionnement de votre source, car maintenant, il est accessible par les autres developpeurs. "Commit" est une validation de votre travail.
Par contre il se peut qu'un autre développeur le modifie en même temps que vous. CVS va se charger de faire un "merge" des fichiers, mais vous, vous n'avez pas cette version. Pour y remédier, faites à la racine du CVS local:
$ cvs update TRUC
Lors de votre commit, CVS va prendre en charge le rassemblement des sources. Cela peut vous generer une ambiguité que CVS vous nitifira. Mais etant donné que ce fichier "mergé" se fait sur le serveur, il vous a fallut le récupérer; c'est ce qu'à fait "update", il a mis à jour votre cvs local.
Vous pouvez evidemment supprimer un fichier, il suffit simplement de faire:
$ cvs remove TRUC/fichier... si on est à la racine du repository évidemment. N'oubliez pas de faire un update!
Maintenant il est aussi possible de créer un répertoire et de le supprimer mais là ATTENTION! Supprimer un répertoire ne va pas l'enlever du module... car il contient les version dites Attic (grenier) des fichiers supprimés. L'option -P (prune) du commit devrait y remédier mais le mieux étant de le supprimer sur le serveur (bien plus simple). Si vous avez accès au CVS via FTP , alors tout se simplifie, n'est ce pas ?
Etant donné que l'etiquette est collante, elle restera collée tout le temps; chaque commit , update etc... se fera sur cette version. La version principale du CVS étant chez Tuxfamily le tag HEAD3, cette version n'en sera pas touchée.
Comment créer une branche de la version HEAD en version TEST ?
Ici "module" est le nom du module (dans la section 1 on l'avait appelé TRUC).
Si vous n'avez pas encore récupéré le module faite un
$ cvs co modulesinon :
$ cvs update moduleensuite création de la branche:
$ cvs rtag -b -r HEAD TEST moduleCela crée la branche TEST à partir de la version HEAD.
$ cvs co -r TEST moduleou simplement un fichier:
$ cvs co -r TEST module/foo.c
Là nous avons la version TEST, vérifions:
$ cvs status modulequi fait apparaître le sticky tag (tag collant) TEST dans le rapport qui s'affiche à l'ecran. Maintenant toute les modifications auront une impacte QUE sur la version test.
Nous voulons, maintenant que notre version TEST à reçut des modifications, mettre à jour notre version principale (nommée par défaut HEAD) à partir de notre version TEST. Il nous faut d'abord revenir à la version HEAD avec un checkout (co) avec l'option -A pour supprimer les tags:
$ cvs co -A module //prend la version sans sticky tag $ cvs update module //pour remettre \`a jour les fichier locaux (facultatif)ensuite on fait un merge de la version TEST vers la version HEAD (celle que nous avons en local) :
$ cvs update -j TEST modulepuis confirmons tout ça:
$ cvs ci modulefaites tout de même un update au cas où puis faites un status. Notre version locale HEAD à donc reçut les modifications de la version TEST.
Toute cette partie pouvait se faire entre deux branches parallèles:
1- $ cvs co -r TEST2 module // modifications des sources, ajout de fichier etc ... 2- $ cvs ci TEST2 3- $ cvs co TEST module 4- $ cvs update -j TEST2 module 5- $ cvs ci modulececi à pour effet de (1) rapatrier la version TEST2 sur votre disque, (2) ajouter les modifications au CVS distant, (3) rapatrier la version TEST sur votre disque, (4) rassembler les modification de la partie 2 sur la version TEST2 vers votre version TEST, (5) confirmer vos modifications sur le CVS distant.
Important ! Si vous créez un répertoire dans la version TEST2 et que vous voulez joindre vos modifications dans la version TEST, le répertoire ne sera pas inséré! Effectivement il faut faire un add dans la version TEST avant de faire un "join". La seule exception se fait lors d'un "join" sur la version initial, où là le répertoire se créra.
Imagons ce qu'il vient de se passer dans cette section:
Vous avez un paquet de documents, un gros dossier. C'est le dossier de travail. Vous voulez
faire en sorte que ce dossier puisse evoluer en test et le rendre publique seulement si il est bon.
Vous prenez donc un gros sac dans lequel vous mettez vos documents et vous collez sur ce qac une etiquette
autocollante avec ecrit dessus "TEST". Ce sac est alors distribué à qui le veut. Vous modifiez des choses,
vous y inserez des feuilles. Cette version vous plait, vous copier alors tout ce dossier et le mettez dans le
sac principal (publique) qui n'a pas l'etiquette "TEST". Mais vous avez encore une version de l'ancien
sac principal ainsi que le sac TEST au cas où.
$ cvs co Module- rapatrie un module en local, "co" est une abréviation de l'option "checkout" à faire une seul fois pour récupérer un module ou une version.
$ cvs ci Module, cvs ci fichier ...- "ci" est une abréviation de "commit", cela confirme vos modifications sur le serveur CVS.
$ cvs update Module ou $ cvs update fichier- pour rafraîchir votre CVS local avec les versions public, à faire à chaque commit et en début de phase de travail... soit régulièrement
$ cvs rtag -b -r Version1 Version2 module- crée une branche nommée Version2 à partir de la Version1 du module "module" (faire un commit ensuite pour confirmer )
$ cvs co -r Version module- récupère la version "Version" du module "module"
$ cvs co -A module- récupère la version principale (-A supprime les tags de votre cvs)
$ cvs add fichier- ajoute le fichier "fichier" au cvs ...
$ cvs remove fichier- supprime le fichier "fichier" du cvs
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.50)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 aide_CVS.tex
The translation was initiated by Patrice FERLET on 2002-10-15