État des lieux du Projet Étudiant "Serveur Libre", ouverture vers le projet PeCoVall Pascal Pucci address@hidden 23/05/2001 1 Avertissement : Cette description est tout à fait personnelle. Cette évaluation du projet s'appuie sur mon expérience (http://www.pascalou.org/cvs/fr) et sur les discussions que j'ai pu avoir avec les acteurs du projet. Pour essayer de donner un peu de crédit à mon discours (et non pas pour étaler mes compétences), je me permets de vous retracer rapidement certaines des réalisations que j'ai pu effectuer : * Co-fondateur du Lug Avignonnais Linuxpien Avignon (Président fondateur). * Co-fondateur de DeeNoo SARL (http://www.deenoo.com & http://www.beetell.com) : Services Internet utilisant des technologies autour de PHP/MySql * Développement/Installation du serveur : www.cooperons.net (utilisation de DaCode (moteur php de linuxfr)) offrant un service de communication globale pour des communautés : Mail, Webmail, Ftp, News, Liste de diffusions... (technologies utilisées : Administration totale sur LDAP, utilisation et configuration de Openldap, Postfix, Cyrus, Proftpd, Mailman, Imp, daCode). * Contributions libres récentes : Patch Ldap sur daCode, Patch Phphoo (annuaire d'urls) sur daCode. * Diplômé de l'université d'Avignon : IUP informatique d'Avignon (Maîtrise). Je n'ai pas la prétention de faire une synthèse globale de l'existant, mais j'espère présenter ici un document retraçant une analyse personnelle permettant de nous aider dans les décisions à venir. Sans prétendre à la vérité, j'essaie d'avoir une vision objective et constructive qui devrait permettre, je l'espère, de contribuer efficacement au projet. Vos critiques, corrections et commentaires (les plus cinglants ou les plus amicaux, ceux que je préfère) sont naturellement la bienvenus. 2 Serveur Libre : La concrétisation d'un besoin étudiant et du monde enseignant 2.1 Une démonstration des compétences L'ENST Bretagne ainsi que ses écoles partenaires accueillent chaque année des élèves brillants qui se sont déjà impliqués ou qui s'impliquent dans des projets informatiques annexes libres ou non libres de très bonnes qualités. Ces étudiants ont très souvent envie de promouvoir leurs travaux grâce à l'usage d'internet. C'est le cas lors de la publication de pages internet directement sur le site de leur école. Par contre en ce qui concerne la réalisation de projets informatiques, il est difficile et parfois impossible de disposer d'outils spécifiques d'une manière souple et efficace au sein de son école. Ces étudiants ont donc souvent l'unique solution d'utiliser d'autres services de qualité, ouverts et souples de type sourceforge (www.sourceforge.net). On assiste donc chaque années à une délocalisation d'une certaine production étudiante vers d'autres horizons. Ceci constitue naturellement un manque à gagner vis à vis de l'image (en termes de compétences techniques) de l'école. On peut rappeler ici, à titre d'exemple, que l'école 'Centrale Paris' héberge et soutient depuis plusieurs années un projet étudiant nommé "VideoLan", très en avance en matière de 'streaming' vidéo, démontrant par sa qualité technique et sa réalisation tout le bien fondé que l'on peut avoir de l'image de cette école. 2.2 Un besoin pédagogique évident Le développement de projets informatiques dans le cadre des études universitaires par les étudiants relève le plus souvent de l'exercice appliqué ou même parfois "de la simple recherche de la note". Cette attitude est tout à fait compréhensible : "Le projet fini et noté, le code source part à la poubelle. Pourquoi alors je m'appliquerai alors à faire du code propre, documenté, scalable ?...". Dès lors qu'une une instance quelconque arrivera à montrer que ces projets ont une durée de vie bien plus longue que la durée de vie du module d'enseignement, elle arrivera sûrement à motiver d'avantage ses étudiants à la conception de leur projet scolaire. De plus, des outils supplémentaires tel que la gestion de version avec CVS, une meilleure communication à travers un groupe grâce à l'usage d'une liste de diffusion, l'usage d'outils de documentation (etc...) sont la garantie de réunir tous les éléments propices à la production de logiciel de qualité (objectifs que devra réaliser tout ingénieur informatique dans son métier). 2.3 Un besoin étudiant à ne pas décevoir Les étudiants n'auront aucun problème à utiliser cet outil de conception dans le cadre de leurs études ou non. Mais il faut encore avoir la capacité de leur offrir un outil de bonne qualité. En effet, le gage de qualité et le confort d'utilisation sont bien plus importants que l'aspect revendicatif de la formation, « l'image de son école » : Un étudiant préférera utiliser la plate-forme de son école uniquement s'il est sur d'y trouver l'assurance d'y avoir une plate-forme stable, contenant tous les outils dont il a besoin et dont il est sûr de sa pérennité. (Vivien Chappelier, principal auteur du "Serveur Libre" et développeur dans d'autres logiciels phares, utilise SourceForge pour son développement). Je dois ici rappeler que certains projet sont directement en relation avec le monde professionnel. Ceci nous oblige encore plus à proposer un outil d'une qualité indiscutable. De même, si l'on arrive à avoir l'adhésion des chercheurs de l'école dans l'utilisation de cette plate-forme, c'est l'assurance de rapprocher et multiplier les échanges entre le monde étudiant et celui de la recherche. L'émulation au sein d'une école d'ingénieurs est souvent l'un des ou le seul moteur de l'excellence. Mais, là encore une fois, cela nous oblige à nous doter d'un outil irréprochable. 3 Description du 'Serveur Libre' 3.1 Cahier des charges (à fortiori) * Mise à disposition des étudiants d'une plate-forme de travail disposant : * D'une gestion de la présentation du logiciel. * D'une gestion de version pour permettre un meilleur travail collaboratif par l'usage de CVS. * D'une liste de diffusion pour mieux communiquer au sein du groupe. * D'une gestion d'erreurs logiciels ("Bug Report"). * D'une gestion de la documentation et des FAQ (Questions les plus fréquentes). * D'une gestion du site de présentation du projet. * Possibilité d'avoir des projets accessibles uniquement en interne et des projets accessibles en externe. * Administration facile 3.2 Rapide historique du développement logiciel du projet 'Serveur Libre' Au début du développement (été 2000), il faut rappeler que SourceForge n'était pas encore très accessible et ne pouvait donc pas constituer de base de départ pour ce développement. Il a donc été décidé de débuter la réalisation du "Serveur Libre". Le projet a donc été initié par deux étudiants (à l'époque en 1ere année) Vivien Chappelier et Thomas Cougnard pour un stage d'une durée deux mois (~ 640 Heures). Ce projet a ensuite été poursuit par Loïc Guelorget et Emmanuel Pierru (élèves de 3eme année) durant leur projet de fin d'étude (qui a permis notamment l'intégration de sympa) (~160 Heures). 3.3 Description personnelle de l'existant 3.3.1 Vision personnelle (donc subjective) du projet * Le code : * Le code actuel est tout à fait correct eut égard au nombre d'heures de travail qu'il a nécessité. La présence d'outils de configuration type "autoconf" montre facilement les compétences réelles des développeurs qui se sont intéressés à ce projet. * Il y a une amorce d'autoconfiguration de l'outil mais un tel programme reste évidement difficilement « empaquetable » et très spécifique. (à titre d'exemple, il m'a fallu trois jour pour installer correctement la solution sur ma machine personnelle). * Le projet utilise des scripts "sh" bien écrit et lancé par Apache tournant avec un utilisateur nommé "libre". * Le code PHP est écrit de manière séquentielle (il n' y a qu'un seul petit module développé en objet) mélangeant de l'HTML et du code PHP. Cette particularité rend le code difficilement compréhensible et surtout difficilement extensible. * La scission des différents modules est bien pensée et permet une recherche relativement aisée des problèmes. * On y trouve un petit programme 'Perl' unique (servant au cryptage des mots de passe). * On y trouve aussi un cryptage fait maison dont je ne maîtrise actuellement pas les raisons de sa conception. * La modélisation de la base de données : * La base de données possède une incohérence dans la modélisation : La distinction « droit admin » et droit sur les développeurs est inutile. 3.3.2 Vision de l'auteur principal (chef de projet) Vivien Chappelier m'a formulé clairement au détour d'une discussion : "Si c'était à refaire, je referais tout". 3.3.3 Usage trop spécifique du serveur Un tel serveur ne peut-être que spécifique, dédié. Mais il n'en reste pas moins que la configuration nécessaire pour faire fonctionner le serveur relève d'une spécialisation bien mal pensée en termes de sécurité et nécessite des manipulations obscures. 3.3.4 Respect des exigences de départ Lors de la réalisation du serveur, il a été formulé le besoin de disposer de sites en interne (projets non accessibles de l'extérieur) et de projets accessibles au grand public (vitrine logiciel de l'ENST Bretagne). Or, on doit ici remarquer que le serveur libre n'a pas été pensé de la sorte. La tâche proposée qui consiste à faire basculer un projet interne en un projet externe relève d'une administration "bricolage" : "Extraire correctement les données de la base de données interne spécifique à un projet, ré-injecter ces données dans la base 'Serveur Libre' public, puis déplacer les sources". Ce besoin sera bien entendu impossible à satisfaire avec une montée en charge du serveur. 3.3.5 Sécurité * Accès CVS : L'accès CVS est fait par le mode "pserver" qui n'est pas sécurisé. C'est à dire qu'une simple écoute sur le segment contenant le 'Serveur Libre' ou sur un segment, où passe la requête, permet de récupérer tous les mots de passe. Il serait gênant qu'un groupe perde son travail à cause d'une personnes maligne et mal attentionnée. (J'ai moi-même testé cette affirmation par un simple tcpdump et, je le confirme, il est tout à fait simple de récupérer les mots de passe de tous les utilisateurs). Il faut ici se rappeler qu'on sera amené à utiliser le serveur CVS de l'extérieur. Tous les mots de passe CVS, qui sont aussi les mots de passe du "Serveur Libre", passeront en clair sur l'internet entre l'ENST Bretagne, l'ENST Paris et l'INT. Solution : Mettre en place une sécurisation SSH (simplement comme pour la plupart des serveurs CVS publics). * Accès base de données : L'accès à la base de données est fait, lui aussi, sans aucun cryptage, ce qui ne pose aucun problème dès lors que la base de données Mysql est hébergée sur le même serveur que le serveur apache lui effectuant des requêtes. Dans le cadre de la communication entre les serveurs, cette configuration est inadaptée car non sécurisée : Le mot de passe de l'utilisateur libre de la base de données nécessaire à toute connexion passera en clair sur la toile. C'est à dire à la disposition de toutes personnes voulant avoir un accès à la base de données des logiciels et du 'Serveur Libre'. Solution : Recompiler Mysql en mode "secure", restreindre au minimum les accès serveurs, utiliser des serveurs apaches sécurisés (Apache Ssl ou module Ssl pour apache). Interdire des requêtes non sécurisées ou peut-être mettre en place des tunnels Ssh ou même des ponts sécurisés (Vtun). * Site en lui même : Actuellement, le mode Ssl (cryptographie) n'est pas en fonctionnement, c'est à dire que tous les mots de passes admin ou chefs de projets passent en clair sur le réseau local actuellement et plus tard sur la toile. Solution : Installer un serveur apache sécurisé. * Aberrations graves de la configuration : Actuellement le serveur Apache tourne sous l'utilisateur 'Libre'. Cette utilisateur a tout les droits sur les répertoires CVS, FTP, HTTP et sur la configuration des alias mail pour sympa. La documentation d'un projet se fait par un simple envoi d'un fichier qui est ensuite inclus dans des fichiers PHP interprété par apache et exécuté par l'utilisateur libre. Si bien, qu'il suffirait de rajouter dans les fichiers HTML de documentation (envoyés sur le serveur) quelques lignes PHP pour exécuter des commandes PHP avec l'utilisateur libre. Autrement dit, je crée un fichier HTML avec quelques lignes PHP servant à détruire le contenu des répertoires CVS, FTP, HTML que j'envoie en tant que documentation et j'active ce script en regardant cette documentation : Je détruis automatiquement et anonymement des milliers d'heures de travail et de la même façon le 'Serveur Libre'. (J'ai aussi testé cette affirmation). Ne parlons pas ici des problèmes et malaises engendrés pour l'administrateur, les responsables du projet et les étudiants. Un tel incident serait fatal : Peut-on par exemple arrêter tous les projet S4 pour une durée d'un mois afin de réparer le serveur ? (remettre uniquement les données sauvegardées). Cette question mérite d'être posée maintenant. Solution : repenser le mode de la documentation, repenser les droits des utilisateurs. 3.3.6 Résistance à la charge L'accès CVS est actuellement donné par l'intermédiaire d'une requête sur la base de données des utilisateurs. Ceci ne demande pas trop de ressources pour quelques utilisateurs. Mais dans le cas d'une utilisation plus poussée (30 projets), on peut émettre des doutes en ce qui concerne la résistance du serveur Mysql : "Exemple : un commit général provoqué par la fin des cours de 11h00". Solution : Refaire le mode d'authentification : passer par des fichiers temporaires. 3.3.7 l'Intégration de Sympa L'intégration Sympa a été réalisée durant une deuxième phase de développement par deux étudiants de 3eme année. Cette phase a permis l'intégration de sympa et notamment l'ajout supplémentaire d'erreurs et de problèmes de comportement : Pour cette intégration, il a été rajouté des "frames" au 'serveur libre' rendant (du fait de la conception du serveur) toutes les fonctions d'envoi de fichier (upload) inopérantes. J'ai commencé à réparer ces erreurs, mais ces corrections relèvent d'un codage "sauvage" (obligatoire selon la conception actuelle du logiciel) desservant la qualité du code du 'Serveur Libre' . De plus, on n'a aucune synchronisation des mots de passe qui oblige tous les utilisateurs à mémoriser 2 mots de passe (un pour le serveur libre, un pour sympa). De même, on déplore aucune documentation sur cette partie du projet. 3.3.8 Les erreurs connues Vous pourrez constater à l'adresse suivante la liste des erreurs logiciels encore à corriger pour permettre une utilisation de ce serveur : http://serveur-libre.enst-bretagne.fr/index.php?main=projets/bugs.php&menu=projets/menu.php&project=serveur_libre 3.3.9 Erreurs inconnues / défaut d'utilisation du serveur actuel L'un des plus gros problèmes actuels est le fait que ce serveur n'est actuellement pas ou très peu utilisé. Les problèmes les plus importants sont bien souvent ceux que nous ne connaissons pas. Je n'ai eu actuellement qu'un seul retour par rapport à un problème d'authentification général. Il reste des 'bugs' importants que je n'ai pas réussi actuellement à diagnostiquer : "Fermeture de sessions aléatoires sur le serveur, authentification CVS rompue nécessitant un changement de mot de passe". 3.4 Évolution nécessaire (indispensable) pour une mise en production au niveau de l'ENST Bretagne 3.4.1 Problèmes En vous reportant naturellement au chapitre précédent vous y trouverez des problèmes cruciaux relatifs à la sécurité qu'il faut absolument rectifier. Balayer ces problèmes d'un revers de main en émettant l'hypothèse que nous sommes en présence d'étudiants et développeurs responsables serait pour moi une attitude inconsciente. Personnellement, j'ai pu largement constater dans mon cursus des cas de piratage informatique purement vandalistes. La simple création, l'innovation et la démonstration des compétences de certains élèves provoquent parfois des rancoeurs chez d'autres élèves. De même, ce serveur veut et se doit de devenir accessible de l'extérieur. Il n'en sera donc que plus vulnérable. De plus, la configuration actuelle permet un vandalisme tout à fait anonyme (les fichiers de logs sont aussi effaçables en même temps que la destruction du reste du serveur (Les logs d'apaches appartiennent aussi à utilisateur apache : libre )). De même et en accord avec Vivien Chappelier (chef du projet), les "apports" de l'intégration du module sympa sont à revoir intégralement en raison des erreurs logiciels qu'ils ont provoquées et de sa conception (à revoir également). 3.4.2 Estimation (temps) de la correction Si on réunit les ressources et les compétences en développement logiciel sur ce projet au niveau de l'ENST Bretagne, j'estime cette phase de conception à 2 mois de développement complet à plein temps. (plus ou moins 2 semaines). 3.5 Évolution nécessaire (indispensable) pour permettre de "vrais échanges" entre les serveurs dans le cadre du projet PeCoVall 3.5.1 Problème En ce qui concerne le projet PeCoVall, il va s'en dire que les modifications de sécurité relative au mode d'administration du 'serveur libre' sont à effectuer. Il serait dommage qu'une communication maladroite entre les différents serveurs soit la cause d'un piratage au niveau de l'ENST Paris, l'INT ou même l'ENST Bretagne. 3.5.2 Estimation (temps) de la correction Cette phase requiert la première phase de développement. J'estime à 2 semaines de travail complet (~ plus 2 semaine) sous réserve d'avoir les droits d'administrer le serveur. 3.6 Évaluation du temps nécessaire pour une mise à niveau Cela peut vous sembler choquant, mais pour toutes les raisons que je vous ai indiquées, ce serveur a besoin encore d'une grosse phase de développement pour passer en production. Cette phase de production est nécessaire et inclut uniquement une réparation et une sécurisation des modules présents actuellement sur le serveur. Cette phase nécessite un travail soutenu qui requiert 2 mois et demi de développement. On peut espérer avec un travail soutenu et sans ajouter de nouvelles fonctionnalités avoir un outils relativement correct en production d'ici mi-septembre. Ceci exclut bien entendu toute coopération dans le cadre du projet PeCoVall car nécessitant lui aussi un temps de développement non négligeable. Sans aucune modification de l'actuel 'Serveur libre', le projet PeCoVall me semble voué à l'échec. De même, de trop grands risques au niveau de la sécurité subsistent. Un simple piratage pourrait très facilement annuler simplement tout l'engouement qu'il peut y avoir autour de ce projet. Généralement, le pionnier n'a pas droit à l'erreur et encore moins à l'échec. 3.7 Évolution pédagogiquement souhaitable (non obligatoire mais fortement conseillée pour disposer d'un produit relativement correct). Le 'Serveur Libre' satisfait actuellement plusieurs besoins : CVS, FTP, liste d'erreurs, liste de diffusion, spseudo documentation. Mais il n'en reste pas moins incomplet en matière de besoins pédagogiques, par exemple : * Un échéancier : Gestion de Tâches, répartition du travail * Outils de statistique plus poussés : fréquence de travail, analyse des tâches de chaque élèves, popularité... * Forum * Outils de recherche * Interface en ligne du CVS (WebCvs) Ces outils sont ou seront raisonnablement nécessaires à la gestion des projets étudiants. Ces projets, certes universitaires, ont quasiment les mêmes besoins que tous projets. La différence entre un développeur, un chercheur et un étudiant en fin de cycle est bien souvent presque nulle. Ces modules sont déjà présents sur d'autres logiciels. Ce développement qui reste, restera à fournir représente beaucoup d'heures de travail qu'il faudra financer. Ne sommes nous pas en train de vouloir faire une pâle imitation de sourceforge sans en avoir les moyens ? 4 L'alternative Sourceforge/Savannah 4.1 Présentation 4.1.1 Sourceforge Sourceforge est un projet initié par "VaLinux", société américaine d'expertise en matériel informatique et en logiciel libre, ayant pour but d'offrir à la communauté du libre une plate-forme de développement. L'ambition de VaLinux est de fournir, en plus de cette station de travail, une bibliothèque de codes sources afin de dynamiser les initiatives en matière de développement Open Source. La station de travail est GPL. 4.1.2 Savannah Le projet GNU soutenu par la FSF (Free Software Fondation) a eu l'envie de mettre à disposition de la communauté du libre ce même outil. Des contributions au projet sourceforge ont été faites par l'intermédiaire de plusieurs développeurs extérieurs à VaLinux (Guillaume Morin d'Alcôve ou de Loïc Dachary de la FSF Europe par exemple). Des difficultés d'intégration de leur contribution au niveau du code source de sourceforge ont été rencontrées. Malgré des initiatives de coopération, la FSF a donc été contraint de créer une nouvelle branche de développement du logiciel SourceForge afin de pouvoir ajouter leur contribution. Il existe donc actuellement deux logiciels de type sourceforge avec deux équipes de développement différentes : Valinux pour Sourceforge, la FSF pour Savannah. 4.2 Serveur libre : Respectons-nous l'esprit logiciel libre ? Le projet 'Serveur Libre' cherche et même s'il s'en défend à avoir les mêmes fonctionnalités que Sourceforge. Dans l'histoire du logiciel, il y a eu des cas de réécritures complètes de logiciels similaires. Mais ceci fut fait la plupart du temps pour des raisons estimables : ré-implémentation plus propre, changement de langage, etc... Or le développement du "serveur libre" ne correspond à aucun de tous ces aspects. La stratégie du logiciel libre représente encore et toujours "une politique du moindre effort" par l'utilisation d'outils existants. Ceci permet une diminution du facteur le plus coûteux en informatique : le temps de développement. De plus, ceci laisse place, bien souvent, à l'innovation et non à une ré-implémentation systématique de tous les outils. L'usage du logiciel libre, c'est avant tout une réutilisation et une personnalisation d'outils existants à des fins de services, ce qui entraîne la nécessité de maîtriser un outil et de s'y adapter. La personnalisation d'un outil et sa compréhension consiste en elles-même en une tâche importante nécessitant bien plus de compétences que pour du développement pur réalisé à partir de rien. Mais là, est le défi d'un développeur libre : Savoir s'adapter et contribuer si besoin est. 4.3 L'assurance d'un appui ferme et durable de la communauté SourceForge est connu actuellement par tous les acteurs du libre. Choisir une telle architecture, c'est s'assurer de recueillir la sympathie d'une communauté en mal de reconnaissance. Suite à notre rencontre "autour du libre" de l'ENST Bretagne, on peut envisager de façon certaine une coopération et un soutien de la FSF à notre projet. Encore faut-t-il faire le pas vers leur technologie. De même, il nous est permis et ceci est possible de personnaliser Sourceforge à nos besoins : Ceci est la force de tout logiciel libre. 4.4 L'assurance d'avoir un environnement complet et connu Au fil des années, sourceforge, hébergeant plus de 20000 projets avec plus de 175000 utilisateurs s'est installé comme un standard incontournable en matière d'outil de développement. (Beaucoup de sites d'emploi classent d'ailleurs cet outil au même titre que l'UML ou la modélisation Merise comme un outil d'aide à la conception). Beaucoup de développeurs s'y sont battis un référentiel et connaissent déjà l'outil. 4.5 Ce que le "serveur libre" n'a pas et ce que Souceforge permet/permettra d'obtenir Sourceforge est un outil complet, stable et utilisé. Il possède plusieurs outils d'intérêts pédagogiques que le "serveur libre" n'a pas : * Gestion de tâches, échéancier * Gestion d'erreurs logiciel (non erronées comme celui du 'serveur libre'). * Statistique sérieuses sur les développeurs (étudiants). * Cvs-Web : gestion CVS en ligne * Archivage correct * Une sécurisation correcte : Sensibiliser les étudiants à la sécurité informatique me semble important * Outils de recherche De même, sourceforge permet d'héberger une page de présentation de chaque développeur (étudiant). Ce qui peut permettre aux étudiants de mieux valoriser leur compétences et ainsi de mieux obtenir un emploi auprès du monde professionnel. On y trouve en plus : la gestion de 'patch', la gestion de sondage, la gestion de thèmes (apparence d'affichage de l'outils)... Mais sourceforge reste modifiable comme tout logiciel libre... 4.6 La place donnée à l'innovation et la contribution de l'ENST à la communauté du logiciel libre 4.6.1 Des modules innovants ? L'ENST Bretagne, l'ENST Paris et l'INT peuvent avoir des besoins spécifiques non offerts par Sourceforge. Exemple : Module pour professeur pour aider à la notation d'un élève, un module de "flicage" pour connaître les étudiants les moins pugnaces en matière de développement logiciel (réservé pour les professeurs exigeants, « sadiques »), etc... Ceci deviendrait une contribution directement disponible pour d'autres écoles d'ingénieurs. On rappellera ici qu'une implémentation à partir du 'Serveur Libre' ne permettra aucune innovation car nécessitant un temps de développement conséquent à des fin de mise à niveau. 4.6.2 Faisons-nous une identité L'ENST mettant à disposition de ses étudiants un outil de qualité reconnu se place directement dans une reconnaissance professionnelle de sa formation. La force de toute école comportant des hautes technologies est d'arriver à former des ingénieurs directement opérationnels à la sortie de leur école (directement utilisables). L'informatique évolue rapidement et faire l'effort d'évoluer en ce mettant à jour est un gage d'excellence et de reconnaissance. Les technologies disponibles, il y a un an, ne sont pas celles dont on peut disposer aujourd'hui. Il peut sembler judicieux de tenir compte de cette évolution. Des alternatives existent aujourd'hui et leurs qualités sont indiscutables. Sourceforge reste un outil spécifique. Il nous importe d'en utiliser les fonctionnalités pour en faire un outil de formation pédagogique reconnu. Personnaliser l'outil avec une charte graphique personnelle, des modules supprimés/ajoutés reste, tout à fait, possible et le bienvenu. 5 Les choix & conséquences 5.1 Le choix : "serveur libre" 5.1.1 Avantages : * On ne change pas de cap sur des choix technologiques (âgé d'un an et demi). * On mets à disposition un serveur pour les étudiants fait par des étudiants : Reconnaissance du travail des 4 étudiants ayant développé le 'Serveur Libre'. * Ce serveur reste une image de marque spécifique à l'ENST Bretagne : Identification faite par l'exception. * On reste sur un existant : Installation d'un nouveau serveur inutile = moins de travail. 5.1.2 Inconvénients : * Serveur à mettre à niveau (sécurité, erreurs logiciels, etc...) = 2 mois et demi de développement. * Temps disponible pour PeCoVall réduit presque à zéro. Possibilité d'échanger des informations presque nulles. * Risque de piratage, de perdre toutes les données. * On perd le soutien d'une communauté de développeurs. (FSF, Lugs, étudiants s'impliquant dans le libre). * Risque d'une périclitation au fur et à mesure de sa monté en charge. * Administration impossible dès lors qu'on monte en charge. * Qualité et variété des outils tout à fait médiocre : risque certain d'un mécontentement des utilisateurs. * Très faible rentabilité de ma mission : un 6 mois/homme pour disposer d'un logiciel incomplet, non éprouvé. 5.2 Le choix "Sourceforge/Savanah" 5.2.1 Avantages * L'Enst dispose d'un logiciel de bonne qualité et complet. * Personnalisation possible de l'outil. * Communication dans le cadre du projet PeCoVall facilitée (Si on reste sur la solution de 3 serveurs communicants). * Adhésion et aide de la communauté du libre (par l'intermédiaire de la FSF). * Diminution des coûts de développement. * Administration plus aisée. 5.2.2 Inconvénients * Nécessite des compétences. * Usine à gaz : nécessité de simplifier et personnaliser l'outil. * Requiert un serveur relativement puissant. 5.3 Crédibilité du choix / Opinion personnelle Les arguments servant à défendre un choix interne "serveur libre" plutôt qu'un logiciel reconnu tel que Souceforge ou Savannah relèvent à mon sens d'une mauvaise compréhension de l'usage des logiciels libres. Le choix de mettre à disposition un code source, c'est le moyen d'avoir une rentabilité meilleure en terme de développement : Avoir la maximum d'utilisateurs et de développeurs est l'assurance d'améliorer sans cesse un logiciel. Or, cette perspective de vouloir faire absolument un logiciel maison est un non sens : Combien d'utilisateurs ? Quelques dizaines. Combien de développeurs ? 3, 4 et en plus, non coordonnés entre eux. Un tel choix serait perçus comme une attitude très prétentieuse : "Sourceforge ne me satisfait pas, je développe un logiciel identique en tout point pour montrer ce que je sais faire". Or comme j'ai essayé de vous le montrer : ce logiciel maison, en plus d'être à revoir, n'est pas du tout prêt pour une utilisation concrète (une mise en production). "Vouloir faire un Sourceforge français" comme un étudiant de l'école a pu me soutenir semble, pour ma part, correspondre à une sorte de chauvinisme nombriliste qui n'est pas du tout compatible avec les notions de l'internet et du logiciel libre qui prônent une coopération bien au delà du clivage des nationalités, des langues et des cultures différentes. Le projet a un an d'existence et seulement quatre développeurs réels ont participé à ce projet. Je dois dire, et en toute sincérité, que si on avait la capacité de réunir une vingtaine de développeurs compétents, on ne serait même pas sûr d'arriver à réaliser un logiciel correct dans le temps imparti. Mettre à disposition des étudiants un outil erroné et non fonctionnel relèverait d'un non respect de leur condition de travail. De même, toute adoption du monde professionnel par l'intermédiaire des projets S4 en sera proscrit pour des raisons d'exigences qualitatives évidentes. Par ailleurs les problèmes d'administration relatifs à ce logiciel risquent de provoquer tôt ou tard un refus des administrateurs du serveur hébergeant ce logiciel. 6 Projet PeCoVall : Marge de manoeuvre selon le choix de la station de travail 6.1 Temps/Homme Suite à des correspondances par mail, je puis constater actuellement : * ENST Bretagne : 1 admin / 1 développeur : 6 mois * INT : 1 admin / 2 développeurs : 2 mois (probable, pas confirmé). * ENST Paris : 1 admin / 1 développeur : durée non connue à présent. Pour résumer, nous disposons de peu de moyens. 6.2 Communication entre les serveurs Quels est le besoin ? Permettre à des étudiants de disposer d'une interface unique avec derrière des serveurs hétérogènes. Défis technologique évident qui va nécessiter bien 2 mois de travail complet. En avons-nous les moyens ? Je reprendrai ici le discours de Loïc Dachary, membre de la FSF Europe et de la FSF France : "[...] En bref ce qui me semblait bloquant lorsque l'on avait discuté est l'idée de réaliser plusieurs serveurs d'hébergement qui dialoguent entre eux. C'est beaucoup de travail et je crois comprendre que vous ne disposez pas de ressources infinies pour la concrétisation de ce projet. Je me suis fait l'avocat du fait qu'une solution centralisée est meilleure. [...]". 6.3 Indépendance des parties, personnalisation Chaque partie du projet (école) voudrait avoir sa propre identité tout en utilisant une même station de travail : Chose tout à fait possible avec SourceForge. Il pourra nous sembler utile et sans trop de perte de puissance d'utiliser trois chartes graphiques différentes en utilisant trois instances CVS personnalisées pointant toutes trois vers la même base de données, la même messagerie, etc... De même, nous voulons maîtriser actuellement la publication des projets : "diffuser uniquement certains projets". Il nous importe donc d'effectuer une modification du code source de sourceforge pour ajouter un paramètre de publication pour tous les projets. La solution qui consiste, comme dans le cas du 'Serveur Libre', à faire fonctionner deux serveurs différents, un en interne et un en externe, semble tout à fait ingérable, non administrable (comme déjà expliqué). 6.4 Administration dans le cas d'une vrai collaboration D'une simple constatation : trois serveurs correspondent à trois administrateurs différents pour trois travaux identiques. De plus, ceci peut aussi provoquer l'achat de trois serveurs moyens à la place de l'achat d'un seul serveur de puissance correcte. Il peut encore sembler trivial de penser que l'union de trois administrateurs compétents permettra sûrement une réparation des problèmes plus rapide que dans le cas d'un administrateur unique. De plus, c'est un système d'archivage unique. L'ENST Bretagne dispose de 16 MegaOctets de bande passante, ce qui ne pose aucun problème dans le cas de l'implémentation d'un serveur au niveau de l'ENST Paris ou de l'INT (disposant sûrement d'une meilleure bande passante). Rien n'empêchera aussi d'installer le serveur CVS (avec un peu de manipulation) sur autre site (sous réserve de le faire de façon sécurisée). Mais en tout état de cause, vouloir installer trois serveurs différents ayant les mêmes fonctionnalités et pourchassant les mêmes objectifs me semble totalement incohérent et inadapté. Établir un protocole de communication entre des serveurs hétérogènes est une mission tout à fait intéressante, mais qui me semble inutile pour atteindre nos objectifs. De plus, ce projet peut consommer un certain temps non disponible actuellement. 6.5 Globalisation/Collaboration/Administration triviale La FSF, par l'intermédiaire de Loïc Dachary, se propose d'héberger les projets du GET sous réserve qu'ils soient libres. Ceci est une proposition tout à fait intéressante et à ne pas négliger : * Coût d'administration quasi-nul (pris en charge par la FSF). * Coût d'installation quasi-nul (pris en charge par la FSF). * Garantie de disponibilité sûrement plus grande des serveurs. (les administrateurs de la FSF sont simplement plus nombreux). * Gain d'image pour le GET Mais en contre partie, le GET risque de perdre : * Une fonctionnalité désirée : Projet public, projet privé. * Son identité si aucun effort est fait pour personnaliser l'outil Savannah à l'image des écoles. * Son indépendance vis à vis de l'administration directe des machines. * Sa fonction première qui est de former des élèves et non de produire des projets. Le soutien de la FSF envers notre projet me semble tout à fait la bienvenu et ne doit surtout pas être refusé. L'apport de la FSF par le partage de l'expérience des administrateurs actuels de Savannah est une chance pour le bon déroulement du projet. De même, le projet Savannah pourra aussi profiter de nos contributions s'il était décidé de poursuivre cette voie. Mais pour tous les inconvénients énoncés précédemment, il me semble plus judicieux d'avoir un serveur au niveau du GET. On peut souligner ici que des partenariats de type promotion commune des serveurs ou même un soutien en matière d'expertise logiciel est en soi une collaboration non négligeable. 6.6 Préconisation personnelle pour PeCoVall / Vision personnelle du projet D'après les constatation précédentes, il serait tout à fait judicieux de passer par l'usage d'un serveur unique disposant communément de Sourceforge et de tous les outils fondamentaux utilisés par celui-ci : Base de données/CVS/Liste de diffusion, etc... Ce qui évitera tout problème de réplication et de synchronisation des projets. De même, nous pourrons faire tourner sur ce serveur trois instances SourceForge (communément modifiés selon nos besoins propres ou pas) pointant sur les outils précédemment cités. On y gagne : * en temps d'administration * en facilité de mise oeuvre * sur le temps de développement du projet (Somme de travail mieux répartie). * en partage des compétences, émulation de groupes * sur la personnalisation de l'outil (design), facile et personnalisable. * en puissance : on peut se permettre d'acheter un serveur puissant * en disponibilité du serveur : 3 administrateurs compétents 'veillant au grain' * sur l'archivage, sur la sauvegarde des données : Un seul serveur à sauvegarder, archiver. * sur la scalabilité de l'outil : rien n'empêchera de scinder (mettre le serveur CVS ailleurs, par exemple) ou de répliquer ce serveur. Les possibles défis technologiques de cette réalisation : * La maîtrise de Sourceforge : Pour ma part, ayant déjà travaillé avec tous les outils utilisant Sourceforge, je me sens tout à fait capable avec, bien entendu, du temps et de la persévérance d'installer ce logiciel. De même, j'espère profiter de l'expérience de proches ayant déjà travaillé sur ce sujet. * L'authentification : arriver à patcher Sourceforge/Savannah pour utiliser des comptes NIS ou LDAP selon les choix locaux de chaque école peut permettre un mise en production très simple et une administration quasi nulle. Actuellement, les comptes sont gardé dans la base de données. On pourra étudier tout type d'intervention : court-circuit, réplication, etc... ajouter la fonctionnalité projet public/privé et son interface d'administration. * La mise en place des 3 instances bien indépendantes utilisant les mêmes outils bas-niveau (à priori, il n'y a pas ou peu de problèmes). * La personnalisation : ceci relèvera du goût, de l'envie et des moyens de chaque école. Chaque école aura sa plate-forme (partie logiciel PHP uniquement) qu'elle pourra modifier à sa guise. Poursuivant mon discours et ma proposition, je me permets ici de vous proposer une ébauche possible d'échéancier si cette proposition semblait vous convaincre : 1. Achat du serveur selon les moyens (serveur puissant et fiable) + les outils de sauvegarde. 2. L'installer sur le réseau à l'ENST Paris ou l'INT. 3. Phase d'adaptation à l'outil Sourceforge (~un mois). 4. Mise en production de l'outil brut Sourceforge ou Savannah. 5. Synchroniser les comptes d'accès au serveur avec les différents architectures des écoles (UNIX/NIS/LDAP), gérer l'hétérogénéité des authentifications. 6. Patcher le code pour disposer des fonctionnalisés spécifiques communes aux trois écoles. 7. Faire tourner trois instances CVS de Sourceforge/Savannah (uniquement le code php, les trois instances disposeront du même serveur CVS, du même serveur Apache, de la même base de données, du même serveur de liste de diffusion...). 8. Patcher son instance indépendamment des autres écoles selon ses propres besoins. (Chaque école modifie à sa guise son instance, charte graphique, fonctionnalités, etc...). 9. Promotion et mise en production du serveur dès septembre. 10. Correction en production et fignolage jusqu'à fin octobre (fin de ma mission). 7 Conclusion Pour toutes les raisons techniques déjà exposées, pour un usage rentable de ma mission et toutes les raisons éthiques précédemment exprimées, je déconseille fortement à l'ENST Bretagne de continuer dans la voie 'Serveur Libre'. Si le 'serveur libre' est choisi, il augmentera le risque d'échec du projet PeCoVall, car dévaluant complètement le qualité technique de l'ensemble logiciel du projet. De même, il est sans nul doute que les possibilités offertes seront moins grandes et le résultat moins probant. S'engager vers une alternative type Sourceforge/Savannah est l'assurance de disposer d'un outil stable, connu et fonctionnel. De même, c'est l'assurance de réunir le soutien de la communauté du libre et de la même façon d'avoir le soutien de développeurs très compétents. Je préconise aussi, pour des raisons d'efficacité et de facilité de mise en oeuvre, l'utilisation d'un seul serveur localisé au niveau du meilleur accès au réseau où fonctionneraient trois instance SourceForge/Savannah personnalisées (une par école) utilisant la même base de données, un même CVS, une même messagerie, etc... Pour ma part, j'ai l'ambition de réaliser un travail innovant qui perdurera après mon départ. Faire en sorte que les étudiants et le monde enseignant/recherche dispose du meilleur outil qui soit, car satisfaisant leurs besoins, est sans nul doute mon objectif. Ceci semble résumer ma mission et je m'engage tout à fait à la respecter. En conséquence, ma proposition en terme de choix technologique s'oriente naturellement vers une solution type SourceForge/Savannah de la façon exprimée précédemment. 8 Bibliographie [http://www.sourceforge.net||Sourceforge] [http://savannah.gnu.org||Savannah] [http://serveur-libre.enst-bretagne.fr||Serveur Libre]