mémoire de fin d’études - oliviermo75.free.froliviermo75.free.fr/cley_fin_cycle.docx · web...

CYCLE DE FORMATION

Analyste informaticien

PROJET DE FIN D’ÉTUDES

Sujet : Automatisation du processus de déploiement logiciel

Soutenu par : Christopher LEY

Entreprise : CIEME Informatique

Sous le tutorat de : M. David BESIN

Contrat du 10/2008 au 10/2010

http://afcepf.fr/

Mémoire de Fin d’EtudesCycle de formation : Analyste Informaticien

Sujet : Automatisation du processus de déploiement logiciel

Suivi :

2010

Christopher LEY PROMO 70

RR3363

Mémoire de fin d’études

Remerciements

Je tiens à remercier dans un premier temps, toute l’équipe pédagogique de l’INSTA et les intervenants professionnels responsables de la formation Analyste Informaticien, pour avoir assuré la partie théorique de celle-ci.

Je souhaite remercier AFCEPF et plus particulièrement Monsieur Patrick RAKOTOMALALA qui nous a suivi et s’est montré disponible durant toute la rédaction du mémoire.

Je remercie également Monsieur Ryad LEBIB pour l’aide et les conseils qu’il m’a apporté pour le bon déroulement de ma formation.

Je tiens à remercier tout particulièrement et à témoigner toute ma reconnaissance aux personnes suivantes, pour l’expérience enrichissante et pleine d’intérêt qu’elles m’ont fait vivre durant ces deux années au sein de l’entreprise CIEME Informatique :

Monsieur Florent RAUGEL, PDG de CIEME Informatique, pour son accueil et la confiance qu’il m’a accordé dès mon arrivée dans l’entreprise.

Monsieur David BESIN, responsable du service « Services & Support » de la société CIEME Informatique, mon tuteur, pour m’avoir intégré rapidement au sein de l’entreprise et m’avoir accordé toute sa confiance, pour le temps qu’il m’a consacré tout au long de cette période, sachant répondre à toutes mes interrogations, sans oublier sa participation au cheminement de ce rapport.

Toute l’équipe technique, ainsi que l’ensemble du personnel de CIEME pour leur accueil sympathique et leur coopération professionnelle tout au long de ces deux années.

3/71Mémoire de fin d’études LEY Christopher PROMO 70


SommaireCYCLE DE FORMATION......................................................................................................1

Analyste informaticien...............................................................................................................1

Chapitre 1 : Introduction.................................................................................................................8

1.1 Situation actuelle..........................................................................................................................8

1.2 Contexte......................................................................................................................................8

1.3 Objectifs généraux........................................................................................................................8

1.4 Présentation des différentes parties............................................................................................9

1.4.1 Présentation de l’entreprise.................................................................................................9

1.4.2 Analyse des besoins et de l’existant......................................................................................9

1.4.3 Solutions possibles et restrictions.........................................................................................9

1.4.4 Le projet................................................................................................................................9

1.4.5 Résultat final........................................................................................................................10

1.4.6 Conclusion...........................................................................................................................10

Chapitre 2 : Présentation de l’entreprise.......................................................................................11

2.1 Présentation générale................................................................................................................11

2.2 Historique...................................................................................................................................11

2.3 Domaines d’activités..................................................................................................................12

2.4 Offres..........................................................................................................................................12

2.5 Concurrents et parts de marché.................................................................................................14

2.6 Situation économique................................................................................................................14

2.7 Certifications et reconnaissance.................................................................................................15

2.8 La recherche et développement dans l’entreprise.....................................................................15

Chapitre 3 : Analyse des besoins et de l’existant............................................................................16

3.1 Analyse des services...................................................................................................................16

3.1.1 Organigramme de l’entreprise............................................................................................16

3.1.2 Les différents services..........................................................................................................16

3.1.3 Présentation du service technique......................................................................................17

3.2 Schéma d’occupation du service « Services et Support »...........................................................19

3.3 Les résultats de l’audit................................................................................................................20

3.4 Les besoins du service................................................................................................................20

3.4.1 Processus de préparation et d’acheminement d’une commande.......................................20



3.4.2 Tableau récapitulatif de la durée des tâches.......................................................................21

3.4.3 Analyse de l’existant............................................................................................................21

3.4.4 Les limites de ce système....................................................................................................21

3.4.5 Les nouveaux besoins du service.........................................................................................22

Chapitre 4 : La solution..................................................................................................................24

4.1 L’automatisation........................................................................................................................24

4.1.1 Les avantages de l’automatisation.......................................................................................24

4.1.2 Pourquoi automatiser la préparation ?................................................................................24

4.2 Panorama des solutions.............................................................................................................25

4.2.1 Altiris Deployment Solution de Symantec...........................................................................25

4.2.2 Microsoft WDS.....................................................................................................................26

4.2.3 Scripts et Linux RedHat Kickstart.........................................................................................26

4.3 Ressources et restrictions...........................................................................................................27

4.3.1 Ressources...........................................................................................................................27

4.3.2 Restrictions..........................................................................................................................27

4.4 Contraintes du cahier des charges..............................................................................................28

4.5 La solution retenue.....................................................................................................................28

4.5.1 Altiris Deployment Solution de Symantec...........................................................................28

4.5.2 Microsoft WDS (Windows Desktop Search).........................................................................29

4.5.3 Scripts et Linux RedHat Kickstart.........................................................................................29

4.6 Critères de choix.........................................................................................................................30

4.7 Procédure de sauvegarde...........................................................................................................30

4.8 Le choix du serveur.....................................................................................................................31

4.8 Les aspects fonctionnels.............................................................................................................31

Chapitre 5 : Le projet.....................................................................................................................32

5.1 Technologies utilisées.................................................................................................................32

5.1.1 Le protocole PXE..................................................................................................................32

5.1.2 Le protocole DHCP...............................................................................................................33

5.1.3 Le protocole TFTP................................................................................................................34

5.1.4 Le protocole HTTP...............................................................................................................35

5.1.5 Le service Kickstart..............................................................................................................35

5.1.6 Les fichiers PXELinux............................................................................................................36

5.2 Configuration des serveurs.........................................................................................................36

5.2.1 Schéma de fonctionnement.................................................................................................36



5.2.2 Principe de fonctionnement................................................................................................37

5.2.3 Configuration du serveur DHCP...........................................................................................38

5.2.4 Configuration du serveur TFTP............................................................................................39

5.2.5 Configuration du serveur Apache........................................................................................40

5.2.6 Le service kickstart...............................................................................................................41

5.2.7 Les fichiers PXELinux............................................................................................................43

5.3 Les scripts Post Installation.........................................................................................................44

5.4 Organisation...............................................................................................................................45

5.4.1 Listes des tâches..................................................................................................................45

5.4.2 Répartition des tâches.........................................................................................................46

5.4.3 Gantt....................................................................................................................................47

5.5 Les livrables................................................................................................................................48

5.6 Documentation UML..................................................................................................................49

5.6.1 Diagramme de fonctionnement...........................................................................................49

5.6.2 Diagramme de déploiement................................................................................................50

5.7 La maintenance..........................................................................................................................51

5.7.1 Le transfert de compétences...............................................................................................51

5.7.2 Aspects fonctionnels de la Maintenance.............................................................................51

5.8 Les difficultés rencontrées..........................................................................................................52

5.9 La mise en production (MeP)......................................................................................................53

5.9.1 Prérequis.............................................................................................................................53

5.9.2 Tableau des anomalies après MeP ou VABE (Validation à la Bonne Exploitation)...............54

Chapitre 6 : Résultat final..............................................................................................................55

6.1 Aperçu du projet.........................................................................................................................55

6.1.1 « Booter » en réseau...........................................................................................................55

6.1.2 Choix de la distribution........................................................................................................56

6.1.3 Récupération de l’image et installation...............................................................................56

6.1.4 Exécution des scripts Post-Installation................................................................................58

6.2 L’impact du système sur le service technique............................................................................59

6.3 Le retour utilisateur....................................................................................................................59

6.4 Les attentes ont-elles bien été respectées ?...............................................................................60

Chapitre 7 : Conclusion..................................................................................................................61

7.1 Le gain pour l’entreprise.............................................................................................................61

7.2 Le gain personnel.......................................................................................................................61



Chapitre 8 : Annexes.....................................................................................................................62

8.1 Glossaire.....................................................................................................................................62

8.2 Scripts d’automatisation Linux Red Hat 5.3 (32 Bits)..................................................................63

8.3 Scripts de Sauvegarde.................................................................................................................66

8.4 Fiche de Formation.....................................................................................................................68

8.5 Caractéristiques Dell PoxerEdge R310........................................................................................69

8.6 Exemple de fiche de test ou PV de Recette................................................................................71



Chapitre 1 : Introduction

1.1 Situation actuelle

Je travaille actuellement dans une société de création de progiciels de gestion financières des télécoms ou GFT, qui propose des solutions aussi bien pour les entreprises, que pour les hôpitaux ou hôtels.J’appartiens au service client, plus particulièrement à l’équipe « Support et Service ». Je suis en charge de l’installation des serveurs, du logiciel de taxation, de leur mise à jour ainsi que de leur débogage lorsque cela s’avère nécessaire, plus particulièrement sous univers Unix (Linux, SCO…), mais également à moindre partie sous Windows.

1.2 Contexte

L’équipe Support passe énormément de temps à préparer les commandes clients, notamment la préparation des serveurs selon les demandes des clients.En effet le marché des GFT étant une activité relativement peu connue du grand public, ainsi que la complexité de la base de données des logiciels de la CIEME Informatique (Base de données propriétaire), font qu’une préparation extérieure à nos locaux sans formation au préalable se révèle extrêmement compliquée. Pour qu’un déploiement soit bien réalisé, certains pré requis systèmes doivent être respectés, encore plus sous univers Unix. Nous devons respecter un partitionnement, des packages, des droits et autorisations spécifiques, ainsi qu’identifier l’infrastructure actuelle du client, le type de PABX ou IPBX, la présence ou non d’interface utilisateurs, surtout dans les milieux hospitaliers et hôteliers. A l’heure actuelle, toutes ces tâches sont réalisées manuellement par un technicien, qui est responsable de la machine et plus précisément de la commande, de la réception jusqu’à l’acheminement chez le client et sa mise en production. Le temps de préparation serveur se révèle donc extrêmement long, et occupe une ressource du service pendant environ ½ journée sans pour autant que ce soit un réel retour sur investissement pour la société.

1.3 Objectifs généraux

