Refonte d'une solution libre d'archivage de courrier électronique

Rapport de stage Master 2 Professionnel Compétence complémentaire en informatique Sous la responsabilité de Fabien Granjon Guillaume Storchi Refonte d'une solution libre d'archivage de courrier électronique Responsable de stage Pr. Pascal Sicard Le 5 Septembre 2006

Sommaire Liste de Figures Remerciements Partie I : Contexte de travail et déroulement du stage 1 1) Relation entre le monde du logiciel libre et celui de l'entreprise 2 2) Présentation de l'entreprise et de son activité 2 3) Déroulement du stage 3 4) Les technologies employées 3 Partie II : La solution d'archivage OMA Fonctionnement et architecture 4 1) Introduction 5 2) Analyse, dépôt et mise à jour de la base de données 6 2.1) Structure et fonctionnement 6 2.1.1) Analyse de l'entête 6 2.1.2) Copie du message sur le système de fichier 6 2.1.3) Insertion dans la base de données 7 i) Etude d'une structure théorique 7 ii) Choix dùune structure optimisée 7 2.2) Problèmes rencontrés dans la version 1.0.0 et améliorations apportées par la version 2.0.0 8 2.2.1) Une analyse et un formatage éronés de l'entête principale 8 2.2.2) Mise en place d'un nouveau script 8 2.3) Bilan 3) Le Serveur 9 10 3.1) Les fonctionnalités du serveur 10 3.2) Principe de fonctionnement des différentes connections 10 3.2.1) Communication démon à démon 11 3.2.2) Communication client démon 11 3.3) Algorithmes des démons 11 3.3.1) Démon principal (Figure 9) 11 3.3.2) Démon d'archivage (Figure 10) 12 3.4) Traitements effectués par le serveur d'archivage : l'archivage et la restauration. 12 3.4.1) Archivage des fichiers 12 3.4.2) Restauration des fichiers 13

3.5) Les plugins 13 3.5.1) La classe Plugins : interface des plugins 13 3.5.2) Implémentation de plugins 14 i) Plugin d'accès à medium 14 ii) Plugin de restauration 14 3.5.3) Conclusion 14 3.6) Bilan du développement de la partie serveur 4) Interface Web 15 16 4.1) Les fonctionnalités 16 4.2) Developpement à venir 17 5) Conclusion 18 Partie III Bilan du stage 19 1) Bilan technique 20 2) Bilan professionnel 21 Références Annexes

Liste des figures Figure 1: Organigramme de l'entreprise 2 Figure 2: Feuille de route du stage 3 Figure 3: Exemple d'architecture réseau à laquelle peut s'intégrer un 5 serveur dédié à l'archivage Figure 4: Répresentation de l'architecture de la partie de récupération 6 du message par OMA Figure 5: Exemple d'entête principale d'un message 6 Figure 6: Schéma de l'algorithme du script mail_delivery.php 7 Figure 7: Diagramme de classe de la structure des données 8 Figure 8: Diagramme de classe de la structure des données de la version 8 2.0.0 Figure 9: Schéma des communicatons démon-démon et client-démon 10 Figure 10: Algorithme du démon principal (omad) 11 Figure 11: Algorithme du démon d'archivage 11 Figure 12: Schéma des flux d'archivage et de restauration 12 Figure 13: Diagramme de classe de l'implémentation des plugins 13 Figure 14: Onglet de configuration de l'application 16 Figure 15:Interface de consultation des messages de la base de données 16 Figure 16: écrans d'une procédure d'archivage 16

Remerciements Je tiens tout particulièrement à adresser ma reconnaissance envers toutes les personnes d'octant Informatique, pour leur sérieux, leur haut niveau de compétence et leur expérience du monde de l'informatique libre. Merci à Alain Ganuchaud, directeur et fondateur de la société pour le cadre qu'il a su apporter à ce stage, et pour sa sympathie. Merci à Stéphane Willotte, pour ses surprises quotidiennes, et sa gentillesse. Une grande part de ma reconnaissance va logiquement à Didier Granjon, pour sa disponibilité, son aide précieuse, sa maîtrise de l'environnement GNU/Linux, et les petits travaux pratiques en réseau. Finalement ce stage n'aurait su exister sans Fabien Granjon, qui s'est présenté comme l'interlocuteur central et le guide indispensable à ce premier travail de taille significative. Merci pour ta disponibilité et ton oeil perspicace, j'ai beaucoup appris et beaucoup retenu grâce à toi.

