mémoire - pierre.sweid1.free.frpierre.sweid1.free.fr/cnam/cours_c3/memoire.pdf · habituellement...

Conservatoire National des Arts et Métiers

Mémoireprésenté en vue de l’obtention du

Diplôme d’Ingénieur CNAMEn Informatique

Par Sylvain MEDEOT

Mise en place d'une solution de travail de groupe libre(partage de messagerie, d'agendas, de contacts et de tâches)

Soutenu le 9 avril 2008

Jury

Président : Michel CRUCIANU

Membres : Pierre SWEID

X....

Mise en place d'une solution de travail de groupe libre Mémoire d'ingénieur C.N.A.M., Clichy 2008

RésuméLa croissance du trafic de messagerie et la nécessité de disposer d'outils de communications dotés de fonctions collaboratives ont amené la ville de Pontoise à prendre la décision de remplacer ses outils de messagerie. Cette migration est l'occasion de mener une étude des différentes offres du marché afin de sélectionner le produit le plus adapté, en l'occurence une solution à base de logiciels libres. La mise en place d'un tel outil nécessite une réflexion approfondie afin de réussir son intégration avec les autres briques du système d'information. La pérennisation de la solution, sa capacité à suivre l'évolution croissante du volume des données échangées et à s'adapter aux nouveaux usages sont des aspects clés qu'il convient d'étudier avec soin.Ce mémoire s'attache donc à présenter les différents aspects de ce projet, depuis le choix de la solution jusqu'à son intégration définitive et à établir un bilan technique et économique.

AbstractThe growth of the email traffic and the need for having collaboratives functions led the town of Pontoise to take the decision to replace its mail servers. This migration is the occasion to undertake a study of the various market's offers in order to select the product more adapted, in the event, a solution based on free software. The installation of such a tool requires a thorough reflexion to succeed the integration with other bricks of the information system. The perpetuation of the solution, its capacity to follow the increasing evolution of exchanges and to adapt to the new uses are key aspects to study carefully. This engineer report plans to present the various aspects of this project, since the selection of the solution until its final integration and to establish a technical and economic assessment.

Mots clés : Messagerie collaborative, logiciel libre, Kolab, migration, XML.

Keywords : Groupware, Open Source Software, Kolab, migration, XML.

Page 2 sur 137

Table des matièresRemerciements..................................................................................................6Introduction.......................................................................................................7I) Présentation de la ville de Pontoise.................................................................8

I.1) Histoire de la ville...............................................................................................8I.2) La Direction Informatique et Téléphonie.............................................................8

I.2.1) Son rôle...............................................................................................................................9I.2.2) Ses moyens........................................................................................................................10

I.3) Le contexte.......................................................................................................12I.3.1) Le marché de la messagerie dans le monde........................................................................12I.3.2) Situation existante.............................................................................................................13I.3.3) Problèmes et limites de l'architecture actuelle.....................................................................14I.3.4) Expression du besoin, rédaction de la note d'orientation....................................................15I.3.5) Objectif du stage................................................................................................................15

II) Etude préliminaire.......................................................................................16II.1) Sélection des solutions potentielles..................................................................16

II.1.1) Grille d'évaluation des solutions........................................................................................16II.1.2) Bilan de la phase d'évaluation...........................................................................................16II.1.3) Sélection d'une solution....................................................................................................18

II.2) Evaluation des ressources requises et établissement du planning...................20II.2.1) Plan d'utilisation des ressources.......................................................................................20II.2.2) Tâches affectées aux différentes ressources.......................................................................21II.2.3) Diagramme de Gantt........................................................................................................22II.2.4) Estimation des coûts........................................................................................................23

III) Installation et évaluation de la solution......................................................24III.1) Définition d'un environnement de test............................................................24

III.1.1) Matériel à disposition pour l'environnement de test..........................................................24III.1.2) Système d'exploitation......................................................................................................24III.1.3) Organisation réseau.........................................................................................................24III.1.4) Virtualisation...................................................................................................................25

III.2) Mise en place de l'environnement de test........................................................25III.2.1) Configuration du système hébergeur (DOM0)...................................................................25III.2.2) Configuration du système hébergé (DOMU)......................................................................27III.2.3) Installation de la solution................................................................................................31

III.3) Administration et fonctionnement de la messagerie........................................363.1.a) Fonctionnement de l'interface d'administration....................................................................363.1.b) Mécanismes de traitement des messages............................................................................383.1.c) Lutte contre les messages non sollicités et virus..................................................................38

III.4) Utilisation des fonctionnalités collaboratives..................................................45III.4.1) Format des données collaboratives...................................................................................45III.4.2) Accès aux données collaboratives à partir des clients.......................................................48III.4.3) Utilisation des fonctions collaboratives avec des appareils mobiles...................................51

III.5) Sécurité et confidentialité...............................................................................52III.6) Tests de montée en charge de la solution ......................................................53

III.6.1) Mise en place de l'environnement de mesure....................................................................536.1.a) Simulation d'envoi sans pièce jointe.....................................................................................556.1.b) Simulation d'envoi avec pièces jointes..................................................................................566.1.c) Simulation d'envoi avec pièces jointes en désactivant Amavis.............................................57

III.6.2) Bilan des tests de montée en charge................................................................................58

Page 3 sur 137

III.7) Problèmes rencontrés durant la phase de tests..............................................59III.7.1) Gestion message d'absence..............................................................................................59III.7.2) Gestion de groupes d'utilisateurs dans les listes...............................................................59III.7.3) Limitation des utilisateurs à certains domaines / adresses..............................................60III.7.4) Fonctionnement du greffon « Toltec » avec Outlook............................................................60III.7.5) Solutions de contournement envisagées...........................................................................61

IV) Mise en place de la solution.........................................................................62IV.1) Installation de l'architecture réseau................................................................62

IV.1.1) Installation du serveur dans la zone démilitarisée.............................................................62IV.1.2) Configuration des serveur mandataires inversés...............................................................63

1.2.a) Serveur mandataire inversé pour le service SMTP...............................................................631.2.b) Serveur mandataire inversé pour le service HTTP...............................................................641.2.c) Serveur mandataire inversé pour le service IMAP................................................................65

IV.2) Outils additionnels et sauvegardes.................................................................67IV.2.1) Réalisation des interfaces manquantes.............................................................................67

2.1.a) Gestion d'absence.................................................................................................................672.1.b) Restriction de l'envoi de messages aux destinataires d'une liste.........................................692.1.c) Serveur de décision...............................................................................................................70

IV.2.2) Mise en place des procédures de sauvegarderestauration................................................71IV.3) Procédure de migration des données..............................................................73IV.4) Formation des usagers...................................................................................75IV.5) Intégration à l'intranet....................................................................................76

V) Compterendu opérationnel..........................................................................77V.1) Sécurité, évolutions.........................................................................................77

V.1.1) Mises à jour de sécurité.....................................................................................................77V.1.2) Mises à jour globales applicatives......................................................................................77

V.2) Tableaux de bord, surveillance quotidienne.....................................................78V.2.1) Suivi avec les tableaux de bord de messagerie...................................................................78V.2.2) Comptesrendus quotidiens..............................................................................................79V.2.3) Intégration à l'outil Nagios................................................................................................80

V.3) Bilan technique et économique........................................................................81V.3.1) Bilan technique.................................................................................................................81V.3.2) Bilan économique.............................................................................................................82

Conclusion.......................................................................................................83Lexique............................................................................................................84Bibliographie....................................................................................................90Webographie.....................................................................................................90Annexes............................................................................................................91

Page 4 sur 137

