MALIN Nicolas DESS SIRAD. Rapport de Stage. Septembre 2004 1/61

MALIN Nicolas DESS SIRAD Rapport de Stage Septembre 2004 1/61

Table des matières 1. Introduction...5 2. Présentation de l'entreprise...5 3. Objectifs du Stage...5 PREMIERE PARTIE : OFBiz 1. Découverte d'ofbiz...7 2. Fonctionnement général d'ofbiz...7 Architecture...7 Organisation d'un module...8 Architecture d'un module...8 Description des fichiers et répertoires...9 Cheminement lors d'une requête...10 Mon intervention sur OFBiz...14 3. Forces et faiblesses du PGI...14 Ses Forces...14 Ses Faiblesses...15 Mon sentiment sur le PGI...16 4. La naissance d'un projet : Neogia...16 Un changement de programmation...16 Qu'apporte LutinGenerator dans le cas d'ofbiz?...17 Ce que remplit Neogia...17 Une conception de haut niveau...18 Une programmation orientée Objet...18 Un gain de temps sur le développement...18 Une réactivité du développement...18 Au final...19 5. Fonctionnement de Neogia...19 L'arborescence de fichier...19 Explication de l'arborescence de Neogia...20 Les dépendances du projet...21 Comment fonctionne la génération...21 6. Création du module de comptabilité...22 Diagramme UML...22 Diagramme de classe : CharOfAccount...23 Diagramme de classe : AccountingTransaction...24 Première génération...24 Création de l'arborescence du module...25 Développement du module...25 Renseigner le model UML...26 Effectuer le développement spécifique...26 Dans le cas de la comptabilité...28 Les comptes comptables (NGlAccount)...28 Les périodes comptables (GlPeriod)...28 Les transactions (AcctgTransaction)...28 Les écritures (AcctgTransactionItem)... 29 Les lignes d'écritures (GlEntry)...29 Les problèmes d'intégration dans OFBiz...29 Un projet en pleine croissance...29 Au niveau de la licence...30 7.Conclusion...30 2/61

DEUXIEME PARTIE : REORGANISATION DE L'INFRASTRUCTURE DE NEREIDE 1. Description de l'existant et des besoins...32 Structure du réseau existant...32 Quels besoins doit couvrir la nouvelle architecture?...33 2. Analyse des choix pour une nouvelle architecture...33 Harmonisation des systèmes d'exploitation...33 Authentification centralisée des utilisateurs...35 Centralisation des données utilisateurs...36 Sécurisation du réseau...37 Protection du réseau des attaques extérieures... 37 Sécurisation des informations...37 Continuité des services du réseau de Néréide...39 3. Nouvelle architecture du réseau de Néréide...40 Services réseau offerts...41 4. Mise en place de la nouvelle architecture...42 Première étape : passage sur un serveur auxiliaire...42 Deuxième étape : une migration progressive...42 Dernière étape : le basculement final...42 5. Les sauvegardes...42 Le script de synchronisation des disques: vue_journaliere.sh...43 Le script de sauvegarde sur le serveur secondaire : balance_push.sh...43 6. Problèmes rencontrés...44 Le serveur LDAP...44 Le serveur DNS : MaraDNS...44 Migration des données utilisateurs...44 Erreur humaine ou piraterie réussie...45 7. Une migration non finie...45 8. Conclusion...45 Conclusion du stage...47 Remerciements...47 Bibliographie...49 Références utilisées dans le cadre du développement... 49 Sites internets...49 Livre O'reilly...49 Autre livre...49 Références utilisées dans le cadre de la migration du réseau de Néréide...49 Sites internets...49 Livre O'reilly...49 Annexes 1.Migration du réseau de Néréide...51 But du document...51 Etapes de la migration...51 Première étape...52 Export des répertoires via NFS...52 Configuration de la machine cliente (imbros)...53 Reallocation des $HOME :...53 Après réallocation des $HOME des utilisateurs,...53 3/61

Deuxième étape...54 Troisième étape...55 Quatrième étape...55 Migration du service ldap...55 Migration des services de fichiers...55 Migration des données...55 Re-positionnement du serveur...55 Cinquième étape...56 Préparation de la migration...56 Migration des machines...56 2.Migration de serveur principal pour la nouvelle architecture réseau...57 But du document...57 Analyse de l'existant...57 /dev/hda :......57 /dev/hdc :...57 Étapes de la migration de serveur principal...58 Installation de Debian Sarge sur serveur principal...58 Sauvegarde des données restante...58 Réorganisation des disques durs de serveur principal...58 Installation des services...58 Configuration des services...59 Migration des données utilisateurs...59 3.Sauvegarde des données du serveur...60 But du document...60 Deux types de sauvegarde...60 Sauvegarde disque à disque......60 Explication...60 Fonctionnement de la sauvegarde...60 Fonctionnement du script...60 Sauvegarde sur serveur secondaire...60 Explication...60 Fonctionnement de la sauvegarde...61 4/61

1. Introduction L'informatique d'entreprise a longtemps ignoré les logiciels libres, pas assez "pro", pas assez sérieux, pas assez rémunérateur. Actuellement, le système d'éditeur de logiciel propriétaire entame un déclin dû à un coût de licence prohibitif. En effet, les entreprises qui investissent dans des solutions logicielles propriétaires pour améliorer leur système d'information, doivent justifier auprès de leur direction des retours sur investissement. Le peu d'argument expliquant le coût de licence de ces logiciels devient flagrant. De plus en plus de chefs d'entreprise arrivent effectivement à ce constat. Seule, les offres de service associées trouvent des justifications. Les logiciels libres commencent à prendre une part de marché dans les logiciels d'entreprise. Ceci est particulièrement vrai pour les serveurs, et commence timidement pour la bureautique. Il reste des secteurs où des solutions libres ne sont pas encore disponibles et notamment dans le secteur des Progiciels de Gestion Intégré. Néréide est une Société de Services du Logiciel Libre, spécialisée dans le domaine de l'intégration de PGI open source à destination des PME, qui m'a prise en stage dans le but de m'investir sur le développement d'un PGI libre nommé OFBiz. Mon travail doit, dans un premier temps, porter sur la compréhension du fonctionnement du PGI sur la couche fonctionnelle, puis sur le développement d'un module de comptabilité. Néréide étant une société naissante, mon maître de stage m'a confié la tâche de réorganiser leur réseau de façon à le rendre plus performant et plus souple par rapport à leurs méthodes de travail. 2. Présentation de l'entreprise Néréide est une SSLL sous le statut SARL. Créée en mars 2004, elle comporte 4 personnes et couvre principalement la mise en oeuvre, le développement et les services sur le PGI libre à l'attention des PME : OFBiz. 3. Objectifs du Stage Premier Objectif : Comprendre le fonctionnement du PGI Libre OFBiz et y développer un module de comptabilité. Second Objectif : Mettre en place une nouvelle architecture réseau opérationnelle pour la société Néréide. 5/61

PREMIERE PARTIE : OFBiz 6/61

1. Découverte d'ofbiz OFBiz est un Progiciel de Gestion Intégré libre, développé sur une architecture JAVA - J2EE. Son développement a été pensé dès le début pour être le plus modulaire possible, surtout avec l'utilisation de technologie libre pré-existante. Ainsi OFBiz est compatible avec : - tous les serveurs d'applications J2EE ( Jboss, Tomcat, Jetty, etc... ) - toutes les bases de données (MySql, PostgresSql, SapDB, Firebird, DB2, etc...) De plus, il utilise de nombreux projets libres, dont : Jetty : serveur d'applications par défaut Jpublish, Freemark, BeanShell : pour la gestion des écrans utilisateurs HyperSonicDB: base de données par défaut Jasper Report : génération de fichier pdf OFBiz fonctionne sur une architecture J2EE orientée web via l'utilisation des servelets donc le client a juste besoin d'un navigateur internet quelconque pour pouvoir se connecter au PGI. 2. Fonctionnement général d'ofbiz Architecture OFBiz repose sur une architecture à plusieurs niveaux où chaque niveau est spécialisé dans un domaine. Applications Composants applicatifs de base Composants applicatifs - techniques Composants techniques de base J2EE container SGBD Java OS Chaque niveau possède des éléments spécialisés dans une fonction. Le niveau nous intéressant étant les composants applicatifs. 7/61

Comptabilité Générale Gestion Commerciale Gestion Maintenance Applications Composants Acteur applicatif de base Commun Contenu Sécurité Services ECA Entity WorkFlow Employé - Ressource Humaine Gestion Projet Relation Client Relation Fournisseur Gestion du service E-Commerce Comptabilité Analytique Comptabilité Tiers Article Ordre Stock Tâche Comptabilité Trésorerie Catalogue Produit Gestion Achat Gestion Production J2EE container SGBD Java OS Ce niveau est structuré en modules qui ont pour spécialisation une application métier de l'entreprise. Organisation d'un module Un module est un programme fonctionnel s'appuyant sur les couches techniques du PGI. Le module contient toutes les informations nécessaires à son bon fonctionnement : description des entités, source java, description des services, fichier de définition d'écran, etc... Toutes ces informations sont organisées dans une arborescence propre au module. Cette arborescence la même structure quelque soit le module et sera détaillée au chapitre suivant. Les modules peuvent inter-agir entre eux via des mécanismes simples (service), permettant de bien spécialiser les fonctionnalités de chacun. Architecture d'un module Les modules sont tous structurés de la même façon. Ci-dessous suit une présentation de l'architecture d'un module d'ofbiz : module +- config +- data +- entitydef +- lib 8/61

+- servicedef +- src +- webapp `-module +-error +-sous-module +-templates +-WEB-INF +-actions +-pagedefs -controller.xml -jpublish.xml `-web.xml `-login.ftl `- OFBiz-components.xml Description des fichiers et répertoires module : config : ce répertoire contient les fichiers d'internationalisation et les fichiers «properties» de configuration. data : ce répertoire contient des fichiers xml de données utilisateurs relatif au module. Ces données sont d'ordre d'obligation ou de démonstration entitydef : ce répertoire contient deux fichiers qui décrivent les entités qu'utilisent ce module. Ces fichiers sont directement utilisés pour la description et la construction des tables de la base de données. servidef : ce répertoire contient un fichier, services.xml qui associe des fonctions java, ou d'autres langages, présentes dans les sources du module à un nom de service. src : ce répertoire contient les sources des fichiers java relatif au module. C'est dans ces fichiers que sont définies les fonctions appelées via le fichier services.xml. webapp : ce répertoire contient une arborescence de fichiers qui sont utilisés pour la génération des écrans utilisateurs. OFBiz-components.xml : ce fichier décrit le module pour son intégration dans OFBiz. module/webapp/module : error : ce répertoire contient les messages à afficher suivant 9/61