Le but de ce projet est donc d’améliorer le processus de préparation commande et plus précisément des préparations machines. De cette façon, nous pourrons diminuer de façon considérable le temps de livraison et d’occupation du service. Il faut également que cette transition se fasse de façon transparente pour la société, que cela ne perturbe pas les préparations actuelles... De plus il doit être facile de modifier ou d’ajouter pour n’importe quel intervenant du service, d’éventuelles mises à jour du logiciel, ou de nouvelles distributions à déployer.



1.4 Présentation des différentes parties

1.4.1 Présentation de l’entreprise

Cette première partie permettra de mieux appréhender l’entreprise CIEME Informatique. Nous pourrons y découvrir son historique et sa place sur le marché concurrentiel qu’est le logiciel de Gestion Financière des Télécoms (GFT). Nous pourrons y voir également ses objectifs, le savoir-faire qu’elle offre à ses clients ainsi que les avancées qu’elle a permise dans le secteur informatique des télécoms. Cette partie se terminera par la présentation des différents pôles produits ainsi que les offres que ceux-ci proposent aux clients.

1.4.2 Analyse des besoins et de l’existant

Au cours de cette partie, nous présenterons les différents services, leurs activités et les interactions existants entre eux. Cette étape nous permettra d’exposer les besoins récurrents de chacun au service Support ainsi que les besoins des intervenants extérieurs au service Support lorsque qu’ils prennent contact avec celui-ci. Cela nous permettra d’analyser avec plus de recul l’existant, les éventuelles carences de ce dernier et les améliorations bénéficiant au service que devrait permettre le développement du nouvel outil.

1.4.3 Solutions possibles et restrictions

Pour faire suite à l’analyse des besoins de chacun, nous présenterons ici les différentes solutions possibles pour améliorer le service et le travail de chacun. Nous mettrons également en évidence les restrictions imposées pour le projet pour présenter plus en détail la solution retenue et ce qu’elle apportera concrètement au service. Chaque projet comporte également sa part d’obligations légales et cela est d’autant plus vrai dans le domaine des télécoms. Il est donc indispensable pour ce projet d’avoir des stratégies de sécurité et de maintenance. Nous verrons donc également dans cette partie les obligations légales que doit respecter ce projet ainsi que la stratégie de sécurité mise en place afin d’assurer la confidentialité des données. La pérennité des informations est aussi indispensable ce qui nécessite que le système soit doté d’une grande fiabilité. Il est donc impératif que ce dernier possède une stratégie de maintenance et de sauvegarde, laquelle sera également présentée au cours de cette partie.

1.4.4 Le projet

Une fois la solution retenue et exposée en détail, nous présenterons l’organisation du projet. Les différentes étapes nécessaires à la réalisation de celui-ci seront ici décrites et les différents acteurs intervenant dans la bonne réalisation du projet y seront présentés. Puis nous aborderons la planification des différentes étapes afin que le projet soit finalisé en temps et en heure. Cette partie présentera également une étape essentielle du projet, à savoir le déploiement. Seront exposés plus en détail les différents choix techniques abordés lors du choix de la solution retenue. Nous y verrons donc aussi bien les technologies choisies pour l’élaboration du projet que les étapes de conceptualisation. Nous finirons cette partie par une présentation des différents livrables de ce projet.



1.4.5 Résultat final

Cette partie nous donnera un aperçu du projet après sa réalisation. Nous pourrons y découvrir le comportement de celui-ci après sa mise en production et les différents retours des utilisateurs. Ceux-ci pourront permettre d’estimer si le projet a atteint ses objectifs et si les différentes analyses et les différents choix effectués durant toute la réalisation de ce projet étaient pertinents.

1.4.6 Conclusion

Pour finir, la conclusion nous permettra de faire le point sur ce qu’a concrètement apporté ce projet à l’entreprise et ce qu’il m’a apporté sur un plan personnel. Nous clôturerons cette analyse avec les différentes améliorations demandées par les utilisateurs et celles en cours de développement.



Chapitre 2 : Présentation de l’entreprise

Cette première partie a pour but de mieux comprendre les origines de la société CIEME Informatique. Nous commencerons donc par l’histoire de la société CIEME Informatique. Cela nous permettra de découvrir son évolution au cours des années et ce qui lui a permis d’arriver à ce qu’elle est à présent. Nous poursuivrons ensuite par la place que CIEME occupe sur le marché. Seront aussi présentées dans cette partie les recherches et innovations qui lui ont permis de devenir un des leaders sur le marché du logiciel de taxation. Pour finir, nous présenterons les différents pôles produits et les solutions que ces pôles proposent sur le marché de l’informatique des télécoms.

2.1 Présentation générale

Statut Juridique : Société Anonyme à Conseil d’Administration Capital : 431 632 Euros Chiffre d’affaires : 1 634 000 Euros (au 30/06/2009) Président Directeur Général : M. Florent RAUGEL Effectifs : 17 employés Adresse : 25 rue du 8 Mai 1945, 94470 Boissy Saint-Léger Domaines d’activités : Société Editrice de Logiciels, SSII, hébergement…

2.2 Historique

Depuis plus de vingt-cinq ans, CIEME s’est toujours située à la pointe de l’innovation en matière de Techniques de l’Information et de la Gestion Financières des Télécoms dans les domaines de l’Hôtellerie et de la Santé et de l’Industrie.Depuis sa création en 1984, la vocation de Cieme Informatique est fondée sur la mise au point de progiciels destinés à mieux gérer les systèmes de facturation des télécommunications chez les opérateurs et dans les entreprises.La société CIEME INFORMATIQUE, éditeur en solutions progiciels de gestion financière des télécommunications, a accompagné plusieurs changements importants du marché des télécommunications. Tous ces changements ont eu des effets plus ou moins importants sur ses solutions progiciels. Des simples changements de numérotations réalisés sur le réseau français, jusqu’à la dérégulation des opérateurs télécoms et l’arrivée de nouveaux opérateurs sur le marché. Tous ces changements ont eu pour conséquence d’imposer des modifications fonctionnelles très importantes.L’appellation même du marché, « la gestion financière des télécoms », est survenue au milieu des années 90 à la suite d’une modification importante du mode de tarification des communications.Alors que les télécommunications constituent de plus en plus le lien fondamental de l'entreprise avec son environnement, Cieme Informatique s'appuie sur plus de 20 années d'expérience



d'interopérabilité entre les univers de la téléphonie et de l'informatique pour proposer un ensemble de progiciels et de services capable de mieux maîtriser et optimiser les flux de communication.

Quelques dates clés :

1984 : Création de CIEME Informatique 1985 : Lancement d’InfoTax, progiciel précurseur dans la taxation téléphonique 1990 : Dérégulation des télécommunications, on parle maintenant de GFT 1992 : Lancement de la gamme InfoServ en remplacement d’InfoTax 1998 : Ouverture du marché des télécoms français à la concurrence 2002 : Adaptions de la gestion financière à la nouvelle monnaie : l’Euro 2002 : Lancement du module MobilServ 2003 : Interface client/serveur Web avec la mise à jour InfoServ 2.3

2.3 Domaines d’activités

Editeur et vendeur de progiciels de gestion des flux voix et données, Cieme est devenu l'acteur majeur sur le marché de la Gestion Financière des Télécommunications (GFT).Une présence de longue date sur ce marché a permis à Cieme d'acquérir une expérience et des compétences reconnues par l'ensemble des professionnels des Télécommunications Traditionnelles et TOIP. Avec des budgets moyens en hausses de 10 à 15% par an, la facture des différents moyens de communications représente aujourd'hui plus de 4 % du chiffre d'affaire des entreprises. Dès lors, la GFT devient une priorité stratégique pour l'ensemble des entreprises dont le retour sur investissement atteint une vitesse exceptionnelle, de moins de six mois en moyenne.

2.4 Offres

Actuellement, la société propose 3 solutions personnalisables en fonction des besoins du client :

InfoServ, divisé en 3 catégories pour une approche encore plus large du marché :

InfoServ Industrie & Service permet de répondre à la problématique d’entreprise en :

établissant une simulation opérateurs sur la base des différents tarifs pratiqués sur le marché pour optimiser vos choix en termes d'opérateurs