Table des illustrationsIllustration 1 : Applications métier en usage au sein de la ville de Pontoise 9 Illustration 2 : Evolution du budget de 2002 à 2007 10 Illustration 3 : Répartition des charges sur le budget de la Direction 10 Illustration 4 : Evolution de la répartition des charges de la Direction de 2002 à 2007 11 Illustration 5 : Evolution du nombre de machines connectées à internet dans le monde 12 Illustration 6 : Evolution du chiffre d'affaires messagerie auprès des « Grands comptes » 12 Illustration 7 : Parts de marché des logiciels de messagerie 12 Illustration 8 : Organisation des serveurs de messagerie de la ville de Pontoise 13 Illustration 9 : Activité des serveurs de messagerie pour l'année 2007 (860 000 messages) 14 Illustration 10 : Architecture type d'une solution de travail collaboratif s'appuyant sur des logiciels libres 17 Illustration 11 : Architecture réseau de l'environnement de test 24 Illustration 12 : Interface d'administration de Kolab 35 Illustration 13 : Génération des gabarits 37 Illustration 14 : Acheminement et traitement d'un message 38 Illustration 15 : Schéma de filtrage des messages par Amavis 38 Illustration 16 : Trafic entrant de messagerie avant et après la mise en place de Postgrey 41 Illustration 17 : Mécanismes de contrôle des messages entrant sur Postfix 44 Illustration 18 : Fiche contact une fois décodée dans le logiciel Outlook et dans Horde 46 Illustration 19 : Fiche contact une fois décodée dans le logiciel Thunderbird avec le greffon SyncKolab 47 Illustration 20 : Ajout de droits à d'autres utilisateurs dans Horde et Outlook 48 Illustration 21 : Mise en vis à vis d'agendas dans Horde et Outlook 48 Illustration 22 : Recherche de disponibilités dans Outlook 49 Illustration 23 : Synthèse des évènements dans Outlook 50 Illustration 24 : Affichage d'une tâche dans Outlook 50 Illustration 25 : Représentation du journal dans Outlook 50 Illustration 26 : Fonctionnement de SyncML 51 Illustration 27 : Flux accessibles depuis l'internet 52 Illustration 28 : Mesures de l'activité du serveur avec Mailgraph 53 Illustration 29 : Principe de fonctionnement du programme client 54 Illustration 30 : Mesures constatées lors de l'envoi sans pièces jointes 55 Illustration 31 : Mesures constatées lors de l'envoi avec pièces jointes 56 Illustration 32 : Mesures constatées lors de l'envoi avec pièces jointes avec Amavis désactivé 58 Illustration 33 : Interactions entre Kolab, Outlook et le greffon Toltec 60 Illustration 34 : différences entre Outlook et Horde 61 Illustration 35 : Choix possibles en matière de configuration réseau 62 Illustration 36 : Circulation des flux sur le serveur mandataire inverse 66 Illustration 37 : Modules de gestion d'absence 67 Illustration 38 : Processus de création d'un message d'absence 68 Illustration 39 : Principe du serveur de décision 70 Illustration 40 : Processus de sauvegarde des données de Kolab 72 Illustration 41 : Processus de transfert des données de Exchange vers Kolab lors de la migration 74 Illustration 42 : Rapport d'utilisation du serveur avec Vispan 78

Page 5 sur 137

RemerciementsJe tiens en premier lieu à remercier la Direction de la ville de Pontoise qui m'a proposé puis offert les moyens de reprendre mes études au Conservatoire National des Arts et Métiers.

Je remercie Monsieur Philippe GARNIER, Directeur Général Adjoint qui a cru en ma réussite et m'a beaucoup aidé par ses précieux conseils et son soutien. A la fois présent et disponible, il a encouragé mes initiatives au travers de la grande liberté d‘actions qu‘il m‘a autorisée.

J'adresse un remerciement spécial à mes collègues informaticiens de la Direction Informatique pour leur aide et leur support tout au long de ce projet.

Le sujet de ce mémoire tout comme sa rédaction ont très largement fait appel à la communauté du logiciel libre à qui j'exprime tous mes remerciements.

Je remercie tous les membres du jury qui ont accepté d'être présents.

Enfin, je remercie Monsieur Pierre SWEID, mon tuteur au CNAM de Clichy, pour son suivi, son écoute et ses remarques très judicieuses.

Remerciements Page 6 sur 137

IntroductionDepuis mon entrée en fonction au sein de la ville de Pontoise en juillet 2002, j'occupe le poste de Directeur Informatique et Téléphonie. J'ai ainsi pu acquérir une vision d'ensemble des impératifs d'une telle fonction au sein d'une collectivité locale.

J'ai dû prendre en charge des éléments aussi variés que l'organisation informatique générale, la téléphonie d'entreprise, la gestion d'une équipe au quotidien, le fonctionnement transversal, les aspects juridiques, l'élaboration de cahiers des charges et la veille technologique.

Dans le cadre de la préparation de mon diplôme d'ingénieur CNAM, Monsieur Philippe GARNIER m'a demandé de migrer les outils de messagerie interne vers un outil évolutif et adapté à l'évolution des pratiques internes.

Le choix s'est porté sur une solution alternative aux outils propriétaires classiques rencontrés habituellement pour ce type d'application. Basée sur des logiciels libres, elle a dû faire l'objet d'un processus d'évaluation complet avant de valider sa mise en production.

Ce mémoire relate l'ensemble de ce projet, depuis sa phase de réflexion initiale jusqu'à la mise en place finale de l'outil. Il est structuré en cinq chapitres.

Tout d'abord, une description du contexte du stage, de la Direction dans laquelle il a été effectué et des objectifs fixés.

Ensuite, une présentation de la méthodologie ayant permis d'évaluer les solutions retenues afin de sélectionner l'offre la plus proche des attentes exprimées, suivie de l'organisation en termes de tâches et de ressources de cette opération.

La première phase opérationnelle a permis de réaliser une maquette afin de confirmer la validité du choix effectué. Elle a été l'occasion de configurer l'outil puis de le soumettre à des phases de tests rigoureuses.

Dès lors, la planification des opérations de mise en place a pu commencer.

Des développements ont dû être réalisés pour pallier certaines déficiences constatées en matière de fonctionnalités ou d'ergonomie. La formation des utilisateurs, la migration des comptes et la pérennisation de l'outil ont ensuite été menées à bien. Au terme de cette étape, le nouvel outil est fonctionnel.

La dernière étape a consisté à l'intégrer étroitement au système d'information. Un bilan technique et économique a posteriori de cette migration vient conclure ce chapitre.

Introduction Page 7 sur 137

I) Présentation de la ville de Pontoise

I.1) Histoire de la ville Pontoise (du latin « Pons Isarae », le pont sur l'Oise) est une ville du département du Val d'Oise et l'une des onze communes de l'agglomération nouvelle de CergyPontoise. Située à 30 kilomètres au nordouest de Paris, elle compte une population de 28725 habitants (Pontoisiens, Pontoisiennes) répartis sur 711 hectares.

C'est sur l'éperon calcaire du Mont Belien, sculpté dans la pierre par les vallées de l'Oise et de la Viosne que se développe la ville médiévale. Cité fortifiée aux frontières du royaume, ville commerçante, elle connaît son apogée aux XIIe et XIIIe siècles.

Au cours du XIXe siècle, l'arrivée du chemin de fer et l'extension de la banlieue parisienne influent sur le destin de la ville. Par le chemin de fer, Pontoise se rapproche de Paris tandis que, par l'essor de la banlieue, les impressionnistes donnent à la ville et la vallée de l'Oise leurs lettres de noblesse artistique (Camille Pissaro, Paul Cézanne, Ludovic Piette, Paul Gauguin, Vincent Van Gogh).

Ville chargée d'histoire, Pontoise a cependant su s'adapter, évoluer et engager un développement maîtrisé en quelques années. La commune est parvenue à conserver la richesse de son patrimoine historique tout en se tournant résolument vers le futur.

Deuxième ville de l'agglomération nouvelle en terme de population, Pontoise bâtit aujourd'hui son avenir sur ces deux atouts : son patrimoine historique, culturel et commercial et son appartenance à un ensemble intercommunal dynamique et reconnu. De plus, la ville conserve sur l'ensemble de la région un rayonnement incontestable grâce à son centre hospitalier, son tribunal, ses lycées, son site universitaire et sa cathédrale.

Philippe HOUILLON, Député Maire, est à la tête d'une ville composée de nombreux sites (hôtel de ville et ses annexes, centre technique municipal, crèches, écoles maternelles et primaires, centre de loisirs, équipements sportifs, musées, bibliothèques, maison des associations, maisons de quartiers).

La ville de Pontoise compte environ 700 employés (la filière technique étant de loin la plus importante avec environ 47,10 % du personnel communal).

I.2) La Direction Informatique et Téléphonie Composée de cinq personnes, elle fait appel à de multiples savoirfaire et à une grande capacité d'adaptation du fait de la variété des missions qui lui sont confiées.