l'erreur générée par le serveur d'applications. sous-module : un module est organisé en sous-parties, suivant l'application faite dans le module avec un objectif de description. Ce répertoire contient les fichiers de structure des forms et les fichiers de structure d'écrans utilisateurs (fichiers ftl). templates : ce répertoire contient les fichiers de structure de base comme l'écran d'accueil du module ou encore les écrans de recherche. WEB-INF : ce répertoire contient une arborescence contenant les fichiers effectuant les traitements nécessaires sur les informations avant leur affichage. login.ftl : ce fichier décrit la structure de l'écran de connexion au module. module/webapp/module/web-inf : actions : ce répertoire contient des fichiers source java interprétés : des fichiers beanshell. Ces derniers servent à remplir le contexte d'informations, nécessaire à l'affichage des informations dans les écrans utilisateurs. Ces informations peuvent provenir d'un appel à la base de données ou d'un traitement quelconque sur des informations déjà présentes dans le contexte. pagedefs : ce répertoire contient la définition d'un écran utilisateur. Ceci comprend les informations initiales et/ou à rajouter au contexte pour l'utilisation de cette page ainsi que diverses définitions des fichiers de structure et des fichiers BeanShell à appeler pour la génération de l'écran. controller.xml : ce fichier met en relation les urls envoyées par le client et la page à renvoyer. Cette page est le résultat d'un enchaînement d'opérations qui sont indiquées dans ce fichier. jpublish.xml : fichier de configuration pour la fusion du contexte avec les fichiers de strucutre ftl. web.xml : configuration du serveur web. Deux fichiers sont extrêmement importants dans un module : le fichier controller.xml et le fichier services.xml. Le premier : controller.xml sert à OFBiz pour savoir quel service et action puis quelle vue doit être appelés suivant une requête effectuée. Le second : services.xml sert à OFBiz pour mettre en relation l'appel à un service et la fonction associée se trouvant dans les sources du module Cheminement lors d'une requête Le développement effectué sur OFBiz ne se situe pas dans les couches basses du PGI mais au niveau de l'interaction entre l'utilisateur et OFBiz, sur la partie fonctionnelle. Pour cela, il est nécessaire de bien cerner l'ordre des fichiers qu'ofbiz va lire suivant une requête afin de construire la page de réponse. 10/61

Voici le cheminement d'une requête simple pour la construction de l'écran en réponse. L'utilisateur saisit un objet et valide son édition : 11/61

1) L'utilisateur valide l'édition de l'objet; la requête est alors envoyée au serveur d'application d'ofbiz. A la réception de la requête, le serveur lit le fichier controller.xml du module concerné pour savoir ce qui doit être exécuté. Voici les lignes nous intéressants, contenues dans le fichier controller.xml : <request-map uri="editobjet"> <security https="true" auth="true"/> <event type="service" invoke="editobjet"/> uri reçu par le serveur service appelé <response name="success" type="view" value="editobjet"/> <response name="error" type="view" value="editobjet"/> </request-map> retour du service et action à effectuer <view-map name="editobjet" type="jpublish" page="/sousmodule/editobjet.ftl"/> Ecran à générer via le fichier ftl indiqué 2) Suivant les informations contenues dans le fichier controller.xml, un service et/ou une création d'écran est appelé. Création de l'écran de réponse : Le fichier controller.xml indique le chemin vers un fichier, ici EditObjet.ftl. Ce fichier va servir de structure pour l'écran de retour. Est associé implicitement à ce fichier, un autre fichier : EditObjet.xml, qui définit diverses informations de l'écran. C'est à partir de ce fichier que sont mentionnés différents fichiers qui vont être lus pour remplir le contexte des informations nécessaires et ainsi satisfaire la demande. Voici en exemple le contenu du fichier EditObjet.xml: <page> <template>main</template> <property name="titleproperty">editobjet</property> <property name="headeritem">exemple</property> <property name="submenu">/exemple/tabbarobjet.ftl</property> <property name="viewsize">20</property> <property name="permission">objet</property> <property name="entityoperation">_update</property> <property name="permissiontype">simple</property> <content-action name="/includes/checkpermission.bsh"/> <content-action name="/exemple//editobjet.bsh"/> 12/61 propriétés de la page mises dans le contexte Liste des fichiers bsh à appeler pour le remplissage des informations dans la page

<content-action name="/includes/pagelistprep.bsh"/> </page> Appel d'un service : Lorsqu'un service est appelé, OFBiz lit le fichier service.xml du module afin de déterminer la fonction à appeler. Voici l'entrée de notre exemple : <service name="editobjet" default-entity-name="objet" engine="java" location="org.ofbiz.exemple.sousmodule.objetservices" invoke="editobjet" auth="true"> description de <description>editer un Objet</description> l'appel de fonction <auto-attributes include="all" mode="inout" optional="true"/> <attribute name="actionform" type="string" mode="in" optional="false"/> </service> description des paramètres passés à la fonction et ses valeurs de retour 3) Les différents fichiers bsh (beanshell) sont appelés dans l'ordre de leur rencontre dans le fichier de description de la page (EditObjet.xml dans notre cas). Dans ce dernier se trouve aussi le chemin vers un fichier de form. Ce fichier FormObjet.xml, dans notre cas, contient les différentes formes qui peuvent apparaître pour l'affichage de l'écran. Durant l'exécution des fichiers bsh, diverses informations sont inscrites dans le contexte. Ces dernières peuvent provenir des résultats d'une recherche dans la base de données, d'un appel de fonction ou encore de l'utilisation d'algorithme. Voici un exemple de la description de la forme pour l'editobjet contenue dans le fichier FormObjet.xml: description de la forme, notamment l'uri appelé lors du submit <form name="editobjet" type="single" target="editeditobjet" title="" default-map-name="formsdata" default-title-style="tableheadtext" default-widgetstyle="tabletext" default-tooltip-style="tabletext"> <field name="actionform"><hidden value="commit$ {actionform}"/></field> <field name="description" title="${uilabelmap. ExempleDescription}"><text/></field> <field name="submitbutton" title="${uilabelbutton}" widgetstyle="smallsubmit" ><submit button-type="button"/></field> </form> bouton de liste des champs soumission de la forme 13/61

4) Le fichier EditObjet.bsh effectue les opérations nécessaires sur les données à afficher, appelant le cas échéant des fonctions java, puis met en relation la forme et les données, ensuite injecte le tout dans le contexte. 5) OFBiz transpose le contenu du contexte avec la structure contenue dans le fichier EditObjet.ftl. Le flux obtenu en sortie est transmis au serveur d'application qui l'envoie à l'utilisateur. Mon intervention sur OFBiz Au début du mois d'avril, M. Heintz travaillait sur la création d'un module de gestion de production. J'ai donc participé à ce développement sur de petites parties afin de découvrir au fur et à mesure le fonctionnement d'ofbiz. Ce travail a consisté à modifier ou créer des écrans utilisateur, comme l'ajout d'un bouton de recherche, la traduction d'une page, etc... Ces petits exercices de découverte du PGI m'ont fait appréhender un bon nombre des technologies mentionnées ci-dessus et m'ont permis de comprendre la philosophie du PGI ainsi que d'entrevoir ses forces et ses faiblesses. 3. Forces et faiblesses du PGI Ses Forces Une des grandes forces du PGI est sa modularité. Chaque requête passe tout d'abord par un contrôleur qui résout la demande suivant les indications d'un fichier xml. Ce procédé rend la gestion des requêtes d'une grande simplicité, tout en permettant une grande amplitude de mouvement pour la résolution d'une requête. L'indépendance entre chaque niveau du PGI implique des configurations plus nombreuses afin d'obtenir une abstraction du fonctionnement entre différents niveaux. L'utilisation de nombreuses interfaces et façades permet aux développeurs de se concentrer uniquement sur le niveau développé. La gestion des accès à la base de données est réalisée par une façade. Cette dernière utilise énormément la mise en cache afin d'optimiser les accès fréquents à une table. La modularité du PGI fait qu'il évolue souvent dans les couches inférieures, en utilisant de nouvelles technologies. Ses Faiblesses 14/61

OFBiz est développé dans un langage de programmation fortement orienté objet qui est : JAVA. Lors de mon apprentissage du PGI, j'ai eu énormément de mal à en comprendre le fonctionnement dû à une utilisation non conforme, par rapport à la philosophie de ce langage. Alors que les couches techniques sont bien développées sur le modèle objet, l'utilisation des tables de la base de données via la façade se fait par interrogation directe. Les entités de la base ne sont pas générées comme un objet. Ceci implique que la programmation des fichiers bsh et java des modules est développée sur un modèle relationnel. On se retrouve à faire un développement en relationnel sur un langage objet. Personnellement, lors de la réalisation de projet durant mon cursus informatique, j'ai beaucoup plus utilisé l'approche objet pour la conception et la programmation que l'approche relationnelle. Cette dernière approche ne me paraît pas adaptée pour des développements de cette importance. Cette non compréhension a impliqué que, lors de mes nombreuses rencontres avec M. Heintz pour l'apprentissage d'ofbiz, nous avions du mal à nous comprendre, puisque lui ne connaissant pas beaucoup la modélisation objet et moi ne comprenant pas l'utilisation d'une approche relationnelle dans un langage objet, nos visions n'étaient pas concordantes. Il nous a fallu un bon mois pour arriver à bien nous comprendre. La modularité du PGI en fait sa force mais aussi sa faiblesse. Pour le développement d'un module, de nombreux fichiers sont à renseigner, et souvent d'informations répétitives. Cette quantité d'informations à renseigner dans les différents fichiers implique un risque de fautes de frappe non négligeable qui conduisent un débuggage souvent long pour des erreurs minimes. Lors de mon intégration au développement du PGI, je me suis retrouvé avec une quantité de technologies et de concepts totalement nouveaux comme les freemarkers ou encore les bsh. Pour les technologies externes au projet OFBiz, la documentation se trouve souvent sur les sites officiels. Lors de technologie propre à OFBiz, une documentation n'est pas toujours présente, surtout dans le cas de technologies récentes ou avancées. Ainsi, on se retrouve souvent à regarder les fichiers sources des développeurs principaux du projet, afin de cerner l'utilisation de certaine API ou autres technologies. Dans certain cas, l'utilisation de technologies développées n'est pas encore faite par ces développeurs. Dans ce dernier cas, la seul solution pour comprendre les fonctionnalités d'une technologie est d'effectuer les testes pas à pas afin d'en analyser les résultats mais ceci est très coûteux en temps. Mon sentiment sur le PGI OFBiz est un PGI possédant un potentiel vraiment important avec une conception technique vraiment poussée. Mais cette capacité est aussi son défaut puisque les développeurs travaillent beaucoup plus sur cette technique au détriment de la partie fonctionnelle du PGI. Le manque de documentation sur les technologies avancées, de même que l'utilisation d'une approche relationnelle et le nombre important de fichiers à renseigner, font que le développement des interfaces utilisateurs n'est pas vraiment d'une grande facilité, ce qui est surprenant au vue des efforts faits pour l'abstraction des niveaux inférieurs du PGI. 15/61