donnant les informations nécessaires à l'amélioration de vos services téléphoniques indispensables aux centres d'appels (nbre d'appels aboutis/non aboutis, nbre de sonneries, etc.) pour une optimisation du taux de satisfaction de leurs clients.

pouvant refacturer en interne (par services, centres de coûts, postes, etc.) vos frais fixes et variables

InfoServ Hôtelier (HoriZon), le produit HoriZon a été spécifiquement conçu pour répondre aux besoins des professionnels de l'hôtellerie. Tout en optimisant les coûts financiers,



l'utilisation d'HoriZon met à la disposition du client un ensemble de fonctionnalités nouvelles à partir de 4 points fondamentaux:

L'interface avec des applicatifs externes utilisés dans l'hôtellerie (Fidelio, Optims, Hogatex, MAI/HIS, Cegid).

Les fonctions vocales, comme la messagerie téléphonique ou les fonctions réveils La gestion financière des clients, la tarification multi-opérateur ou la facturation des

communications téléphoniques selon les services et choix d'opérateurs alternatifs. L'accueil téléphonique, pour optimiser l’analyse des appels arrivés (durée de sonnerie,

appels non répondus…)

InfoServ Santé, pour les établissements de santé, il est indispensable d'apporter des solutions probantes en termes de flux téléphoniques et de services proposés aux patients tout en gérant efficacement les aspects financiers et administratifs. Ainsi, les avantages d'InfoServ Santé se retrouvent dans différents domaines :

L'interfaçage avec les différents applicatifs informatiques existants La gestion administrative des patients : gestion des admissions, édition automatique des

bordereaux et des différentes factures… La gestion financière des patients

MobilServ, qui permet de consolider l’ensemble des CDR (Charging Data Record) fournis par les opérateurs nationaux (Orange, SFR, Bouygues Telecom) pour une lisibilité simplifiée du contrôle des coûts, ainsi que :

L’inventaire de l’ensemble des terminaux mobiles présents dans la société La comparaison des coûts en fonction des différents opérateurs

Actis, pour l’amélioration de la gestion de la société cliente, grâce à un service de Télétraitement qui permet de se libérer des coûts récurrents liés aux systèmes d'administration des télécoms :

Maîtrise des ressources humaines : pas d'investissement de temps dans la gestion des outils, pas de problème de remplacement pendant les périodes de vacances

Maîtrise des ressources financières : aucun investissement matériel, donc pas d'immobilisation

Pas de coûts d'exploitation induits (mise à jour, veille technologique…) Mise à disposition d'un personnel compétent et efficace prenant en charge l'analyse de

vos besoins sur le long terme Ponctualité dans la réception des rapports de statistique



2.5 Concurrents et parts de marché

CIEME occupe une position de leader sur le marché des GFT, car elle est la seule à proposer des offres ayant une interopérabilité sur l’ensemble des réseaux PABX, IPBX présent sur le marché.

De plus ses certifications et partenariats, en font le numéro 1 auprès des constructeurs télécoms, comme Matra, Alcatel, Cisco….

France Télécom, propose des solutions complètes clé en mains basées sur un InfoServ simplifié : InfoServ TPE, qui nous permet d’élargir et d’étendre notre domination sur le territoire français.

Parmi ces concurrents ont peu noter :

Cogis GT2F SLIT Axitel Memobox

A elles seules, les solutions de CIEME Informatique représentent 57% du marché français. *

* source interne

2.6 Situation économique

La situation économique de la société est saine, mais stable.

En effet depuis les années 2001-2002, date de passage à l’euro qui a engendré une recrudescence massive des entreprises pour la surveillance et le contrôle des relevés téléphoniques, le chiffre d’affaire de CIEME Informatique a connu un léger recul, sans pour autant devenir catastrophique.

On peut définir l’âge d’or des solutions de GFT sur cette période, le marché s’étant affaibli, il est normal que le résultat net de la société suive la même courbe.

CIEME a su réagir en diversifiant ses offres et ses services, et ainsi « élargir » le marché sur laquelle elle se positionne.

Quelques chiffres :

Exercice fiscal * 2000-2001

2001-2002

2002-2003

2003-2004

2004-2005

2005-2006

2006-2007

2007-2008

2008-2009

Chiffres d’affaires en Millions d’euros

2,3 2,5 2,3 2,1 2,0 2,0 1,9 1,8 1,7

* Exercice clos au 30 juin



2.7 Certifications et reconnaissance

Cieme Informatique met en œuvre de multiples partenariats technologiques et marketing, et réalise également de nombreux accords de distribution. Ces partenariats s'effectuent tant à l'échelle francophone qu’européenne. CIEME Informatique est certifiée parmi les plus grands groupes informatiques et de télécoms mondiaux, comme Cisco, Microsoft, 3com, Alcatel…

De par ces certifications et ses chaînes de distributions, les solutions de CIEME Informatique sont aujourd’hui présentes sur plus de 6000 sites, tous secteurs confondus.

2.8 La recherche et développement dans l’entreprise

Cieme Informatique consacre par ailleurs un investissement soutenu en Recherche et Développement (30% de son chiffre d'affaires), qui lui permet de faire évoluer constamment ses produits afin de coller le plus possible aux évolutions technologiques du marché.



Chapitre 3 : Analyse des besoins et de l’existant

Après avoir présenté CIEME d’un point de vue externe, cette partie présentera CIEME d’un point de vue interne. Nous présenterons ici les différents services, leur fonctionnement respectif ainsi que les tâches qui leur incombent. Nous verrons ensuite les différents processus et le cheminement complet d’une préparation commande. Cela nous permettra de dégager une problématique sur la gestion du temps et des ressources nécessaires à la réalisation de la prestation. Nous finirons par l’analyse de l’existant et de ses éventuelles carences.

3.1 Analyse des services

3.1.1 Organigramme de l’entreprise

3.1.2 Les différents services

On peut donc voir dans l’organigramme que l’entreprise comprend quatre services principaux : les ressources humaines, le développement, le commerce et marketing, le service client et SAV.

Les ressources humaines : Ce service est responsable du personnel. Il est en charge de la gestion des contrats de travail, de la gestion des congés et des payes mensuelles.



Le développement : Ce service est en charge de toute la partie développement logiciel des progiciels commercialisés par CIEME. Les développeurs ont également pour mission de corriger les bugs dus à des erreurs de développement. Quand l’anomalie est reproductible sur les bases de données internes à la société, les développeurs l’analysent et la corrigent. Parfois, les anomalies ne sont pas reproductibles au sein de CIEME ; dans ce cas là, ils doivent se connecter directement au site afin de constater l’anomalie. La rédaction des documentations d’installation et la création des procédures de mise à jour du logiciel font également parties de leurs prérogatives.Ce service permet aux offres de CIEME d’évoluer afin de coller le plus possible aux évolutions technologiques du marché. Près de 30% du CA est investi dans ce service.

Le commerce et marketing : Sa mission est de répondre aux appels d’offre afin de placer les logiciels de CIEME. Il assure également la promotion des progiciels de CIEME, avec des procédés marketing tels que le CIEME TV.

Le service client, SAV et technique: Ce service se compose de pôles particuliers. Le premier est la partie Support.Le support vient en aide au client en cas de problème, il corrige les anomalies du systèmes et fait l’analyse de niveau un. Lorsqu’il ne peut pas corriger eux-mêmes, il transfère les anomalies aux développeurs afin qu’un correctif soit programmé.Le deuxième pôle est la partie la plus technique. Il s’agit de l’équipe installation. Ce sont les installateurs qui sont chargés d’installer chez les clients les différents logiciels vendus par la société. Les interventions peuvent être réalisées directement chez le client mais sont le plus souvent effectuées en télémaintenance.Il est également responsable de la préparation des commandes et sa livraison.

C’est sur ce dernier service sur lequel s’axe notre projet, nous allons donc rentrer plus en profondeur sur les actions réalisées par ce service.

3.1.3 Présentation du service technique

Dés mon arrivée à la CIEME Informatique, j’ai été affecté au service « Support et Services » sous la direction de M. David Besin.

Ce service est responsable de :

1- L'étude et la préparation technique du projet

Cette phase consiste à analyser l'existant et identifier les besoins. L'objectif est de mettre en place une solution adaptée au fonctionnement et la structure du client. L'équipe Services de Cieme Informatique va alors être impliquée dans la réalisation d'audits, d'actions d'avant vente et de missions ponctuelles de conseil. La genèse et la validation d'un document technique, conformément à la Méthodologie de Gestion de Projet de Cieme Informatique va être le point de départ du déploiement.



2 - Le déploiement de la solution sur site

Le déploiement de l'application sur site peut être assuré par l'équipe Services. Le progiciel est alors personnalisé suivant les spécificités du site, les connexions avec autocommutateur ou commutateur et éventuellement d'autres applications externes sont établies et une batterie de tests est réalisée. La solution doit être opérationnelle à l'issue de cette phase. Si le déploiement est assuré par une tierce partie, l'équipe Services fournit, au besoin, une assistance téléphonique comprenant toutes les procédures précitées.

3 - Le transfert des compétences

Le transfert de compétences s'effectue par le biais de deux canaux complémentaires : la formation aux utilisateurs et les supports pédagogiques. La formation aux utilisateurs est dispensée par un membre de l'équipe Services. Flexible, elle va permettre de renforcer les aspects les plus importants par rapport à l'installation. Elle est complétée par des supports pédagogiques sous forme de manuels ou de didacticiels.

4 - L'accompagnement de l’installation

Le membre de l'équipe Services qui a été en charge de votre projet et réalisé chacune de ses étapes sera votre unique interlocuteur. En cas de requêtes de votre part, l'équipe Hotline va l'en informer afin qu'il tienne votre dossier à jour. Il vous communiquera le cas échéant les évolutions postérieures de l'application, les nouvelles facultés qui peuvent vous intéresser et sera pour vous une véritable force de proposition au cas où vos installations réseaux et télécoms évoluent.

Comme vue précédemment ce service est composé, outre M. Besin, de 5 techniciens réseaux et télécoms dont moi-même. Ce qui est très peu compte tenu de la charge de travail à réaliser par le service. Cf. : Organigramme de la CIEME Informatique

La CIEME Informatique reçoit environ une dizaine de commandes de préparation serveur par semaine que ce soit sous environnement Linux ou Windows et ce chiffre est en constante augmentation.

La logistique de préparation de commandes, après réception du service commercial, se compose comme suit :

La génération de la licence suivant l’OS et les modules commandés La sortie de stock du matériel nécessaire à la préparation de la commande La préparation et la configuration serveur (Raid, rajout de carte réseau, vocale, série…) L’expédition La Mise en Service sur site

Un délai de 15 jours suivant la réception de la commande auprès du service commercial est à respecter sous peine de pénalités régies par un dédommagement forfaitaire définies avec nos installateurs.



Outre les préparations des commandes, ce service est également en charge de :

La Hotline : ouverte du Lundi au Vendredi entre 8h30 et 17h30 L’administration du réseau de la Société Du helpdesk collaborateur

De plus chaque technicien se voit attribuer un ou plusieurs grands comptes clients à administrer :

Moi-même, je suis responsable de toute l’administration et le contact de la Banque Africaine de Développement (BAD)

Sans compter toutes les petites prestations annexes, comme les mises à jour des grilles tarifaires des solutions clientes après migration chez un autre opérateur, ou la mise en place d’édition personnalisée de leurs facturations téléphoniques.

3.2 Schéma d’occupation du service « Services et Support »



3.3 Les résultats de l’audit

Un audit a été réalisé par la direction pour «faire un point » sur le fonctionnement du service « support et services », il s’est avéré que l’utilisation des ressources humaines de ce service n’était pas optimisée, notamment pour la tâche de préparation des commandes.

Voici les « points noirs » qui sont ressortis après cet audit :

Délai de préparation trop important Délai de réquisition d’un technicien trop important Anomalies constatées lors de la configuration serveur (erreurs humaines) Pas de documentation centralisée

3.4 Les besoins du service

Afin de mieux appréhender le problème du service au niveau de la préparation des commandes, nous allons mettre en évidence le processus actuel. Ceci nous permettra de voir et d’étudier le temps de chaque phase pour essayer d’en améliorer la productivité.

3.4.1 Processus de préparation et d’acheminement d’une commande

On peut voir ci-dessous les différentes étapes de la commande. A l’heure actuelle toutes ces étapes se font de façon manuelle. Il n’y a aucun processus pour automatiser le procédé.



3.4.2 Tableau récapitulatif de la durée des tâches

Avec le tableau ci-dessous nous sommes en mesures de constater qu’elles sont les tâches les plus contraignantes, et ainsi orienter notre phase d’analyse pour orienter nos travaux là-dessus.

Tâche Commentaires Temps estimé Génération de la licence Option + éventuel

développement spécifique5 minutes

Sortie de stock du matériel Serveur + éventuels matériels 10 minutesPréparation du serveur et test de fonctionnement

Installation de l’OS + configuration + test

3 heures

Demande d’enlèvement Demande d’enlèvement en ligne auprès de notre transporteur

15 minutes

Total : 3 heures 30 minutes

3.4.3 Analyse de l’existant

On peut donc remarquer que la préparation des serveurs est une des fonctions les plus contraignantes assurée par le service technique en termes de temps heure/employé.

Environ 2/3 d’une préparation commande est dédié à la configuration et la préparation du serveur.Cependant cette tâche ne représente qu’une petite partie de la valeur marchande d’une commande.

Cette tâche n’est pas des plus rentables pour la société car, elle nécessite et bloque donc un employé qui pourrait s’occuper ailleurs.

Actuellement, la configuration se fait « à la main », c'est-à-dire qu’un technicien est dédié au suivi de la machine, de son expédition et de son installation sur site.

3.4.4 Les limites de ce système

Après avoir détaillé les processus opérationnels, on remarque que sur 3h30 de préparation, 3h sont dédiées à la préparation et au test machine.

On peut donc rapidement isoler les inconvénients et limites de cette préparation :

Le temps trop important, pour une tâche à faible valeur ajoutée Le blocage d’un technicien Le coût



Mon responsable m’a donc demandé de réfléchir sur une technique d’amélioration de préparation des serveurs.

3.4.5 Les nouveaux besoins du service

Véritable opération à valeur ajoutée, la préparation de commandes consiste à collecter les informations et optimiser le flux. Réussir à rationaliser et à optimiser cette tâche nous permettrais à la fois de gagner en productivité et d’améliorer la qualité de service et donc l'image de marque de CIEME Informatique (envoi des commandes dans le respect des délais négociés avec les clients, etc.).

Après études réalisées au préalable par la direction, il a été évalué qu’un technicien du service « Support et Services » avait un charge moyenne de travail sur un an d’environ 130%, avec des pics allant jusqu’à 175%, lors de congé ou d’indisponibilité d’un des technicien du service.

I.II.

III.a.b.

i.ii.

iii.iv.v.

3.4.5.1 La problématique

Une problématique a donc été soulevée :

Comment améliorer le processus de préparation des serveurs ?

Recruter ?

Cette solution a été très vite abandonnée par mon responsable, pour cause de restrictions budgétaires. Cf. chapitre Ressources et Restrictions

Il a donc fallu se tourner vers d’autres moyens et d’analyser méthodologiquement les possibilités restant à notre disposition.

Maîtriser les ressources internes ?



Effectivement, comme constaté précédemment, on peut voir que la société à l’heure actuelle, n’optimise pas la préparation des serveurs, ce qui est une perte de temps considérable donc d’argent pour la CIEME Informatique.

Nous nous sommes donc tournés sur les possibilités d’amélioration de cette tâche.

L’automatisation de l’opération nous est donc apparue comme la solution.



3.4.5.2 Les résultats attendus

Comparativement au tableau des tâches du sous-chapitre 3.2.2, nous pouvons espérer, grâce à l’automatisation du processus de préparation machine, un gain de temps conséquent.

Voici un tableau récapitulatif des différentes tâches et du temps estimé attendu de celle-ci :

Tâche Commentaires Temps estimé Génération de la licence Option + éventuel

développement spécifique5 minutes

Sortie de stock du matériel Serveur + éventuels matériels 10 minutesPréparation du serveur et test de fonctionnement

Installation de l’OS + configuration + test

1 heure

Demande d’enlèvement Demande d’enlèvement en ligne auprès de notre transporteur

15 minutes

Total : 1 heures 30 minutes

On espère ainsi avec cette solution, diminuer de plus de moitié, le délai de préparation commande et plus précisément de diminuer de 1/3 le temps nécessaire à la préparation du serveur passant de 3 heures actuellement à 1 heure, grâce à ce procédé.



Chapitre 4 : La solution

Pour faire suite à l’analyse du service et de l’existant, nous allons maintenant pouvoir proposer différentes solutions afin de palier aux besoins de la préparation serveur. Après avoir mis en évidence plusieurs solutions, nous écarterons celles s’avérant irréalisables au vue des restrictions imposées par le projet. Nous pourrons donc présenter plus en détail la solution retenue et nous décrirons les stratégies de sécurité et de maintenance qu’il sera obligatoire de mettre en place afin que le projet respecte les obligations définies dans le cahier des charges.

4.1 L’automatisation

Comme nous l’avons évoqué dans le chapitre précédent, notre solution se porte sur l’automatisation de la préparation serveur, nous allons au préalable faire un petit rappel de l’avantage et le pourquoi nous avons retenus cette solution.

4.1.1 Les avantages de l’automatisation

L’automatisation de la préparation permet indiscutablement à la société d’améliorer ses délais de livraisons tout en maximisant l’intégration des ressources existantes.

En effet, pour optimiser la qualité logicielle, accélérer les délais de mise sur le marché et maximiser le retour sur investissement, il est indispensable de penser au-delà d’un simple outil d’automatisation et d’inscrire les préparations serveurs dans une perspective stratégique plus étendue impliquant : des investissements initiaux pour planifier un processus de développement logiciel piloté par les impératifs de qualité pour pleinement bénéficier des avantages de l’automatisation.

4.1.2 Pourquoi automatiser la préparation ?

Les préparations manuelles sont appropriées dans certains cas mais restent toujours longues, fastidieuses et en inadéquation avec la brièveté des cycles de développement actuels.L’automatisation de la préparation génère de nouveaux vecteurs d’efficacité qui accélèrent les cycles de livraison, par ailleurs, lorsqu’un grand nombre de machines doivent être préparées simultanément, la charge de la préparation manuelle croît proportionnellement en multipliant les risques d’erreurs humaines et d’incohérences susceptibles d’altérer les résultats finaux.L’automatisation de ce processus optimise la qualité logicielle et l’efficience opérationnelle, elle présente les avantages à long terme suivants :

Réemploi : L’automatisation permet à l’équipe de préparation et de déploiement de réduire les délais de livraison en réemployant des configurations machines déjà existantes sans en recréer à chaque nouvelle commande. Cette faculté de réemploi permet également à



l’équipe de préparation de constituer des bibliothèques de configuration, devenant à terme des actifs de propriété intellectuelle générateurs de valeur.

Prévisibilité et cohérence : Grâce à l’automatisation, nous pouvons vérifier rapidement que les fonctionnalités des nouvelles versions logiciel de la société sont toujours opérationnelles et dans le cas contraire, de fournir un retour immédiat à l’équipe de développement

Productivité : L’automatisation créée un environnement à haute productivité permettant à l’entreprise d’étendre sa capacité de production sans ajout de ressources. Cette organisation libère des ressources pour se focaliser sur d’autres besoins.

Ces multiples bénéfices de l’automatisation permettent à l’équipe d’évaluer très précisément les niveaux de qualité, de prendre des décisions plus pertinentes quant aux délais de livraison et de minimiser les risques de déploiement.

4.2 Panorama des solutions

Aujourd’hui, il existe sur le marché plusieurs solutions permettant d’automatiser le processus de déploiement de systèmes d’exploitation.Dans cette partie, nous allons présenter les différentes solutions avec un descriptif complet de chaque application

4.2.1 Altiris Deployment Solution de Symantec

Une solution possible pourrait être Altiris Deployment Solution de Symantec.Cette solution permet de déployer et de configurer des systèmes d’exploitation, de migrer les paramètres utilisateurs et ensuite de déployer des logiciels sur le système d’exploitation une foi celui-ci installé.

Principales fonctionnalités :

Déploiement en masse d'images indépendantes du matériel d'un système de référence vers les nouveaux systèmes et les systèmes existants à l'aide de la technologie Symantec Ghost

Configuration de chaque système d'après des critères standards, comme la fonction, le type d'utilisateur ou la localisation

Création simplifiée de tâches permettant d'automatiser les fonctions de déploiement et de migration, telles que la création d'images, l'installation de système d'exploitation basée sur script, la configuration et le déploiement de logiciels

Compatible aussi bien pour les systèmes d’exploitation 32 Bits que 64 Bits



4.2.2 Microsoft WDS

Une autre solution possible pourrait être Microsoft Windows Desktop Search (WDS), anciennement RIS (Remote Installation Services). Cette fonctionnalité serveur fournit par Microsoft permet à des ordinateurs dont le BIOS prend en charge le PXE (Preboot eXecution Environment) d’exécuter de façon distante des variables d’environnement de démarrage.


Déploiement rapide avec prise en charge de Microsoft System Management Server et le contrôle des mises à jour logiciels Windows

Gestion aisée avec prise en charge des stratégies de groupes de Windows

Boot depuis le réseau grâce à la technologie PXE

4.2.3 Scripts et Linux RedHat Kickstart

Une autre solution serait d’utiliser un utilitaire freeware très peu connu appelé Kickstart développé sous environnement Unix plus particulièrement par RedHat, mais aussi disponible sur des OS Linux ne nécessitant pas de licence comme Fedora 12 ou CentOS 5.4.Grâce à cette méthode, un administrateur système peut créer un simple fichier contenant les réponses à toutes les questions posées durant une installation normale.Les fichiers kickstart peuvent être conservés sur un simple système serveur et lus par les ordinateurs durant l’installation, ce qui en fait un outil idéal pour les administrateurs systèmes et réseau nécessitant un protocole d’automatisation. De plus, il est possible de spécifier des scripts d’automatisation pour l’installation d’un logiciel ou un paramétrage annexe du système d’exploitation.


Déploiement rapide et fiable

Possibilité de déploiement illimité avec les scripts d’automatisation

Prend en charge le boot par PXE

Compatible aussi bien pour les systèmes d’exploitation 32 Bits que 64 Bits



4.3 Ressources et restrictions

4.3.1 Ressources

Matériel :

Pour réaliser ce projet, certains serveurs sont nécessaires et doivent être accessibles depuis le réseau. Un adressage IP spécifique sera néanmoins étudié.

Liste des serveurs nécessaires :

Un serveur DHCP Un serveur TFTP Un serveur hébergeant l’application retenue

Cependant, il sera possible de faire cohabiter certains serveurs sur la même machine, ce qui requiert néanmoins un serveur suffisamment puissant. Nous y reviendrons sur la partie déploiement de la solution.

Logiciel :

Pour la partie logicielle, aucun nouvel achat n’est envisagé. Il faudra donc que la solution soit gratuite ou que la société possède déjà les licences nécessaires.

Pour la partie OS, c'est-à-dire logiciel serveur, aucun achat n’est également envisagé, la solution devra soit être installée sur un OS gratuit de type GNU ou que CIEME Informatique possède déjà des licences utilisables.

Humaines :

Pour la partie documentation et développement, je serais seul sur le projet. Mon tuteur interviendra pour la partie validation et mise en production. Cependant l’ensemble du service participera à la phase de test final.

4.3.2 Restrictions

Lors de la création du projet, certaines restrictions ont été abordées :

Recyclage du matériel : Il n’est pas envisagé d’acheter du matériel spécialement pour le projet. Il faudra donc utiliser un serveur existant.

Aucun impact sur le réseau existant : Afin d’être le moins contraignant possible, la mise en place du projet ne devra pas perturber le système de préparation actuel, ni perturber le fonctionnement des serveurs actuels.



Les mises à jour doivent être transparentes : Les mises à jour futures du projet devront elles aussi être transparentes et réalisables par une autre personne du service technique que moi-même, cela entraîne donc une bonne documentation et formation.

Pas d’achat de nouveau logiciel : Le projet devra également utiliser des logiciels gratuits ou déjà en possession de la CIEME Informatique. Aucun frais logiciel n’est à envisager.

Sécuriser l’application : Le projet devra également mettre en place un système de sauvegarde du serveur, pour palier à toutes pannes et donc de pertes de données.

Déployer des distributions Unix : Le projet devra être capable de déployer des distributions basées sur des noyaux Unix (RedHat, Fedora, CentOS…) obligatoirement et éventuellement des distributions Windows.

4.4 Contraintes du cahier des charges

Nous pouvons conclure que le cahier des charges nous impose donc les contraintes suivantes :

Un budget matériels/logiciels de O € La solution devra automatiser le déploiement La solution devra déployer des distributions Linux

4.5 La solution retenue

Au vue des restrictions mises en évidence dans la partie précédente, nous allons pouvoir écarter deux des solutions pour nous concentrer sur celles correspondant le mieux au projet.

4.5.1 Altiris Deployment Solution de Symantec

Sans doute la solution la plus complète de toute. Effectivement cette solution regroupe toutes les fonctionnalités établies par le cahier des charges. Altiris Deployment Solution propose un package « clé en main », regroupant une solution de déploiement, d’une configuration post déploiement ainsi qu’un processus de sauvegarde et de restauration grâce à la technologie de Symantec Ghost.

Cependant, cette application a un coût et nous avons vu que l’application ne devra générer aucun frais supplémentaire. Hors la société CIEME Informatique ne possède aucune licence d’Altiris Deployment Solution, cette solution n’est donc pas envisageable.



4.5.2 Microsoft WDS (Windows Desktop Search)

L’avantage de cette solution est qu’elle est très facile à déployer sur le réseau, car c’est un module à part entière de Windows Serveur 2003 R2. De plus le fait d’utiliser un outil Microsoft rend possible un support de très bonne qualité, ainsi que beaucoup de documentations sur Internet. CIEME Informatique possède également déjà des licences Windows Serveurs 2003 R2, donc il n’y a pas de licence à acheter.

Cependant le problème majeur de cette solution est que WDS ne peut déployer que des distributions Windows (Serveur 2003, 2008, XP, Vista, Seven), or nous avons vu que l’application devait obligatoirement être capable de déployer des systèmes d’exploitation Unix/Linux, cette solution n’est donc également pas envisageable.

4.5.3 Scripts et Linux RedHat Kickstart

Sans doute la solution la plus méconnue et la plus compliquée pour quelqu’un ne connaissant pas l’univers Linux. Cependant Kickstart permet d’automatiser le processus d’installation en plaçant les informations rentrées normalement au clavier dans un fichier de configuration.

Mais attendez, il y a mieux !

Une fois le processus d’installation achevé, Kickstart permet de spécifier une liste de commandes Shell ou Scripts qu’on souhaite voir exécutées. Cela signifie qu’on peut automatiquement installer des logiciels locaux qui ne font pas partie de la distribution Linux et procéder aux derniers réglages nécessaires pour rendre le nouveau système d’exploitation parfaitement opérationnel.De plus toutes les technologies utilisées sont libres et ne génèreront donc aucun frais.

Un des problèmes de cette solution vient du fait qu’elle ne peut pas déployer des distributions Windows, mais cela ne rentre pas dans les restrictions du cahier des charges et a été validé par mon responsable.

C’est donc le choix du Scripts et Linux Kickstart qui a été retenu.



4.6 Critères de choix

Voici un tableau récapitulatif des solutions proposées selon les critères de choix du cahier des charges :

Comme nous pouvons le voir sur ce tableau, on voit bien que la solution N°3 : Linux Kickstart + Scripts répond bien à tous les prérequis du cahier des charges.

C’est donc cette dernière solution que nous avons retenue.

4.7 Procédure de sauvegarde

N’ayant pas eu de budget pour mettre en place une solution de sauvegarde appropriée, j’ai pris notamment l’initiative de mettre en place une procédure simplifiée de sauvegarde sur le serveur.Il s’agit d’un script qui exécute une requête ftp, qui sauvegarde le répertoire ou se trouve les fichiers de configuration et l’envoi sur un serveur dédié. En effet, les scripts de configuration sont ce qu’il y a de plus importants, car ils constituent le cœur du projet. Cette sauvegarde s’effectue tous les soirs à 23h00.

Le détail du script se trouve en annexe.



4.8 Le choix du serveur

Une contrainte du projet est qu’il n’y a pas eu de fonds débloqués pour l’achat d’un nouveau serveur.Il a donc fallu que je fasse un inventaire du parc existant pour savoir quelles machines je pourrais utiliser pour la réalisation de celui-ci.

Tous les serveurs disponibles étaient soit HS soit trop obsolètes pour pouvoir être utilisés en production.

Heureusement, nous avons eu beaucoup de chance, car DELL nous a fourni un serveur rackable PowerEdge R310, car nous avions réalisé la 500ième commande de serveurs auprès de DELL et c’est un gage de remerciement de notre fidélité.

Voici les caractéristiques du serveur PowerEdge R310 :

Fonctionnalité Serveur Dell PowerEdge R310

CPU Processeurs Quadcore Intel Xeon 3400

Mémoire 4 Go

Disque Dur 2 disques durs SAS de 146 Go

Contrôleur RAID Adaptateur de bus hôte de 6 Gbit/s

Cartes d’interface réseau

Carte Intel Gigabit ET 2 ports

Ce serveur est bien plus que suffisant pour la réalisation du projet.

Il nous permet également de rajouter une sécurité sur la sauvegarde des données du fait de son contrôleur RAID et ses 2 disques durs que nous montrons en RAID 1.

NB : Un descriptif complet du serveur Dell R310 se trouve en annexe

4.8 Les aspects fonctionnels

Nous pouvons donc espérer grâce à cette solution d’automatisation, obtenir les aspects fonctionnels suivants :

Amélioration du délai de préparation commande Amélioration de la qualité du livrable Soulager le personnel de cette tâche Améliorer le ROI



Chapitre 5 : Le projet

A présent que les grandes lignes du projet sont définies, nous allons nous lancer dans la réalisation technique de celui-ci.

Nous commencerons par l’organisation du projet. Il sera découpé en sous-parties qui seront ensuite placées dans un diagramme de GANTT. Nous pourrons donc voir de cette façon la répartition des tâches et des ressources dans le temps. Nous verrons également les différentes technologies utilisées pour la réalisation de celui-ci et leur mise en œuvre.

5.1 Technologies utilisées

Pour la bonne réalisation de ce projet plusieurs technologies et protocoles réseaux ont dus être utilisés et mise en place, nous commencerons par lister ces protocoles, puis nous les décrirons et expliquerons leur principe de fonctionnement.

Les protocoles et services utilisés sont les suivants :

Le protocole PXE (Preboot eXecution Environment) Le protocole DHCP (Dynamic Host Configuration Protocol) Le protocole TFTP (Trivial File Transfert Protocol) Le protocole HTTP Le service Kickstart Les fichiers PXELinux

5.1.1 Le protocole PXE

PXE est l’acronyme de Preboot eXecution Environment, c’est l’élément clé sur lequel repose tout notre projet.

PXE est donc un environnement regroupant plusieurs services/protocoles qui permet à une station de démarrer depuis le réseau en récupérant une image de système d’exploitation qui se trouve sur un serveur.

L’image ainsi récupérée peut-être le système d’exploitation brut ou bien le système d’exploitation personnalisé avec des composantes logicielles (suite bureautique, utilitaires, scripts, etc.…)



Une fois cette image « pré-chargée », elle peut éventuellement, en fonction des paramètres passés, être installée sur la machine qui a booté en PXE.

Ce protocole permet également d’installer de manière automatique et à distance des serveurs sous divers OS.

Pour activer le PXE, il faut auparavant le configurer dans le BIOS si celui-ci le permet. L’option se trouve fréquemment dans un menu concernant la carte réseau. Aujourd’hui, toutes les cartes réseaux supportent ce protocole et sont déjà activées par défaut pour accepter ce mode démarrage.

5.1.2 Le protocole DHCP

DHCP (Dynamic Host Configuration Protocol) est un protocole réseau permettant à la base de configurer automatiquement les paramètres IP du client, c'est-à-dire l’adresse IP du client, le masque de sous réseau, la passerelle par défaut et le ou les DNS.

Cela se déroule en 4 étapes :

1) DHCPDISCOVER qui permet au client de découvrir les serveurs DHCP disponibles sur le réseau et demander une première configuration.

2) DHCPOFFER qui est la réponse du serveur, contenant les premiers paramètres.