Localisée au sein de l'hôtel de ville, elle vient en appui d'un parc informatique comptant environ 450 postes et 16 serveurs (couvrant des domaines aussi variés que la messagerie, les bases de données, les serveurs d'application, les contrôleurs de domaine, DHCP, DNS, FTP, VPN, serveurs mandataires, annuaires, serveurs de télécopie, outils de supervision des réseaux et serveurs de terminaux).

Son domaine d'intervention s'étend sur près de 25 sites bénéficiant d'interconnexions au moyen de réseaux privés virtuels.

Parmi ces sites, on recensera notamment les services techniques, mairies de quartiers, postes de police municipaux, musées, bibliothèques, centres aérés, crèches, écoles primaires et maternelles, maison des associations, gymnases, salle des fêtes.

En plus des moyens informatiques, la Direction Informatique assure aussi la gestion des installations téléphoniques (une douzaine d'autocommutateurs).

I) Présentation de la ville de Pontoise Page 8 sur 137

Par souci d'optimisation des budgets, l'infrastructure logicielle s'appuie largement sur les logiciels libres (« open source »), partout où des alternatives équivalentes aux logiciels commerciaux existent.En plus de ses missions traditionnelles, la Direction Informatique évolue dans un environnement placé dans un cadre juridique strictement défini qui impacte son fonctionnement dans la mesure où de nombreuses tâches administratives sont aussi de sa responsabilité.

I.2.1) Son rôleDirection par essence transversale, la DSI est à l'écoute des services de la ville, ses clients. Ces derniers, très différents les uns des autres de par la variété de leurs métiers, de leur approche de l'usage des outils de communication modernes et disséminés sur l'ensemble du territoire de la commune, multiplient de ce fait la diversité des missions. Il est donc nécessaire de jongler entre des outils logiciels très hétéroclites : la qualité première des membres de la Direction Informatique est donc une capacité d'adaptation tant aux missions qu'aux utilisateurs côtoyés. Le périmètre d'intervention de la Direction Informatique est le suivant :

➢ Réseau, disponibilité des systèmes et des outils de communication,➢ Pérennisation des données et sécurisation du réseau interne,➢ Mise en place d'outils de filtrages d'url au travers de serveurs mandataires,➢ Développement de l'intranet et du site internet,➢ Assistance bureautique, formations aux outils bureautiques,➢ Suivi des applications métier, formation, assistance, mises à niveaux,➢ Téléphonie (aspects techniques et administratifs),➢ Organisation et suivi des marchés publics de la Direction,➢ Gestion du budget de la Direction,➢ Veille technologique, programmation pluriannuelle

Pour illustrer la variété des missions, voici un aperçu sous la forme d'un diagramme par Direction des applications métiers en usage :

Illustration 1 : Applications métier en usage au sein de la ville de Pontoise


2002 2003 2004 2005 2006 2007

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

Evolution du budget informatique téléphonie

8%

23%

13%

46%

Répartition des charges

Achat de licencesAchat matérielAchat téléphonieMaintenance logicielleMaintenance matérielleMaintenance téléphonieConsommations tél.

I.2.2) Ses moyens

Le budget de la Direction Informatique et Téléphonie de la ville de Pontoise est en baisse assez régulière depuis 2002.

Cette baisse a été rendue possible par le recours systématique à la mise en concurrence (marchés publics), le contrôle rigoureux des dépenses et l'usage de solutions à base de logiciels libres.

Illustration 2 : Evolution du budget de 2002 à 2007

La répartition des charges du service montre l'importance des coûts liés aux liaisons, qu'elles concernent la voix ou les données.

Illustration 3 : Répartition des charges sur le budget de la Direction

L'achat de matériel est ensuite le second poste devant la maintenance applicative des logiciels métiers qui est considérable.


2002 2003 2004 2005 2006 2007

0

50000

100000

150000

200000

250000

Budget informatique téléphonie 20022007 (€)

Achat de licences

Achat matérielAchat téléphonieMaintenance logicielle

Maintenance matérielleMaintenance téléphonie

Consommations tél.

Illustration 4 : Evolution de la répartition des charges de la Direction de 2002 à 2007

En dépit de l'extension du parc informatique, de la croissance du nombre d'utilisateurs et de la mise en place de nouveaux sites, l'évolution des budgets de fonctionnement et d'investissement de la Direction Informatique et Téléphonie a été contenue.

Cette performance a été obtenue en réorganisant de façon plus cohérente le système d'information.

Des applications ont ainsi été transférées sur des systèmes plus récents en éliminant au passage des contrats de maintenance souvent très coûteux eu égard à la vétusté du matériel.

Un audit a aussi été mené sur l'usage réel d'un certain nombre d'outils peu ou pas utilisés.

Dans certains cas, ces outils ont tout simplement été abandonnés dans la mesure où ils ne correspondaient plus à un besoin ou faisaient doublons avec d'autres applications.

Dans d'autres cas, des développements internes ont été menés afin de les remplacer.


1994 1995 1996 1997 1999 2000 2001 2002 2003 2004 2005 2006

0

50000000

100000000

150000000

200000000

250000000

300000000

350000000

400000000

450000000

500000000

I.3) Le contexte La ville de Pontoise souhaite faire évoluer ses outils de messagerie afin d'anticiper la saturation du système actuel et de donner aux agents accès à des fonctionnalités de travail collaboratif.

I.3.1) Le marché de la messagerie dans le monde

La formidable croissance de l'utilisation d'internet au cours des quinze dernières années a vu apparaître de nouvelles formes de communication qui ont petit à petit pris la place des modes de communication classiques.

Illustration 5 : Evolution du nombre de machines connectées à internet dans le monde

L'une des principales applications de l'internet est la messagerie électronique. Ses enjeux sont énormes à l'échelle mondiale. Les données ciaprès illustrent la gigantesque bataille qui se déroule pour la conquête de parts de marché :

2005 2006 2007 2008 2009

Amérique du Nord 43% 42% 40% 39% 38%

Europe 29% 28% 28% 27% 27%

Asie / Pacifique 22% 23% 24% 25% 26%

Reste du monde 6% 7% 8% 9% 9%

2830 M$ 3041 M$ 3289 M$ 3602 M$ 3985 M$

Illustration 6 : Evolution (en millions de US $) du chiffre d'affaires messagerie auprès des « Grands comptes »

En 2006, le trafic mondial est estimé à 171 milliards de messages par jour. Entre 71% et 75% de ces échanges sont des courriers non sollicités (spams). Huit millions de terminaux portables RIM BlackBerry, permettant la lecture de courriels, le partage de contacts et d'agendas à distance sont en circulation.

Le marché est occupé en 2006 par deux grands acteurs qui sont les sociétés IBM et Microsoft avec leurs produits phares Lotus Domino et Microsoft Exchange et par une multitude d'acteurs s'appuyant sur des logiciels libres.

Illustration 7 : Parts de marché des logiciels de messagerie


I.3.2) Situation existante

L'outil de messagerie en vigueur au sein de l'hôtel de ville est Microsoft Exchange Server dans sa version 5.5, le tout installé sur un serveur de type Windows NT 4.0 qui est dédié à cette application. Le matériel hébergeant l'outil est de type HP Netserver et montre de sérieuses difficultés à soutenir la charge malgré un nombre de clients limité. En effet, la configuration des outils de messagerie de l'hôtel de ville s'appuie sur trois serveurs, chacun d'entre eux ayant une spécificité que l'on retrouve sur le schéma ciaprès :

Illustration 8 : Organisation des serveurs de messagerie de la ville de Pontoise

Le serveur Exchange est utilisé principalement pour les messageries des responsables qui bénéficient des fonctions de partages de calendriers et de contacts. Le client de messagerie est alors Outlook 97 ou Outlook 2000 de Microsoft. Les clients communiquent avec le serveur au moyen de l'interface de communication Microsoft MAPI. Le serveur fournit aussi un annuaire s'appuyant sur le protocole d'annuaire LDAP qui permet de recenser l'ensemble des adresses (réelles ou virtuelles) et qui gère les listes de diffusions partagées.

Pour chacun des comptes clients, il est nécessaire de disposer d'une licence client Microsoft Server sur le serveur, d'une licence client Exchange sur le serveur et d'une licence Outlook. Le choix de réserver l'accès à ce type de messagerie est donc avant tout économique. Pour pallier cet état de fait, un serveur (domaine extranet.villepontoise.fr) a été mis en place. S'appuyant sur une distribution Linux et le serveur de messagerie Postfix, il a permis de fournir des adresses de messagerie sans générer de coût de licences.

