Département de Mathématiques et Informatique Université de La Réunion
RAPPORT DE STAGE DE MASTER M2 INFORMATIQUE
RESPONSABLE PÉDAGOGIQUE: Frédéric MESNARD
ANNÉE UNIVERSITAIRE : 2014-2015
Mise à jour de la liste de diffusion Sympa
STAGE REALISÉ DANS LE SERVICE DE LA DIRECTION DES SYSTÈMES D’INFORMATION (DSI)
Date du stage: 5 janvier au 10 juillet 2015
Réalisé par: Yannis VELECHY
Etudiant: Encadrants: M.Yannis VELECHY M.CARPIER Vincent N◦Etudiant:31003477 M.PEQUIN Laurent Remerciements
Je tiens à remercier dans un premier temps, notre responsable pédagogique M.Frederic Mes- nard enseignant-chercheur en informatique de la Réunion ainsi que tous les acteurs du master informatique, pour toutes les connaissances théoriques et pratiques qu’ils m’ont apportées.
Ensuite je tient à faire un grand remercierement à M. Vincent CARPIER directeur de la DSI (Direction des Systèmes d’Information) et M. Laurent PEQUIN ingénieur réseaux et Re- sponsable du SSI (Service Systèmes d’Information), de m’avoir encadré lors de cette expérience au cours de ces six mois de stage ou ils m’ont apporté conseil dans la réalisation de ma mission.
De plus, je souhaiterais remercier toutes les personnes ayant favorisé à un climat propice à l’apprentissage et au partage de connaissance dans la bonne humeur, notamment M.Jephté Clain, M.Etiènne Gourdon, M.Mamy Haja Rakotobe, M.Matthieu Bannier, M.Teddy Trecasse, M.Loic Mousselet, aussi mon collègues M.Nick Sautron qui à cotoyer les mêmes services que moi, et ainsi les autres stagiaires M.Jerôme Figuin, Michael .... Tables des matières
1 Introduction 5 1.1 Contexte ...... 5 1.2 Problèmatique ...... 5 1.3 Objectifs ...... 5 1.4 L’Université en chiffres ...... 6 1.4.1 Patrimoine immobilier ...... 6 1.4.2 Structures ...... 6 1.4.3 Etudiants ...... 7 1.5 Organisme d’accueil ...... 7 1.5.1 Missions de la DSI ...... 7 1.5.2 Missions de la DUN ...... 8 1.5.3 Organigramme de la DSI ...... 8 1.5.4 Organigramme de la DUN ...... 9
2 Gestion de projet 10 2.1 Présentation de l’équipe de projet ...... 10 2.1.1 Apports et conseilles ...... 10 2.1.2 Planifications avec GanttProject ...... 11 2.1.3 Suivie avec Redmine ...... 13
3 Gestionnaire de liste de diffusion Sympa 13 3.1 Présentation ...... 13 3.1.1 Logo ...... 14 3.1.2 Identité ...... 15 3.1.3 License ...... 15 3.1.4 Fonctionnalité ...... 15 3.1.5 Environnement de Sympa ...... 16 3.1.6 Sympa et la délégation de responsabilité ...... 16 3.1.7 Les spooles ...... 18 3.1.8 Les terminologies des rôles SYMPA ...... 19
4 Réalisation: Phase de test 20 4.1 Veille technologies ...... 20 4.1.1 Prérequis techniques ...... 20 4.2 Organisation de Sympa ...... 21 4.2.1 La hiérachique des fichiers et répertoires de Sympa ...... 21 4.2.2 Panorama de l’organisation de Sympa ...... 22 4.3 Les partitionnements et les systèmes de fichiers ...... 23 4.3.1 Analyse porté sur les «I/O» du serveur Sympa de production ...... 23 4.3.2 Les partitions ...... 24 4.3.3 Les systèmes de fichiers ...... 25 4.4 Installation de Sympa et de ses prérequis ...... 26 4.4.1 Procèdures ...... 26 4.4.2 L’installation des diverses paquets qui ont été téléchargé depuis le dépot de Debian ...... 26 4.4.3 Les paramètres des fichiers de configurations ...... 27 4.5 Service d’authentification CAS ...... 33 4.5.1 Définition ...... 33 4.5.2 Principe ...... 33 4.6 Installation et configuration du module SSL pour Apache2 ...... 36 4.6.1 Vérification que les paquets nécessaires sont déjà installés ...... 36 4.6.2 Création d’un certificat auto-signé ...... 36 4.6.3 Configuration spécifique d’apache ...... 36 4.7 Installation de l’antivirus ClamAV ...... 38 4.7.1 Mise à jour des fichiers disponibles dans les dépôts APT (/etc/apt/sources.list) 38 4.7.2 Installation ...... 38 4.7.3 Installation d’amavis-new ...... 38 4.7.4 Modification dans le fichier(/etc/postfix/master.cf) ...... 38
5 References 40 5.0.5 Sympa ...... 40 5.0.6 Postfix ...... 40 5.0.7 HTTPS ...... 40 5.0.8 Mysql ...... 40
6 Annexe 41 6.0.9 Batteries de test ...... 41 6.0.10 Analyses portée sur les bases de données ...... 43
3 Résumé Dans le cadre de mon stage en fin d’année de Master Informatique, je me suis orienté vers un des projets proposé par les responsables de l’informatique de l’université de la Réunion plus précisément la DSI (Direction des Systèmes d’Information) qui porte donc sur la mise à jour de la liste de diffusion de Sympa. Mon stage fut encadré par Monsieur Carpier Vincent qui est actuellement le directeur et Pequin Laurent Responsable du SSI (Service Systèmes d’Information).
Sympa (Système de multipostage automatique) est un gestionnaire de listes de diffusion qui propose des fonctionnalités avancées au sein d’une interface web riche et sécurisée. Il est utilisé par la grande majorité des établissements d?enseignement supérieur et de recherche français. Il est également très utilisé dans les milieux académiques internationaux ainsi que par de nombreuses organisations (NASA, Unesco, CGT...) des ministères (affaires étrangères, culture, défense, finances...) et des hébergeurs (Infomaniaks, Ouvaton...). On y retrouve la liste des utilisateurs de Sympa qui peut être consultée sur le site du logiciel https://www.sympa.org/users/custom.
A travers de ce rapport nous allons dans un premier temps être amener à découvrir une presentation du gestionnaire de liste de diffusion Sympa, ensuite suivra dans un second ordre les procèdures qui ont été mise en oeuvre afin de réaliser l’objectif qui à été posé.
Enfin nous terminerons se rapport sur une conclusion général portant sur l’analyse de l’ensemble des opérations qui ont été menée.
Abstract
As part of my internship at the end of my last years master’s degree, I referred to a project proposed by the university IT managers Reunion specifically ISD (Information Systems Depart- ment) which concerns the updating of the mailing list of Sympa. My internship was supervised by Mr. Vincent Carpier currently the director and Laurent Pequin responsible SSI (Service Information System). Sympa (automatic multipostage System) is a mailing list manager that provides advanced capabilities in a rich and secure web interface. It is used by the vast majority of the french Higher Education and Research institutions. It is also widely used in international academic circles and by many organizations (NASA, UNESCO, ... SGC) ministries (foreign affairs, culture, defense, finance ...) and hosting (Infomaniaks, Ouvaton .. .). It contains the list of users that Sympa can be found on the software website url https://www.sympa.org/users/custom. Through this report we will initially discover a presentation mailing list manager Sympa, then in a second part the procedures that have been implemented in order to achieve the objective that has been posed. Finally we will finish this report on a general conclusion as to the analysis of the set of operations that have been conducted.
4 1 Introduction
1.1 Contexte Ce rapport de stage a été édité par Yannis VELECHY dans le cadre du stage de fin d’étude du master informatique de l’Université de la Réunion. Ce satge a été encadré par:
• M.Vincent CARPIER Directeur de la DSI (Direction des Systèmes d’Information) • M.Laurent PEQUIN Responsable de la SSI (Services Systèmes d’Information)
Les listes de diffusion permettent à des personnes d’un même groupe ou partageant un même centre d’intérêt d’échanger, par l’intermédiaire du courrier électronique, des informations et des idées. Chaque personne peut écrire à l’adresse électronique de la liste. Un serveur automate se charge de distribuer les messages à toutes les personnes qui se sont/ont été abonnées à la liste. L’information est livrée directement dans la boîte aux lettres électron- ique des abonnés. L’abonnement est gratuit. Il est également possible de lire les messages classés par thèmes et de partager des documents et des ressources. Pour garder le gestionnaire de liste de diffusion en bon état de performances il est donc néces- saires de mettre à jour ce-dernier. Afin de pouvour réussir il est nécessaire de le déployer sur un autre serveur de test afin de mener à bien l’objectif pour éviter de porter des modifications sur le serveur Sympa de production.
1.2 Problèmatique Le gestionnaire de liste de diffusion Sympa de l’Université de la Réunion est le coeur de la communication de l’établissement entre à la fois les professeurs, les étudiants, les personnels, les chercheurs, les doctorants et aussi aux personnes extérieur désirant y participé etc ... Voilà maintenant quelques années qui se sont écoulé depuis l’installation du gestionnaire de liste de diffusion à l’Université de la Réunion et il y a pas eu jusqu’a maintenant une mise à jour de ce-dernier. Pour remedier à problèmes, cela découle donc de la réalisation de se projet afin dans un premier temps de mettre à jour le gestionnaire de liste de diffusion Sympa pour permettre l’utilisation de ces nouvelles fonctionnalités, et dans un second ordre d’ussé des autres opportunité que nous offres les acteurs de Sympa.
1.3 Objectifs Afin de mettre à jour le gestionnnaire de liste de diffusion de Sympa plusieurs phase vont être mis en oeuvre. D’une part pusiqu’on ne peut intervenir directement sur la liste de diffusion de Sympa puisqu’il est actuellement en production (en service). Ci-dessous les diverses phases qui vont permettre de mener à bien se projet. Dans un premier temp on vera l’élaboration de la gestion du projet qui va être mise en place afin de déterminer les procèdures avenir. Ensuite dans un second ordre viendra la phse de test dans lequel on va mettre en place l’ensemble des dispositi pris lors de la phase précedent. Enfin la dernier phase sera la mise en production afin de mettre en service le gestionnaire de liste de diffusion de Sympa avec ses nouvelles fonctionnalites qu’on été apporté par les acteurs de Sympa.
5 1.4 L’Université en chiffres 1.4.1 Patrimoine immobilier L’Université de La Réunion est implantée sur 6 sites universitaires
• Campus du Moufia : 53 973 m2
• Campus du Tampon : 18 706 m2
• Site de Saint-Pierre : 9 462 m2
• Parc Technologique Universitaire : 8 373 m2
• Site de la Victoire : 2 911 m2
• Site de Bellepierre : 9 587 m2
1.4.2 Structures L’Université de La Réunion, est se décompose en:
• 5 unités de formation et de recherche (UFR)
– UFR Droit et Economie – UFR Sciences et Technologies – UFR Lettres et Sciences Humaines – UFR Sciences de l’Homme et de l’Environnement – UFR Santé
• 5 instituts et écoles
– Institut d’Administration des Entreprises – Institut Universitaire de Technologie – Ecole Supérieure d’Ingénieurs Réunion Océan Indien – Ecole Supérieure du Professorat et de l’Education – Observatoires des Sciences de l’Univers - Réunion
• 3 départements internes de formation
– Centre de Formation des Apprentis – Institut Confucius – Institut de l’Illettrisme
• 21 unités de recherche, dont 7 unités mixtes de recherche (UMR)
6 1.4.3 Etudiants L’Université de la Réunion est à accueilli pour l’année universitaire 13999 d’étudiants. Ci-dessous leur répartition dans diverse composantes.
1.5 Organisme d’accueil Ce stage fut réalisé dans les locaux de la DSI (Direction des Systèmes d’Information) de l’Université de La Réunion, plus précisément dans le service de la SSI (Services Systèmes d’Information). Pendant la période de ce stage, la DSIUN (La Direction du Système d’Information et des Us- ages Numérique) nom que porté juqu’ici le département de l’informatique, fut divisé en deux directions qui sont la DSI et la DUN (Direction des Usages du Numérique) afin de répondre aux nouveaux enjeux de développement liés aux technologies informatiques et aux usages du numérique. Ces nouvelles directions apportent un soutien actif aux acteurs de l’Université, dans l’ensemble des domaines de la pédagogie, de la recherche, de l’insertion professionnelle des étudiants dans le cadre des besoins des usagers et les évolutions apportées par le numérique.
1.5.1 Missions de la DSI La DSI a pour mission de proposer et mettre en oeuvre la politique du système d’information dans le domaine du traitement informatisé ou numérique de l’information relative à l’enseignement, à la recherche, à la documentation et à la gestion. Son périmètre d’action regroupe toutes les composantes et services de l’établissement. Ainsi lors de ce stage j’ai put être amener à constater que la DSI est un support essentiel pour le coeur décisionnel de pilotage de l’Université de La Réunion, notamment au travers de la centralisation des données de gestion et du développement de l’Environnement Numérique du travail.
7 1.5.2 Missions de la DUN La direction des usages du numérique (DUN) est un service central qui repose sur deux grandes missions transversales : l’accompagnement pédagogique au numérique ainsi que la production et la diffusion de ressources numériques.
L’accompagnement des enseignants et des étudiants dans l’évolution de la pédagogie univer- sitaire, la gestion du Certificat Informatique et Internet (C2I) pour les personnels et étudiants ainsi que l’accompagnement des chercheurs en calcul scientifique sont les principales activités du Service du Numérique et de l’Accompagnement Pédagogique.
Le Service Audiovisuel et du Multimédia, quant à lui, développe une politique de produc- tion et de diffusion de ressources numériques et explore de nouveaux champs de la diffusion des connaissances. Il pilote également le développement et le déploiement d’infrastructures et d’outils de communication. La DSI et la DUN se décompose respectivements de trois et de deux services.
1.5.3 Organigramme de la DSI
Figure 1: Organigramme de la DSI de l’Université de La Réunion
• SIP: Service d’Infrastruture de Proximité • SIC: Service d’Infrastructure centrale • SSI: Service de Systèmes d’Information
8 1.5.4 Organigramme de la DUN
Figure 2: Organigramme de la DUN de l’Université de La Réunion
• SIP: Service d’Infrastruture de Proximité • SIC: Service d’Infrastructure centrale • SSI: Service de Systèmes d’Information
9 2 Gestion de projet
2.1 Présentation de l’équipe de projet Durant mon stage j’ai travaillé en équipe avec les personnels de la DSI (Direction des Systèmes d’Information) plus précisément avec le directeur Vincent CARPIER et Laurent Pequin. L’organigramme ci-dessous représente les personnes qui ont contribué à ce que ce projet soit réalisé.
Figure 3: Organigramme de l’équipe de projet
2.1.1 Apports et conseilles Pendant l’avancement de ce projet avec les membres de l’équipe du projet, ces-dernier m’ont apporté correction sur les procédures à mettre en place afin de mener à bien la mise à jour de la liste de diffusion Sympa. Il m’a été demandé aussi, une compréhension générale et spécifique du gestionnaire de listes de diffusion Sympa afin de prendre connaissances de l’organisation qui existe sur le serveur Sympa actuelle et ainsi d’apporter des comparaisons avec la nouvelle mise à jour qui va être effectué.
10 2.1.2 Planifications avec GanttProject Afin de mener à bien se projet l’équipe impose de definir un diagramme de Gantt. Ce dernier est un outil permettant de modéliser la planification des tâches nécessaires qui se succèdera au cours de ces six mois de stage. Ensuite lors de la réalisation de ces différentes tâches une réunion été tenue avec la présence de M.Vincent CARPIER afin de lui soumettre les résultats de l’avancement du projet. La figure suivant montre une capture du diagramme portant sur le projet et qui a été réalisé par GanttProject
Figure 4: Gantt-partie-1 Organigramme de l’équipe de projet
11 (a) Diagramme de Gantt-partie-2
(b) Diagramme de Gantt-partie-3
Figure 5: Diagramme de Gantt
12 2.1.3 Suivie avec Redmine Pour permettre aux membres de l’équipe de se tenir au courant de l’évolution du projet précisé- ment des tâches réalisé, il a été décidé d’inscrire le projet dans l’outil Redmime de l’Université de La Réunion. Redmine est une application web de gestion de projet ou l’avancement, les anomalies, la sup- pression, l’ajout des tâches,etc..., peuvent être observés.
Figure 6: Diagramme de Gantt
3 Gestionnaire de liste de diffusion Sympa
3.1 Présentation SYMPA est un serveur de listes de diffusion et de discussion, libre et gratuit. Il offre des fonctions de gestion de listes pour les abonnements, la modération, les archives, le partage de documents et de projets. Il est développé par le Comité Réseau des Universités, situé à Rennes, et utilisé par de nombreuses universités et administrations de France et du monde entier. Ses capacités et sa fiabilité, avec des listes pouvant dépasser les 700 000 abonnés, en fait un outil reconnu. Il s’adapte aussi bien aux petites structures (et/ou peut être partagé entre plusieurs), qu’aux grandes, sans souci d’indiscrétion (une liste pouvant être cachée à tous).
Sympa est un produit conçu pour opérer un service de listes de diffusion, il permet de paramétrer dans le serveur les éléments d’une politique de listes qui est l’ensemble des règles qui assurent la sécurité, le respect des obligations réglementaires, l’équité et la transparence du service.
13 3.1.1 Logo
Figure 7: Logo de Sympa
Une des qualités revendiquées de Sympa est sont intégration dans le systèmes d’informations. Il est en mesure de gérer:
• Authentification
• Autorisation
• Interface WEB
• Définition des ensembles d’abonnés
• Définition des ensembles de listes
• Intégration d’autres applications
Ci-dessous une image qui illustre ces qualités
Figure 8: Integration de Sympa dans le SI
14 3.1.2 Identité • Développeurs:
– Christophe Wolfhugel – Serge Aumont – Olivier Salaün – David Verdin – Étienne Méléard
• Première version: 1 Avril 1997 • Dernière version: 6.1.24 • Écrit en: Perl • Environnement: Unix et dérivés • Langue: multilingue • Type: Gestionnaire de liste de diffusion • Site web: www.sympa.org
3.1.3 License Sympa est un logiciel libre, on être amener à le distribuer selon les termes de la GNU General Public License Version 2. On peut faire et donner des copies exactes sans restriction, à condition qu’on duplique toutes les mentions de copyright originales et les avertissements associés.
3.1.4 Fonctionnalité Sympa fournit toutes les fonctionnalités de base que tout logiciel de gestion de liste de diffusion devrait inclure. Alors que la plupart des caractéristiques Sympa ont leurs équivalents dans d’autres applications de listes de diffusion, Sympa est unique en incluant des fonctionnalités dans un seul logiciel. exemple de ces caractéristiques:
• Haute vitesse de traitement de distribution et de contrôle de la charge. Sympa peut être accordé pour permettre à l’administrateur système de contrôler la quantité de ressources utilisé par l’ordinateur . Son algorithme optimisé permet:
– L’utilisation du moteur SMTP selon notre préférence,ex: Sendmail, Qmail ou Postfix – Réglage du nombre maximum de processus fils SMTP – Regroupement des messages selon les domaines des destinataires – La journalisation détaillée – L’interface utilisateur multilingue. – L’interface web wwwsympa est un interface web régroupant tous les fonctionnalités de Sympa (incluant l’administration).Celui-ci fournit: ∗ Une classification des listes, avec un index de recherche ∗ Un contrôle d’accès à toutes les fonctions y compris la liste des listes
15 • Sympa extrait les pièces jointes des messages entrants et lance un scanne de virus sur eux. Il travaille généralement avec McAfee / uvscan, FSecure / fsav, Sophos, AVP, Trend Micro / VirusWall et Clam Antivirus.
• Authentification par LDAP via l’uid et e-mails stockés dans des répertoires LDAP.
• ...
3.1.5 Environnement de Sympa La figure ci-dessous illustre de manière générale tous les acteurs qui permettent le bon fonction- nement de Sympa.
Figure 9: Environnementde Sympa
3.1.6 Sympa et la délégation de responsabilité Pour fonctionner Sympa met en œuvre un certain nombre de démons qui ont toutes un rôle important dans le chainage du fonctionnement de Sympa. Le tableau ci-dessous liste la plupart des Démons principaux:
16 Roles et Privilèges Description (Super)Listmaster Ce sont les personnes qui administrent le service, ils sont défini dans le fichier de sympa.conf. Ils héritent du rôle de listmaster dans les hôtes virtuels et sont l’ensemble des listmasters pour les hôtes virtuels par défaut (Robot)Listmaster Définir un ensemble différent de listmasters à un niveau d’hôte virtuel (dans le fichier robot.conf). Ils sont responsables de la modération créa- tion de listes de diffusion (si la création de liste est configuré de cette façon), fournir de l’aide à la liste des propriétaires et des modérateurs Propriétaires privilégiés Le premier propriétaire privilégiée défini est la personne qui a demandé de la liste la création de la liste. Plus tard, il peut être modifié ou étendu. Ils héri- tent (de base) des privilèges de propriétaire et sont également respons- ables de la gestion des propriétaires de la liste et les éditeurs eux-mêmes (par le biais de l’interface Web) list owners Chaque liste est gérée par un propriétaire. Il peut modifier les paramètres de la liste (par exemple réserver la consultation de la liste aux abonnés, ou l’ouvrir à tous...).. Il peut abonner ou désabonner des personnes à cette liste. Cependant, pour la plupart des listes, ce sont les personnes elles-mêmes qui choisissent de s’abonner à une liste ou de s’en désabonner. Moderateurs (ou édi- Les modérateurs sont responsables des messages diffusés dans la liste teurs) de diffusion (par opposition aux propriétaires qui occupent les membres de la liste). Les modérateurs sont actifs si la liste a été monté en tant que liste de diffusion modérée. Si aucun modérateur est défini pour la liste, alors les propriétaires de la liste hériteront du rôle de modéra- teur. Lorsqu’une liste est modérée, chaque message envoyé à la liste est d’abord envoyé au modérateur. C’est lui qui pourra ensuite valider ou non la diffusion du message aux abonnés. Cela fait partie des options choisies par le propriétaire de la liste. Abonnés (ou membres Les abonnés sont des personnes qui sont membres d’une liste de diffu- de la liste) sion, soit ils ont souscrit à la liste, ou ils sont ajoutées directement par Listmaster ou via une source de données (LDAP, SQL, une autre liste, ...)
17 3.1.7 Les spooles Les spooles est un systèmes de stockages de différentes types de messages. Il est défini de manière hiérarchisé comme présenté dans le tableau ci-dessous. Ces répertoires est scanner continuellement par diverses types de programme pour leur permettre d’exécuter leur tâches.
Répertoires Description /var/spool/sympa/auth/ Pour le stockage des messages jusqu’à ce qu’ils aient été con- firmées. Les fichiers sont créés et traités par le programme de sympa.pl /var/spool/sympa/bounce/ Pour stocker les messages entrants non-délivré. Les fichiers sont créés par le programme de bouncequeue (via alias de messagerie) et traitées par le démon bounced.pl /var/spool/sympa/bounce/bad Pour stocker les messages non-délivré pour lesquels la gestion de ce dernier a échoué,bien que l’utilisateur a été identifié. Les fichiers sont déplacés ici par le démon bounced.pl /var/spool/sympa/digest/ Pour stocker un message digère avant qu’ils ne soient envoyés. Les fichiers sont créés et traités par le démon sympa.pl /var/spool/sympa/mod/ Pour le stockage des messages non modéré. Les fichiers sont créés par le programme de sympa.pl et traitées soit par sympa.pl ou wwsympa.fcgi /var/spool/sympa/msg/ Pour stocker les messages entrants. Les fichiers sont créés par le programme queue (via alias de messagerie) et traités par le programme de sympa.pl /var/spool/sympa/msg/bad/ Sympa stocke les messages rejetés dans ce répertoire. Les fichiers sont créés par le démon sympa.pl /var/spool/sympa/distribute/ Pour le stockage des messages prêts pour la distribution. Ce spool est utilisé uniquement si l’installation lance 2 démons sympa.pl, l’un pour les commandes, et l’autre pour les mes- sages /var/spool/sympa/distribute/bad/ Sympa stocke les messages rejetés dans ce répertoire. Les fichiers sont créés par le processus sympa.pl dédiée à la distri- bution de message /var/spool/sympa/task/ Pour le stockage de toutes les tâches créées. Les fichiers sont créés et traités par le démon task_manager.pl /var/spool/sympa/outgoing/ sympa.pl copie les messages dans ce spool pour attendre archivage par archived.pl. wwsympa.fcgi peut également créer des fichiers dans ce spool /var/spool/sympa/outgoing/bad Pour le stockage des messages qui ne pouvaient pas être archivés. Les fichiers sont déplacés ici par le démon archived.pl
18 3.1.8 Les terminologies des rôles SYMPA Sympa permet d’attribuer des rôles aux utilisateurs (identifiés via leurs adresses e-mail) à dif- férents niveaux dans Sympa. Les privilèges sont associés (ou peuvent être associés) à ces rôles. Ci-dessous l’énumération des rôles (de la plus puissante pour le moins), ainsi que les privilèges pertinents. Programme Description Sympa.pl Démon principal il traite les commandes et prépare des messages dans la base de données. Scanne en continue le msg bulk.pl Démon de distribution de message. Scanne en permanence la base de données la table bulkmailer_table et envoie des messages tel que préparé par sympa.pl wwsympa.fcgi Programme CGI offrant une interface web complète aux listes de diffusion. Il peut fonctionner dans les deux modes de CGI et FastCGI classiques, bien que nous recommandons mode FastCGI, être jusqu’à 10 fois plus rapide bounced.pl Ce démon traite les bounces (messages non livrés), recherche les mauvaises adresses. Les propriétaires de liste vont ultérieure- ment accéder à l’information des bouncespar l’intermédiaire de WWSympa (l’interface web). Scanne en permanence le /spool/bounces Archived.pl Démon qui alimente les archives web, convertie les messages de txt en format HTML et il lié les deux. Il utilise le pro- gramme MhOnArc . canne en continue les message sortant /var/spool/outgoing task_manager.pl Démon qui gère les tâches: (la création, la vérification, l’exécution). Scanne régulièrement les tâches /var/spool/task/ queue Petit programme qui recupère les messages entrants à partir des alias et les stockes dans /var/spool/msg bouncequeue Même programme que queue qui recupère les messages entrants à partir des alias et les stockes dans /var/spool/bounce familyqueue Même programme que queue qui recupère les messages entrants à partir des alias et les stockes dans /var/spool/automatic
19 4 Réalisation: Phase de test
4.1 Veille technologies 4.1.1 Prérequis techniques Pour réaliser l’objectif viser de ce projet,celui-ci demande des conditions préalables nécessaires. Ci-dessous les prérequis matériels/logiciels indispensable:
• Un serveur de test (Neutre)
• Debian 7.8 (Version courante)
• Wheezy-Backports (Version courante)
– Postfix (Version courante)
– Mysql (Version courante)
– Apache2 (Version courante)
– Sympa 6.1.23
– Autres
Résumé: Pour la mise en oeuvre de Sympa celui-ci nécessite une base de donnée (Mysql) qui va par exem- ple gérer les authentifications interne de Sympa, ensuite il a besoin d’un serveur de messagerie électronique pour gérer l’envoie et la réception des messages, puis d’un annuaire LDAP pour permettre une authentification CAS par exemple, et le serveur Apache qui va gérer les requêtes HTTP.
20 4.2 Organisation de Sympa 4.2.1 La hiérachique des fichiers et répertoires de Sympa Ci-dessous un aperçu de ce que Sympa une fois installé sur le système. Cela illustre également la philosophie Sympa. Presque tous les fichiers de configuration peuvent être définis pour une liste particulière, pour un hôte virtuel ou pour l’ensemble du site, et la plupart d’entre eux ont une valeur raisonnable par défaut fourni par la distribution Sympa.
Figure 10: Survol hiérachique des fichiers et répertoires de Sympa
21 4.2.2 Panorama de l’organisation de Sympa Afin d’appréhender le fonctionnement de Sympa, la figure ci-dessous nous donne un panorama de l’organisation de Sympa.
Figure 11: Panorama de l’organisation de Sympa
Résumé: Commençons par le démon principal sympa.pl ou celui-ci va recevoir et diffuser les messages via postfix (mailman, qmail ou exim). Il consulte et modifie les listes d’abonnés dans la base de Données. Il alimente archived.pl après diffusion d’un message. Ensuite le démon wwsympa.fcgi qui peut recevoir des requêtes du serveur HTTP (Apache), faire des mises à jour dans la base de données. Il délègue la diffusion des messages à Sympa via un spoule. Puis le bounced.pl est le démon de traitement des rapports de non-remise. Il reçoit ceux-ci du moteur SMTP et met à jour la base de données. Vien ensuite le démon archived.pl quiest chargé de l’archivage. Il traite les messages du spool « outgoing » et les convertit en template HTML utilisés par wwsympa.fcgi. Et enfin le démon taskmanager.pl qui permet de gérer tous les taches de sympa.
22 4.3 Les partitionnements et les systèmes de fichiers 4.3.1 Analyse porté sur les «I/O» du serveur Sympa de production Cette partie présente la phase d’analyse qui à été menée au cours de la phase de test du projet. Le tableau suivant décrit diverses activités qui sont opérer sur le disque dur actuelle du serveur de production Sympa. Ces résultats vont permettre de mettre en place les nouvelles configu- rations (partitionnement) du disque dur ou celui-ci, accueillera le nouveau serveur de liste de diffusion. I/O(Lecture/Ecriture) Les partitions Les en- Description concernant le choix sur le disque trées/Sorties des systèmes de fichiers de l’ordre de Lecture: 5k/s Ecriture: / 10(I/O)/s Racine (root), à laquelle seront at- 3k/s tachés tous les autres sous-répertoires Lecture: Ecriture: 0k/s /boot 0(I/O)/s Ça va être plutôt de la lecture, il n’a pas besoin d’être journalisé, donc prévoit de l’Ext2, pas besoin de grande performance, pas d’écriture/lecture en permanence Lecture: Ecriture: ~4k/ /swap 2(I/O)/s Dans le cadre de cette analyse, cette s partition n’a pas était trop sollicité comparé à celle de /var, donc peu d’entrée/Sortie sur le disque. Mais comme il s’agit d’un « serveur » on va suivre les règles avec une capacité de 2 fois la RAM Lecture: ~4k/s Ecrit- /var 20(I/O)/s Dans ce répertoire par rapport au /etc. ure: ~144k/s on aura de gros entrées/Sortie, car il va accueillir la base de donnée (le coeur de MYSQL se trouve là ), je propose de favoriser la mémoire cache car les I/O sur la mémoire RAM et plus rapide que celle des I/O du disque dur. Les logs qui eux aussi fait assez d’écriture sur le disque à chaque sollicitation de l’interface web Lecture: ~7k/s Ecrit- /archives 25(I/O)/s Dans cette partition on aura besoin ure: ~14k/s de la journalisation pour s’assurer de l’intégrité des données en cas d’une panne, ensuite comme les données sont de petites tailles donc des blocs de 4ko seront suffisant donc voir Ext3 ou XFS( préférer de Debian) Concernant le volume on aurait besoin d’un assez grand espace de stockage (au moins 100 Go),car l’archivage actuel est de 50 Go et ce depuis une mise en oeuvre de 7 ans
23 4.3.2 Les partitions Ci-dessous nous allons faire le descriptif des partitionnements qui a été mis en place pour permettre au serveur de Sympa de fonctionné d’une part avec les meilleures performances et d’une autre de pouvoir l’opérer en un minimum de temps dans le cas d’une panne. Le tableau ci-dessous a été élaboré après les analyses observé sur le serveur de liste de diffusion actuelle (production).
Partition Point de montage Type de partition Taille /dev/sda1 swap Primaire 3Go /dev/sda2 /boot Primaire 100Mo /dev/sda3 /var Primaire 10Go /dev/sda5 /archives Logique 132Go /dev/sda6 /ext4 Logique 11Go
Remarque Après analyse porté sur 6 mois il en résulte que la taille de l’archive a augmenté de 7Go. Pour une utilisation sur 5 ans il faut prévoir une quantité d’espace d’au moins 77Go. En résumé 50Go + 77Go + 5 Go supplémentaire = 132Go
Au niveau de la mémoire:
Memoire CPU Mémoire RAM:Taille 2Go CPU:Quantité 2
Résumé Concernant la mémoire RAM Swap il a été préconisé une mémoire important car, après analyse de la mémoire effectué avec la commande htop il a été relever que pour une utilisation quasi ba- nal c’est-à-dire (des abonner en ligne) alors on a un taux d’occupation de la mémoire d’environ de 1.5 Go RAM, donc pour une meilleur performance on prévois donc un besoin d’au moins de 2 Go RAM avec 1 Go pour le swap )
Pour le CPU, celui-ci va rester inchangé puisque lors des analyses effectuées sur le disque dur il a été observé que pour les abonnées actives (en lignes) les processus sollicité le besoin d’un seul processeur.
24 4.3.3 Les systèmes de fichiers Nous abordons ici les systèmes de fichiers qui permet d’organiser et de stocker une arborescence sur un support (disque, disquette, cd ...). Sous linux il existe quelques systèmes de fichiers qui ont chacun leur avantages parmi eux on retrouve l’ext2 qui ne propose pas par exemple de journalisation, on a ensuite son successeur l’ext3 qui a pour principale différence l’utilisation d’un fichier journal, lui permet d’éviter la longue phase de récupération lors d’un arrêt brutal de la machine. Ensuite vient l’ext4 successeur de l’ext3 ou la fonctionnalité majeure de ext4 est l’allocation par extent qui permettent la pré-allocation d’une zone contiguë pour un fichier, pour minimiser la fragmentation ainsi d’augmenter les performances du disque dur.
Nous allons procéder ci-dessous au choix du système de fichier qui ont été effectué on con- sidération des attendu qui vont être mis sur le nouveau serveur de production.
Partition Point de montage Systèmes de fichiers Journalisable /dev/sda1 swap swap non /dev/sda2 /boot ext2 non /dev/sda3 /var ext4 oui /dev/sda5 /archives ext4 oui /dev/sda6 /ext4 ext4 oui Résumé: Concernant la premier partition ou figure le point de montage swap celui utilise comme type de systèmes de fichiers le swap qui sert de mémoire virtuelle. Ensuite il a été choisi de mettre comme type de systèmes de fichier ext2 sur le point de montage afin de privilégier du non journalisation car il y a très peu d’écriture qui est fait sur cette partition. Contrairement aux deux partitions précédent, celui a besoin d’être journalisé, et de plus comme c’est une partition ou certains branche hiérarchique peuvent contenir des gros fichiers alors il a été choisi de prendre comme systèmes de fichiers de l’ext4 afin d’usé de sa nouvelle fonctionnalités qui permet de mieux gérer les gros fichiers. Pour la partition ou va être stocké l’archive celui va aussi bénéficier des atouts du système de fichiers ext4 par exemple de la journalisation mais aussi de textitl’extends même si celui comporte en moyenne des petits fichiers. Enfin nous avons la dernier partition qui va stocker la racine de l’arborescence du système de fichiers, ou celui va avoir comme précédemment de l’ext4 comme type de systèmes de fichiers pour garantir la journalisation de ce-dernier et de textitl’extends.
25 4.4 Installation de Sympa et de ses prérequis 4.4.1 Procèdures Dans cette partie nous allons voir comment la procédure de l’installation a été effectué nous aborderons d’abord le choix des installations, puis nous aborderons quelques paramètre princi- paux dans les fichiers de configurations. Au départ de ce projet lors de la phase d’analyse (test) il y a eu une question pour déter- miné comment l’installation de Sympa doit-il se faire pour qu’il puisse être efficace. Après des recherches sur internet principalement sur le site de Sympa ou de Debian on a pu voir diverses possibilité pour procédé à l’installation, on a vu que cela prouvé se faire par le packages que proposé la communauté de Sympa. Mais lors d’une recherche dans le WheezyBackport que pro- pose les acteurs de Debian on sait aperçu qu’il proposé l’installation de la version Sympa6.1.23 avec la version de Debian Debian7.1. Ceci est une opportunité qui nous à été offert du fait du nombre de module que fait intervenir l’installation de Sympa. Un autre avantage qu’on tire se cela, c’est que nous pouvons s’attendre à ce que l’installation de Sympa puisse être mise à jour par les acteurs de Debian (la communauté), ce qui ait ici un avantage pour l’équipe de la DSI. Pour commencer la phase de l’installation de Sympa en utilisant le Wheezy-backport, il m’a paru logique de commencer les installations des prérequis de Sympa afin que lors de l’installation de celui-ci le gestionnaire de packages utilisé, va nous proposer la configuration automatique de ces acteurs pour qu’ils puissent s’interrogées si besoin ait. Ci-dessous le chainâges de l’installation:
• Débian • Apache • Postfix • Mysql • Sympa
Les diverses versions ci-dessus ont été installé depuis le dépôt de Debian, a l’exception de l’installe de Debian qui ces fait à partir d’un .iso de version 7.1 et qui à connu une migration avec la commande upgrade ce qui nous amène à la dernière version disponible Debian 7.8 lors de la réalisation de ce projet. Nous allons voir ci-dessous les diverses parties de l’installation et des configurations qui permet que l’ensemble des acteurs puissent s’interroger. Ces configurations ont été d’une part proposées lors des installations à l’aide du gestionnaire de paquets et d’autre part modifié à la main lors des phases de test dans le but de s’appréhender de l’importance de ces divers paramètres que constitue les fichiers de configurations.
4.4.2 L’installation des diverses paquets qui ont été téléchargé depuis le dépot de Debian apt-get -t wheezy-backports install debian apt-get -t wheezy-backports install Apache apt-get -t wheezy-backports install Postfix apt-get -t wheezy-backports install Mysql apt-get -t wheezy-backports install Sympa
Remarque Pour un meilleur visuel, les différentes commandes ci-dessus n’ont pas été exécutées dans en même temps. Chacune d’eux ont été effectué une fois que l’installation précèdent été terminé.
26 4.4.3 Les paramètres des fichiers de configurations Nous allons étudier dans les étapes suivantes, les paramètres des fichiers de configurations
• Configuration spécifique d’Apache pour Sympa Nous procédons dans cette partie à la création d’une machine virtuel (virtualhost) spéci- fique pour le serveur de listes de diffusion qui sera accessible à l’adresse http://sympa-test. univ.run/ et on verra plus loin qu’il devra être accessible de manière sécurisé https: //sympa-test.univ.run/ (voir la session configuration du module SSL pour apache).
Comme nous avons vu dans les parties précédents tous les installations vont se faire sur une machine virtuel de test nommée jusqu’ici sympa-test afin de ne pas interrompre le serveur actuelle de production. Dans la liste de paramètre principaux figurant ci- dessus nous définissons un administrateur comme son nom l’indique c’est celui qui va administrer le serveur en cas de panne ou pour toutes autres modifications. Ensuite viens le nom du serveur asso.univ-reunion.fr, ou celui-ci sera à charge de la gestion de ce nom de domaine. On définit ensuite des règles dans la balise de
Figure 12: Cheminements des requêtes vers le serveur Apache
Ainsi lors d’une requête comme par exemple l’affichage de l’interface web de Sympa celui-ci va d’abord passer par le DNS de l’université de La Réunion, ou celui-ci indiquera l’adresse
27 IP de la machine à charge de ces requêtes. Une fois que le DNS à fait la translation en adresse IP, la machine en questions va être sollicité c’est la dire la machine virtuel sympa- test,disposant d’un serveur apache. Ce serveur d’apache est à l’écoute des requêtes HTTP va donc prendre en charge la requête est permettre l’affichage de l’interface web de Sympa. Activation des modifications apportées à la machine virtuelle et le recharge- ment du serveur Apache
A2ensite defaut Service apache reload
• Configuration de Postfix
Myhostname= sympa-test.univ.run Myorigin = $$myhostname Mydestination = sympa-test_courrier-non-domaine, localhost.localdomain, localhost, sympa-test.univ.run, asso.univ-reunion.fr relayhost =[smtp.univ.run] mynetworks = 127.0.0.1/8 voir aussi les réseaux local mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all
Résumé La configuration ci-dessous nous décrit les étapes nécessaires pour la mise en œuvre du serveur de messagerie. Nous avons d’une part le premier paramètre Myhostname qui cor- respond au nom de la machine serveur SMTP. Ensuite nous avons le paramètre Myorigin qui représente le domaine qui sera utilisé pour être affiché dans le courrier sortant. En- suite vient le paramètre destination qui détermine les noms de domaine pour lesquels on accepte le courrier. Puis nous avons l’utilisation du relai de l’Université de La Réunion qui va servir d’intermédiaire entre le serveur postfix actuelle et les clients. Par défauts, Postfix relai le courrier des clients des réseaux autorisés et des domaines autorisés ceci avec le paramètremynetworks, dans le cas de ce projet on n’autorise que la machine lo- cale. Vient ensuite les trois dernière lignes ou le premier paramètre définit la taille limite des messages ici il y a pas de limite, le second permet de séparer le nom d’utilisateurs et l’extension d’adresse enfin le dernier définit que la machine est à l’écoute sur tous ces interfaces. Pour terminé la configuration dans le fichier (main.cf) on rajoute les lignes suivantes qui permet de définir le nombre de destinataire par message délivré.
# SYMPA parameters; sympa_destination_recipient_limit = 1 sympabounce_destination_recipient_limit = 1
28 On va maintenant apporté une Modification dans le fichier (/etc/postfix/master.cf) Ceci afin que Postfix comprenne qui est « sympa » et « sympabounce » en rajoutant les lignes suivantes
#Configuration for Sympa Mailing Lists sympa unix - n n - - pipe flags=R user=sympa argv /usr/lib/sympa/bin/queue ${recipient} sympabounce unix - n n - - pipe flags=R user=sympa argv /usr/lib/sympa/bin/queue/bouncequeue ${recipient}
Une fois la modification effectue on relance Postfix avec la commande suivantes pour valider la configuration
Service postfix reload
Dans les étapes qui vont suivre nous allons aborder la définition des alias de Sympa et sa configurations. Les alias mail sont recommandé par Sympa pour le daemon sympa.pl afin de recevoir les commandes mail et les messages des listes. Un gestionnaire de liste électronique tel que Sympa est construite autour de deux processus (étapes) – L’envoie de message vers la liste ou vers Sympa lui-même est reçu par le serveur SMTP. Lors de l réception du message le serveur SMTP lance le programme tex- titqueue pour stocker les messages dans les spool. – Le démon sympa.pl qui est monté dès le démarrage du système, va scanner les spool. Dès qu’il détecte un message il traite et effectue les actions demandés (distribution ou traitement des commandes). Pour séparer les traitements des commandes(inscription, désinscriptions, demande d’aide, etc. . . ) des traitements des messages destinée au gestionnaire de liste. Un mail alias spé- cial est réservé pour les requêtes administratives, ce qui permet à Sympa d’être accessible en permanence aux utilisateurs. Pour commencer on va procèdé à la création du fichier (/etc/mail/sympa/aliases) qui va contenir les futurs allias de messagerie de tous les listes qui vont être créé sous le domaine asso.univ-reunion.fr à l’aide du gestionnaire de d’alias que dispose Sympa et qui est lancer par wwsympa.
Vim /etc/mail/sympa/aliases
On porte une modification des paramètres alias_maps et alias_database dans (/etc/postfix/main.cf) de la manière suivantes: alias_maps = hash:/etc/aliases, hash:/etc/mail/sympa/aliases alias_database = hash:/etc/aliases, hash:/etc/mail/sympa/aliases
Cela à pour but de configurer le gestionnaire d’alias (alias manager) pour qu’on puissent l’indiquer ou est–ce qu’il peut créer les alias de messagerie de tous les listes. Remarque Ici on à fait un ajout d’alias, si ces lignes contenaient plus de fichiers que seulement hash:/etc/aliases au départ, il est nécessaire de les garder.
29 Une fois que le fichier est crée on va définir les alias de messagerie dans le fichier pour réorienté les messages vers les exécutables de Sympa chargés de les traiter.
## List aliases used for the sympa mailing-list manager sympa: "| /usr/lib/sympa/bin/queue [email protected]" listmaster: "| /usr/lib/sympa/bin/queue [email protected]" bounce+*: "| /usr/lib/sympa/bin/bouncequeue [email protected]" abuse-feedback-report: "| /usr/lib/sympa/bin/bouncequeue [email protected]" sympa-request: [email protected] sympa-owner: [email protected]
Après des modifications porté des mise à jour de la base d’alias est nécessaires pour prendre en compte les changements.
newaliases
De même qu’avec le relancement de Postfix
Service postfix reload Service postfix restart
• Configuration de Mysql Dans cette partie on va retrouver les paramètres qui sont utilisé afin de mettre en place la base de données. Ces paramètres sont des paramètres qu’on retrouve comme souvent dans une base de donnes comme par exemple le nom de la machine, le nom de la base de données, le mot de passe du super Utilisateur (root) et d’un utilisateur, et diverses paramètres. • Configuration de Sympa La configuration de Sympa se passe principalement dans le fichier de configuration de /etc/sympa/sympa.conf et /etc/sympa/wwsympa.conf Durant l’installation de Sympa, des informations concernant la correspondance entre Sympa et la base de donnée ont été demandé comme par exemple (mot de passe de l’administrateur de la base de donnée, définir un utilisateur pour Sympa.Mais ces infor- mations peuvent être modifié dans les fichiers de configurations cités précédement.
Une fois l’installations terminé, il resté plus qu’a tester qu’on à bien accès à l’interface web de Sympa. Le test terminé on constate que l’interface web de Sympa ne fonctionnait pas.
Après des recherches effectué il se trouvé que le FASTCGI n’été pas activé. Nécessité d’activé le FASTCGI.Pour cela il fallait se rendre dans le fichier (/etc/sympa/sympa.conf) et renseigner la valeur 1 pour le paramètre suivant :
Use-fast-cgi 1
Ce qui va permettre l’affichage de l’interface web Sympa, qui pour fonctionner à besoin du fastCGI Maintenant on va consulte le fichier de configurations(/etc/sympa/sympa.conf et lister queleques paramètres principaux. Pour commencer nous avons le nom du domaine de se
30 robot principal sous lequels seront traité tous les émails. Main robot hostname domain asso.univ-reunion.fr Puis nous avons la définition de l’url de l’interface web de Sympa qui est:
## URL of main Web page wwsympa_url http://sympa-test.univ.run/wws
On ensuite l’augmentation de niveau de verbosité des logs
## Log verbosity ## 0: normal, 2,3,4: for debug log_level 3
Ici, plus le niveau est élevé plus les fichiers de logues concernant Sympa seront verbeux Ensuite on à les données concernant les la base de données de Sympa, on retrouve le nom de la base de données, l’utilisateur, mot de passe, etc..
## Name of the database db_name sympa ## User for the database connection db_user sympa ## Password for the database connection db_passwd password
Et enfin une fois ces modifications apportées ont relance le service Sympa et Apache
Service sympa reload && service sympa restart && service apache2 restart
Enfin nous aborderons ci-dessous un point intéressant de Sympa qui sont les machines virtuelle de Sympa. Dans le contexte de la réalisation de ce projet il y a nécessité de gérer qu’un seul domaine, mais on peut être amené pour plus tard à crée un autre domaine, du coup on va le configurer comme un hôte virtuel. De cette manière, lors de l’ajout d’un hôte virtuel, il y a aucun risque de se retrouver avec des configurations de listes ou de robot sur plusieurs niveaux. Pour chaque robot, il est nécessaire de créer ses propres répertoires et fichiers de configuration. Donc il nous faut procéder à la création du répertoire et du fichier robot.conf qui ressemble au fichier de configuration de /etc/sympa/sympa.conf
Mkdir /etc/sympa/asso.univ-reunion.fr/ Chmod 750 /etc/sympa/asso.univ-reunion.fr Vim /etc/sympa/asso.univ-reunion.fr/robot.conf
Une fois qu’on à créer le répertoire et le fichier robot.conf, celui-ci va être modifié sur deux principaux paramètre en particuliers.
## URL of a virtual host http_host asso.univ-reunion.fr
## Listmasters email wwsympa_url http://sympa-test.univ.run/wws listmaster [email protected], [email protected], [email protected], [email protected], [email protected]
31 Puis on apporte des modifications sur le groupe et utilisateur du répertoire afin que sympa puisse écrire dans ce répertoire.
Chown –R sympa :sympa /etc/sympa/asso.univ-reunion.fr/
Enfin comme la machine virtuelle de Sympa on doit aussi créer un répertoire avec comme nom du domaine associé à se robot et on recharge le service Sympa et Apache afin de prendre en compte les nouveaux changements. mkdir /var/lib/sympa/list_data/asso.univ-reunion.fr chown sympa :sympa /var/lib/sympa/list_data/asso.univ-reunion.fr Service sympa reload && service sympa restart && service apache2 restart
Finalement une fois accédé à l’interface web de Sympa on a procédé à quelques tests et ont vu que les listes créer se retrouve dans les répertoires en questions.
32 4.5 Service d’authentification CAS 4.5.1 Définition CAS est un système d’authentification créé par l’Université Yale. C’est un système d’authentification unique. Il a pour but d’offrir une page d’authentification avec le login et le mot de passe à travers un interface Web. Une fois que nous avons indiqué les informations permettant de s’authentifié la validation de celui-ci va nous permettre de nous loguer auprès d’un serveur CAS. Une fois authentifié on pourra bénéficier de l’avantage du CAS qui va faire de manière automatique nous authentifié sur tous les sites web qui utilise le même serveur CAS cela nous évite de nous loguer à chaque fois qu’on accède à une application en mettant en place un système de ticket.
4.5.2 Principe Ci dessous une répresentation de se fonctionnement avec Sympa
Figure 13: Le cheminements de CAS
Résumé Nous avons un utilisateur par exemple un étudiant de La Réunion qui se rend sur la page web de la liste de diffusion Sympa. Une fois sur le site il décide de se loguer pour consulter ses émail et il va donc être redirigé vers la page CAS (interface web), pour lui permettre de s’authentifié. Le serveur CAS reçoit sa demande d’authentification il va donc vérifier s’y le client possède un ticket valide si oui alors le serveur CAS va retourner au démon Sympa l’UID du client. , sinon le serveur CAS lui remet un ticket valide. Quand le démon Sympa reçoit L’UID du client celui va contacter l’annuaire LDAP afin de récupérer l’émail du client et permettre son authentification au sein de l’interface web de Sympa avec comme information qu’il est loguer et aussi l’affichage de son adresse email sur le haut de page à gauche. Une fois connecter si le client décide d’aller sur le site web de l’Université de La Réunion alors il va voir que son authentification au sein de cette page c’est fait de manière automatique.
33 Nous allons voir ci-dessous l’installation et la configuration de ce concept
• Installation du module CAS Pour permettre l’utilisation du CAS sur le serveur test on va procéder à l’installation du module avec la commmande suivante
apt-get -t wheezy-backports install libauthcas-perl
Une fois que le module à put être installé nous allons porter des modifications dans le fichier /etc/sympa/auth.conf Ce fichier permet de définir quel méthodes d’ authenfica- tion Sympa va appliquer lors de l’authentification au sein de l’interface web de Sympa.
• Ajout de l’authentification CAS dans /etc/sympa/auth.conf
cas base_url https://cas.univ-reunion.fr:443 login_path /cas/login/ auth_service_name Authentification-Centrale ldap_host ldap.univ.run:389 ldap_get_email_by_uid_filter (uid=[uid]) ldap_timeout 20 ldap_suffix ou=user,dc=univ-reunion,dc=fr ldap_scope sub ldap_email_attribute mail
Résumé Pour permettre la gestion de l’authentification du CAS dans Sympa on doit dans le fichier /etc/sympa/auth.conf ajouter le paragraphe CAS et ces diverses paramètre comme présenté ci-dessus. Les paramètres s’affichant dans le paragraphe CAS ci-dessus nous renseigne de l’adresse du serveur CAS, le chemin d’accès du service de login auprès du serveur CAS, le nom du service qui va s’affiché sur la page web de Sympa, de l’adresse du serveur LDAP, qu’on va faire un filtrage par UID du client afin d’obtenir l’émail, que le temps maximal est de 20 secondes maximum pour que nous obtenons le résultat du filtrage. Puis nous avons aussi la branche de LDAP par lequel on doit commencer la recherche ici sa sera dans le groupe user, du nom de domaine univ-reunion avec comme point racine le .fr. Viens ensuite la recherche dans tous les sous branches de l’arbre et pour terminer l’attribut email à récupérer dans le LDAP. Ensuite lors d’une tentative d’authentification je constate que je ne suis pas redirigé vers Sympa, je reste figé sur la page login & mdp du serveur CAS De ce fait je me rencontre que la correspondance d’adresse du serveur CAS n’a pas été défini On va donc dans l’étape suivant faire la correspondance d’adresse du serveur CAS avec le nom de domaine.
• Modification du fichier /etc/hosts Permettre la correspondance d’adresse du serveur CAS avec le nom de domaine
10.82.70.83 cas.univ-reunion.fr
Après l’ajout de celui-ci le problème à été résolu et finalement on obtient la récupération de l’émail de l’utilisateur par le démon Sympa et ainsi permettre son affichage au sein de l’interface web.
34 • Ajout de l’authentification user_table dans /etc/sympa/auth.conf Dans les étapes précédentes nous avons défini une méthode d’authentification qui permet seulement l’authentification des personnels de l’Université de La Réunion se qui restreindre l’accès aux personnes de l’extérieur souhaitant s’inscrire ou s’authentifié sur l’interface web de Sympa. Du coup dans cette partie nous allons voir que Sympa permet de répondre à cette con- trainte car il peut gérer jusqu’à quatre mode d’authentification.
user_table regexp .*
Ce paragraphe est lié à l’authentification interne de Sympa par email et password La seule seul directive ou paramètre sont regexp ou negativeregexpquisontdesexpressionsréguliersappliquésurunadressemailfournie. Après modification apporté à ce fichier il y a besoin de redémarrer wwsympa.fcgi, on effectue donc le redémarrage d’apache
• Redémarrage du service Apache
Service apache restart
35 4.6 Installation et configuration du module SSL pour Apache2 Dans cette partie nous allons voir comment assuré la communication entre un client et un serveur à travers les différentes étapes de configurations et des installations qui en découleront dans cette partie.
4.6.1 Vérification que les paquets nécessaires sont déjà installés Pour permettre l’utilisation du module SSL pour Apache, il est nécessaire que les paquets ci-dessous soient installés.
• libssl0.9.8
• openssl
• ssl-cert
Pour effectuer les vérification sur se paquets il fallait regarder avec la premièr commande ci- dessous si les paquets été installé. Une facon de connaitre cette information été possible grace à cette commmande. Pour y parvenir il fallait regarder si oui ou non il possèder les deux lettres ii en suffixe, si c’est le cas alors il été déjà installés. Sinon il falllait exécuter la deuxième commande ci-dessous :
Dpkg -l | grep ssl apt-get install openssl
4.6.2 Création d’un certificat auto-signé L’utilisation d’une connexion SSL, nécessite d’avoir un certificat signé, mais celui-ci en terme de coup est trop chers. Pour cela on va utiliser une autre méthode qui consiste à créer un certificat auto-signé, certes qui est considéré comme non sûr par les navigateurs mais qui est suffisant pour obtenir une connexion SSL au serveur. Comme tout niveau de sécurisation qui soient SSL, HTTPS cela nécissite la création de certificats. Comme on se trouve sur Apache on va donc créer un certificat et le stockés dans le répertoire suivants /etc/apache/ssl Cela a été éffectuer avec la deuxième commande ci-dessous
/usr/sbin/make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/certs/sympa-test.univ.run.pem
Nous avons notre certificat qui se trouve à dans le fichier suivants /etc/ssl/certs/sympa-test. univ.run.pem Maintenant qu’on à notre certificat il faut le placer dans le serveur et c’est ce qu’on va voir dans l’étape suivants:
4.6.3 Configuration spécifique d’apache Concernant le paramétrage d’Apache pour un site Sécurisé il nous faut s’assurer que le serveur apache écoute sur le port 443. Se trouvant sur Apache il faut éditer le fichier /etc/apache2/ ports.conf et vérifier que la ligne Listen 443 y soit bien présente. Une fois qu’on s’est assuré que le port 443 est ouvert on va donc procédé à la création d’une machine virtuel afin de prendre en compte notre certificat SSL
36 La création de cette machine virtuel c’est fait dans le répertoire suivants /etc/apache2/ sites-available/sympa qui se nomme Sympa. Ensuite on insert le certificat dans le serveur comme dans le code ci-dessous.
SSLEngine On SSLCertificateFile /etc/ssl/certs/sympa-test.univ.run.pem DocumentRoot /var/www
ErrorLog /var/log/apache2/error.log LogLevel warn
CustomLog /var/log/apache2/access.log combined ServerSignature On
Enfin il ne reste plus qu’a activé certains module et ainsi le redemarrage du serveur Apache comme ci-dessous. Si on se rend sur l’interface web de Sympa avec comme adresse https: //sympa-test.univ.run/wws/ normalement on va être basculer sur la page sécurisé ou il y aurra besoin de comfirmer l’accés à la page car on le rappele que ce n’est pas un certificats signé par une autorité de certification mais un certificats auto-signé.
A2enmod ssl A2ensite sympa Service apache restart
37 4.7 Installation de l’antivirus ClamAV Dans cette partie nous allons mettre en place un antivirus afin de consulter les emails rentrant et les emails sortant. Nous allons voir dans cette section la mise en place d’un antivirus sur le serveur de test afin que celui scanne les emails entrant et sortant mais aussi les archives et spooles.
4.7.1 Mise à jour des fichiers disponibles dans les dépôts APT (/etc/apt/sources.list) 4.7.2 Installation 4.7.3 Installation d’amavis-new 4.7.4 Modification dans le fichier(/etc/postfix/master.cf)
38 Bilan du projet
Le projet continue son avancement, actuellement sur l’étape de la migration de la base de données de Sympa de production vers le serveur de test.
L’avancement de ce projet arrive presque qu’à la fin de la Réalisation de phase de test il ne manque que l’étape de la migration de Sympa. Ainsi lors de la réalisation de ce-dernier on pourra valider la fin de cette phase de test et passer en phase de production.
Enfin une fois que la phase de réalisation terminé on va procéder à la quelques vérifications de sécurité (panne, etc...), mettre en place une procédure de remise en production dans les plus brefs délais.
39 5 References
5.0.5 Sympa http://www.sympa.org https://sympa-test.univ.run/wws/help/introduction http://www.vgsi.fr/files/Tutoriel-Sympa-Ubuntu.pdf http://www.sympa.org/distribution/current/INSTALL https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769074 http://irp.nain-t.net/doku.php/200messagerie:040postfix4:010_principe https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-fcgid/+bug/1266400
5.0.6 Postfix http://postfix.traduc.org/index.php/BASIC_CONFIGURATION_README.html#myhostname http://www.securite-informatique.gouv.fr/gp_article106.html http://www.sympa.org/faq/postfix_howto http://wiki.auto-hebergement.fr/serveurs/postfix
5.0.7 HTTPS http://www.linux-france.org/prj/edu/archinet/systeme/ch23s05.html https://technique.arscenic.org/lamp-linux-apache-mysql-php/apache/modules-complementaires/ article/installer-et-configurer-ssl-pour https://wiki.debian.org/Self-Signed_Certificate
5.0.8 Mysql http://www.sympa.org/internals/database#spool_table http://www.alsacreations.com/tuto/lire/615-installation-configuration-MySQL.html http://www.lifl.fr/~mailliet/miage2/cours_magali/MySQL/Tables.html
40 6 Annexe
6.0.9 Batteries de test Les messages Etude sur divers tests afin de s’assurer de l’envoi et la réception des messages sur Sympa
Figure 14: Envoie de message
41 Les familles des listes
(a) Famille de listes
(b) Famille de listes
42 Figure 15: Famille de listes
6.0.10 Analyses portée sur les bases de données Objectif Analyse porte sur la base de données de Sympa actuelle (de production) avec celui de test sympa-test », afin de déterminer quels sont les modifications qui ont été apporté, quel sont les nouveaux champs qui ont été rajouté dans les tables et voir si ces champs peut prendre comme valeur vide ou pas pour certains attributs de la table. Rappel sur les bases de données de :
• Production On se connecte sur la base de donnée, avec comme non d’hôte cri-bdd.univ.run, en tant qu’utilisateur sympa, et son mot de passe. La base de données de la production contient à son actif 10 tables. • Test On se connecte sur la base de donnée, avec comme non d’hôte sympa , en tant qu’utilisateur sympa et son mot de passe. La base de données de la production contient à son actif 12 tables. Remarque Les tables présentées ci-dessous contiennent uniquement des informations (champs) qui ont été rajouté ou modifié
Dans les prochaines lignes ci-dessous nous allons porter une analyse sur les diverses tables afin de voir ce qui a été modifié ou rajouté et proposé une lecture des tables.
43 La listes de ableaux
• bulkmailer_table
Figure 16: Table bulkmailer-table
Nous avons deux nouveaux champs qui apparaissent « messageid_bulkmailer » et « merge_bulkmailer » . Le premier est de type « varchar(200) », on voit que sa valeur peut être omise « YES » et qu’il prend comme valeur par défauts « NULL ». Ensuite pour le deuxième champ on à peu près les mêmes valeurs que le premier sauf pour le type ou celui-ci est une « int »
Remarque générale Que dans la plupart des tables présentées, ils prennent tous comme valeur par défaut « NULL », donc on peut dire que si l’attribut « NULL » des tables nous renseigne qu’un champ doit avoir obligatoirement une valeur ceci par la valeur « NO », alors dans on est assuré d’avoir au minimum la valeur « NULL »
• admin_tables
Figure 17: Table bulkmailer_table
Cette table contient les informations sur les administrateurs, on peut y retrouvé leurs rôles (editor,owner,etc. . . ),emails, etc. . . Aucun modification sur cette table (concernant les valeurs des attributs : « Field », « Type », « Null », « Key », « Default »)
44 • bulkspool_table
Figure 18: Table bulkspool_table
• logs_table Cette table stocke tous les évènements important (il peut nous informer à quelle heure tel action a été effectué, il peut identifier le message qui a déclenché l’action, il peut identifier l’adresse IP à partir duquel le message a été envoyé, etc...)
Figure 19: Table logs_table
• netidmap_table Les valeurs de l’attribut « Default» ont été modifié pour certains champs
Figure 20: Table netidmap_table
45 • one_time_ticket_table Stocke des informations concernant les tickets (authentification) Aucun modification sur la table concernant les valeurs de ces attributs : Field, Type , Null , Key , Default , Extra
• session_table Cette table permet la gestion des sessions http
Figure 21: Table session_table
Résumé Pour le moment je n’ai rien trouvé sur les deux champs qui ont été rajouté
• subscriber_table Cette table stocke les abonnements, les options d’abonnements, etc..
Figure 22: Table subscriber_table
46 • user_table Cette table est principalement utilisée pour gérer la connexion à partir de l’interface web. Remarque : Un abonné peut ne pas apparaitre dans cette table s’il ne sait jamais connecté via l’interface web.
Figure 23: Table user_table
L’ajout de deux tables
• exclusion_table Cette table est utilisée afin de gérer les désabonnements pour les abonnées inclus à partir d’une source de données externe
Figure 24: Table exclusion_table
Résumé : Pour le moment je n’ai rien trouvé sur ces nouveaux champs
47 • list_table Cette table stocke les options des listes
Figure 25: Table list_table
Résumé Pour le moment je n’ai rien trouvé sur ces nouveaux champs
48