3) DHCP REQUEST pour confirmer la demande d’attribution.

4) DHCPACK est la réponse finale du serveur, elle contient l’ensemble des paramètres IP et autres du client.

Schéma de fonctionnement DHCP :



DHCP va être aussi utile pour indiquer au client le nom du fichier et l’adresse du serveur TFTP sur lequel télécharger le fichier de configuration une fois le paramétrage terminé.

5.1.3 Le protocole TFTP

TFTP est l’acronyme de Trivial File Transfer Protocol, c’est un protocole simplifié de transfert de fichiers.

Il fonctionne en UDP sur le port 69, au contraire du FTP qui utilise lui TCP. L’utilisation d’UDP, protocole «non fiable », implique que le client et le serveur doivent gérer eux-mêmes une éventuelle perte de paquets. En termes de rapidité, l’absence de fenêtrage nuit à l’efficacité du protocole sur les liens à forte latence. On réserve donc généralement l’usage du TFTP à un réseau local.

Les principales simplifications visibles du TFTP par rapport au FTP est qu'il ne gère pas le listage de fichiers, et ne dispose pas de mécanismes d'authentification, ni de chiffrement. Il faut connaître à l'avance le nom du fichier que l'on veut récupérer. De même, aucune notion de droits de lecture/écriture n'est disponible en standard.