4. La naissance d'un projet : Neogia Les développements à venir sur OFBiz ne concernent que le dernier niveau du PGI : la création de la couche métier. Or, les faiblesses indiquées au chapitre précédent ne nous poussent guère à lancer un développement massif pour combler les manques fonctionnels du PGI. C'est pour ces raisons que début mai commença un nouveau projet nommé Neogia. Que doit apporter Neogia afin de faciliter le développement de la couche métier : une sur-couche objet pour appliquer un développement objet et ignorer la structure de la base de données. remplir automatiquement le plus de fichiers de configuration possibles dont les informations sont répétitives, pour les écrans standard. Un changement de programmation Neogia utilise un projet nommé LutinGenerator, développé par l'entreprise Code Lutin, qui est un «préparateur» à la génération. LutinGenerator fonctionne en deux temps : 1 er temps : LutinGenerator lit des fichiers scripts, typés sur java, et construit une librairie avec les informations contenues dans ces fichiers. 2 ème temps : LutinGenerator lit un diagramme de classe UML et formate le flux récupéré. Ensuite le formatage est appliqué à la librairie qui génère une structure de fichiers sources définie. Quels sont les intérêts de LutinGenerator : La génération se fait à partir d'un diagramme de classe UML, ce qui apporte une conception du logiciel de haut niveau. La génération n'est pas figée à un langage de programmation comme beaucoup de logiciels de création de schéma UML. Les générateurs sont écrits suivant ce que l'on désire générer, avant la première génération du diagramme. Qu'apporte LutinGenerator dans le cas d'ofbiz? La génération de fichier peut vraiment être intéressante dans le cas d'ofbiz puisque le nombre d'informations génériques à renseigner dans les différents fichiers de configuration est assez important. Ceci peut faire gagner un temps énorme en terme de développement. L'utilisation d'un diagramme de classe UML est aussi non négligeable. Actuellement, le développement d'un module (notamment celui de manufacturing) se fait sur la connaissance de l'informaticien fonctionnel, en l'occurrence M. Heintz. Les autres développeurs, en cas d'incertitude dans l'avancement du projet, doivent souvent le déranger pour savoir quelle direction prendre afin de ne pas développer hors du contexte. Je parle notamment pour ma personne puisque ne connaissant pas du tout le monde de l'entreprise de production, l'incertitude était vraiment grande (couplé à une découverte au fur et à mesure d'ofbiz et un développement 16/61

en relationnel : un vrai bonheur). Le manque d'ingénierie logiciel dans un tel développement se fait cruellement ressentir et une conception UML des modules ne peut être qu'un plus pour faciliter et structurer le développement, sans parler des nombreux apports à l'utilisation d'une conception de haut niveau. Ce que remplit Neogia Neogia est une sur-couche d'ofbiz dont le développement s'effectue en parallèle du développement de ce dernier. Il a pour objectif de combler les faiblesses d'ofbiz pour le développement de la couche fonctionnelle du PGI et d'en accélérer son évolution. Neogia est un ensemble de composants complémentaires à la plate-forme d'application d'entreprise OFBiz. Ces composants sont de 3 types: Des composants fonctionnels soient en tant que composant nouveau, soient remplacant un composant OFBiz existant. manufacturing : remplace le composant OFBiz existant, c'est une refactorisation de celui-ci, avec la définition d'un modéle UML propre et une ré-écriture compléte du code. facility : remplace le composant OFBiz existant pour toute la gestion des stocks, il n'inclut pas la gestion des expéditions qui reste réalisée par OFBiz. Il fournit une gestion des inventaires physiques complète. Ce composant est apparu suite à une refactorisation complète du modéle de données réalisé avec UML permettant de gérer les stocks actuels et planifiés. accounting : remplace le sous-composant OFBiz existant, pour la gestion comptable et analytique. La modélisation UML est entièrement nouvelle. La gestion des paiements reste réalisée par OFBiz servicemgnt : nouveau composant permettant de gérer des activités de service ou de projet. Le composant étant nouveau, son modéle UML est également nouveau. Des composants permettant de se connecter aux composants OFBiz existants. Les diagrammes UML reprennent les éléments de OFBiz. common : utilisé pour les liaisons avec les entity enum et status content : utilisé pour unifier certaines règles de développement et pour la gestion des champs en multi-langue. order : utilisé pour accéder aux objets commandes et ligne de commandes party : utilisé pour accéder aux objets acteurs, rôle, acteur-rôle et adresse, et aux objets communications product : utilisé pour accéder à l'objet article et pour la liaison entre OFBiz et le composant facility de Neogia Un composant technique, permettant de générer la majeure partie du code OFBiz à partir des diagrammes de classe UML. Cela permet d'avoir des 17/61

composants développés à partir d'une modélisation objet. La génération permet de généraliser les bonnes pratiques OFBiz et mets à disposition des développeurs les éléments nécessaires au développement objet. Les développements complémentaires sont réalisés dans des sur-charges objets et pas sur les éléments générés garantissant ainsi la possibilité de régénérer certains éléments lors de l'apparition de nouvelle bonne pratique. Une conception de haut niveau L'utilisation de LutinGenerator implique l'utilisation de schéma UML. Chaque module développé dans Neogia est conçu depuis un schéma UML, et, pour être plus précis, d'un diagramme de classe, offrant ainsi une vue globale sur l'interaction entre entités et la direction du développement. Pour pallier à la limitation d'uml dans la description des informations nécessaires à la génération, des balises ont été définies. Une programmation orientée Objet Pour pallier au défaut du développement par approche relationnelle, une surcouche objet est généré par dans Neogia afin que le développement sur la couche fonctionnelle se fasse totalement indépendamment des tables de la base de données. Un gain de temps sur le développement La génération des fichiers remplace les tâches répétitives comme le remplissage des fichiers de configuration nécessaire au bon fonctionnement du module. Ainsi, le temps en développement est optimisé, tout en évitant toute sorte de bug lié à des erreurs de frappes. Une réactivité du développement J'ai déjà indiqué qu'ofbiz était en constante évolution grâce à l'intégration de nouvelles technologies. Bien que souvent ces améliorations ne touchent que rarement la couche fonctionnelle du PGI, dans le cas d'un changement majeur dans cette couche, comme le changement de la gestion des interfaces utilisateurs, il suffira de modifier les générateurs et de relancer la génération des modules pour avoir la nouvelle technologie intégrée. Il restera bien sûr quelques retouches, dans les 20% ou 30% de fichiers non générés mais le gain de temps pour intégrer une nouvelle technologie est vraiment important. Au final Le développement via Neogia des modules fonctionnels d'ofbiz permet : une conception de haut niveau de chaque module. une génération de 70% à 80% des fichiers sources nécessaires au fonctionnement du module. une écriture des fichiers sources propre, structurée et directement en 18/61

relation avec la conception. une sur-couche objet pour faciliter le reste du développement. 5. Fonctionnement de Neogia L'arborescence de fichier Neogia possède une arborescence de fichiers totalement séparée de celle d'ofbiz: neogia +- components +- module1 +- module2 +-dist +-target +-src +-build.xml +-project.xml +-project.properties `- maven.xml +- doc +- generators +-src +-target +- neogiaproject.xml +- project.xml +- project.properties `- maven.xml +- neogiaproject.xml +- project.xml +- neogiaofbiz.patch 19/61