Partie I Contexte de travail et déroulement du stage

Directeur Technique (Alain Ganuchaud) Ingénieur systèmes et réseaux (Didier Granjon) Ingénieur de développement (Fabien Granjon) Figure 1: Organigramme de l'entreprise Directeur Commerciale (Thierry Lenenbach) Technicien maintenance réseau et développement (Stéphane Willotte)

1) Relation entre le monde du logiciel libre et celui de l'entreprise Le monde informatique comporte deux grands courants : Le logiciel propriétaire, fondé sur une dynamique purement économique, qui propose des solutions développées sous licence qui implique un caractère payant au produit, et un non accès au code source. Le logiciel libre, aujourd'hui largement constitué de passionnés, mais aussi d'entreprises, est à l'origine issu du monde universitaire. La licence (GPL: General Public Licence) sous laquelle est rendu disponible un produit, permet sa modification ainsi que sa redistribution libres et gratuites, et interdit toute distribution à but lucratif. Aujourd'hui les solutions libres font l'objet d'un intérêt toujours grandissant de la part des informaticiens mais aussi des entreprises, d'une part pour sa flexibilité, sa stabilité et sa sécurité. Ce dernier point est crucial depuis le début du large développement que connaît internet, et donc la possibilité d'accéder à des activités sensibles à travers les réseaux. Utiliser un produit sous licence GPL pour des activités même très sensibles est une chose très répandue, mais délivrer le fruit d'un développement sous licence GPL l'est moins. Cependant ce dernier point présente des avantages séduisants que sont les termes de sa licence: gratuit donc intéressant économiquement, et aussi son caractère adaptatif très fort du fait de l'accès libre au code source et à sa modification. De cette manière une entreprise (qui développe ou bien redistribue) peut mettre en avant son expertise du produit et est en mesure de pouvoir proposer des solutions sur mesure à ses clients, ce que ne permet pas forcément les solutions propriétaires. 2) Présentation de l'entreprise et de son activité Octant informatique est une SARL fondée en 2000 et aujourd'hui composées de cinq employés (Figure 1). Les activités reposent en majeure partie sur le déploiement de solutions libres et open-sources (et propriétaires dans quelques cas particuliers) en matière de sécurité et infrastructures réseaux (mise en place, audit). Une partie des prestations est orientée sur le développement de solutions libres appliquées à des problématiques de gestion de l'entreprise (ERP, solutions d'archivage) et c'est dans ce cadre que s'inscrit le projet qui m'a été confié.

1 Stabilisation de la version 1: Tâche Statut Durée (j) Améliorer l'analyse des adresses emails permettant de fiabiliser l'écriture sur le système de fichier l'insertion des données dans la base de donnée Fait 15 Ecriture du script de remplacement de maildrop Fait 2 Mise à jour de la fonctionnalité de règles de filtrage Fait 1 Mise à jour l'interface des règles de filtrage Fait 1 Analyse de la situation et établissement de la stratégie de récupération de l'existent A faire 2 Récupération de l'existent sur antartic2 A faire 5 Statut Durée (j) Conception de la structure et mise en place de la base de données. Réorganisation de l'arborescence des fichiers de l'application Fait 3 Réécriture des classes permettant l'interaction avec la base de données Réécriture du script d'insertion des mails Fait 5 6 En cours 30 IHM gestion des sessions (Admin, Users...) * Limitations de l'accès aux IHM d'administration * Confidentialité des résultats des requêtes de consultation des mails Mise en place d'alias utilisateurs (pb des adresses malformatées) * Limitation du nombre de lignes affichées * Affichage d'une ligne par mail (celle du sender) + possibilité d'affichage des lignes des recipients * Housekeeping (Planification de l'archivage automatique) A faire 15 IHM Sécuriser la récupération des champs des emails Sécuriser les entrées utilisateur A faire 1 Internationalisation fr FR, en US A faire 1 Mise en place d'une maquette et tests A faire 3 Création d'un package (archive avec script install.sh) Documentation fr en A faire 6 Mise en production et migration A faire? 2 Conception et développement de la version 2: Tâche Développement du moteur d'archivage les démons (interpréteur commande, communication) les plugins d'archivage * conception du framework * développement du framework (classe abstraite) * développement des plugins * gestion configuration propre au plugin * intégration 3 Fonctionnalités futures Mise en place d'une structure dynamique de la base de données Gestion des sessions utilisateurs au niveau des démons Figure 2: Feuille de route du stage