À cause de ces fonctionnalités absentes, FTP lui est généralement préféré. TFTP reste très utilisé pour la mise à jour des logiciels embarqués sur les équipements réseaux (routeurs, pare-feu, etc.) ou pour démarrer un PC à partir d'une carte réseau.

Schéma de fonctionnement TFTP :



5.1.4 Le protocole HTTP

HTTP est l’abréviation de HyperText Transfert Protocol, c’est un protocole de communication client-serveur développé pour le World Wide Web (www).

HTTP est un protocole de la couche application. Il peut fonctionner sur n'importe quelle connexion fiable, dans les faits on utilise le protocole TCP comme couche de transport. Un serveur HTTP utilise alors par défaut le port 80.

Les clients HTTP les plus connus sont les navigateurs Web permettant à un utilisateur d'accéder à un serveur contenant les données.

Ces clients se connectent à des serveurs http tels qu’Apache ou IIS.

Ce protocole sera nécessaire pour l’hébergement des images des OS à déployer, car elles devront être accessibles en HTML.

5.1.5 Le service Kickstart

Le service Kickstart est un utilitaire développé par Red Hat Network pour son système d’exploitation Red Hat 5.0 Entreprise. Ce service a ensuite été reconduit sur les distributions Freeware comme Fedora 12 et CentOS 5.0.