+- maven.xml `- build.xml Explication de l'arborescence de Neogia Neogia : répertoire racine du projet components : ce répertoire contient tous les modules en développement qui seront intégrés à OFBiz module dist : ce répertoire contient le module développé de Neogia qui est opérationnel dans OFBiz (fichiers générés + développements spécifiques) src : ce répertoire contient le diagramme UML décrivant le module ainsi que quelques informations non générables comme des labels pour l'internationalisation du module target : ce répertoire contient les fichiers générés à partir du diagramme UML, une fois la génération finie. project.xml et project.properties : ce sont deux fichiers de configuration utilisés par LutinGenerator pour la génération maven.xml : fichier de configuration pour le lancement de la génération via maven build.xml : fichier d'instruction pour ant afin de déplacer les fichiers voulus dans l'arborescence d'ofbiz, utilisé seulement par les développeurs du module generators src : répertoire contenant les sources des générateurs target : répertoire contenant les générateurs compilés neogiaproject.xml, project.xml et project.properties : ce sont trois fichiers de configuration utilisés par LutinGenerator pour préparer les générateurs maven.xml : fichier de configuration utilisé par maven pour compiler les générateurs build.xml : ce fichier d'instruction ant déplace le contenu des répertoires components/*/dist vers l'arborescence OFBiz pour intégrer les modules Neogia dans le PGI. neogiaofbiz.patch : patch à appliquer à la racine d'ofbiz pour préparer le PGI à l'intégration des modules développés via Neogia project.xml et project.properties : ce sont deux fichiers de configuration utilisés par LutinGenerator pour la description du projet maven.xml : fichier de configuration pour la configuration du projet via maven. 20/61

Les dépendances du projet Neogia ne peut fonctionner sans deux logiciels primordiaux : un éditeur UML enregistrant au format xmi (format standard pour l'uml) le constructeur maven (disponible à l'adresse http://maven.apache.org ) L'éditeur de diagramme UML utilisé est Poséidon de la société gentleware. Ce n'est pas un logiciel libre, mais la version commerciale du logiciel libre ArgoUML. Une version communautaire existe. Maven est un automate de tâche système. En plus de ces deux logiciels, on utilise le constructeur ant, qui est une version portable des Makefiles et basé sur java. Comment fonctionne la génération La génération d'un module suit plusieurs étapes : création du diagramme UML création des générateurs compilation via maven des générateurs génération via maven des fichiers sources du module La génération, aussi pratique soit-elle, ne suffit pas à créer un module fonctionnel. Il reste le développement spécifique à réaliser. 6. Création du module de comptabilité La réalisation du module de comptabilité a commencé au début du mois de juillet. Sa réalisation est une exception dans l'utilisation des générateurs puisque la comptabilité possède des écrans utilisateurs très spécifiques qui sont difficilement réalisables par génération. La difficulté de ce module est d'effectuer un développement en utilisant le plus possible les fichiers générés afin de profiter d'un maximum d'indépendance du développement vis à vis de la génération. 21/61

Diagramme UML La première étape dans la création du module est la création du diagramme UML. Cette tâche m'a été confiée afin de mettre à profit mes acquis sur la conception logiciel. Bien que possédant les bases nécessaires, la création de tels schémas n'est pas chose aisé et le nombre de modifications apportés au premier schéma est quelque peu conséquent. L'évolution du schéma s'est faites par retour successif de la part de mon maître de stage sur les manques fonctionnels afin d'obtenir une solution intéressante à envoyer en production. 22/61

Diagramme de classe : CharOfAccount 23/61

Diagramme de classe : AccountingTransaction Première génération 24/61

Une fois les diagrammes créés, on passe dans le répertoire des générateurs et on y exécute la commande maven. Cette opération va résoudre les librairies dont le projet dépend, puis lancer la compilation des fichiers sources des générateurs. Une fois la compilation terminée, on obtient un fichier jar qui va nous servir pour la génération des fichiers du module. Une fois la compilation réussie, on revient dans le répertoire du module, puis on relance la commande maven. Cette fois, l'exécution lit le fichier UML puis lance la génération des fichiers. Une fois l'exécution de cette dernière finie, on obtient une première liste de fichiers pour le module. Les fichiers générés ne sont pas tous utilisables. Il y a, en gros, trois types de fichier : les fichiers utilisables directement après la génération : tous les fichiers ftl, de form, bsh, sources, de description des entités. les fichiers à valider soi même : les fichiers de définition de page et les fichiers sources contenant des objets hérités les fichiers qui nécessitent un transfert du contenu manuellement : service.xml et controller.xml Afin de distinguer les fichiers générés des fichiers développés, dans chaque répertoire du module pouvant avoir ces deux types de fichiers se trouvent deux répertoires : "developed" et "generated" qui servent à organiser le développement. Création de l'arborescence du module La première tâche, une fois les fichiers générés, consiste à savoir de quels fichiers on a besoin. On transfère tous ces fichiers du répertoire de génération au répertoire dist du module. Il faut que l'arborescence contenue dans le répertoire dist, fonctionne afin de pouvoir être intégrée par les autres contributeurs du projet Neogia. Une fois l'arborescence faite, vient le développement spécifique. Comment cela se traduit il? Développement du module Avant de se lancer dans le développement spécifique du module, il nous faut 25/61

définir les besoins fonctionnels de ce dernier. Ceci nous permet de savoir quels écrans utilisateurs sont nécessaires. Renseigner le model UML Une fois que nous avons défini les besoins de l'interface, le projet Neogia définit des étiquettes à mettre sur les éléments du diagramme de classe. Cette étiquetage de valeur va renseigner les générateurs sur nos besoins et générer la plupart des interfaces. La liste des étiquettes et des valeurs à renseigner est présente dans la documentation des développeurs du projet Neogia Effectuer le développement spécifique Une fois que les fichiers générés voulus sont présents dans le répertoire dist, on les transmet au répertoire du module dans OFBiz. De là,on commence à effectuer les développements spécifiques. Configurer les écrans Les premiers développements interviennent sur les fichiers de description des écrans (fichiers contenus dans le répertoire webapp/module/web-inf/pagedefs du module). Il faut renseigner diverses informations nécessaires à la navigation, puis créer les fichiers ftl de menu et sous-menu. Les fichiers de sous-menu sont au format ftl et sont placés dans le répertoire webapp/module/sous-module/"developed" du module (sous-module dépend de quel sous-module dépend la page). Le fichier de menu est par défaut le fichier webapp/module/include/header.ftl Modifier les codes sources Le code java généré par Neogia possède une structure bien précise pour chaque entité : EntiteBase.java : cette objet contient les accesseurs aux attributs de l'objet qui sont établi suivant le diagramme de classe. Il contient aussi des fonctions de base relatives à OFBiz comme la recherche des entités dans la base de données, ou encore un constructeur à partir d'une clé primaire. EntiteServices.java : cet objet contient les fonctions appelés pour la modification de l'entité dans la base de données comme l'édition ou la suppression de l'entité. Ces deux fichiers sont contenus dans un répertoire "generated", et ne sont pas utilisables directement pour le développement. Afin de permettre leur utilisation, une autre classe est créée, dans notre cas : Entite.java : cette classe hérite de EntiteBase.java. C'est elle qui est utilisée lors de développement spécifique. Ce fichier est contenu dans un répertoire "developed", il doit donc être intégré 26/61

par le développeur suivant ses besoins. Cette architecture nous donne la sur-couche objet énoncée dans les chapitres précédents. Lors de notre développement sur les sources, seule cette classe est modifiée, on peut y ajouter des fonctions ou redéfinir les fonctions de la classe mère suivant nos besoins. Ainsi, si la gestion de l'objet change, pour x raisons, cela n'implique pas le code développé, ou que légèrement. Il est important durant le développement des fichiers sources de s'assurer que les fichiers compilent bien. Si ce n'est pas le cas, les autres contributeurs seront bloqués puisqu'ofbiz ne pourra plus compiler sans erreur, provoquant une perturbation dans les développements globaux. Gestion des informations à afficher Le développement des fichiers sources ne nous permet pas de gérer les données à envoyer dans le contexte (en pratique, oui mais ce n'est pas dans la philosophie d'ofbiz). Pour cela, on utilise les fichiers bsh. Afin de ne pas toucher aux fichiers générés, il nous faut écrire de nouveaux fichiers qu'on positionnera dans le répertoire "developed" correspondant. Cela ne suffit pas pour pourvoir les utiliser, il faut renseigner leur utilisation dans les fichiers de description des pages concernées. Cette méthode, bien que rajoutant des opérations au PGI, puisqu'il peut avoir à effectuer deux ou trois fois les mêmes opérations de lecture du contexte, permet de garder, encore une fois, les bénéfices offerts par la génération. Toucher directement les fichiers générés induit de ne plus bénéficier d'une nouvelle génération, ou alors abandonner les modifications faites. La gestion des informations peut être diverse dans ces fichiers : appeler un service, vérifier les données et changer l'affichage en conséquence, etc... Changement de la structure de la page Les fichiers bsh ne servent qu'à gérer les informations contenues dans le contexte. Si le besoin est de modifier la structure d'une forme, cela doit se faire via les fichiers de forme correspondants. Un fichier de forme contient une liste de forme, il ne sert à rien de passer toutes les formes générées de "generated" à "developed". Il est juste nécessaire de déplacer les formes voulues et ne pas oublier de renseigner ce changement dans les fichiers de description des pages concernées. 27/61

Retoucher un fichier de structure ftl généré doit se faire vraiment en dernier recours, en effet ces fichiers sont associés à un fichier de description de page. En cas de changement du fichier de structure, le passage du répertoire "generated" à "developed" implique : d'éditer le contenu du fichier contrôller.xml pour la vue concernée. Changer de répertoire le fichier de description de page associé Ces changements commencent à rendre lourd la gestion des "developed" et "generated". C'est pour cela qu'il est conseillé d'utiliser la modification des fichiers ftl générés qu'en dernier recours. Dans le cas de la comptabilité La création du module n'a pas été une chose simple puisse que la découverte du projet Neogia (du moins le fonctionnement) se faisait en avec. Le premier objectif de la comptabilité est de pouvoir saisir des écritures, donc il nous fallait développer afin qu'il permette : la recherche et l'édition des comptes comptables la recherche et l'édition des périodes comptables la recherche et l'édition des transactions l'édition des écritures à partir d'une transaction l'édition des lignes à partir d'une écriture Les comptes comptables (NGlAccount) La création de ces écrans ne nous a pas posé de problème puisque ce sont des écran générés non retouchés Les périodes comptables (GlPeriod) Ces écrans ont été retouchés afin de pouvoir gérer la hiérarchie de périodes. Ce sont essentiellement des retouches au niveau des bsh afin de pouvoir afficher les périodes parents disponibles lors de l'édition. Les transactions (AcctgTransaction) Pas de retouche sur ces écrans. La difficulté à cet endroit est l'utilisation d'écrans d'association plus complexe que des écrans de saisie. Cet écran permet de saisir les écritures appartenant à la transaction éditée. La génération remplie vraiment bien son rôle puisque la réalisation d'écrans de ce type est assez complexe. Bien que les écrans n'aient pas été retouchés, il a fallu intégrer la gestion du 28/61

brouillard et du statut des transactions. La solution prise a été le développement de fonctions dans la classe AcctgTransaction et la création du fichier contrôller.xml afin de sélectionner l'écran à retourner suivant l'état de la transaction. Les écritures (AcctgTransactionItem) Les écritures sont saisies depuis l'écran d'édition d'association des transactions. Cet écran affiche la liste des écritures appartenant à une transaction. Le problème dans l'affichage de cette liste était l'impossibilité de modifier les lignes d'écriture associées à l'écriture. Il a donc fallu modifier la forme en ajoutant le lien vers l'écran d'association. Les lignes d'écritures (GlEntry) Le plus gros du travail a été effectué sur cet écran d'association. Le problème des lignes d'écriture se pose sur la gestion des comptes comptables associés et dans l'affichage de la ligne. Cette écran a demandé une grande refonte de la génération de l'affichage, nous obligeant à sortir de la génération. C'est une exception qui confirme notre règle : modifier au minimum les fichiers générés. Les problèmes d'intégration dans OFBiz Lors de l'intégration du module de comptabilité dans OFBiz, des conflits de nom entre entités, au niveau de la base de données, sont apparus. La solution prise a été de renommer les entités venant de Neogia. Ainsi GlAccount est devenu NGlAccount, Period est devenu GlPeriod, ect... Il est préférable de changer les noms des entités de Neogia que de supprimer les doublons, car dans ce dernier cas Neogia modifie le fonctionnement d'ofbiz et n'est plus une sur-couche évoluant parallèlement au PGI. Un projet en pleine croissance Neogia est un projet jeune, moins de 6 mois, qui prend forme peu à peu. Quelques temps ont été nécessaire afin de bien cerner le fonctionnement du projet. Durant ce temps, lors d'erreur de génération ou de compilation, je ne savais pas trop si l'erreur venait d'une erreur du diagramme de classe, d'une faute dans les compilateurs, ou d'une erreur de développement. Les premiers modules développés dans Neogia ont permis de découvrir les buggues de jeunesse et autres problèmes de conception. Lors du passage à la version 1.0 de Neogia, les problèmes de jeunesse devraient être fortement diminués. 29/61

Au niveau de la licence OFBiz est développé sur une licence MIT. Cette licence ne convenait pas à la société Néréide puisqu'elle permet à une société de récupérer le travail effectué et d'en continuer le développement sous une licence propriétaire, à l'instar de Poseidon reprise du logiciel ArgoUML. C'est pour cette principale raison, que la licence GPL couvre le projet. Neogia étant une sur-couche du PGI, la différence de licence ne dérange aucunement l'évolution des deux projets. Cette licence permet de garder libre le travail effectué et d'en assurer l'évolution. Le domaine des PGI étant assez technique, le retour sur l'investissement effectué par la société Néréide, vient de la demande de services sur la mise en place ou le développement spécifique autour du PGI. 7.Conclusion OFBiz est un PGI vraiment prometteur dont le principal inconvénient et la difficulté à développer les modules fonctionnels. Le projet Neogia a pour but de combler ce défaut en offrant un outil de développement pour les couches fonctionnels le plus performant possible. L'utilisation d'une conception de haut niveau, couplé à une génération font du couple OFBiz-Neogia une réussite, avec un projet spécialisé dans la couche technique et un projet spécialisé dans la couche fonctionnelle. Le projet Neogia est, de mon point de vue, une réussite dont le mérite revient principalement à M. Heintz, pour tous le travail accomplie autant sur les générateurs que sur la conception des diagrammes UML. Personnellement, j'ose espérer que les facultés, notamment celle d'orléans, se penche sur ce projet afin d'apporter une vision pratique aux étudiants sur la génération de programme à partir de diagramme UML, couplé à l'utilisation d'un PGI. Le tout étant sous licence libre et disponible gratuitement, je pense sincèrement que c'est un environnement de travail vraiment intéressant pour appréhender bon nombre de technologies, sans que la faculté fasse le travail des commerciaux des éditeurs de logiciel propriétaire. 30/61

DEUXIEME PARTIE : REORGANISATION DE L'INFRASTRUCTURE DE NEREIDE 31/61

Avant mon arrivée, Néréide fonctionnait sur une architecture mise en place par M. Heintz, qui ne répondait pas pleinement à ses attentes et aux besoins de l'entreprise. Du fait de ma petite expérience et de mes ambitions en la matière, il m'a donné la lourde tâche de réorganiser le réseau de l'entreprise suivant des attentes bien précises qui seront détaillées un peu plus loin. 1. Description de l'existant et des besoins Avant d'entamer la migration d'un système d'information, il est important de prendre en compte l'existant. L'entreprise, bien que jeune, possède un historique qu'il faut respecter et intégrer tout au long des étapes de la migration. Structure du réseau existant Le parc informatique de Néréide était composé de : 2 serveurs faisant office aussi de machine de développement, tournant sur une distribution mandrake linux 9.1 2 ordinateurs portables tournant sous une distribution linux knoppix 3.3 Chaque machine du réseau était totalement indépendante dans la gestion des utilisateurs et des fichiers de ces derniers. Le serveur principal couvrait les services NFS et CUPS. Les fichiers disponibles via NFS étaient à disposition de tous les utilisateurs du réseau. Voici le schéma de l'ancienne architecture: 32/61

x.x.2.1 serveur principal x.x.2.2 serveur secondaire x.x.2.3 Poste 1 x.x.1.1 Poste 2 x.x.1.1 La nouvelle architecture ne doit pas changer les serveurs physiques. Le serveur principal existant sera le serveur principal de la nouvelle architecture et il en sera de même concernant le serveur secondaire. Quels besoins doit couvrir la nouvelle architecture? Harmonisation des systèmes d'exploitation Authentification centralisée des utilisateurs Centralisation des données utilisateurs Sécurisation du réseau et disponibilité des services réseaux 2. Analyse des choix pour une nouvelle architecture Une fois les besoins définis, il nous faut pouvoir choisir la nouvelle architecture de façon à ce que chaque besoin trouve sa solution. Harmonisation des systèmes d'exploitation 33/61

Pour une plus grande flexibilité d'administration et d'utilisation par les utilisateurs, les systèmes d'exploitation de Néréide doivent être le plus uniforme possible. Néréide impose l'utilisation de systèmes libres mais n'a pas de distribution sélectionnée. L'harmonisation des systèmes passe par une sélection de la distribution à utilisée officiellement au sein du système d'information de la société. Trois distributions ont été pré-sélectionnées pour les machines de Néréide : Mandrake Linux 10.0, FedoraCore 2 et Debian Sarge. Les critères de choix : Stabilité Administrabilité Adaptabilité Ergonomie Pour le choix de la distribution, il est important de savoir qu'il ne doit pas y avoir trois distributions distinctes : une pour les machines bureautiques, une pour les développements et une pour les serveurs en production. Le choix doit être fait de sorte que les caractéristiques de la distribution couvrent correctement ces trois types de mise en application. Tableau de comparaison des distributions Distribution Mandrake 10 FedoraCore 2 Debian Sarge Installation 4 4 3 Connaissances requises 4 4 3 Stabilité 3 4 5 Administrabilité 3 3 4 Evolutivité 2 2 5 Maintenabilité 3 3 5 Total 19 / 30 20 / 30 25 / 30 Mandrake Linux possède une facilité d'installation vraiment intéressante et l'administration de la machine est grandement facilitée via l'utilisation du logiciel drakconf. Par contre, la distribution souffre toujours de quelques bugs qui rendent l'ensemble d'une stabilité relative. De plus, cette distribution utilise un système de paquet rpm ne permettant pas une gestion simple de l'évolution de la distribution. FedoraCore2 est équivalente en de nombreux points avec Mandrake Linux à l'exception d'une stabilité accrue mais possède un manque de logiciels empaquetés par rapport à sa consoeur. De plus, sa conception en fait une distribution plus adaptée aux machines bureautiques qu'à des serveurs. La Debian Sarge est une distribution dont l'installation et l'administration demandent plus de connaissances et de compétences que les deux précédentes. Par contre, la gestion des logiciels par les paquets.deb en fait une distribution évolutive et structurée. Le choix des logiciels empaquetés est largement supérieur aux deux 34/61

autres. De plus, cette distribution possède une grande stabilité d'ensemble. Le système d'exploitation installé sur les serveurs et les machines d'utilisateurs sera donc la distribution GNU/Linux Debian Sarge, et ceci au vu des avantages que cette distribution possède par rapport à ses consoeurs : qualité et stabilité de la distribution exemplaires facilité de maintenance et d'évolution respect total de la philosophie des logiciels libres (c'est la distribution officielle de la FSF ) grande facilité de configuration mais nécessite quelques connaissances. Bien que demandant un effort supplémentaire dans la configuration de la distribution, l'environnement dans lequel est déployé cette distribution fait que ce petit effort est largement à la portée des techniciens de Néréide. Authentification centralisée des utilisateurs Néréide a besoin de centraliser l'authentification des utilisateurs afin de pouvoir faire abstraction des machines physiques sur lesquelles il se connectent ainsi que pour faciliter l'administration des comptes utilisateurs. Le choix du type de serveur d'authentification doit prendre en compte l'architecture de type Unix et l'évolution du gestionnaire d'authentification. Actuellement, pour centraliser l'authentification des utilisateurs sur un système GNU/Linux, il existe deux solutions : NIS de Sun Microsystem Les Annuaires LDAP Tableau de comparaison des deux serveurs d'authentification Serveur d'auth. NIS+ LDAP Intégration Unix 5 4 Sécurité 4 5 Evolutivité 2 5 Administrabilité 4 3 Total 15 / 20 17 / 20 La première solution, NIS, permet de centraliser l'authentification des utilisateurs et de gérer les groupes, netgroupes et ressources partagées nativement sous les systèmes Unix. Par contre, il n'est pas très évolutif des futures contraintes d'architectures et ne se plie pas facilement à l'intégration de système d'exploitation autre que de type Unix. NIS est un protocole vieillissant, bien qu'une nouvelle version soit présente : NIS+, elle ne comble pas tous les manques de NIS. LDAP n'est pas un serveur d'authentification spécialisé comme l'est NIS, c'est un annuaire, ce qui rend son utilisation beaucoup plus généralisée. Toute application basée sur des entités telles que des utilisateurs, des groupes ou 35/61

des netgroupes peuvent coopérer avec un serveur LDAP qui se montre bien plus sécurisé et extensible que le serveur NIS. Les choix techniques de Néréide n'étant pas figés, il va de soi que la mise en place d'un système d'authentification normalisé est largement plus intéressant sur le long terme. La solution LDAP est donc retenue, vu ses principaux avantages : LDAP est un protocole normalisé Bonne intégration de l'annuaire LDAP dans les modules d'authentification PAM Possibilité d'authentifier d'autres systèmes d'exploitations et applications. Possibilité d'utiliser l'annuaire pour d'autres services en plus de l'authentification, ce qui offre une évolution de l'existant Il existe un serveur LDAP libre : OpenLDAP ( bien qu'il existe également une version libre de NIS ) Centralisation des données utilisateurs Afin de permettre à un utilisateur de retrouver son environnement de travail quelle que soit la machine utilisée, la mise en place des répertoires personnels des utilisateurs sur un serveur de fichier est tout simplement obligatoire. Il existe deux principaux serveurs de fichier sous les systèmes GNU/Linux : Samba et NFS. Ces deux services sont totalement transparents aux utilisateurs puisque c'est le noyau du système GNU/Linux qui va se charger de la gestion de l'emplacement réseau des fichiers. Comparaison entre les deux serveurs de fichiers Serveur de fichiers Samba NFS Sécurité 5 2 Administrabilité 3 5 Rapidité 3 5 Intération Unix 4 5 Total 15 / 20 17/20 Samba est basé sur le protocole SMB, protocole utilisé par les systèmes d'exploitations de Micro$oft. Il permet un contrôle avancé sur les partages des ressources, ce qui peut être important dans un environnement demandant des restrictions particulières. L'accès à un répertoire ou un fichier doit être explicitement indiqué avec la possibilité d'indiquer de nombreux paramètres d'accès via des ACL (utilisateurs, machine, groupe de machines, heures d'accès... ). Ceci rend la configuration assez lourde si l'on a décidé de mettre en place de telles restrictions. NFS est beaucoup moins poussé dans la gestion des contrôles d'accès. Celle-ci se 36/61

fait essentiellement par déclaration d'un répertoire associé à une liste de machine et/ou groupe de machine ayant l'autorisation d'utiliser le partage réseau. Une fois la ressource montée, la gestion d'accès aux fichiers se fait par correspondance entre uid/guid et droits Unix entre les machines. Ceci pose un petit (en fait, un énorme) problème de sécurité puisque NFS est très sensible à l'usurpation d'identité. Bien qu'il possède des trous de sécurité non négligeables, NFS a l'avantage d'être plus rapide que son confrère puisqu'il fonctionne sur le protocole réseau UDP. Il est aussi beaucoup plus facile à administrer. N'utilisant que le serveur de fichiers pour un intranet de faible envergure, NFS convient amplement. En ce qui concerne les soucis de sécurité, ce sera au contrôleur de sécurité de faire le travail. C'est au firewall et au serveur ssh d'assurer la sécurité puisqu'ils sont les seuls visibles depuis l'extérieur. Bien qu'une solution Samba soit plus sécurisée, sa mise en place aurait demandé beaucoup plus de temps, tant en termes d'architecture que de mise en oeuvre. Les données utilisateurs (donc les home des utilisateurs) seront donc centralisées sur le serveur principal et disponibles depuis les machines clients via le protocole NFS. Ceci permet, couplé à l'annuaire LDAP, de faire abstraction des machines physiques pour les utilisateurs. Sécurisation du réseau Pour des raisons évidentes d'intégrité des informations contenues sur le serveur, le réseau de Néréide doit être sécurisé et donc séparé du reste du réseau déjà en place. Mais la sécurité n'est pas seulement restreinte à l'intégrité et la sûreté des informations mais s'applique surtout à leur disponibilité. Protection du réseau des attaques extérieures Le premier rempart à mettre en place pour protéger le réseau, est un firewall dédié au filtrage des paquets entrant et sortant du réseau de Néréide. C'est lui qui va dans un premier temps assurer la première protection, notamment pour le serveur NFS. Le firewall mis en place sera software, pour des raisons économiques et administratives. Il est plus simple pour les techniciens de Néréide de modifier les règles d'un firewall comme iptables ou ipfilter bien connus que d'un firewall matériel dont l'administration diverge d'un constructeur à un autre. Le firewall peut être déployé sur un boîtier avec une micro carte faisant tourner un système openbsd ou GNU/linux. Ce procédé coûte beaucoup moins cher qu'un firewall matériel. Sécurisation des informations La mise en sûreté des informations passe par des sauvegardes des données pour pallier à des défaillances matérielles ou humaines, ou encore des catastrophes naturelles (ou surnaturelles!). Dans le cadre de réseau Néréide, la première priorité est d'assurer la sûreté des données contre les défaillances humaines et 37/61

matérielles. Quelles sont les données à mettre en sûreté : toutes les données utilisateurs toutes les sources des programmes en développement les fichiers de configuration des serveurs Toutes ces informations se trouvent sur le serveur principal. Si ce dernier subit une défaillance quelconque, la société court le risque d'une importante perte d'informations et de temps. Technologies disponibles : Le serveur principal est équipé d'une carte RAID 0,1 et de deux disques durs identiques d'une capacité de 60 Go chacun. Il est équipé d'un graveur de CD-R et CD-RW Le serveur secondaire possède un deuxième disque dur d'une capacité de 80 Go Solutions possibles : Le serveur principal possédant une carte RAID 0/1, il serait logique de vouloir l'activer. Ceci nous protège contre les défaillances matérielles des disques durs. Pourtant, après réflexion, la carte ne sera pas activée car elle ne répond pas à nos besoins. En effet, si un utilisateur détruit un de ses fichiers accidentellement, l'erreur sera automatiquement reproduite sur les deux disques, donc la défaillance humaine n'est pas gérée par ce système. Une solution pourrait mettre en place le RAID plus une sauvegarde automatique sur des CD-RW. L'inconvénient est le volume des données à sauvegarder, s'il y a 8 Go, il va falloir qu'une personne passe un à un les CD-RW dans le graveur. Soit 11 CD-RW à une vitesse de gravure de 10x, donc environ 120 minutes de sauvegarde. Si la sauvegarde est effectuée une fois par semaine, cela peut encore être envisageable mais si elle doit être effectuée tous les jours travaillés ou tous les deux jours, ce n'est pas possible. De plus, la restauration des données, en cas d'incident, risque de ne pas être d'une grande simplicité Une autre solution est de coupler le RAID avec une sauvegarde réseau sur le serveur secondaire. Là s'impose un problème physique, la fluctuation de gros volumes de données sature le réseau jusqu'à le rendre presque inutilisable. Donc, on ne peut pas envisager de le faire souvent sans risquer de perturber l'environnement de travail. La solution choisie : La solution retenue est de désactiver le RAID et d'utiliser les disques indépendamment. Ainsi, on peut utiliser le premier disque pour le fonctionnement normal du serveur, et se servir du deuxième disque pour cloner les données du premier. 38/61

Qu'est ce que cela nous apporte : faible dérangement pour les utilisateurs durant la synchronisation des disques. protection contre les pannes matériels d'un des disques. protection contre les défaillances humaines. le re-lancement du serveur sur le second disque en cas de panne du premier. Ce système nous protège des défaillances humaines du simple fait que la synchronisation entre les disques doit se faire manuellement (ou via un script). Donc suivant les intervalles entre deux synchronisations, on a toujours possibilité de récupérer un fichier endommagé sur le disque de sauvegarde puisque ce dernier possède la vue du premier disque à la dernière synchronisation. En cas de chute d'un des disques, on bascule le fonctionnement du serveur sur le disque valide. Une fois le disque endommagé remplacé, il ne reste qu'à resynchroniser les disques afin de remettre en place notre système de sauvegarde. Néanmoins, il reste un point à résoudre. Si le serveur subit une altération importante qui viendrait à le mettre en péril, les données ne sont plus en sécurité. Il nous faut donc effectuer une sauvegarde sur un support hors du serveur. Vu la configuration du réseau, c'est le serveur secondaire qui récupérera de temps en temps une sauvegarde du serveur principal. Ce système de sauvegarde couvre les risques les plus courants que pourrait subir la société Néréide. Il reste encore un point à couvrir, la protection contre les catastrophes de zone. Pour l'instant, le système est protégé contre les inondations puisque le serveur secondaire est géographiquement à une altitude plus élevée que le serveur principal ;). Une protection de zone ne sera faisable que si Néréide possède une ligne dsl ou similaire afin de pouvoir synchroniser sur des serveurs distants. Continuité des services du réseau de Néréide La continuité de service du serveur signifie une non-interruption des services offerts se serveur. Or, si ce dernier doit subir un arrêt, le réseau n'est plus en état de fonctionner puisqu'il est la clé de voûte du réseau de Néréide. Il nous faut donc un moyen de changer de clé de voûte en cas de chute de la première et ce, sans que les utilisateurs du réseau en subissent les conséquences. La solution est de dupliquer les services fournis par le serveur principal sur le serveur secondaire. Si le serveur principal tombe, les machines clientes doivent alors passer sur le serveur secondaire. Le seul problème est la nécessité d'une intervention humaine pour réaliser ce changement. Idéalement, il faudrait que le serveur secondaire prenne la place du serveur principal. Ceci n'est pas vraiment faisable sans mettre en place un service de hautedisponibilité. Mais par contre, on a la possibilité de détourner une fonctionnalité de la résolution DNS. Si le serveur principal tombe, les requêtes DNS seront faites sur le serveur secondaire. Il suffit dès lors d'associer le nom du serveur principal à l'adresse IP du serveur secondaire dans le serveur DNS secondaire. Ainsi, si le serveur principal tombe, les requêtes sont réorientées vers le DNS secondaire qui indiquera les 39/61

services du serveur secondaire. D'où une perte minime de disponibilité pour les services du réseau (en théorie). Reste que la vue du système de fichier se trouvant sur le serveur secondaire sera au pire d'une semaine. 3. Nouvelle architecture du réseau de Néréide Après les choix expliqués au chapitre précédent, voici ce à quoi devra correspondre le réseau de Néréide : Le réseau Néréide est séparé en deux sous-réseaux : x.x.0.0 / 24 ce sous-réseau est réservé pour les serveurs et les éléments d'infrastructure x.x.1.0 / 24 ce sous-réseau est réservé aux stations de travail x.x.x.1 firewall dmz.nereide.o rg x.x.0. serveur secondaire x.x.0.3 x.x.0.1 x.x.0.4 bridge x.x.1.1 serveur principal x.x.0.2 Poste 1 x.x.1.1 Poste 2 x.x.1.1 Autre allocation par dhcp 40/61

Services réseau offerts Serveur principal du réseau Néréide, il offre les services suivants : sshd dns via maradns nfs openldap : authentification des utilisateurs OFBiz : développement cups samba (pour des portables potentiels sous windows) Sauvegarde : assure la synchronisation entre les deux disques Serveur secondaire. Assure la prise en charge des services du serveur principal en cas de chute de ce dernier. sshd dns via maradns (actif secondaire) nfs (inactif) openldap (actif secondaire) OFBiz : développement (inactif) cups samba (inactif) apache2 (configuration du serveur LDAP) Sauvegarde : assure la sauvegarde des disques du serveur principal par l'exécution de scripts Firewall : Assure une première sécurisation du réseau de Néréide. Sshd Bridge : Assure le rôle de passerelle entre le réseau des Isles et Néréide sshd dhcp sur le réseau x.x.1.0 4. Mise en place de la nouvelle architecture Le passage de l'ancienne architecture à la nouvelle se passe en plusieurs étapes. Je ne vais pas re-décrire toutes les opérations qui sont déjà présentes dans le 41/61

document de migration disponible dans les annexes 1 et 2, mais juste reprendre les plus importantes. Première étape : passage sur un serveur auxiliaire Pour ne pas perturber le fonctionnement de l'entreprise, il a été choisi de sortir le serveur secondaire du réseau, le temps de le préparer pour faire office de serveur principal. Le serveur secondaire est donc la première machine à subir la migration. Tous les services nécessaires sont installés puis testés avant de passer le serveur secondaire en serveur principal temporaire de la nouvelle architecture Deuxième étape : une migration progressive Une fois le serveur validé, nous passons à la deuxième étape qui est le basculement du réseau de Néréide sur la nouvelle architecture. (cf document en annexes 1 et 2). Durant cette étape, on transfère les données et les utilisateurs de l'ancienne architecture sur la nouvelle, puis on s'occupe de basculer une à une les machines clientes sous la nouvelle architecture. Une fois que toutes les machines clientes fonctionnent sur la nouvelle architecture, on migre le serveur principal afin qu'il reprenne sa fonction sur la nouvelle architecture. Le serveur secondaire reprend lui aussi sa position. Il ne reste plus qu'à mettre en place les procédures de sauvegarde. Dernière étape : le basculement final Lorsque toutes les machines fonctionnent sur la nouvelle architecture, la dernière étape consiste à séparer les réseaux pour obtenir l'architecture finale voulue. C'est dans cette dernière étape qu'il faut modifier les bases DNS et les modules d'authentification des machines clientes qui ne fonctionnent pas avec la résolution DNS. 5. Les sauvegardes Pour effectuer les sauvegardes des données utilisateurs et des fichiers du système se trouvant sur le serveur principal, nous avons utilisé le langage de script shell combiné au gestionnaire de tâche cron afin d'automatiser leur lancement. Il y a deux scripts : vue_journaliere.sh : qui synchronise les deux disques du serveur principal. balance_puh.sh : qui sauvegarde les données utilisateurs à arborescence identique sur le serveur secondaire et les fichiers systèmes du serveur principal dans un répertoire sauvegarde du serveur secondaire. Les scripts ont été tirés, puis adaptés du livre : Administration Linux à 200% de 42/61

Rob Flickenger au édition O'REILLY Le script de synchronisation des disques: vue_journaliere.sh Ce script appelle le logiciel rsync pour qu'il duplique à l'identique tous les répertoires nécessaires au bon fonctionnement du système (les répertoires /proc et /dev ne sont pas pris en compte). Le script est appelé à 12h et 18h, afin de sauvegarder le système après une demi-journée de travail. La synchronisation n'entraîne quasiment pas de ralentissement sur le système global une fois la première synchronisation faite. Ensuite rsync ne fait qu'appliquer les changements du système de fichier depuis la dernière synchronisation. Cependant, il se pose un problème dans la synchronisation totale du système. En effet si le premier disque dur vient à tomber, on bascule alors le système sur le second. Mais comme le second possède les mêmes fichiers que le premier disque, la table des systèmes de fichiers se retrouve faussée (le fichier /etc/fstab) puisque les disques n'ont pas les mêmes emplacements physiques. Pour pallier ce petit défaut, le fichier /etc/fstab n'est pas synchronisé mais retouché en fonction du disque. Pour s'assurer que le système ne modifie pas ce fichier, le drapeau immuable a été mis à 1 sur les deux fichiers. Ce drapeau interdit la modification du fichier même par l'utilisateur root. Le script de sauvegarde sur le serveur secondaire : balance_push.sh Ce script appelle lui aussi le logiciel rsync, mais à travers ssh afin d'effectuer une sauvegarde distante. Cette sauvegarde se passe en deux temps. Dans le premier temps, les répertoires systèmes du serveur principal sont sauvegardés dans un répertoire sur le serveur secondaire. Dans le deuxième temps, les répertoires de données utilisateurs sont eux aussi sauvegardés sur le serveur secondaire, mais à arborescence identique. Pourquoi? Si le serveur principal vient à tomber, alors les services réseaux passent sur le serveur secondaire. Les utilisateurs retrouvent leurs données datant de la dernière sauvegarde et ce, sans intervention humaine. Le script s'exécute tous les samedis, afin de ne pas gêner les utilisateurs. Ceci fait que le serveur principal a toujours une sauvegarde datant d'une semaine en cas de problème majeur (cf. problèmes rencontrés) 6. Problèmes rencontrés Le serveur LDAP 43/61

L'installation a présenté des difficultés. Le premier problème survenu est son installation. Les paquets disponibles pour la distribution Debian Sarge ne fonctionnaient pas, chose étonnante pour cette distribution. Mais elle est tenue par des hommes et l'erreur est humaine! Je suis donc passé sur l'installation par compilation des sources disponibles sur le site officiel http://openldap.org. Il est d'ailleurs plus intéressant de passer par cette méthode puisque cela permet de compiler juste les options nécessaires pour le serveur. Ensuite, un autre problème rencontré, est le remplissage de la base de données. Ldap est un protocole très strict sur la syntaxe. Un espace mal placé dans un fichier ldif ou le fichier de configuration et le serveur LDAP refusera d'obtempérer. Bien des heures sont passées avant de comprendre cela, et ce n'est pas la journalisation du serveur qui indique bien les erreurs. Autre souci pour les fichiers ldif : lors de la charge du fichier, si une entrée est déjà présente, le serveur indiquera le succès de cette entrée mais s'arrêtera sur une erreur non indiquée dans les logs et ne poursuivra pas le chargement. Le dernier problème, toujours non résolu, est l'activation du support TLS sur le serveur LDAP. La configuration indique bien la présence du support, mais la création du certificat indique une non conformité qui n'a pas encore été résolue. Les requêtes des clients sur le serveur LDAP se font donc en clair. Ceci présente des contraintes en termes de sécurité. Le serveur DNS : MaraDNS Ce serveur est un serveur beaucoup plus sécurisé et simple à configurer que BIND. Le souci par contre est la récursion des requêtes DNS sur les serveurs racines du réseau Internet. Bien que le fichier de configuration soit juste, la configuration ne fonctionne pas. Il a fallu repartir d'un exemple fourni avec le logiciel, puis le modifier pour qu'il soit conforme à la configuration du réseau pour que le serveur DNS fonctionne en récursion. Migration des données utilisateurs Lors de la migration, j'ai omis l'option d'archivage des données sur l'utilitaire scp. Ce qui m'a valu de recommencer la migration puisque les dates de création des fichiers n'étaient pas sauvegardées. Autre problème, mais ne dépendant pas de ma personne, le hub sature lors de gros transferts, ce qui a occasionné une grande latence du réseau pendant presque 12 heures. Mozilla s'est montré peu coopératif pendant la migration des utilisateurs. Lors du changement de répertoire maison des utilisateurs dans le cadre de la réorganisation des données, Mozilla ne voulait pas se relancer avec le profil de l'utilisateur. Après recherche, cela vient de la gestion des chemins de fichiers de configuration d'utilisateur. Mozilla n'utilise pas les chemins relatifs à partir du $HOME de l'utilisateur pour indiquer les fichiers de données. Ainsi, après un déplacement du répertoire maison de l'utilisateur, ce dernier ne pouvait plus retrouver ses données. La première solution étant de créer un lien symbolique mis à la place dans 44/61

l'ancien répertoire maison et pointant sur le nouveau (solution non propre par force brute), la deuxième étant de renommer le profil posant problème et de recréer un profil avec le nom du précédant. Mozilla retrouve les chemins et fonctionne à nouveau correctement. Erreur humaine ou piraterie réussie Juste après la mise en place des scripts de sauvegarde, le serveur principal a subi une grave altération de son système et des données utilisateurs. Les dégâts engendrés ont mis le système hors fonctionnement et ceci juste avant la mise en place de la procédure de sauvegarde. Après la première analyse, il se pourrait que les scripts de sauvegarde étaient buggués et ont lancé une suppression récursive à partir de la racine du système de fichier. Or les fichiers supprimés et les fichiers restants ne correspondaient pas à ce type d'opération. Il s'agirait plutôt d'une suppression aléatoire de dossier. Le serveur principal fournissait un service web disponible depuis l'internet. Une seconde supposition est la chute du serveur web due à une mauvaise configuration. Reste que le réseau a été immobilisé pendant quelques temps. La perte des données a été minimisée grâce à une sauvegarde préventive faite la veille de l'incident sur le serveur secondaire. 7. Une migration non finie Actuellement le réseau n'est pas totalement finalisé. Il reste encore la migration des adresses IP avec l'installation des bridges et finir la configuration du serveur LDAP avec le support de TLS. Une autre tâche s'est aussi rajoutée : pouvoir enlever la dépendance des «maileurs» de mozilla via l'utilisation d'un serveur IMAP tournant sous PostFix, mais des priorités plus importantes se sont greffées, qui ont fait passer cette tâche au second plan. 8. Conclusion Je n'avais personnellement jamais réalisé une telle migration sur un réseau en production. Ceci m'a énormément été profitable à tous points de vue. La connaissance nécessaire pour mettre en place un tel réseau est loin d'être négligeable. J'ai vu les manques au niveau de mes connaissances sur les systèmes Unix comme pour la sauvegarde ou encore les serveurs LDAP, et qu'il me reste encore beaucoup à apprendre pour être véritablement digne d'opérer en entreprise. Mais ceci s'acquiert par l'expérience, et cette expérience-là est déjà un bon début pour l'avenir. La documentation pour rendre pérenne un réseau est vraiment importante. Or, 45/61

bien que documenter une mise en application, une prévision ou toute autre chose dans le cadre scolaire ou associatif soit dans mes possibilités, la réalisation de documentation dans le milieu professionnel était à revoir. Néréide m'a appris à rédiger des documentations dans ce cadre, de façon qu'elles puissent être vraiment efficaces pour les collaborateurs. Effectuer une migration sur un réseau en production rend l'opération plus intéressante non pas du fait de la technique à mettre en place, mais de la relation avec les utilisateurs, qu'il faut déranger le moins possible tout en les prévenant sur les risques potentiels durant les opérations (internet non accessible, réorganisation des répertoires). Tout ceci est vraiment intéressant, même si la communication avec les utilisateurs est un échec, due essentiellement à un manque d'expérience. Heureusement que l'excuse : «c'est un stagiaire» existe, mais j'espère que ce sera la dernière fois que j'en profiterai. C'est clairement un défaut sur lequel je dois travailler absolument afin de l 'améliorer avant le lancement de ma propre entreprise. 46/61

Conclusion du stage Je ne peux que remercier la société Néréide pour la confiance qu'elle m'a accordée dans la migration de leur architecture. Sur le domaine de l'administration système. L'expérience acquise durant le stage m'a vraiment servi à prendre conscience de mes défauts concernant la communication, la documentation et l'organisation requises par un tel projet. Sur le côté du développement, bien que n'étant pas mon domaine de prédilection, mon maître de stage m'a là aussi fourni un travail nécessitant analyse et réflexion, me faisant participé à l'élaboration du projet Neogia. Bien que pensant ne pas avoir été à la hauteur des responsabilités données, le développement effectué est un enrichissement personnel très important. Sur le plan fonctionnel, M. Heintz m'a confié le développement du module de comptabilité, alors que mes connaissances sur ce sujet au début de mon stage étaient proches de zéro. Quand je voie le temps que M. Heintz a passé pour m'apprendre la comptabilité d'entreprise, le fonctionnement d'ofbiz, l'utilisation de Neogia, je ne peux que m'en sentir redevable. Le stage passé à Néréide m'a impliqué dans les trois types d'informatique d'entreprise, l'informatique : de développement fonctionnelle administrative L'intégration dans les projets est une grande ouverture pour ma compréhension de l'informatique en entreprise. Bien que me sentant un peu juste sur l'ensemble de mes compétences pour créer mon entreprise, il est indéniable que ce stage a contribué à combler ce manque. Remerciements Bien, c'est la partie qui devrait être la plus longue de ce rapport, mais je vais essayer d'être court. Je remercie énormément M. Heintz pour tout le temps passé à me former sur toutes les nouvelles technologies rencontrées, à m'informer sur les créations d'entreprise, pour la confiance accordée, pour... etc. (faire court). Remerciement aussi au directeur technique, M. Thébault, pour toutes ses remontrances sur mes manques, faites avec le sourire, et qui m'ont permises de me jauger. 47/61

Remerciement à Mme Heintz pour ses conseils et ses apports sur la communication, et surtout pour ses pauses «café» qu'elle sait si bien préparer. En gros, un énorme merci à toutes les personnes qui font Néréide, pour leur accueil, leur façon de voir la vie et le partage. Cela été un vrai plaisir de passer ces six mois dans une société humaine. En espérant que ce ne soit que le début... 48/61

Bibliographie Références utilisées dans le cadre du développement Sites internets www.ofbiz.org : site officiel du PGI libre OFBiz labs.libre-entreprise.org : site de développement pour les sociétés appartenant au réseau libre-entreprise www.freemarker.org : site officiel du projet freemarker (fichier ftl) www.beanshell.org : site officiel du projet de script java jdee.sunsite.dk : site officiel du projet d'environnement java pour l'éditeur GNU/emacs Livre O'reilly Introduction à JAVA de Pat NIEMEYER et Jonathan KURSDEN Autre livre The Data Model Resource Book au édition Wiley de Len SILVERSTON Autre - Documentation du projet Neogia Références utilisées dans le cadre de la migration du réseau de Néréide Sites internets www.openldap.org : site officiel du serveur ldap, openldap, déployé sur la nouvelle architecture réseau de Néréide. www.maradns.org : site officiel du serveur dns, maradns, déployé sur la nouvelle architecture réseau de Néréide. linuxfr.org : site d'information et de documentation sur les systèmes libres. Livre O'reilly LDAP Administration système de Gérald CARTER Administration réseau sous linux de Olaf KIRCH et Teny DAWSON Administration Linux 200% de Rob FLICKENGER 49/61

Annexes 50/61

1.Migration du réseau de Néréide But du document Ce document décrit les différentes étapes de la migration des utilisateurs et des machines du réseau Néréide vers la nouvelle architecture. Il est destiné aux administrateurs réseaux et aux utilisateurs désirant connaître la procédure à effectuer. Etapes de la migration La migration du réseau de Néréide vers la nouvelle architecture va se dérouler en cinq étapes Première étape, migration des données utilisateurs de moindre importance du serveur principal vers le serveur secondaire, à savoir les répertoires des utilisateurs suivants : mathilde paul brice fanny lea Ainsi que le répertoire partagé /home/commun qui sera déplacé en /home/lesisles/commun Deuxième étapes, la migration des répertoires de travail : serveur principal:/home/boulot/néréideiii vers serveur secondaire:/home/boulot/commun serveur principal:/home/boulot/* vers serveur secondaire:/home/boulot/archive erg:/home/paulette vers serveur secondaire:/home/les-isles/paulette serveur principal:/var/ofbiz vers serveur secondaire:/app, Ne pas oublier de modifier les fichiers de configuration des différentes version d'ofbiz Troisième étape de la migration, passage d'imbros sous une distribution Debian Sarge et migration des données de l'utilisateur lucien - serveur principal:/home/lucien vers serveur secondaire:/home/lesisles/lucien Quatrième étape migration, passage serveur principal sous une distribution debian Sarge. Migration des services de serveur secondaire sous serveur principal Cinquième et dernière étape, mise en place du firewall et migration des adressages IP du réseau. 51/61

Première étape Pour pallier aux soucis de stabilité de serveur secondaire sur le service de nommage nsswitch sur ldap, on calque les entrées ldap sur le contenu des fichiers / etc/passwd et /etc/group Création de la partition /dev/hda8 pour accueillir /home/les-isles. Dans un premier temps, la partition /dev/hda8 sera montée en /home pour garder une compatibilité avec les variables $HOME des utilisateurs. Migration des comptes des utilisateurs prévus : scp -rp /home/brice /home/mathilde /home/paul /home/lea \ /home/fanny /home/commun serveur secondaire:/home Ré-attribution des utilisateurs en fonction des règles définies : chown -R brice /home/brice chown -R paul /home/paul chown -R mathilde /home/mathilde chown -R fanny /home/fanny chown -R lea /home/lea chown -R lucien /home/commun Ré-attribution du groupe des répertoires : chgrp -R les-isles /home/* Modification du fichier /etc/fstab de serveur secondaire: changement de : serveur principal:/export/home /home nfs soft 0 0 par : /dev/hda8 /home ext3 default 1 3 Export des répertoires via NFS Création du répertoire /export contenant les liens symboliques des répertoires à exporter. Ces répertoires sont : /export/home/les-isles -> /home/les-isles /export/home -> /home contenu du fichier /etc/exports : /export/home x.x.2.0/255.255.255.0 (rw) /export/home/les-isles x.x.2.0/255.255.255.0 (rw) 52/61

Configuration de la machine cliente (imbros) Pour imbros il faut configuration le fichier /etc/fstab et rajouter la ligne : serveur secondaire:/export/home/les-isles /home nfs soft 0 0 Reallocation des $HOME : Le changement du $HOME est à effectuer sur le serveur ldap. Si le serveur secondaire ne s'authentifie toujours pas sur ldap, ne pas oublier de changer en local. Après réallocation des $HOME des utilisateurs, sur serveur secondaire : supprimer tous les liens symboliques contenus dans /home/les-isles sur les machines clientes : changer : serveur secondaire:/export/home/les-isles /home nfs soft 0 0 par : serveur secondaire:/export/home/ /home/ nfs soft 0 0 53/61

Deuxième étape Dans la deuxième étape, passer erg et le $HOME de paulette sous serveur secondaire. Migration des donnée de erg vers serveur secondaire scp -rp /home/paulette serveur secondaire:/home/les-isles Puis modifier le $HOME dans la base ldap Ensuite configurer erg pour le montage du $HOME via le fichier /etc/fstab en rajoutant : serveur secondaire:/export/home/ /home/ nfs soft 0 0 Migration des données de serveur principal vers serveur secondaire, à partir de serveur secondaire: scp -rp serveur principal:/home/boulot /home/boulot mkdir /home/boulot/archive mkdir /home/boulot/commun mv /home/boulot/boulot/néréideiii/* /home/boulot/commun rm -f /home/boulot/boulot/néréideiii mv /home/boulot/boulot/* /home/boulot/archive rm -f /home/boulot/boulot scp -rp serveur principal:/var/ofbiz /app chgrp -R boulot /app /home/boulot chown -R tyannick /app /home/boulot chmod +X+t ug+w -R /app /home/boulot 54/61

Troisième étape L'installation d'un Debian Sarge sur imbros avec la liste des applications par défaut de Néréide. Configuration de'imbros pour intégrer le réseau de Néréide Transfère des données de l'utilisateur lucien : scp -rp serveur principal:/home/lucien /home/les-isles/lucien chgrp -R les-isles /app /home/les-isles/lucien chown -R lucien /home/les-isles/lucien Quatrième étape Installation de Debian Sarge sur serveur principal et migration des services de serveur secondaire vers serveur principal Migration du service ldap sur serveur secondaire, il faut récupérer la base de données ldap : killall slapd slapcat > ListeUtilisateurNereide.ldif scp ListUtilisateurNereide.ldif serveur principal:/root/ldap/ sur serveur principal, il faut intégrer la base dans le serveur ldap : slapadd -f /root/ldap/listeutilisateurnereide.ldif /etc/init.d/slapd start Migration des services de fichiers Mise en place des partages disponibles, sur serveur principal: scp -p serveur secondaire:/etc/exports /etc/exports Migration des données sur serveur principal : scp -rp serveur secondaire:/home/* /home scp -rp serveur secondaire:/app/* /app Re-positionnement du serveur Une fois le serveur principal en place, il ne reste plus qu'à re-synchroniser les machines clientes sur ce nouveau serveur principal. Pour cela, il faut remplacer serveur secondaire par serveur principal dans les fichiers : /etc/ldap.conf /etc/fstab Pour permettre à serveur secondaire de couvrir les services de serveur principal en cas de chute de ce dernier, on place l'adresse IP de serveur secondaire sur le nom de serveur principal dans les fichiers de configuration DNS de serveur secondaire. 55/61

Puis pour chaque client, on indique les serveurs DNS dans l'ordre suivant : serveur principal serveur secondaire Ainsi, si serveur principal devient non disponible, serveur secondaire prendra le relais de façon transparente pour les machines clientes Cinquième étape La ré-allocation des adresses IP va nécessiter un arrêt de l'accès aux services pendant une heure pour les utilisateurs. Préparation de la migration Re-nommage des adresses IP sur le DNS dans un fichier secondaire db.lesisles.org.tmp Migration des machines Arrêt de tous les services des serveurs. Re-nommage de l'adresse IP des machines, modification des adresses ip dans le fichiers /etc/network/interfaces. remplacement du fichier /etc/maradns/db.les-isles.org mv /etc/maradns/db.les-isles.org /etc/maradns/db.les-isles.org.old mv /etc/maradns/db.les-isles.org.tmp /etc/maradns/db.les-isles.org Mise en place du firewall Relancement des serveurs : serveur principal et serveur secondaire Vérification de l'état du réseau et des services. 56/61

2.Migration de serveur principal pour la nouvelle architecture réseau But du document Ce document a pour but de décrire l'installation de la distribution Debian Sarge sur serveur principal ainsi que des services à installer et des opérations a effectuer pour que serveur principal fasse office de serveur princial. Analyse de l'existant Actuellement serveur principal tourne sous une distribution mandrake 9.1 mise à jour. Il est en grande partie déconnécté des autres ordinateur du réseau qui on pour authorité serveur secondaire. Ces disques durs sont organisés comme l'indique les tableaux suivants : /dev/hda : Partition taille Utilisation Type & commentaires /dev/hda1 2 Go / etx3 /dev/hda5 549 Mo Swap mandrake Swap /dev/hda6 5,1 Go /usr etx3 /dev/hda7 3 Go /var etx3 /dev/hda8 19 Go /home etx3 /dev/hda9 9,3 Go /misc etx3-18 Go vide - /dev/hdc : Partition taille Utilisation Type & commentaires /dev/hdc1 2 Go /Sav etx3 /dev/hdc5 549 Mo Swap mandrake Swap /dev/hdc6 5,1 Go /Sav/usr etx3 57/61

Partition taille Utilisation Type & commentaires /dev/hdc7 3 Go /Sav/var etx3 /dev/hdc8 19 Go /Sav/home etx3 /dev/hdc9 10 Go /Sav/misc etx3-17 Go vide - Étapes de la migration de serveur principal la migration va suivre les étapes suivantes : Installation d'une distribution Debian Sarge sur /dev/hdc Installation et configuration des services nécessaire à l'exploitation Migration des données utilisateurs Installation de Debian Sarge sur serveur principal L'installation de la distribution Debian Sarge se fait sur le deuxième disque dur /dev/hdc. Le disque dur /dev/hda n'est pas touché car contenant encore des données utilisateur. Sauvegarde des données restante Les données se trouvant dans le répertoire actuel /misc seront sauvegardé dans le répertoire de l'utilisateur folivier sur serveur secondaire : sur serveur principal : scp rp /misc/image serveur secondaire:/home/les isles/folivier sur serveur secondaire : chown paul R /home/les isles/paul/image chgrp les isles R /home/les isles/paul/image Réorganisation des disques durs de serveur principal Le disque /dev/hdc est réorganisé suivant la structure finale déjà définie cf. Description_des_partitions_de_serveur principal.sxw Installation des services Les applications de Néréide sont à installer. Pour pouvoir fournir ces services serveur principal doit avoir d'installer : 58/61

NFS apt-get install nfs-common nfs-kernel-server nfs-user-server Serveur ldap : Openldap Installation à partir des sources, version 2.2.12 Serveur DNS : maradns apt-get install maradns Serveur SSH : OpenSSH apt-get install ssh Serveur d'impression : CUPS apt-get install cups* foomatic-db* Seveur http : Apache2 apt-get install apache2 Serveur SMB : Samba apt-get install samba Configuration des services cf Migration_du_réseau.sxw : Quatrième Etape Migration des données utilisateurs cf Migration_du_réseau.sxw : Quatrième Etape 59/61

3.Sauvegarde des données du serveur But du document L'objectif de ce document est de décrire les procédures de sauvegarde de serveur principal. Il s'adresse aux administrateurs réseaux à titre d'information. Deux types de sauvegarde Sauvegarde disque à disque Explication serveur principal étant équipé de deux disques durs ide de même capacité, les deux disques ont les mêmes partitions de façon à pouvoir répliquer le disque en fonctionnement sur le disque inactif. Fonctionnement de la sauvegarde La sauvegarde est faite par le script : /root/sauvegarde/vue_journaliere.sh Ce script est lancé par crontab à 12h00 et 18h00 chaque jour. Fonctionnement du script 1ère étape : Montage des partitions de sauvegarde à partir du répertoire / mnt/sauvegard Synchronisation des répertoires : via rsync Démontage des partitions Sauvegarde sur serveur secondaire Explication Les répertoires contenant les données utilisateurs sont répliqués à arborescence identique de serveur principal sur serveur secondaire. Les répertoires systèmes sont répliqués de serveur principal dans le répertoire / app/sauvegarde de serveur secondaire 60/61

Fonctionnement de la sauvegarde La sauvegarde s'exécute via le script /root/sauvegarde/balance_push.sh. Deux fichiers contiennent les répertoires à sauvegarder sur serveur secondaire. Le premier : rep_a_dupliquer.txt, contient les répertoires à dupliquer en respectant l'arborescence. Le deuxième : rep_a_sauvegarder.txt, contient les répertoires à sauvegarder dans un répertoire de sauvegarde sur serveur secondaire La sauvegarde est lancée par crontab tous les samedis à 19h00 61/61