3- Déroulement du stage Sous la responsabilité de Fabien Granjon, j'ai été chargé de développer en grande partie la version 2 d'un produit d'archivage de courrier électronique. L'application présente chez plusieurs clients, présentait quelques dysfonctionnements. Des points spécifiques devaient être fiabilisés, et de nouvelles fonctionnalités ajoutées. Ainsi, deux phases de travail se sont dessinées: 1) Appréhension (prise en main) de la solution Fiabilisation des versions en production 2) a)réécriture du produit afin de mettre en place une architecture modulaire et intégration de nouvelles fonctionnalités b) Internationalisation documentation et packaging du produit afin qu'il soit exploitable par la communauté opensource 4) Les technologies employées L'ensemble du travail a été réalisé sur un système de type GNU/Linux, utilisant uniquement des technologies libres. Le langage utilisé, PHP5, grâce à sa flexibilité, sa bonne intégration au système Linux, ainsi qu'au serveur web Apache, a permis un développement rapide et très bien adapté au contexte d'évolution de l'application.

Partie II La solution d'archivage OMA Fonctionnement et architecture

Figure 3: Exemple d'architecture réseau à laquelle peut s'intégrer un serveur dédié à l'archivage

1) Introduction La communication est un point crucial dans la vie d'une entreprise et celle-ci passe aujourd'hui très majoritairement par le courrier électronique. Ces échanges sont présents dans la vie interne de l'entreprise son organisation et donc sa productivité, et dans la communication avec le monde extérieur, les clients, les partenaires etc... Dans l'avenir il est possible d'imaginer que ces courriers puissent faire office de preuve sur le plan juridique en cas de conflit entre deux contractuels. C'est pourquoi Octant Informatique a choisi de développer une solution d'archivage de courrier électronique permettant : La consultation des courriels échangés L'archivage des courriels sur des supports afin de les conserver sur plusieurs dizaines d'années La restitution des courriels archivés Le produit baptisé OMA (Octant Mail Archiver) a été entièrement développé en PHP et délivré sous licence GPL pour les systèmes de type Linux et Unix. Le serveur de messagerie (MTA) transmet une copie de chaque mail qu'il reçoit ou envoie à un programme tiers. Ce dernier analyse la copie qu'il reçoit en entrée standard et la dépose sur le système de fichiers et de mettre a jour la base de données. On peux qualifier ce programme de MDA. Les mails ainsi copiés pourront être archivés sur différents types de media, et restaurés selon différentes procédures. L'ensemble de la solution est administrable par le biais d'une interface web ou à distance via un client telnet. Son ergonomie permet une administration et une utilisation facilitées. La première version fut développée par Fabien Granjon suite à la demande d'un client. Cette version (1.0.0), actuellement en production sur plusieurs serveurs, présente plusieurs défauts qui imposent une maintenance lourde accessible au seul développeur du produit. Son développement et sa mise en production a soulever les faiblesses et de ce fait les améliorations que l'on pouvait apporter. C'est la raison pour laquelle la refonte de solution a été décidée. Tout comme la version antérieure, la version 2.0.0 se scinde en deux fonctions distinctes: Analyse, dépôt et créations des enregistrements dans la base de données, des copies de mails acheminé par le MTA (Postfix). Consultation, archivage et restauration des mails. Nous verrons plus en détails le fonctionnement de chacune de ces parties au cours de ce rapport.