Lorsqu’une machine doit recevoir un fichier kickstart basé sur le réseau, les événements suivants se produisent dans cet ordre :

1) Après avoir été placé sur le réseau et allumé, le PXE logique de la machine diffuse son adresse MAC et une requête à être découverte.

2) Si une adresse IP statique n'est pas utilisée, le serveur DHCP reconnaît la requête de découverte et propose une offre d'information réseau nécessaire pour que la nouvelle machine démarre. Celles-ci incluent une adresse IP, la passerelle par défaut à utiliser, le masque réseau du réseau, l'adresse IP du serveur TFTP ou HTTP contenant le programme de chargeur de démarrage et le chemin et le nom de fichier de ce programme (associé au super utilisateur du serveur).

3) La machine applique les informations de réseau et lance une session avec le serveur pour demander le programme de chargeur de démarrage.

4) Le chargeur de démarrage, une fois chargé, recherche son fichier de configuration sur le serveur depuis lequel il a été chargé. Ce fichier indique le noyau et les options de noyau, comme l'image de disque RAM initial (initrd), qui devraient être exécutés sur la machine qui démarre. En supposant que le programme de chargeur de démarrage est SYSLINUX, ce fichier se trouve dans le répertoire pxelinux.cfg sur le serveur.

5) La machine accepte et décompresse l'image init et le noyau, lance le noyau et commence une installation kickstart avec les options fournies dans le fichier de configuration du



chargeur de démarrage, y compris le serveur contenant le fichier de configuration de kickstart.

6) Le fichier de configuration de kickstart dirige ensuite la machine vers l'emplacement des fichiers d'installation.

7) La nouvelle machine est construite selon les paramètres établis dans le fichier de configuration de kickstart.

5.1.6 Les fichiers PXELinux

Les fichiers de configuration de PXELinux sont dans le pxelinux.cfg. Chaque client peut avoir son fichier de configuration. Par défaut, PXELinux cherche un fichier de configuration ayant comme nom l'adresse mac du client, son adresse IP, des bouts de son adresse IP ou autre (PXELinux les essaie dans cet ordre et charge le premier qu'il trouve).

5.2 Configuration des serveurs

Après avoir présenté et décrit les protocoles utilisés, nous évoquerons dans cette partie la phase de configuration des différents serveurs, les différentes interactions existantes entre eux ainsi que le mode de fonctionnement de notre solution.

5.2.1 Schéma de fonctionnement

Pour commencer, et afin de mieux comprendre le fonctionnement de notre architecture, je vous propose le schéma fonctionnel de notre architecture :



5.2.2 Principe de fonctionnement

Le schéma suivant est tiré de la doc de clic.mandrakesoft.com illustre le processus de fonctionnement :



5.2.3 Configuration du serveur DHCP

Le serveur DHCP occupe un rôle primordial pour notre projet, il a pour rôle de :

Définir les adresses IP des clients PXE Fournir aux clients PXE le nom du système d'exploitation à charger par le réseau.

Je n’ai pas eu besoin de mettre en place un serveur DHCP, car il y en avait déjà un présent sur le réseau de la CIEME Informatique.

Cependant, certaines modifications sont nécessaires et doivent être configurées sur le serveur DHCP.Voici les options à déclarer sur le serveur DHCP :

Le nom d’hôte du serveur TFTP Le nom du fichier de démarrage

CIEME Informatique possède un serveur DHCP sous Windows Server 2003 R2, ces options correspondent aux options 66 et 67 du DHCP Windows.

Configuration du DHCP :

Nous pouvons constater que nous avons renseignés pour l’option 66, l’adresse IP du serveur TFTP et pour le l’option 67, l’emplacement du fichier de configuration.



5.2.4 Configuration du serveur TFTP

Tout d’abord nous avons du installer un système d’exploitation répondant aux prérequis de notre projet.Nous sommes partis sur un Linux CentOS 5.4, car tout d’abord, cet OS est totalement gratuit et disponible légalement en téléchargement sur Internet. C’est également une distribution orientée pour l’utilisation entreprise, elle est donc fiable et reconnue. De plus, CentOS est la version gratuite de RedHat Entreprise, et c’est une distribution que je maîtrise très bien pour avoir réalisé différents projets sur celle-ci.

Nous attribuerons l’adresse IP : 192.168.0.240/24 et nous l’appellerons srv-pxe.

Passons maintenant à la phase de configuration du serveur TFTP.

Pour installer le serveur TFTP, il faut lancer la commande suivante :

Ce dernier est lancé via xinetd.d. On peut donc voir la configuration via la commande suivante :

Il faut supprimer ou commenter cette ligne, aussi non le serveur ne pourra pas se lancer :

Pour installer le système d’amorçage PXELinux, on lancera la commande suivante :

Ceci s'occupera d'aller installer le fichier linux-install/pxelinux.0 dans le dossier du serveur, à savoir /tftpboot. Ce dernier sert aux cartes réseaux pour réaliser leur boot PXE, mais aussi pour afficher un menu permettant de choisir la distribution linux que l'on veut installer, quand le serveur en propose plusieurs.

Il ne reste plus qu’a redémarrer le serveur TFTP :

Voilà le serveur TFTP est maintenant configuré.


yum install tftp tftp-server

more /etc/xinetd.d/tftp

disable = yes

yum install system-config-netboot

/etc/init.d/xinetd restart


5.2.5 Configuration du serveur Apache

Nous installerons notre serveur apache sur le serveur srv-pxe du service technique, c’est la machine dédiée à la réalisation de ce projet.

Le serveur Apache est nécessaire pour le bon processus d’automatisation du déploiement pour que notamment les images des OS ainsi que les fichiers de configuration puissent être accessible en HTML sur le réseau.

Pour installer le serveur Apache, il faut lancer la commande suivante :

Il ne reste plus qu’à taper la commande suivante pour le démarrer :

Comme énoncé précédemment, le serveur Apache a 2 rôles :

Héberger les fichiers des Images des OS Héberger les fichiers de configurations

Une fois le serveur apache configuré, le répertoire de stockage accessible en HTML se trouve à l’emplacement /var/www/html

Ceci est le répertoire racine de notre serveur html, là où les fichiers de configuration et les images des distributions seront mis en ligne.

Cependant pour une meilleure organisation du projet, j’ai décidé de créer d’autres dossiers depuis ce répertoire racine.

Un répertoire parent que nous appellerons pxe dans :/var/www/html/pxe

Un sous-répertoire pour les fichiers de configuration que l’on appellera ks dans :/var/www/html/pxe/ks

Un autre sous-répertoire pour pouvoir monter les images iso des différentes distributions à installer que l’on appellera OS dans :/var/www/html/pxe/os

Dans le sous-répertoire OS, nous créerons également un répertoire unique pour chaque distribution, c’est depuis ces répertoires que seront accessibles les différents systèmes d’exploitation en html.


yum install httpd

service httpd start


5.2.5.1 Schéma de l’arborescence du serveur Apache

Maintenant que nous avons configuré notre serveur apache, il ne reste plus qu’a mettre en place nos fichiers de configuration et nos images des systèmes d’exploitation à déployer.

5.2.6 Le service kickstart

Le service kickstart est l’élément clé du projet, ce petit utilitaire Linux, permet de configurer et automatiser les processus de déploiement et d’installation.

Les fichiers kickstart sont de petits fichiers textes dans lesquels sont inscrites toutes les options d’installation. Si les fichiers ne sont pas présents ou n’existent pas, l’installation par le réseau fonctionnera quand même mais le serveur vous posera des questions pour son installation. Il n’y a donc aucun intérêt à ne pas en créer.

Nous allons tout d’abord installer ce service, il suffit de lancer la commande suivante :

Il existe un utilitaire graphique de ce type de fichier que l’on peut lancer comme ceci :


yum install system-config-kickstart

system-config-kickstart


La fenêtre suivante devrait s’afficher :

Maintenant il n’y a plus qu’à choisir les paramètres que l’on souhaite pour l’installation de la distribution. Il faut savoir que chaque paramètre qui n’est pas renseigné sera demandé à l’installation.Cela peut s’avérer pratique notamment si l’on souhaite un partitionnement différent pour certains serveurs.

L’utilitaire va ensuite nous proposer de sauvegarder un fichier nommé ks.cfg, c’est le fichier de configuration de la distribution, ainsi si on l’a configuré pour un système Linux RedHat 5.3 Entreprise, on pourra le nommer par exemple ksRH53.cfg, comme çà il n’y aura pas d’ambigüité si l’on doit créer un fichier de configuration pour plusieurs distributions différentes.

Il faut le mettre à un emplacement accessible par le serveur HTML.

Comme vu précédemment dans l’arborescence, nous allons le placer dans le répertoire que nous avons créé spécialement pour les fichiers de configurations, c'est-à-dire à l’emplacement suivant :

/var/www/html/pxe/ks

Maintenant que les fichiers de configuration sont créés, il ne reste plus qu’à déclarer les fichiers de boot PXELinux pour que l’installation de notre solution soit fonctionnelle.



5.2.7 Les fichiers PXELinux

L’utilitaire PXELinux permet de renseigner aux machines bootant en PXE, l’emplacement des fichiers de configuration, mais également l’emplacement des images des distributions à déployer.

Il faut tout d’abord lancer la commande suivante pour ouvrir l’utilitaire graphique du boot PXE :

La fenêtre suivante devrait s’afficher :

Nous voyons que nous devons renseigner :

Un nom pour l’installation La méthode d’installation L’emplacement du fichier kickstart L’adresse IP du serveur TFTP L’emplacement des paquets sur le serveur Apache

Au préalable, nous devons « monter » l’image ISO de la distribution à installer à l’emplacement prévu, comme vu dans l’arborescence du serveur Apache, c'est-à-dire dans le répertoire :