Le logiciel client de messagerie utilisé est l'outil de la fondation Mozilla dénommé Thunderbird. L'accès aux boîtes de messagerie se fait au travers des protocoles POP3 et SMTP. Enfin, un troisième serveur de messagerie (domaine intranet.villepontoise.fr) est destiné aux utilisateurs disposant d'un poste informatique mais n'ayant pas à échanger de courriers électroniques avec des usagers externes à la collectivité. Ce domaine n'est pas accessible sur internet et son serveur refuse tout message destiné à des domaines autres que villepontoise.fr (ou l'un de ses sous domaines).


Messages refusés à la connexion 79%

Messages non sollicités 3%

Messages acceptés et livrés 18%

Activités de la messagerie de la ville de Pontoise

Les logiciels clients installés sur les postes de ce type sont ici aussi Mozilla Thunderbird.Le trafic de messagerie est en constante augmentation et la lutte contre les courriels non sollicités ou la détection de messages frauduleux (ou contenant des pièces jointes au contenu nocif) sont consommateurs de ressources sur les serveurs. Le graphique ciaprès donne des éléments sur la situation constatée sur l'ensemble des serveurs pour l'année 2007.

Illustration 9 : Activité des serveurs de messagerie de la ville de Pontoise pour l'année 2007 (860 000 messages)

I.3.3) Problèmes et limites de l'architecture actuelle

En plus d'une certaine complexité en terme d'architecture, la solution utilisée se montre peu satisfaisante par de nombreux côtés :

➢ Multiplicité des logiciels clients,➢ Plusieurs noms de domaines ou de sousdomaines en vigueur au sein de la collectivité

d'où des erreurs fréquentes d'adressage,➢ Accès à certaines fonctions (contacts, agendas, messages d'absence) limités à une

catégorie d'utilisateurs,➢ Stockage des données local sur le poste client pour les clients des serveurs Postfix,➢ Croissance des temps de réponse du fait de l'inadéquation entre les ressources

matérielles et le trafic de messagerie.De nouveaux besoins sont aussi apparus sans que l'architecture actuelle ne puisse y répondre de façon acceptable. Un certain nombre d'utilisateurs souhaite pouvoir réaliser des renvois de leur messagerie en cas d'absence. La lecture des courriers professionnels depuis l'extérieur devient aussi une demande forte, soutenue par la Direction Générale.

Le développement des outils communicants comme les « PDA » ou les « smartphone » suscite de nouvelles demandes telle la synchronisation des agendas ou des listes de contacts partagés. La gestion des espaces alloués sur les serveurs de messagerie est un véritable cassetête au quotidien, coûteux en ressources humaines pour la Direction Informatique.

Les incidents liés à de mauvaises manipulations des utilisateurs nécessitant une restauration des sauvegardes entraînent des interruptions de service qui sont préjudiciables au bon fonctionnement des services.

Enfin, la maintenance applicative des serveurs n'est plus assurée (versions de Postfix trop anciennes sur les serveurs Linux et support de Microsoft Exchange 5.5 et de Windows NT en fin de vie). Des problèmes de sécurité se posent donc potentiellement, l'ensemble des flux de messagerie circulant par ailleurs sur le réseau local sous une forme non chiffrée, danger d'autant plus important que le réseau s'étend sur près de 25 sites.


I.3.4) Expression du besoin, rédaction de la note d'orientation

Au regard de cette situation, le besoin d'un renouvellement de l'outil de messagerie devient une tâche prioritaire.

Après une réunion avec le Directeur général adjoint en charge des services transversaux, la décision de réaliser une étude comparative des solutions existantes sur le marché est prise.

Une note de cadrage est réalisée (reprise en annexes) définissant le périmètre fonctionnel de l'outil qui devra être déployé. Les grandes lignes en matière de fonctionnalités attendues sont les suivantes :

➢ Stockage des messages sur le serveur,➢ Consultation à distance des messages (protocoles IMAP ou Webmail),➢ Réunification des domaines de messagerie sur un seul domaine (villepontoise.fr),➢ Chiffrement des communications entre clients et serveur,➢ Extension à l'ensemble des utilisateurs des partages d'agendas et de contacts,➢ Présence d'indicateurs permettant de suivre à la fois l'évolution du trafic, du stockage,

des effets de la lutte contre les courriels non sollicités ou vecteurs de logiciels malveillants,

➢ Capacité à suivre l'évolution prévisible et attendue en matière de trafic, ➢ Taux de disponibilité attendu supérieur à 99 % pendant les heures ouvrées,➢ Extension des modes de sauvegarde et de restauration de la solution.

La note de cadrage met l'accent sur le coût d'acquisition de la solution mais aussi sur son coût de maintenance opérationnelle, sur son évolutivité et sur le recours à des protocoles ouverts afin de limiter la dépendance à un fournisseur et d'assurer une ouverture maximale de l'outil. Il convient de noter que ce document n'impose pas d'utiliser une solution à base de logiciels libres : le choix doit avant tout porter sur la pérennité de l'outil et son coût, tant en ressources humaines au quotidien qu'en terme d'impact sur les budgets d'investissement et de fonctionnement.

I.3.5) Objectif du stage

Le stage vise donc à mener à bien une analyse exhaustive des outils en compétition, en mettant en valeur tant leurs qualités que leurs défauts, dans l'objectif de déterminer la solution la plus adaptée au cahier des charges de la ville de Pontoise.

Au terme de cette analyse, une décision sera prise et une solution retenue. Cette solution fera alors l'objet d'une mise en situation poussée, visant à valider le choix réalisé. Cette phase de tests devra porter sur un panel représentatif des missions demandées, afin de fournir une charge applicative proche de celle qui serait observée dans le cas d'un déploiement effectif de la solution.

Une fois la solution retenue validée, un bilan sera établi. Si des corrections s'avèrent nécessaires, une réflexion sera menée en ce sens. Cette dernière étape achevée, et dans la mesure où aucune difficulté majeure de nature à remettre en cause le choix effectué n'est détectée, un planning de mise en place de l'outil sera établi.

La mission proprement dite pourra alors commencer avec une conduite de projet visant à assurer le succès de cette migration en contournant les écueils qui pourront se présenter. La réussite du projet sera liée au respect des attentes en matière de fonctionnalités, mais aussi en matière budgétaire, le tout en assurant une migration en douceur pour les usagers. Différentes études et bilans intermédiaires viendront mesurer la réalisation de ces objectifs.


II) Etude préliminaireCette étape a pour objectif de faire un tour d'horizon des solutions à même de répondre au besoin exprimé et de les soumettre l'une après l'autre à une série de contrôles.

II.1) Sélection des solutions potentielles Différents outils permettent aujourd'hui d'apporter une réponse au besoin exprimé. Une sélection a donc été réalisée afin de restreindre le champ d'évaluation à un échantillon représentatif des solutions en usage dans les entreprises ou administrations mais aussi de tenir compte des nouveaux venus qui pourraient bien bousculer l'ordre établi.

L'offre de l'éditeur Microsoft, « Microsoft Exchange Server » qui est aujourd'hui l'une des plus déployées, a bien sûr été retenue.

Une solution s'appuyant sur un fonctionnement au travers d'une interface web et rencontrant un certain succès a aussi été sélectionnée, la suite « Zimbra collaboration Suite ». Enfin, deux solutions à base de logiciels libres ont été évaluées : un ensemble élaboré à la demande du gouvernement allemand par plusieurs SSLL, « Kolab » et l'offre « AliaSource OBM ».

II.1.1) Grille d'évaluation des solutions

La grille d'évaluation (fournie en annexe sous la forme d'un tableau récapitulatif détaillant chaque fonctionnalité examinée) a pour objectif de déterminer la pertinence des différentes solutions en les examinant sous des angles différents. Si les aspects techniques et fonctionnels sont bien sûr présents, ils ne sont pas les seuls.

L'interopérabilité de la solution est aussi un critère essentiel, tout comme le modèle économique choisi par l'éditeur de la solution, les prérequis en matière d'infrastructure de déploiement, les choix en matière de sécurité ou encore les outils d'administration et de suivi mis à disposition.

La grille d'évaluation ainsi constituée tient compte de certaines caractéristiques du système d'information de la ville de Pontoise (qui a largement recours aux solutions dites ouvertes). Cette grille laisse sous silence certains aspects fonctionnels qui ne sont pas requis de par la nature du site considéré et des perspectives d'évolution.