Figure 4: Répresentation de l'architecture de la partie de récupération du message par OMA X-Account-Key: account2 X-UIDL: GmailId10d4a855b797342e X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Gmail-Received: 8bbeeff65fc8e9d6bc33f739f61067aa22e3b18e Received: by 10.90.29.19 with HTTP; Sat, 26 Aug 2006 05:47:36-0700 (PDT) Message-ID: <3bdaca8a0608260547v344a6800s3d0f278c8f19925@mail.gmail.com> Date: Sat, 26 Aug 2006 14:47:36 +0200 From: "exemple1" <exemple1@gmail.com> To: "exemple2" <exemple2@gmail.com>, "exemple3" <exemple3@gmail.com>, "exemple4" <exemple4@hotmail.com> Subject: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_part_13632_11873027.1156596456368" Delivered-To: exemple1@gmail.com Figure 5: Exemple d'entête principale d'un message

2) Analyse, dépôt et mise à jour de la base de données L'analyse, le dépôt et la mise à jour de la base de données sont effectués par le script «mail_delivery.php». Celui-ci a constitué la première partie du travail que j'ai effectué lors de ce stage. Il m'a permis une première approche du langage PHP, du contexte de fonctionnement de l'application et de ces constituants. Ce script est un élément critique de la solution car l'intégrité des informations contenues dans la base de données dépend de l'analyse effectuée par celui-ci. De plus il se doit d'être performant afin de ne pas surcharger le serveur de messagerie. La première version (1.0.0) se basait sur le MDA Maildrop pour réaliser ces étapes. Cette solution a été abandonnée aux vues des dysfonctionnements et des problèmes de performance rencontrés. 2.1) Structure et fonctionnement Le script mail_delivery.php est chargé d'analyser l'entête principal du message, et de copier celui sur le système de fichiers, et au final de stocker les informations relatives à ce message dans la base de données. (Figure 4) L'utilisation de cette copie garantit la conservation du message original et donc un fonctionnement sécurisé du module MDA. 2.1.1) Analyse de l'entête Cette étape est critique dans la mesure où elle est chargée de récupérer les informations nécessaires aux étapes suivantes de stockages des données, et permet de garantir la pérennité de la solution, terme qui constitue la définition même de l'archivage. Elle consiste en la récupération et le formatage du contenu des différents champs de l'entête principale (Figure 5). Soit : -le décodage des caractères et/ou l'encodage en UNICODE UTF-8 -le test de la conformité des adresses (à l'aide d'une expression régulière) et leur modification vers une forme du type 'utilisateur@domaine', -le formatage de la date -la sécurisation des chaînes pouvant contenir des balises script PHP 2.1.2) Copie du message sur le système de fichiers La copie d'un fichier se fait dans un répertoire dont le chemin relatif est de la forme 'domaine/utilisateur/{receiv sent}/new/nom_de_fichier' pour une adresse de la forme 'utilisateur@domain' et de type 'receiv' ou 'sent' respectivement pour l'adresse d'un destinataire ou de l'expéditeur. Cette copie n'est réalisée que lorsque le message n'est pas filtré par le script mail_delivery.php et que les destinataires et expéditeurs appartiennent aux domaines designés comme internes (Figure 5).

Les relations LesMessages LesFichiersMessage MessageFichierIndex Figure 6: Diagramme de classe de la structure des données théorique Les relations LesMessages LesFichiersMessage Figure 7: Diagramme de classe de la structure des données optimisée pour l'insertion