/var/www/html/pxe/OS/RH53


system-config-netboot


Nous le faisons avec la commande suivante :

Voilà le projet est maintenant opérationnel, il ne reste plus qu’à tester le fonctionnement en effectuant un boot réseau (généralement la touche F12 au démarrage) sur une machine cliente.

5.3 Les scripts Post Installation

Les scripts d’automatisation de la configuration et d’installation du logiciel de CIEME Informatique, Infoserv se trouvent en annexe.

NB : J’ai jugé bon de ne mettre qu’un seul script en annexe, en l’occurrence celui de la distribution Linux Red Hat 5.3 Entreprise 32 Bits, car les scripts ne diffèrent que très peu suivant les distributions.


mount –t iso9660 /home/iso/rhel-server-5.3-i386-dvd.iso /var/www/html/pxe/OS/RH53 –o loop


5.4 Organisation

5.4.1 Listes des tâches

Analyse :

Analyse du besoin Analyse de l’existant Rédaction du cahier des charges Validation du cahier des charges Go Nogo Création des documents de spécification

Configuration :

Recherche de la solution Validation de la solution Recherche du matériel Mise en place des différents protocoles utilisés Configuration des serveurs Création des scripts d’automatisation

Finalisation :

Tests unitaires Déploiement des distributions Tests fonctionnels Création de la procédure de fonctionnement Formation utilisateur Mise en production



5.4.2 Répartition des tâches

Nous pouvons voir que le projet a été réalisé sur 35 jours entre le lundi 23/11/2009 et la mise en production le 08/01/2010.

Nous avons effectué ce projet dans les temps car il devait être opérationnel début janvier 2010.Les congés de fin d’année et de noël nous ont bien aidés, car cette période est généralement plus calme. Nous avons donc pu nous concentrer pleinement sur la réalisation de ce projet.



5.4.3 Gantt



5.5 Les livrables

Il sera mis à la disposition du service technique :

L’installation et la configuration des différents serveurs avec la documentation associée

Les scripts d’automatisation de l’installation ainsi que les différents scripts annexes (sauvegarde…) avec la documentation associée

Le processus pour pouvoir booter d’un poste client en PXE

Une documentation explicative de l’utilisation de la plateforme de déploiement :- Création de comptes utilisateurs- Ajout et modification de distribution- Création et modification des fichiers Kickstart- Interopérabilité du serveur sur le réseau- Paramétrage de sécurité

Les scénarios de tests et les cahiers de tests de base ou recettes

NB : Un exemple de fiche de recette se trouve en annexe



5.6 Documentation UML

5.6.1 Diagramme de fonctionnement

Ce diagramme de séquence nous présente les phases de fonctionnement du serveur PXE.



5.6.2 Diagramme de déploiement.

On peut voir sur ce schéma simplifié les différentes interactions qui existent entre les différentes machines.



5.7 La maintenance

La maintenance est un des critères primordiaux pour la validité et la pérennité du projet dans le temps.

Effectivement, si le projet s’avère défectueux pour diverces raisons et que personne n’est en mesure d’y remédier, alors celui-ci n’aura apporté aucunes innovations ou solutions pour la société.

Le but de la maintenance est de maintenir ou rétablir le système afin que celui-ci soit en mesure d’assurer le service qu’il lui est déterminé.

J’ai donc été chargé dans un premier temps de la maintenance de notre solution, car je l’avais réalisé.

Cependant j’ai du faire un transfert de compétences à plusieurs techniciens du « service et support » de la CIEME Informatique, afin que ceux-ci puissent être capable de maintenir également le système.

5.7.1 Le transfert de compétences

Au jour d’aujourd’hui, sur les cinq techniciens informatiques de la CIEME, quatre ont reçus une formation et les documentations nécessaires au bon fonctionnement du système.

Ce transfert de compétences s’est réalisé en plusieurs étapes :

Rédaction des documentations Présentation de la solution Principe de fonctionnement Simulations de pannes

Nous avons effectué les formations sur des après midi de fin de semaines (jeudi ou vendredi), réparties sur le mois de février.

NB : Les formations n’apparaissent pas sur le diagramme de Gantt en 5.4.3

5.7.2 Aspects fonctionnels de la Maintenance

La maintenance du système s’axe sur plusieurs critères, à la fin de la formation, un technicien doit :

Etre capable de prévenir une éventuelle panne du système Etre capable de réparer et remettre en fonctionnement le système Etre capable de participer à des études d’amélioration du processus industriel (Mise en place

d’une nouvelle distribution…)

NB : Un exemple de fiche de formation se trouve en annexe



5.8 Les difficultés rencontrées

Au cours de ce projet nous avons rencontré plusieurs difficultés, concernant le matériel et les ressources disponibles.

Le budget fut la première difficulté à affronter. Nous n’avons pas eu les fonds nécessaires pour la réalisation de ce projet, il a donc fallu se tourner vers des technologies du monde libre. Un monde où les documentations sont souvent abondante, mais non réalisable dans le monde de l’entreprise car ne répondent pas aux critères de sécurité. De plus, il a fallu trouver les machines nécessaires à la mise en place de celui-ci parmi le parc existant de la CIEME Informatique.

Une deuxième difficulté a été les ressources disponibles, car il fallait continuer la production actuelle, je devais donc assurer mon rôle de support technique au client, tout en travaillant en parallèle sur la réalisation du projet.

Les autres difficultés étaient plus du niveau technique et surtout au niveau de la réalisation des scripts d’automatisation.

Nous avons pu malgré tout terminer le projet à temps.

Liste des difficultés principales rencontrées :

Budget Ressources disponibles Configuration matérielles (Scripts….)



5.9 La mise en production (MeP)

Dans ce chapitre, nous verrons comment la mise en production (MeP) s’est déroulée, à savoir quels ont été les événements qui n’ont pas été prévu ou même les erreurs qu’ont pu être effectuées lors de la création du projet.

La mise en production a eu lieu le vendredi 8 janvier 2010 à 14h, mais les premières nécessités de son utilisation ont eu lieu le lundi 11/01/2010 au matin, lors de la réception des premières commandes client de la part du service commercial.(Cf. acheminement d’une commande en 3.4.1)

5.9.1 Prérequis

Il avait été formulé lors de la réunion pour l’aval de la MeP du projet que les utilisateurs du système devaient fournir un retour sur les éventuels besoins ou contraintes qu’ils avaient remarqué.

Ces informations devront être remontées à Christopher LEY.

Un fichier ressource, accessible sur le partage de Christopher LEY, a été mis à disposition des utilisateurs.

Il se présente sous forme de tableau avec les champs suivants :

Date de remontée (DR) Anomalies/Besoins (A/B) Techniciens ayant remonté l’information (TI) Commentaires (C) Correctifs appliqués (CA) Date de correction (DC)

NB: Les éléments entre parenthèses correspondent à l’alias où au code de l’intitulé du champ du tableau



5.9.2 Tableau des anomalies après MeP ou VABE (Validation à la Bonne Exploitation)

DR A/B TI C CA DC11/01/2010 Erreurs client PXE :

impossible de trouver l’image de la distribution

Mickael Chevalier Lors du redémarrage du serveur PXE, les images Iso

des OS ne sont pas remontées

automatiquement

Ligne rajouté sur le serveur srv-pxe dans

/etc/rc.d/rc.local :Mount –t –iso –o loop

11/01/2010 par Christopher LEY

15/01/2010 Perte du lien FTP pour récupérer le logiciel Infoserv à déployer

Julien Demoly Impossible de récupérer le logiciel Infoserv

Création d’un répertoire sur srv-pxe pour stockage en local

du logiciel Infoserv


26/01/2010 Coupure de courant généralisée : le

serveur est HS

Julien Vaghi Installation client PXE à refaire, car crash électrique

Mise en place du srv-pxe sur l’onduleur de la

baie du service

26/01/2010 par Julien Demoly

04/02/2010 Nouvelle version du logiciel Infoserv 2.4-V5-

008 à déployer

Christopher LEY Ancienne version du logiciel, Mise à Jour de version

d’Infoserv

Copie des nouveaux fichiers d’installation

d’Infoserv dans le répertoire de stockage


Légende :

- DR : Date de Remontée - A/B : Anomalies/Besoins - TI : Technicien ayant remonté l’information- C : Commentaires - CA : Correctifs appliqués - DC : Date de correction

NB : Ce tableau de bord et de suivi du projet est toujours en place aujourd’hui, ceci est un extrait du 1er moi après MeP.Cela permet d’avoir un historique des interventions réalisées sur celui-ci



Chapitre 6 : Résultat final

Cette partie sera la présentation finale du projet. Nous verrons ici le projet après sa mise en production en présentant son fonctionnement. Nous nous pencherons également sur le comportement du système d’un point de vue technique. Nous analyserons ensuite l’impact sur le service et si son comportement est conforme aux attentes.

Nous finirons par les différents retours utilisateurs ainsi que les différentes remarques et demandes.

6.1 Aperçu du projet

Dans ce sous-chapitre sera présenté le fonctionnement du serveur de déploiement d’un point de vue utilisateur.

6.1.1 « Booter » en réseau

Pour « booter » en réseau, il faut généralement appuyer sur la touche F12 au démarrage du BIOS :

Une fois « booté » en réseau, le client PXE, se met à la recherche du serveur TFTP :

Le serveur DHCP lui attribue une adresse IP et lui renseigne l’adresse IP du serveur TFTP.



6.1.2 Choix de la distribution

Le serveur TFTP nous renseigne les distributions possibles à installer, c'est-à-dire qui sont déjà configurées sur le serveur de déploiement :

Ici, nous voyons que le serveur héberge neuf systèmes d’exploitation préconfigurés, le technicien n’a plus qu’à sélectionner la distribution qu’il souhaite installer en fonction de ses besoins.C’est la dernière étape manuelle de l’installation.

6.1.3 Récupération de l’image et installation

Le client PXE récupère l’image et le fichier de configuration et procède à l’installation suivant les prérequis :



Paramétrages des prérequis (Partitionnement, mot de passe Root…) :

Installation des packages :



On peut voir que le temps d’installation est d’environ 10 minutes, tandis qu’il est d’environ 45 minutes lors d’une installation manuelle.



6.1.4 Exécution des scripts Post-Installation

Une fois l’installation de la distribution terminée, le fichier kickstart exécute les scripts de post installation pour que la configuration soit optimale et ne nécessite aucunes interventions humaines :

NB : Un script d’installation se trouve en annexe



6.2 L’impact du système sur le service technique

Le déploiement automatisé a permis de maîtriser au mieux les ressources du service « services et support » de la CIEME Informatique, car d’une part, il permet de :