Elle a toutefois été conçue de telle façon que les solutions dites propriétaires puissent être évaluées de façon rigoureuse et que les avantages et inconvénients de chacune des offres puissent ressortir de façon équitable.

II.1.2) Bilan de la phase d'évaluation

L'ensemble des solutions testées répond aux attentes en matière de fonctionnalités mentionnées par la lettre de cadrage. Si les solutions dites à base de « logiciels libres » sont beaucoup plus récentes et n'ont donc pas la maturité de leurs homologues propriétaires, elles n'en sont pas moins tout à fait fonctionnelles. Néanmoins, les solutions propriétaires, principalement Microsoft Exchange et Lotus Notes (ce dernier en perte de vitesse), restent largement les plus diffusées dans les administrations et les grands comptes.

Elles disposent d'une large gamme d'outils complémentaires et de nombreuses sociétés de services sont à même d'intervenir dans le cadre de leur déploiement ou pour une assistance plus ponctuelle. Cela représente toutefois un coût qui s'avère vite élevé si l'on tient compte de tous les éléments nécessaires à la mise en place d'une solution complète.

En effet, un outil collaboratif se doit d'intégrer aussi bien des fonctionnalités collaboratives qu'une panoplie complète et variée de services tels que des outils de sauvegarde et de reprise après incidents et de réelles capacités en termes de scalabilité et de support de charge.

II) Etude préliminaire Page 16 sur 137

De même, la messagerie étant aujourd'hui un vecteur important de menaces informatiques, la lutte contre le courrier indésirable et l'éradication des contenus malveillants sont incontournables et ne peuvent se dissocier de l'offre logicielle à mettre en place. Enfin, l'ensemble des coûts, que ce soit en matière de licences (serveur, clients de serveurs et clients de messagerie, logiciels de sauvegarde spécialisés, licences antivirales serveurs, outils de filtrages contre les courriers non sollicités) ou d'assistance, s'avère vite un réel frein au déploiement généralisé de solutions propriétaires dès lors que des contraintes budgétaires pèsent sur les budgets informatiques. Les offres à base de logiciels libres consistent en un assemblage de briques logicielles, éléments le plus souvent très éprouvés : bases de données, serveurs de messagerie, solution de lutte contre les courriers abusifs et les virus, serveurs d'annuaire, outils de cryptographie. Une architecture centrale spécifique à chaque offre permet de coordonner chacun des sousensembles applicatifs.

Illustration 10 : Architecture type d'une solution de travail collaboratif s'appuyant sur des logiciels libres

On distingue clairement deux sousfamilles d'outils collaboratifs. La première s'appuie sur une structure commerciale (Zimbra, OpenExchange) et offre deux lignes de produits, l'une clairement commerciale, complète, disposant d'un support technique et de documentations complètes. Si l'offre commerciale est de qualité, elle se rapproche rapidement en matière de coût des solutions propriétaires vues précédemment, sans toutefois offrir les garanties que peuvent offrir les leaders du marché en terme de pérennité.

L'offre mise à disposition sous la forme d'une licence logicielle libre consiste quant à elle en la mise à disposition de la solution précédente avec toutefois des restrictions sur les fonctionnalités d'administration et sur les interfaces de migration, ce qui rend quelque peu hasardeuse la mise en production d'un outil dont la visibilité à moyen terme laisse à désirer.


La seconde sousfamille d'outils collaboratifs se rapproche du modèle de développement communautaire qui a fait le succès des logiciels libres. On trouve parfois une entité commerciale (ou gouvernementale dans le cas de Kolab) à l'origine du projet mais le développement reste accessible aux bonnes volontés externes.

Les interfaces d'accès sont clairement documentées, ce qui favorise le développement de greffons logiciels et l'interfaçage avec un certain nombre de solutions existantes, d'où un niveau élevé d'interopérabilité.

Autre avantage, de larges communautés d'utilisateurs fournissent un support très actif au travers de forums, de listes de distributions mais aussi via un réseau de consultants aux prestations assez accessibles en comparaison des tarifs pratiqués par les solutions propriétaires.

II.1.3) Sélection d'une solution

Face à cette pléthore de solutions globalement satisfaisantes, un choix a dû être opéré. Le coût des solutions propriétaires (Exchange) ou semipropriétaires (Zimbra) a clairement pesé en la défaveur de ces deux offres du fait de l'environnement budgétaire contraint de la Direction Informatique et Téléphonie de la ville de Pontoise.

Dès lors, les solutions OBM Groupware et Kolab s'avèrent les principales candidates au remplacement du système de messagerie collaboratif de la ville de Pontoise. Les deux offres sont assez similaires en matière d'architecture avec notamment une utilisation d'outils réputés comme OpenLDAP, Postfix, Cyrus Imapd, ProFTPD, Apache et Cyrus SASL.

L'intérêt de ces deux solutions réside dans l'utilisation d'un socle applicatif éprouvé, tant en matière d'annuaire, de serveur internet que de serveur de base de données de messages.

Ces applications sont toutes deux des références reconnues dans leurs domaines respectifs. Le pari des deux projets Kolab et OBM Groupware a donc consisté à bâtir une interface permettant de coordonner la mise en œuvre de chacun de ces éléments pour former un ensemble cohérent. La partie collaborative s'appuie à la fois sur un outil centralisé permettant de configurer chaque brique logicielle et sur la conception d'un protocole particulier pour la partie collaborative.

Dans le cas de Kolab, il s'agit d'un format de messages particulier (Kolab XML) alors qu'OBM Groupware fait appel à un élément supplémentaire, une base de données relationnelle (qui peut être au choix soit MySQL soit PostgreSQL).On ne distingue pas de différences significatives en terme de performances, ce qui n'est pas surprenant au vu des nombreux éléments communs aux deux outils. OBM Groupware peut, de par sa conception modulaire, être doté de fonctionnalités supplémentaires.

Il fait appel dans le cadre de son fonctionnement aux composants de la distribution Linux sur laquelle il est installé, ce qui permet de l'utiliser sur la plateforme de prédilection de l'utilisateur. Si la mise en place de l'outil de base ne pose pas de problème particulier, la configuration fine de chacun des éléments reste malgré tout source de soucis.

En effet, le choix de pouvoir faire appel à plusieurs type de bases de données et d'utiliser les modules logiciels propres aux différentes distributions Linux multiplie le nombre de configurations possibles, et par là même, les sources de conflits.

L'approche de Kolab est quelque peu différente. Ses concepteurs ont souhaité réaliser un outil compatible avec l'ensemble des distributions Unix/Linux. Ils ont toutefois choisi de fournir un ensemble « prêt à l'emploi » par l'inclusion de tous les éléments requis sous la forme de paquets logiciels (qui peuvent soit être précompilés, soit compilés au moment de l'installation).


La structure des paquets étant dépendante des systèmes d'exploitation utilisés, Kolab fait appel à un projet visant à fournir un système de paquet universel : OpenPkg. Grâce à cet outil, il suffit de disposer d'une plateforme Unix minimale puis de télécharger l'ensemble des composants. Dès lors, un fichier de commande (script) procède aux différentes phases, à savoir compilation, installation puis configuration complète de la solution.

Cette approche, en plus d'offrir une grande simplicité, améliore les opérations de maintenance et les mises à jour. Les fichiers exécutables binaires résultant de cette installation sont aussi optimisés pour la plateforme retenue (qu'elle soit 32 ou 64 bits) et la résolution des dépendances ne se pose plus comme une source possible de conflits.

D'un point de vue financier, l'installation et le paramétrage ne requièrent pas d'intervention extérieure, les outils utilisés étant dans l'ensemble maîtrisés par les membres du service.

L'intervention d'un consultant est malgré tout souhaitable afin de valider les choix en matière d'architecture réseau ou certains aspects critiques comme la sauvegarde des données.

Le montant d'une telle prestation reste limité puisqu'elle s'élève à deux journéeshommes.

L'utilisation de Kolab avec des clients de messagerie comme Outlook (requise initialement afin de minimiser l'impact des changements pour les utilisateurs de l'ancienne solution Microsoft Exchange) impose l'achat d'une extension dont le coût reste modique (25 € par poste client).

Il est aussi tout à fait possible d'utiliser d'autres logiciels. La plateforme Linux KDE (prochainement portée sous Windows) dispose du client Kontact qui donne d'ores et déjà accès à toute la gamme de services offerts par Kolab.