2.1.3) Insertion dans la base de données La base de données est un autre pilier de l'application avec le système de fichiers local du serveur dédié, sachant qu'elle contient l'ensemble des informations nécessaires à la localisation d'un message archivé ou non, et qu'elle permet de réaliser les procédures d'archivage et de restauration. La conception de la structure des données a été élaborée dans un souci d'optimisation du temps d'insertion donc de leur nombre pour chaque courriel traité. i) Étude d'une structure théorique La mise en place de la structure des données suit les étapes théoriques, partant du diagramme UML présenté en Figure 7. La méthode théorique de choix des relations impose la création de trois tables dont la table MessageFichiers, qui contient les identifiants des deux autres relations à savoir id,nom (Permet la jointure des deux tables principales en évitant la redondance des informations). La partie MDA est celle qui doit être la plus rapide et par conséquent les trois étapes d'analyse et formatage, de copie sur le système de fichiers et d'insertion dans la base de données, doivent être les plus rapides possible. Dans ce but d'optimisation, le nombre de ces insertions doit être aussi limité que possible. Lorsque l'on regarde la structure des données précédemment décrite, on peut constater que pour un message donné le minimum d'insertion réalisée est de 5 dans le cas ou un des champs destinataire ou expéditeur est externe au domaine, soit: 2 insertions dans la table Les Messages, (1 pour l'expéditeur, 1 pour le destinataire) 1 insertion dans la table LesFichiersMessage (l'adresse externe ne nécessite pas de copie sur le système de fichiers car aucun utilisateur correspondant n'est utilisateur au sein du domaine) 2 insertions dans la table de jointure. Dans le cas d'un simple message envoyé en interne, le nombre d'insertions s'élève donc à 6. Une autre modélisation a été étudiée, et cette fois-ci ne respectant pas la démarche théorique, en introduisant une redondance d'information(figure 8). Cette fois-ci la classe «Fichier» comporte des données de la classe «Message», ce qui permet de passer à une relation 1-n et donc d'éviter la création d'une table de jointure. ii) Choix d'une structure optimisée Lorsque l'on réalise le décompte du nombre d'insertion celui-ci descend à un minimum de 3 quelque soit la nature des expéditeur et/ou destinataires (au moins un des deux doit être interne au domaine). Au final pour un modèle moins théorique, les performances d'insertion sont multipliées au maximum par deux.

Figure 8:Schéma de l'algorithme du script mail_ delivery.php

2.2) Problèmes rencontrés dans la version 1.0.0 et améliorations apportées par la version 2.0.0 Des dysfonctionnements ont été décelés en production comme une diminution non maîtrisée de l'espace disque disponible pour le stockage des fichiers malgré la réalisation fréquente d'archivage des messages. L'origine de ce problème a été identifiée comme étant une faille dans l'analyse de l'entête principale et plus précisément dans la récupération des adresses. 2.2.1) Une analyse et un formatage erronés de l'entête principale Les différents champs d'un message sont souvent modifiés par le client de messagerie et les différents serveurs qui l'acheminent. De ce fait, l'analyse de l'entête principale et particulièrement des champs contenant les adresses de l'expéditeur mais aussi celles du ou des destinataire(s), nécessite une connaissance des normes RFC de formation de adresses (cf Annexe 1) Dans la version 1.0.0, le MDA Maildrop récupérait de façon autonome les adresses de l'entête principale utilisées pour créer l'arborescence maildir dans laquelle sont copiés les messages. Les informations récupérées par Maildrop contenues dans les champs de l'entête étaient insérées dans la base de données à la suite d'une analyse supplémentaire de l'entête, cette fois-ci réalisée par un script PHP. De cette hétérogénéité résultait une différence entre les données insérées dans la base de données et celles copiées sur le système de fichiers. En conséquence, suite à un archivage, une part non négligeable des fichiers n'étaient pas supprimés mais recensés comme tel dans la base de données, d'où une diminution non contrôlée de l'espace disque. 2.2.2) Mise en place d'un nouveau script Dans la première version, le script de délivrance des messages réalisait uniquement l'étape d'insertion dans la base de données. Les étapes de filtrage des messages sur les différents champs de l'entête principale et de copie des fichiers étaient réalisées par Maildrop (MDA utilisé fréquemment avec Postfix) ce qui ne permettait pas un contrôle satisfaisant de la délivrance d'un message sur le système de fichiers. Dans l'objectif de fiabiliser cette fonctionnalité, le script mail_delivery.php a été développé couplant les trois fonctionnalités de filtrage de copie et d'insertion dans la base de données (Cf figures 3 et 4). En plus d'un rassemblement des fonctionnalités il s'est avéré essentiel d'adopter un standard pour l'encodage des caractères afin d'assurer une homogénéité des données, c'est pourquoi l'encodage unicode (UTF8) a été choisi pour son adaptation reconnue à ce type de contexte. Concernant la fiabilisation du formatage des adresses, il a été nécessaire de recenser un maximum de formatages différents et ceci a été possible d'une part grâce au suivi des serveurs en production, et au retour des clients; ainsi qu'à l'aide de tests conséquents sur le script 'mail_delivery.php'. Aux vues de l'augmentation croissante du nombre d'adresse existante et l'évolution de leurs normes de formatage, notre solution ne peut prétendre à une récupération exhaustive et sans erreur. Ainsi toutes les adresses ne correspondant pas à une adresse valide, après formatage, sont remplacées par une adresse par défaut: 'invalid@invalid.invalid'.