Améliorer le temps de préparation d’une commande Libérer un technicien Supprimer les erreurs humaines lors du déploiement Améliorer le ROI de la Société à moindre coût Améliorer la productivité

6.3 Le retour utilisateur

Le retour utilisateur a été très important lors de la mise en place de ce projet. Le fait d’avoir une équipe pour l’utiliser quotidiennement a permis de très vite remonter des anomalies ou des besoins supplémentaires.

Une des premières remarques à être signalée, a été le nombre de distributions à déployer.Effectivement, lors de la mise en production, le système ne pouvait déployer que 3 distributions en 32 Bits, il nous a été demandé s’il était possible d’incorporer des distributions 64 Bits pour des systèmes plus puissants.

Avis général

Nous nous sommes aperçu que l’avis général sur ce projet était très positif. Les techniciens utilisateurs du produit avaient plus de temps libre et étaient donc plus décontractés car cela leur enlevait une lourde tâche de préparation quotidienne.

De plus nous avons eu un retour très positif de notre principale intégrateur France Télécom qui nous a souligné le fait que le délais de livraison de leurs commandes s’était très nettement amélioré par rapport au 1er trimestre 2009.



6.4 Les attentes ont-elles bien été respectées ?

Il m’avait été demandé de trouver un moyen d’amélioration des ressources du service technique, le service était au bord de la rupture car surchargé de travail.

Il nous a fallu dans un premier temps étudier ce qui était possible d’améliorer et quelles tâches étaient les plus contraignantes. Nous nous sommes tournés très rapidement sur le système de préparation des commandes et notamment la préparation serveur.

Après recherche l’automatisation du système de préparation, nous est apparue comme la réponse à notre besoin.

Voyons maintenant si les attentes ont bien été respectées :

Attentes ValidéesAméliorer les ressources oui

Améliorer le temps de préparation ouiAméliorer le délai de livraison oui

Minimiser les erreurs humaines ouiDiminuer la contrainte du technicien oui

Automatisation Linux ouiAutomatisation Windows non

La réalisation du projet est terminée. Nous avons pu voir que celui-ci était fonctionnel etque son comportement respectait nos attentes. Nous avons également pu voir les différentsretours utilisateurs qui nous ont permis de nous faire une idée de l’impact de ce projet dansle service. Nous clôturerons donc ce mémoire par une évaluation des gains apportés par ceprojet.



Chapitre 7 : Conclusion

Pour conclure, nous allons évaluer les gains que ce projet a apporté à l’entreprise. Nous verrons si le projet a réussi ou non sa mission d’améliorer le processus de préparation commande et si cela a permis un gain de productivité pour l’entreprise. Nous verrons ensuite ce que m’a apporté ce projet sur un plan personnel, tant au niveau technique, qu’au niveau de la gestion d’un projet et d’une équipe.

7.1 Le gain pour l’entreprise

Nous avons pu voir dans les différentes parties que le projet avait été un réel plus pour l’entreprise. Il a pu apporter un outil pratique, simple à utiliser et rapide pour le déploiement à grande échelle de serveurs. Il a pu également améliorer grandement la productivité de la société, le temps de préparation en est ainsi divisé par trois. Nous avons vu également que grâce à ce procédé, le personnel de l’équipe technique est beaucoup sollicité pour la préparation serveur, une tâche nécessitant énormément de temps pour peu de retour sur investissement, qui est donc plus productif et améliore ainsi la position de CIEME Informatique sur son marché.

7.2 Le gain personnel

Sur le plan personnel, ce projet a été très formateur. Il m’a permis de me lancer dans la conduite de projet et de voir les difficultés de cet exercice. J’ai pu m’apercevoir qu’il est très compliqué de tenir un planning et que si on ne prévoit aucune marge de glissement, un projet peut facilement dépasser les délais. Ce projet m’a également permis de travailler en équipe car la partie test et validation des différents jalons du projet étaient délégués aux personnes du service. J’ai donc pu me rendre compte que la conduite de projet ne se résume pas à créer un planning et à donner des ordres. Il m’a fallu tenir compte de la dimension humaine car une personne n’exécutera jamais les ordres comme une machine. Il faut donc réussir à travailler avec les sensibilités de chacun tout en réussissant à faire passer les directives souhaitées.



Chapitre 8 : Annexes

8.1 Glossaire

GFT : Gestion Financière des Télécoms CDR : Charging Data Record ROI : Return On Investment, Retour sur Investissement CA : Chiffre d’Affaire SAV : Service Après Vente DHCP : Dynamic Host Configuration Protocol TFTP : Trivial File Transfert Protocol PXE : Preboot eXecution Environment UML : Unified Modeling Language MeP : Mise en Production VABE : Validation à la Bonne Exploitation



8.2 Scripts d’automatisation Linux Red Hat 5.3 (32 Bits)


#platform=x86, AMD64, ou Intel EM64T# System authorization informationauth --useshadow --enablemd5 # System bootloader configurationbootloader --location=mbr# Partition clearing informationclearpart --all --initlabel # Use graphical installtext# Firewall configurationfirewall --disabled# Run the Setup Agent on first bootfirstboot --disable# System keyboardkeyboard fr-latin1# System language //choix de langue du systèmelang fr_FR# Installation logging levellogging --level=info# Use network installationurl --url=http://192.168.0.237/pxe/RH53# Reboot after installationreboot#Root passwordrootpw --iscrypted $1$zRX7OUW9$KcyZeLHMLpnA7/jpV/pRo0

# SELinux configuration //désactivation du Pare-feu Linuxselinux --disabled# System timezonetimezone Europe/Paris# Install OS instead of upgradeinstall# X Window System configuration information //partitionnementxconfig --defaultdesktop=GNOME --depth=32 --resolution=800x600# Disk partitioning informationpart /boot --bytes-per-inode=4096 --fstype="ext3" --size=400part / --bytes-per-inode=4096 --fstype="ext3" --size=15000part /var --bytes-per-inode=4096 --fstype="ext3" --size=15000part /tmp --bytes-per-inode=4096 --fstype="ext3" --size=10000part swap --bytes-per-inode=4096 --fstype="swap" --recommendedpart /home --bytes-per-inode=4096 --fstype="ext3" --grow --size=1

%packages //Packages sélectionnés pour l’installation@server-cfg@base-x@gnome-desktop@development-libs@base@admin-tools@legacy-software-development@office


Suite du script d’automatisation


@office@sound-and-video@web-server@development-tools@legacy-network-server@legacy-software-support@printing@system-tools@editors@dialup@graphical-internet@text-internet@graphics@authoring-and-publishing@network-server@java@ftp-server

#Post Install

%postmkdir /installcd /installftp -n -i 192.168.0.237 << !user toor databinarycd /home/packages/RH53mget *quit!

#Installation des Packages necessaires a Infoserv

rpm -Uvh aspell-fr-0.50-9.2.2.i386.rpm rpm -Uvh Deployment_Guide-fr-FR-5.2-11.noarch.rpmrpm -Uvh libpng10-1.0.37-1.fc8.i386.rpmrpm -Uvh man-pages-fr-2.39-4.fc6.noarch.rpmrpm -Uvh ncompress-4.2.4-47.i386.rpm rpm -Uvh ncurses4-5.0-11.i386.rpmrpm -Uvh telnet-server-0.17-39.el5.i386.rpmrpm -Uvh sharutils-4.6.1-2.i386.rpmrpm -Uvh dialog-1.0.20051107-1.2.2.i386.rpm rpm -Uvh uucp-1.07-12.i386.rpm


Suite du script d’automatisation


#Modification des fichiers de config

mv /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.oldcp httpd.conf /etc/httpd/conf/mv /etc/sysconfig/i18n /etc/sysconfig/i18n.oldcp i18n /etc/sysconfig/mv /etc/inittab /etc/inittab.oldcp inittab /etc/mv /etc/rc.d/rc.local /etc/rc.d/rc.local.oldcp rc.local /etc/rc.d/chmod +x /etc/rc.d/rc.local

#Creation du lien logique

ln -s /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so /usr/lib/libstdc++-libc6.1-1.so.2

#Desactivation dans ntsysv //désactivation des modules

chkconfig --level 3 ip6tables offchkconfig --level 3 iptables offchkconfig --level 3 sendmail off

#Activation dans ntsysv //Activation des modules

chkconfig --level 3 httpd onchkconfig --level 3 vsftpd onchkconfig --level 3 telnet on

#Infoserv //récupération et copie des fichiers d’Infoserv

mkdir /install/infoservcd /install/infoservftp -n -i 192.168.0.237 << !user toor cieme-ftpbinarycd /home/Iso/infoservmget *quit!chmod 775 INSTALL*

#Installation d’Infoserv //installation d’infoservcd /install/infoservsh INSTALL


8.3 Scripts de Sauvegarde


#Configuration du script#ServeurserveurFTP=192.168.0.100#Port du serveurserveurFTPPort="21"#UtilisateurserveurFTPUser="backup" #Mot de PasseserveurFTPPass="******"#dossier de destination sur le serveur FTP. Attention il doit exister!serveurFTPDossier="sauvegarde/"#Nom de l'archive, n'oublier pas de mettre les extensions ".tar.gz"fichierSortie="Sauvegarde.tar.gz"

#Test de l'existence du dossier passé en argumentif [ "$1" = "" ] ; thenecho Veuillez indiquer le nom du dossier à sauvegarder en argument.echo Usage : $0 NomFichierexit 1fi#Test de l'existence du dossierif [ -e $1 ] ; then#Le code au cas ou le chemin est bonelseecho "Le dossier '$1' n'existe pas"exit 1fin

echo Script de Sauvegarde FTPif [ -e $fichierSortie ] ; thenecho "Suppresion de l'ancienne Archive!"rm $fichierSortiefiecho Compression du dossier : $1tar -czf $fichierSortie $1echo Envoi du fichier sur le serveur FTP : $serveurFTPftp -i -n $serveurFTP $serveurFTPPort <<END_SCRIPTquote USER $serveurFTPUserquote PASS $serveurFTPPasspwdcd $serveurFTPDossierbinaryput $fichierSortiepwd


Suite Script sauvegarde


pwdquit

END_SCRIPTecho "Fin de l'envoi sur le serveur"echo Suppression du fichier de sauvegarderm $fichierSortieecho "Fin de la sauvegarde !"


8.4 Fiche de Formation



8.5 Caractéristiques Dell PoxerEdge R310



Suite Caractéristiques Dell PoxerEdge R310



8.6 Exemple de fiche de test ou PV de Recette


mémoire de fin d’études - oliviermo75.free.froliviermo75.free.fr/cley_fin_cycle.docx · web...

Documents