Le logiciel Thunderbird, de la fondation Mozilla, dispose d'une extension prometteuse, SyncKolab qui permettra d'avoir une interface commune d'accès aux fonctionnalités collaboratives à partir d'environnements logiciels comme Windows, Linux ou Mac OS X.

Enfin, la plateforme Horde, désormais partie intégrante du projet Kolab, complète l'offre clients en donnant accès à distance via le protocole HTTP à l'ensemble des fonctionnalités.

La solution Kolab est aussi soutenue par une base confortable d'utilisateurs qui animent un site collaboratif (wiki) actif et complet avec un grand nombre de solutions originales pour tirer le meilleur parti de l'outil.

De même, une liste de diffusion est accessible et permet de contacter aisément les membres de l'équipe de développement, qui répondent par ailleurs assez rapidement.

Enfin, la solution n'est pas liée à un acteur économique mais tend à servir l'intérêt général ce qui n'est pas le cas par exemple d'OBM Groupware.

Un consortium (le «Kolab konsortium ») fédère les entreprises impliquées dans le projet et donne accès aux services payants de professionnels à même de mener à bien des missions d'évaluation, de planification et de déploiement.

La personnalisation de certains aspects de l'outil est aussi réalisable par ce biais.

Ce sont ces différents éléments qui ont amené au choix de Kolab comme solution de messagerie collaborative pour la ville de Pontoise.


II.2) Evaluation des ressources requises et établissement du planning

II.2.1) Plan d'utilisation des ressources


II.2.2) Tâches affectées aux différentes ressources

Le tableau ciaprès permet de mettre en évidence le planning chronologique des actions mises en œuvre. La colonne « durée » est indicative dans la mesure où chacune des ressources mobilisées dans le cadre du projet a rarement été employée uniquement à ce projet, du fait de la multitude de missions quotidiennes à mener.

● Directeur Général Adjoint (PG) pour la définition de la lettre de cadrage, la décision en matière de choix final de la solution,● Technicien bureautique (PCo) pour l'évaluation des différentes fonctionnalités au sein des différents logiciels clients,● Responsable applications (PCa) pour l'évaluation des clients et l'intégration de la solution dans l'intranet,● Technicien réseau (LD) pour les tests du serveur prototype, l'évaluation des tests de sauvegarde / restauration, l'intégration réseau,● Directeur informatique (SM) agissant en tant que coordinateur du projet et supervisant l'ensemble des étapes techniques.


II.2.3) Diagramme de Gantt

Le diagramme cidessous permet de visualiser, pour chacune des tâches le temps qui lui est alloué, la planification prévue et les ressources qui seront sollicitées. L'enchaînement des actions est matérialisé par les flèches.

Pour chaque action, une durée (Travail) en nombre de jours est précisée : cette durée représente le temps alloué compte tenu des nombreuses autres missions menées parallèlement à ce projet.


II.2.4) Estimation des coûts

La mise en place d'une nouvelle solution engendre un certain nombre de dépenses. Dans le cas de Kolab, dans la mesure où il s'agit d'un outil qui est mis à disposition gratuitement, les coûts sont répartis entre les extensions qu'il est nécessaire de prévoir, les mises à jour logicielles et les éventuelles charges liées à l'intervention d'un consultant.

Le client de messagerie Microsoft Outlook nécessite l'achat d'un greffon logiciel pour être interfacé avec le serveur et bénéficier de ce fait des fonctions collaboratives. Le changement de solution est aussi l'occasion d'une mise à niveau des clients Outlook vers la version 2003 pour des soucis d'homogénéité du parc logiciel.

Licences annexes pour Kolab Coût TTC

50 licences Microsoft Outlook 2003 (coût unitaire 72,80 € HT) 4353,44 €

50 licences Toltec Connector for Outlook (coût unitaire 25 € HT)

1495,00 €

Total des licences 5848,44 €

En dehors de ces coûts, la Direction Informatique et Téléphonie a souhaité avoir recours à une assistance à maîtrise d'ouvrage afin d'obtenir une validation du bien fondé des choix techniques effectués. Le recours à un consultant disposant d'un savoir faire en la matière est donc acté, la société ATOL CD étant retenue pour son expérience dans le déploiement de Kolab auprès de plusieurs grands comptes.

Mission d'assistance à maîtrise d'ouvrage Coût TTC

2 journées sur site et résolution de 24 tickets d'incidents 2000,00 €

Le coût externe total lié aux travaux de déploiement et de licences de la nouvelle solution de messagerie collaborative s'élève à 7848,44 euros TTC. Il est intéressant de rapprocher ce montant des frais de déploiement de la solution Microsoft Exchange en 1999, en tenant compte du fait que cette dernière ne donnait accès aux fonctions collaboratives qu'à un panel d'utilisateurs limité :

Licences pour Microsoft Exchange Coût TTC

Exchange Serveur et Outlook serveur 713,03 €

Exchange Administration 3717,52 €

45 licences Microsoft Outlook 97 (coût unitaire 66,10 € HT) 3557,50 €

Forfait d'installation 1286,97 €

Coût total 9275,02 €

Il convient d'ajouter deux éléments pour être à périmètre comparable, à savoir une solution permettant de lutter contre les courriels indésirables et un outil d'éradication des virus véhiculés par le courrier électronique.

Outils additionnels requis par Microsoft Exchange Coût TTC

45 licences McAfee Spamkiller (coût unitaire 22,10 € HT) 1189,42 €

McAfee GroupShield pour serveur 1537,63 €

Coût total 2727,05 €

Le total de la solution Microsoft Exchange était de 12000 € TTC contre 7848,44 € TTC pour Kolab, soit une économie de plus de 50 pour cent en faveur du nouvel outil.


III) Installation et évaluation de la solutionAfin de valider le choix réalisé, une maquette de la solution doit être réalisée. L'objectif de cette étape consiste à mettre en place un outil suffisamment fonctionnel pour que des tests de nature à valider les capacités de l'outil soient effectués, tout en minimisant les investissements.

III.1) Définition d'un environnement de test

III.1.1) Matériel à disposition pour l'environnement de test

Pour mener à bien les différents tests, un serveur Bull biprocesseur Intel Xeon 3060 (dont la spécificité est d'incorporer le support de certaines fonctions propres aux mécanismes de virtualisation) doté de 4 gigaoctets de mémoire a été retenu. Ce serveur hébergera l'ensemble des services applicatifs. Il dispose de 4 disques SATA de 250 gigaoctets qui seront configurés en mode RAID 5 pour l'occasion.

III.1.2) Système d'exploitation

La ville de Pontoise utilise le système d'exploitation Linux sur l'ensemble de ses serveurs, la distribution utilisée étant Debian GNU Linux dans sa version 4.0 (nom de code Etch). Il s'agit d'une distribution Linux non commerciale extrêmement populaire, réputée pour sa fiabilité et sa richesse. Soutenue par un important réseau de développeurs dans le monde, elle a deux grands principes qui sont l'engagement visàvis de ses utilisateurs et la qualité. Les distributions Ubuntu et Knoppix qui connaissent actuellement un succès croissant sont des dérivés de la distribution Debian. Kolab est disponible sous la forme de paquets OpenPKG précompilés pour cette distribution mais sera compilé à partir des sources.

III.1.3) Organisation réseau

Afin de tester la solution sans perturber le fonctionnement des outils existants, la solution sera configurée comme serveur de messagerie du domaine « pontoise.fr » (le domaine de messagerie de la ville étant « villepontoise.fr »).

Ce domaine DNS n'est pas utilisé pour l'instant et est associé à une des adresses IP de la plage d'adresses fournies par le prestataire d'accès à internet. Une règle sur le parefeu a donc été mise en place afin que les courriels reçus sur cette interface soient redirigés sur le réseau interne de tests.

Illustration 11 : Architecture réseau de l'environnement de test

III) Installation et évaluation de la solution Page 24 sur 137

III.1.4) Virtualisation

Pour mener à bien cette phase de test, le recours à la solution de paravirtualisation XEN a été décidé. Le principe consiste à utiliser sur une même machine physique plusieurs systèmes d'exploitation simultanément.

Le système hébergeur (ou DOM0) permet de contrôler les systèmes hébergés (ou DOMU). Le matériel « vu » par les DOMU est donc virtuel et les ressources peuvent être augmentées ou diminuées pour s'adapter aux besoins. Ce choix permet de simplifier l'installation, le déploiement et l'éventuelle migration des « machines virtuelles » entre machines physiques.