2.3) Bilan Grâce au travail réalisé, la solution est aujourd'hui optimisée en terme de performance et de fiabilité, à travers les points suivant: -L'insertion des informations dans la base de données par la mise en place d'une structure optimisée. -Le traitement de formatages exotiques non pris en compte de façon conforme par la version précédente de la solution, lors de l'analyse de l'entête. -la copie sur le système de fichiers du serveur. La mise en place du script «mail_delivery.php» permet donc un contrôle total de la délivrance des messages grâce à la maîtrise de ses différentes étapes. De plus, un système de d'enregistrement des logs est implémenté garantissant l'accès aux étapes de la procédure de sauvegarde de tous les courriels reçus par le MTA de la solution (Postfix).

Figure 9: Schéma des communicatons émon démon et client démon

3) Le Serveur Il constitue le coeur du produit permettant l'archivage des données et leur restauration. Cette partie a représenté l'effort le plus important en matière de conception mais aussi de réalisation. Elle a été développée dans l'objectif de remplir plusieurs fonctionnalités importantes nécessaires pour assurer la fiabilité, et la stabilité de la solution. C'est pourquoi il est nécessaire de décrire avec précision sa structure et son fonctionnement. 3.1) Les fonctionnalités du serveur Le choix de mettre en place une partie serveur est partie de la nécessité de pouvoir rendre persistantes les procédures lancées sur l'application ainsi que de l'utiliser et de l'administrer à distance (voir l'exemple d'architecture de la Figure 3). L'administrateur doit pouvoir connaître l'état du serveur à n'importe quel moment, il faut donc que l'application puisse lui permettre cet accès et qu'un dialogue soit possible. Une solution existe celle de l'utilisation d'un processus démon (programme qui tourne en continu et de façon autonome) C'est ce que permet le démon principal (omad), via l'initiation d'une connexion par un client telnet. Une connexion au démon principal permet aussi de communiquer directement avec un autre processus démon, appelé démon d'archivage (omarchd). Ce dernier est uniquement accessible via omad et est chargé de réaliser les procédures critiques d'archivage et de restauration des messages. Cette fonctionnalité serveur permet à tout moment de lancer une procédure d'archivage ou de restauration, de se déconnecter, et de prendre connaissance de son état lors d'une connexion ultérieure. La répartition des tâches fiabilise ces procédures du fait de leur prise en charge par un processus indépendant de celui avec lequel le dialogue clientserveur s'établit. 3.2) Principe de fonctionnement des différentes connexions L'ensemble des données échangées entre les trois acteurs présentés dans la figure 9, le sont par des sockets de deux types différents d'un point de vue système : - socket unix (AF_UNIX) - socket internet (AF_INET) Le premier type a été implémenté pour les échanges entre les deux démons et le deuxième pour les connexions client-démon. De plus, toutes les sockets utilisent le protocole TCP car il conserve l'ordre de transmission des paquets échangés, et permet aussi un contrôle des échanges qui se font en mode connecté

Figure 10: Algorithme du démon principal (omad) Figure 11: Algorithme du démon d'archivage

3.2.1) Communication démon à démon Les sockets utilisés sont de type unix car il s'agit d'échanger des données entre deux processus exécutés localement sur la machine serveur dédiée à l'archivage. Ce type de socket est plus sécurisé et plus rapide. Sur la figure 9 sont présentés les deux sockets unix utilisées, l'une permet la récupération du statut du serveur d'archivage par le serveur principal. C'est une information qui doit être envoyée de façon très régulière et de façon non nécessairement synchrone, c'est pourquoi le choix a été fait de maintenir une connexion persistante qui s'initie au démarrage des deux démons. L'autre socket unix est utilisée pour la transmission de commandes depuis omad vers omarchd et le retour de données depuis omarchd vers omad. Elle représente le canal de transmission des requêtes envoyées au travers la connexion d'un client au démon omad. Cette communication est synchrone, ce qui permet de ne traiter qu'une seule requête à la fois, ce qui présente un atout important en cas de plusieurs connexions (un seul client peut lancer une procédure d'archivage à la fois). 3.2.2) Communication client démon La gestion des échanges de données entre le client et le démon principal est identique à celle d'échange du statut entre les deux démons, à la différence près qu'il s'agit de socket de type internet. L'ensemble des sockets d'acceptation est gérée via une instance de la classe Socket écrite pour encapsuler la gestion d'une liste de sockets via la l'utilisation de la fonction 'select'. Une connexion cliente par telnet permet d'obtenir une console pour envoyer des commandes. Ainsi, il est possible d'envoyer les commandes nécessaires à la réalisation d'une procédure d'archivage, de restauration, ou de consultation des fichiers de logs de façon flexible, le suivis du statut du démon omarchd etc... (Annexe 2). 3.3) Algorithmes des démons 3.3.1) Démon principal (Figure 10) Comme il a été dit précédemment omad est à l'interface entre omarchd et le client connecté au serveur. Lorsque ce client envoie une ligne de commande à omad celui-ci récupère la commande et détermine si il s'agit d'une commande à envoyer à omarchd. Si cela est le cas, le serveur d'archivage doit être disponible pour recevoir cette commande (il ne doit pas être en train d'effectuer un archivage ou une restauration).

Figure 12: Schéma des flux d'archivage et de restauration

Dans le cas où le serveur est disponible la socket étant en statut de lecture; l'exécution du script est suspendue jusqu'à réception d'une réponse de la part d'omarchd. Si cette réponse est positive, le statut est mis à jour, et un drapeau est instancié pour bloquer les commandes à destination du démon d'archivage. Seules les commandes qui sont traitées par omad non transmises à omarchd, sont disponibles pour le client : celle de consultation du statut, et de l'aide. 3.3.2) Démon d'archivage (Figure 11) La réalisation des traitements effectués par ce démon est rythmée par la réception de requêtes provenant d'omarchd. En effet, dès l'entrée dans la boucle principale, le démon envoie son statut et se met en attente d'une demande de connexion de la part d'omad (socket en 'accept'). Après réception d'une commande, si celle-ci est valide et que l'ensemble des paramètres nécessaires à la réalisation de la tâche sont correctement positionnés le démon écrit une réponse et ferme la socket résultante de l'acceptation de connexion. Ainsi, la procédure est lancée, et au cours de celle-ci de laquelle le statut est mis à jour régulièrement. 3.4) Traitements effectués par le serveur d'archivage : l'archivage et la restauration.(figure 12) Ces deux procédures sont les deux fonctionnalités coeur du produit d'archivage. C'est sur elles que reposent la pérennité et l'utilité de la solution. Leur réalisation suit deux procédures très proches présentées dans ce qui suit. 3.4.1) Archivage des fichiers L'archivage consiste en la succession d'étapes déterminées, et dont le succès est requis pour que la procédure s'achève avec succès. une seule session d'archivage ne peut être lancée à la fois. Cependant il est possible de réaliser plusieurs copies (exemplaires) d'une même session. 1. Chargement de la liste des messages à archiver (filtrée) 2. Chargement du plugin d'accès au médium utilisé 3. Enregistrement des informations de la base de données correspondant à la liste des fichiers chargés, dans un fichier de dump. 4. Ajout de fichiers de log et de dump à la liste. 5. Initialisation du plugin 6. Lancement de la procédure de copie des fichiers via le plugin 7. Finalisation de la procédure de copie

Figure 13: Diagramme de classe de l'implémentation des plugins