Dans le contexte courant, la livraison finale de l'outil s'en trouvera grandement facilitée. Par ailleurs, l'installation, les tests, les développements peuvent facilement être rétroeffectués dans le cas de mauvaise manipulation, l'ensemble des données du serveur pouvant être regroupé au sein d'un seul fichier vu par le système d'exploitation hébergé comme un disque dur à part entière.

Il est aussi possible d'agir sur la puissance de calcul disponible (nombre de processeurs) ou sur la quantité de mémoire afin de placer l'environnement de test dans une situation de stress. Enfin, le dimensionnement de la solution pourra être revu sans remettre en cause tout le travail effectué. A terme, une fois l'outil en production, il sera beaucoup plus aisé de gérer les cas de reprise après incident.

III.2) Mise en place de l'environnement de test L'installation de la partie hôte de l'hyperviseur XEN ne sera pas abordée ici. Nous commençons donc par l'installation du système hébergé (communément dénommé DOMU) par opposition au système hébergeur (le DOM0).

III.2.1) Configuration du système hébergeur (DOM0)

Sur la machine en question, nous commençons par créer de pseudo volumes disques, qui seront pour l'occasion au nombre de quatre :

➢ un volume disque de 5 gigaoctets qui contiendra le système hôte,➢ un volume disque de 2 gigaoctets destiné aux paquets téléchargés sur le site de Kolab,➢ un volume disque de 30 gigaoctets propre à l'outil Kolab et ses fichiers de données,➢ un volume d'échange de 500 mégaoctets (échanges mémoiredisque).


On utilise pour cela la commande dd pour copier des blocs de données vierges d'information dans un fichier qui sera ensuite destiné à servir de disque virtuel :

xen:/# dd if=/dev/zero of=/images/kolab22.img bs=100M count=300 31457280000 octets (31 GB) copiés, 1352,35 secondes, 23,3 MB/s xen:/# dd if=/dev/zero of=/images/kolab22-inst.img bs=100M count=20 2097152000 octets (2,1 GB) copiés, 32,9061 secondes, 63,7 MB/s xen:/# dd if=/dev/zero of=/images/kolab22-os.img bs=100M count=50 5242880000 octets (5,2 GB) copiés, 201,556 secondes, 26,0 MB/s xen:/# dd if=/dev/zero of=/images/kolab22-swap.img bs=100M count=5 524288000 octets (524 MB) copiés, 2,41596 secondes, 217 MB/s

Au terme de cette étape, nous disposerons de 4 fichiers :

xen:/# ls -l /images -rw-r--r-- 1 root root 31457280000 2008-01-14 11:28 kolab22.img -rw-r--r-- 1 root root 2097152000 2008-01-14 11:35 kolab22-inst.img -rw-r--r-- 1 root root 5242880000 2008-01-14 11:45 kolab22-os.img -rw-r--r-- 1 root root 524288000 2008-01-14 14:09 kolab22-swap.img

Nous transformons ces fichiers en partitions utilisables :

xen:/# mkfs.ext3 /images/kolab22-os.img mke2fs 1.40-WIP (14-Nov-2006) /images/kolab22-os.img n'est pas un périphérique spécial en mode bloc. Procéder malgré tout? (y pour oui, n pour non) y Type de système d'exploitation : Linux Taille de bloc=4096 (log=2) Taille de fragment=4096 (log=2) 640000 i-noeuds, 1280000 blocs 64000 blocs (5.00%) réservés pour le super utilisateur Nombre maximum de blocs du système de fichiers=1312817152 40 groupes de blocs 32768 blocs par groupe, 32768 fragments par groupe, 16000 i-noeuds par groupe Superblocs de secours stockés sur les blocs : 32768, 98304, 163840, 229376, 294912, 819200Écriture des tables d'i-noeuds : complété Création du journal (32768 blocs) : complété Écriture des superblocs et de l'information de comptabilité du système de fichiers : complété

Cette étape est répétée pour chacun des volumes (pour la partition d'échange, on utilisera la commande « mkswap » en lieu et place de « mkfs.ext3 »). Nous allons maintenant monter le système de fichier destiné à recevoir le système d'exploitation :

xen:/# mount -o loop /images/kolab22-os.img /mnt

Il faut désormais installer le système sur la partition en question. « debootstrap » permet d'installer une distribution Debian (ou assimilée) sur un point de montage via l'utilisation d'un autre système en service. Cet outil récupère les paquets à partir d'un site internet.

xen:/# debootstrap etch /mnt http://ftp.easynet.be/ftp/debian I: Retrieving Release I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Checking component main on http://ftp.easynet.be/ftp/debian... I: Retrieving adduser I: Validating adduser I: Configuring sysklogd... I: Configuring tasksel... I: Base system installed successfully.

Au terme de la procédure, il reste à basculer sur le nouveau système :

xen:/# chroot /mnt


Nous sommes maintenant dans l'environnement fraîchement installé qu'il convient de configurer. La première étape va consister en l'ajout du mot de passe de l'utilisateur root :

xen:/# passwd rootEnter new UNIX password: Retype new UNIX password: passwd: password updated successfully

Il importe notamment de configurer le nom de machine, les interfaces réseau, les volumes à monter de façon automatique. Ces informations se trouvent respectivement dans les fichiers /etc/hosts, /etc/hostname, /etc/network/interfaces et /etc/fstab :

/etc/hosts 127.0.0.1 localhost kolab.pontoise.fr

On renseigne le nom de la machine :

/etc/hostnamekolab.pontoise.fr

Enfin, on précise les volumes à monter de façon automatique au démarrage :

/etc/fstab# proc /proc proc defaults 0 0 /dev/hda1 / ext3 defaults 0 1 /dev/hda2 /kolab ext3 defaults 0 0 /dev/hda3 /kolabinst ext3 defaults 0 0 /swap none swap sw 0 0

Puis vient la configuration du réseau, l'interface principale se configurant automatiquement dans notre cas via l'interrogation d'un serveur de type DHCP :

/etc/network/interfacesauto lo iface lo inet loopback

auto eth0 iface eth0 inet dhcp

Dernière étape, pour fonctionner le DOMU doit utiliser une librairie C spécifiquement modifiée. On utilise le système de paquetage propre au projet Debian pour l'installer :

xen:/# apt-get install libc6-xen

III.2.2) Configuration du système hébergé (DOMU)

Notre système est prêt à fonctionner. Il faut désormais le configurer au niveau du DOM0 avant de le lancer et de poursuivre la configuration de l'outil Kolab. On quitte le système hébergé puis on démonte du DOM0 le volume :

xen:/# exitxen:/# umount /mnt

Il faut préparer une interface réseau sur le serveur qui sera dédiée au DOMU Kolab. On modifie à cet effet le fichier de configuration réseau afin d'installer une interface de type pont :

auto br-xeniface br-xen inet dhcp bridge_ports eth0 bridge_stp off bridge_maxwait 0


Cette interface doit être démarrée (elle obtiendra aussi une configuration automatique par l'utilisation d'un serveur DHCP) :

kolab:/# ifup br-xenInternet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ Listening on LPF/br-xen/00:13:46:2f:fc:4f Sending on LPF/br-xen/00:13:46:2f:fc:4f Sending on Socket/fallback DHCPDISCOVER on br-xen to 255.255.255.255 port 67 interval 6 DHCPOFFER from ...

Il convient désormais de préparer le démarrage du DOMU.

Ce dernier se configure à l'aide d'un fichier placé dans le dossier /etc/xen et que nous nommerons ici xenkolab.sxp. Voici le fichier en question :

# On nomme l'hôte virtuelname="kolab.pontoise.fr"

# On active le noyau qu'utilise le DOMU et que l'on retrouve installé sur le DOM0 kernel="/boot/vmlinuz-2.6.18-5-xen-686"

# On nomme le disque chargé en mémoire pour le processus de démarrage du système (initrd )ramdisk="/boot/initrd.img-2.6.18-5-xen-686"

# On précise le disque systèmeroot="/dev/hda1"

# On indique la mémoire allouée memory="2048"

# nous retrouvons ici les disques durs virtuels configurés précedemmentdisk = [ 'file:/images/kolab22-os.img,hda1,w', 'file:/images/kolab22.img,hda2,w', 'file:/images/kolab22-inst.img,hda3,w', 'file:/images/kolab22-swap.img,hda4,w' ]

# spécification d'une interface virtuelle fournir, de son adresse MAC, du pont à utiliser vif=[ 'mac=00:00:de:ad:ba:bf, bridge=br-xen' ]

# On donne les paramètres de l'interfacedhcp="on"

# et enfin le niveau de démarrage du DOMU extra="3"

Il reste à démarrer le nouveau serveur :

kolab:/# xm create -c -f /etc/xen/debian-xen-kolab22.sxp Using config file "/etc/xen/debian-xen-kolab22.sxp". Started domain kolab.pontoise.fr Linux version 2.6.18-5-xen-686 (Debian 2.6.18.dfsg.1-13) ([email protected]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Fri Jun 1 05:05:24 UTC 2007 BIOS-provided physical RAM map: Xen: 0000000000000000 - 0000000080800000 (usable) 1328MB HIGHMEM available. 727MB LOWMEM available. NX (Execute Disable) protection: active ACPI in unprivileged domain disabled Built 1 zonelists. Total pages: 526336 Kernel command line: ip=:1.2.3.4::::eth0:on root=/dev/hda1 3 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Xen reported: 2400.084 MHz processor. Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Software IO TLB disabled vmalloc area: ee000000-f51fe000, maxmem 2d7fe000 Memory: 2062148k/2105344k available (1579k kernel code, 33980k reserved, 584k data, 148k init, 1359880k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 6002.81 BogoMIPS (lpj=12005637)


Allocation de lamémoire spécifiée

Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 4096K Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 12k freed Brought up 1 CPUs migration_cost=0 checking if image is initramfs... it is Freeing initrd memory: 10445k freed Grant table initialized NET: Registered protocol family 16 Brought up 1 CPUs PCI: setting up Xen PCI frontend stub ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled xen_mem: Initialising balloon driver. PCI: System does not support PCI PCI: System does not support PCI NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 5, 131072 bytes) TCP established hash table entries: 131072 (order: 8, 1048576 bytes) TCP bind hash table entries: 65536 (order: 7, 524288 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered audit: initializing netlink socket (disabled) audit(1200389000.510:1): initialized highmem bounce pool size: 64 pages VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Xen virtual console successfully installed as tty1 Event-channel device installed. netfront: Initialising virtual ethernet driver. PNP: No PS/2 controller found. Probing ports directly. i8042.c: No controller found. mice: PS/2 mouse device common for all mice TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 8 NET: Registered protocol family 20 Using IPI No-Shortcut mode Registering block device major 3 netfront: device eth0 has flipping receive path. Freeing unused kernel memory: 148k freed Loading, please wait... Begin: Loading essential drivers... ... Done. Begin: Running /scripts/init-premount ... FATAL: Error inserting fan (/lib/modules/2.6.18-5-xen-686/kernel/drivers/acpi/fan.ko): No such device FATAL: Error inserting thermal (/lib/modules/2.6.18-5-xen-686/kernel/drivers/acpi/thermal.ko): No such device Done. Begin: Mounting root file system... ... Begin: Running /scripts/local-top ... Done. Begin: Running /scripts/local-premount ... Done. kjournald starting. Commit interval 5 seconds


Utilisation d'unprocesseur

Initialisation dela pile TCP/IP

Initialisation dela console virtuelle

Montage du systèmede fichiers racine

EXT3-fs: mounted filesystem with ordered data mode. Begin: Running /scripts/local-bottom ... Done. Done. Begin: Running /scripts/init-bottom ... Done. Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled INIT: version 2.86 booting Starting the hotplug events dispatcher: udevd. Synthesizing the initial hotplug events...done. Waiting for /dev to be fully populated...input: PC Speaker as /class/input/input0 done. Activating swap...Adding 511992k swap on /dev/hda4. Priority:-1 extents:1 across:511992k done. Checking root file system...fsck 1.40-WIP (14-Nov-2006) /dev/hda1: clean, 10992/640000 files, 126895/1280000 blocks done. EXT3 FS on hda1, internal journal Setting the system clock.. Cleaning up ifupdown.... Loading kernel modules...done. Loading device-mapper supportdevice-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: [email protected] . Checking file systems...fsck 1.40-WIP (14-Nov-2006) done. Setting kernel variables...done. Mounting local filesystems...kjournald starting. Commit interval 5 seconds EXT3 FS on hda2, internal journal EXT3-fs: mounted filesystem with ordered data mode.

kjournald starting. Commit interval 5 seconds EXT3 FS on hda3, internal journal EXT3-fs: mounted filesystem with ordered data mode. done. Activating swapfile swap...done. Setting up networking.... Configuring network interfaces...Internet Systems Consortium DHCP Client V3.0.4 Copyright 2004-2006 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:00:de:ad:ba:bf Sending on LPF/eth0/00:00:de:ad:ba:bf Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14 DHCPOFFER from xxx.xxx.200.1 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from xxx.xxx.200.1 bound to xxx.xxx.200.223 -- renewal in 68053 seconds. done. INIT: Entering runlevel: 3 Starting system log daemon: syslogd. Starting kernel log daemon: klogd. * Not starting internet superserver: no services enabled. Starting OpenBSD Secure Shell server: sshdNET: Registered protocol family 10 lo: Disabled Privacy Extensions IPv6 over IPv4 tunneling driver Starting periodic command scheduler: crond.

Debian GNU/Linux 4.0 kolab.pontoise.fr tty1

kolab.pontoise.fr login:

L'option « c » de la ligne de commande permet de suivre le démarrage du serveur, de consulter d'éventuels messages d'erreurs et d'accéder à l'invite de connexion.


Montage des volumes et de la

partition d'échange

Configurationautomatique duréseau via DHCP

Fin du processus dedémarrage et accès àl'invite de connexion

En l'absence de cette option, le serveur Openssh ayant été installé sur le DOMU, il est possible de se connecter à partir de tout client SSH depuis un autre poste.

Le nouveau serveur est désormais opérationnel. Pour que le DOM0 lance automatiquement le nouveau DOMU, il est nécessaire de créer un lien symbolique dans le dossier /etc/xen :

kolab:/# ln -s /etc/xen/debian-xen-kolab22.sxp /etc/xen/auto/debian-xen-kolab22.sxp

Le système est opérationnel, le lancement de l'installation de la solution peut commencer.

III.2.3) Installation de la solution

Pour installer la solution, on doit commencer par télécharger l'ensemble des composants. On va utiliser l'outil rsync pour cela avec la commande suivante :

kolab:/kolabinst# wget -r http://ftp.belnet.be/packages/kolab/server/beta/kolab-server-2.2-beta-3/sources/

L'ensemble des instructions concernant l'installation de Kolab se trouve dans le document 1st.README. Il convient de vérifier la conformité et l'intégrité des paquets téléchargés :

kolab:/kolabinst# gpg --verify MD5SUMS gpg: Signature made Fri Dec 7 20:13:49 2007 CET using DSA key ID 5816791A gpg: Can't check signature: public key not found

La clé est manquante dans le trousseau de l'utilisateur. Il convient donc de l'importer :

kolab:/kolabinst# gpg --keyserver=x-hkp://pgp.mit.edu --recv-keys 5816791A gpg: keyring `/root/.gnupg/secring.gpg' created gpg: requesting key 5816791A from hkp server pgp.mit.edu gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key 5816791A: public key "Thomas Arendsen Hein " imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1

On lance la vérification :

kolab:/kolabinst# md5sum -c MD5SUMS 00INDEX.rdf: OK 1st.README: OK PEAR-Auth_SASL-1.0.2-1.src.rpm: OK PEAR-Date-1.4.7-1.src.rpm: OK PEAR-HTTP_Request-1.4.1-1.src.rpm: OK ...

L'énumération du nom de chacun des paquets téléchargés apparaît suivie d'un signe « OK » pour en confirmer l'intégrité. Le script d'installation doit être rendu exécutable puis lancé :

kolab:/kolabinst# chmod +x ./install-kolab.sh

L'installation de Kolab à partir des fichiers sources nécessite l'installation des éléments de base permettant la compilation et la production de fichiers binaires :

kolab:/kolabinst# apt-get install make gcc build-essentialReading package lists... Done Building dependency tree... Done make is already the newest version. The following extra packages will be installed: binutils cpp cpp-4.1 gcc-4.1 libssp0 Suggested packages: binutils-doc cpp-doc gcc-4.1-locales manpages-dev autoconf automake1.9 libtoo

mémoire - pierre.sweid1.free.frpierre.sweid1.free.fr/cnam/cours_c3/memoire.pdf · habituellement...

Documents