3.4.2) Restauration des fichiers Cette procédure ne peut être lancé que par un seul utilisateur à la fois et suit les étapes suivantes: 1. 2. 3. 4. 5. 6. Chargement de la liste des messages à restaurer (filtrée) Chargement du plugin d'accès au medium utilisé Chargement du plugin de restauration Initilisation du plugin d'accès au medium Initialisation du plugin de restauration Lancement de la procédure de copie ou de forward des fichiers via le plugin re restauration. 7. Finalisation de la procédure de restauration 3.5) Les plugins L'idée générale qui a permi la conception du framework permettant de mettre en place l'archivage et la restauration était de rendre la structure flexible de telle façon que différents type de supports physiques (media) puissent être utilisés. L'implémentation de plugins apparaissait comme la réponse la plus adaptée à cet objectif. Elle garantit une évolutivité à la solution par la possibilité de développer autant de plugins qu'on le souhaite, et de ce fait l'adapter aux nouveaux media et à différentes méthodes de restauration. 3.5.1) La classe Plugins : interface des plugins (Figure 13) La classe plugin a été développée pour interfacer de façon simple et générique les différents types de plugins. Deux types ont été créés : Plugin media, permettant l'accès à un medium donné en lecture et en écriture. Plugin recovery, permettant d'implémenter différentes méthodes de restauration (ex: copie des fichiers vers un répertoire, forward du message). La classe plugin implémente cinq méthodes appelées depuis le démon d'archivage: init: permet d'initialiser les attributs de la classe permettant l'instanciation de la classe du plugin souhaité. load: appelée depuis le démon d'archivage permet le chargement du plugin à utiliser; c'est-à-dire la création d'un nouvel objet (ex dvd) d'une des classes des plugin de restauration ou d'archivage. load_config : chargement de la configuration propre a un plugin save_config : sauvegarde de la configuration dans un fichier call_method : méthode centrale dans la classe Plugin, car celle-ci permet d'appeler les fonctions des plugins. Ainsi de façon générique au cours des procédures de restauration et d'archivage, n'importe quel plugin développé suivant les spécifications requises, peut-être intégré au système.

3.5.2) Implémentation de plugins (Figure 13) i) Plugin d'accès à medium Un plugin doit répondre à un certain nombre de spécifications, qui seront disponibles dans la documentation. Ce dernier doit être entièrement fonctionnel au travers de cinq méthodes qui sont appelées depuis le démon d'archivage: 1. Pour l'accès en écriture: write_init write write_finalize 2. Pour l'accès en lecture read_init read Le plugin doit aussi récupérer une référence vers l'intance du démon d'archivage lui permettant de mettre à jour le statut du démon, et donc de réaliser une certaine interactivité avec l'utilisateur (mise à jour du statut du démon, du sien etc...) Les plugins qui seront à disposition par défaut seront cd, dvd, disk, usbstick. ii) Plugin de restauration Un plugin de ce type utilise les plugins d'accès aux média pur effectuer la restauration de fichiers. Ils implémentent les fonctions suivantes: init : initialisation du plugin copy_files : restauration par copie des fichier vers une desination du système de fichier: forward : restauration des fichiers par envoie à une adresse email de forward Le système de plugin permet ici d'une façon simple de multiplier les méthodes de restauration des messages. 3.5.3) Conclusion Le développement d'un plugin ne nécessite qu'une connaissance superficielle de l'api de l'application. De plus, un fichier squelette sera mis à disposition pour chaque type de plugin, et donc facilitera encore davantage l'écriture.

3.6) Bilan du développement de la partie serveur Deux points permettent de considére la version actuelle de la partie serveur comme une évolution majeure de la solution: 1. La mise en place d'un nouveau mode de communication pour la version 2.0.0 présente de nombreux atouts. Celle-ci permet de contrôler l'accès au démon d'archivage, de le bloquer en attente d'une requête, mais aussi de réaliser un suivi dans le temps des opérations en cours (statut du démon d'archivage). 2. Le développement d'un framework, pour l'implémentation de fonctionnalités sous forme de plugins. Lequel ouvre un large horizon pour l'évolution du système, notamment concernant les évolutions technologiques en matière de support de sauvegarde, et aussi en terme d'adaptation à des besoins spécifiques pour la récupération des données archivées.

Figure 14 : Onglet de configuration de l'application Figure 15 :Interface de consultation des messages de la base de données a b c Figure 16 : écrans d'une procédure d'archivage