rapport de stage 1 - cruz fabien

57
1 Rapport de stage PFMP N°1 NOM : CRUZ Prénom : Fabien Etablissement : Lycée Jean Monet Classe : S.E.N Année : 1 er Durée : Du 28/05/2012 au 05/07/2012 Entreprise : KIMO Instruments Adresse : Zone Industrielle BP16 24700 Montpon Tel : 05.53.80.85.00 Site : www.kimo.fr

Upload: others

Post on 19-Jun-2022

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: rapport de stage 1 - CRUZ Fabien

1

Rapport de stage PFMP N°1

NOM : CRUZ

Prénom : Fabien

Etablissement : Lycée Jean Monet

Classe : S.E.N

Année : 1er

Durée : Du 28/05/2012 au 05/07/2012

Entreprise : KIMO Instruments

Adresse : Zone Industrielle BP16 24700 Montpon

Tel : 05.53.80.85.00

Site : www.kimo.fr

Page 2: rapport de stage 1 - CRUZ Fabien

2

Sommaire 1. Présentation de l’entreprise ................................................................................................ 3

2. Présentation du projet ......................................................................................................... 5

2.1. La problématique ......................................................................................................... 5

2.2. Les solutions du marché .............................................................................................. 5

3. La solution .......................................................................................................................... 7

3.1. Présentation de GLPI /OCS ......................................................................................... 7

3.1.1. GLPI ..................................................................................................................... 7

3.1.2. OCS .................................................................................................................... 10

3.1.3. Couple GLPI/OSC .............................................................................................. 12

3.2. Installation serveur .................................................................................................... 14

3.2.1. OCS .................................................................................................................... 14

3.2.2. GLPI ................................................................................................................... 18

3.3. Paramétrage serveur .................................................................................................. 20

3.3.1. Synchronisation GLPI/OCS ............................................................................... 20

3.3.2. OCS .................................................................................................................... 24

3.3.3. GLPI ................................................................................................................... 27

3.4. Installation Client ...................................................................................................... 37

4. Déploiement ..................................................................................................................... 41

4.1. Tests ........................................................................................................................... 41

4.2. Mise en production .................................................................................................... 49

5. Evolution .......................................................................................................................... 51

6. Conclusion ........................................................................................................................ 52

6.1. Personnelle ................................................................................................................. 52

6.2. Professionnelle ........................................................................................................... 52

7. Remerciements ................................................................................................................. 53

Glossaire ................................................................................................................................... 54

8. Problèmes rencontrés ....................................................................................................... 56

8.1. Démarrage de apache ................................................................................................. 56

8.2. Remonté d’informations client à serveur ................................................................... 56

8.3. Activation LDAP du serveur apache ......................................................................... 56

8.4. Accès au serveur xampp en réseau ............................................................................ 56

Page 3: rapport de stage 1 - CRUZ Fabien

3

1. Présentation de l’entreprise Créée en 1979 en Dordogne, la société KIMO est une entreprise française dont la principale activité était la fabrication de manomètres à colonne de liquide pour les mesures de pression.

Manomètres à colonne de liquide.

KIMO conçoit et fabrique des instruments de mesure pour le contrôle et la surveillance. Il se diversifie actuellement dans 14 champs d’activités :

• Acoustique • Air comprimé • Analyse de gaz • Débit d'air • Détection gaz • Electricité • Humidité • Lumière • Pression • Qualité d'air • Solaire • Tachymétrie • Température • Vitesse d'air

KIMO équipe aussi bien des petits installateurs en climatisation que de grandes industries grâce à une large gamme d'appareils portables ou à poste fixe qui répondent aux exigences de chacun. Elle intervient sur des marchés aussi variés que les laboratoires pharmaceutiques, les aéroports, les centrales nucléaires, l'armement, l'industrie papetière ou l'automobile

Soucieuse de garantir la qualité, l'entreprise développe sans cesse ses laboratoires pour contrôler ses propres appareils, mais procède également à des étalonnages selon les normes AFNOR en pression, température, humidité, vitesse, débit d'air et combustion.

Page 4: rapport de stage 1 - CRUZ Fabien

4

En constante progression depuis plus de 30 ans, le souci de recherche, de développement, la qualité des services sont les points d'honneur de la société. Elle ne se contente pas d'attendre les besoins des clients, mais s'efforce de stimuler la demande.

Evolution du nombre de salariés depuis 30 ans.

Kimo créa en 1998 KGF (Kimo Gestion Finance) qui et un groupe de société à savoir : • Freller (Fabrique des étuis pharmaceutiques et cosmétiques)

• Katrem (Etalonnage en tout genre)

• Kimo • Taulou (Fabrique des moules métallique pour injection plastique)

Page 5: rapport de stage 1 - CRUZ Fabien

5

2. Présentation du projet

2.1. La problématique

Le parc informatique de Kimo se compose de 272 ordinateurs. Actuellement le service informatique n’a aucune visibilité sur l’état du parc informatique. On ne sait pas qui a quoi en terme de matériel informatique. Une bonne visibilité de son parc permet de voir l’évolution ainsi que d’établir une politique de renouvellement. Le second problème est que les incidents déclarés par l’utilisateur n’ont pas de suivi car un problème peut être oublié ou mis de coté trop longtemps.

2.2. Les solutions du marché

Afin de répondre aux besoins de l’entreprise, nous avons étudié différentes solution du marché. Nous en avons trouvé 3 qui sont :

• GIMI est un logiciel qui regroupe tous les éléments de la gestion d’un parc

informatique (gérer les équipements, gérer les utilisateurs, gestion des logiciels, etc…). Il prend en compte les évolutions technologiques du matériel et des logiciels.

Avantage(s) : Green it (permet d’économiser de l’électricité grâce à ; des mises en veille automatiques, des bridages de la fréquence du processeur, etc…) Inconvénient(s) : Payant, pas d’interface web

• DMI permet de gérer les utilisateurs du réseau de l'entreprise, la gestion peut être multi entitées. Il permet une gestion du matériel informatique attribué à l'utilisateur. Cela permet au responsable informatique de savoir en tant réel l'état de son parc micro, imprimante, logiciel et qui possède quoi.

Avantage(s) : support hotline Inconvénient(s) : Payant, aucune modification possible

• GLPI/OCS est le couple d’applications il permet une gestion en temps réel du parc informatique, des rapports de problèmes « ticketing », télè-déploiement etc… Cette solution est évolutive car l’ajout de plugin est possible et même la création.

Avantage(s) : gratuit, télé-déploiement, plugin, forte communauté Inconvénient(s) : aucun service client (car gratuit)

Page 6: rapport de stage 1 - CRUZ Fabien

6

Télé-

Déploiement Gestion des

licences Gestion des

incidents Prix

Nous avons retenue GLPI/OCS car il répond au besoin de l’entreprise et en plus il possède une évolutivité de par ces plugins.

Page 7: rapport de stage 1 - CRUZ Fabien

7

3. La solution

3.1. Présentation de GLPI /OCS

3.1.1. GLPI

GLPI est une application web permettant la gestion de rapport et de problème par « ticketing », il fut lancé en 2003, développé par une communauté de programmeurs en PHP pour supporter une interface web. Il s’installe sur n’importe quel système d’exploitation supportant un serveur apache et mysql. GLPI s’adresse à des parcs informatiques de plus d’une centaine de postes de plus il est possible d’y implanter ou de créer des « plugin » pour y ajouter d’autres fonctionnalités. Il va également permettre une meilleur gestion des pannes, des bugs et surtout de les résoudre avec un meilleur rendement. La gestion de problème par « ticketing » permet à un utilisateur de signaler un bug, problème, etc… pour qu’un technicien intervienne. Après intervention le ticket sera sauvegardé pour élaborer des statistiques, des politiques de maintenance et pour le management.

Schéma du fonctionnement de GLPI.

On peut voir sur le schéma que l’utilisateur crée un nouveau ticket, le technicien peut alors le visualiser grâce à GLPI puis il intervient à distance ou sur place ci besoin est.

Page 8: rapport de stage 1 - CRUZ Fabien

8

GLPI se pressente en six modules différents les voici;

• Le module Inventaire permet d'accéder aux différents matériels inventoriés par défaut il existe ; Ordinateurs, Moniteurs, Logiciels, Réseaux, Périphériques, Imprimantes, Cartouches, Consommables, Téléphones et Statuts. Il est possible dans créer de nouvelle.

• Le module Assistance permet de créer, suivre les tickets, et voir les

statistiques. Voici les différents rôles que l'on retrouve traditionnellement dans les services d'assistance : o Demandeurs : ce sont les utilisateurs ou groupes d'utilisateurs connus

dans GLPI concernés par le ticket. o Exécutants/Techniciens ("attribué à") : la prise en charge d'un ticket est

effectuée soit par un technicien, soit par un groupe de compétences ou encore par un fournisseur référencé dans l'application.

o Observateurs : ce sont des utilisateurs ou groupes d'utilisateurs qui reçoivent des notifications.

• Le module Gestion permet de gérer les contacts, fournisseurs, budgets, contrats et documents. Les informations rentrées ici sont réutilisées dans le module inventaire.

• Le module Outils permet de gérer des notes, la base de connaissance, les

réservations, la synchronisation de l'inventaire avec OCS Inventory NG et visualiser les rapports. o Les notes permettent de gérer des notes, leur durée de vie et de les faire

apparaître dans le planning si besoin. Une note correspond à une information personnelle ou publique.

o La base de connaissances répond à deux objectifs principaux, le premier est de centraliser des connaissances internes aux différents techniciens et le second est de mettre à disposition des utilisateurs des informations (FAQ publique) leur permettant de résoudre seuls des problèmes simples.

• Le module Administration permet d'administrer les utilisateurs, groupes, entités, profils, règles et dictionnaires. Il permet aussi la maintenance de l'application (sauvegarde et restauration de base, vérifier si une nouvelle version est disponible).

o Utilisateurs permet d'ajouter, de modifier, de supprimer des utilisateurs

ou rechercher et exporter la liste des utilisateurs. La liste des utilisateurs enregistrés fonctionne de la même façon que la liste des éléments de l'inventaire.

Page 9: rapport de stage 1 - CRUZ Fabien

9

o Les groupes peuvent avoir plusieurs fonctions : rassemblement

d'utilisateurs par compétences (par exemple les techniciens réseaux, ou les administrateurs de base de données) pour le helpdesk, regroupements organisationnels (par exemple tous les ordinateurs de la direction, ou du service comptable) mais aussi ensemble de personnes à notifier.

o La notion de profil est un pilier dans la configuration de GLPI. C'est

elle qui accrédite les utilisateurs de certains droits, c'est elle qui permet de sécuriser et d'isoler les données à certains utilisateurs.

• Le module Configuration permet d'accéder aux options de configuration générale de GLPI : notifications, collecteurs, tâches automatiques, authentifications, plugins, liens externes, mode OCSNG.

o Intitulés permet la définition des lieux, des statuts de matériels, des

catégories de tickets, des noms des logiciels et des constructeurs : en somme, tout ce qui dépend d'une nomenclature propre à un contexte particulier doit être paramétré. Si certains de ces intitulés sont fournis avec une liste par défaut, la plupart des intitulés doivent être déclarés dans l'application.

o Composants : Un composant matériel est défini par un type, un nom, un

fabricant (à sélectionner dans une liste déroulante renseignée depuis la configuration des intitulés ou directement depuis l'icône d'ajout apposée à la liste déroulante), un commentaire, ainsi que plusieurs champs spécifiques au type de composant. Par exemple, pour une carte mère, on pourra y renseigner le chipset.

o Liens externes : Chaque type de matériel inventorié dans GLPI peut

être associé à un ensemble de liens vers des applications externes. Ceux-ci sont visibles depuis l'onglet Liens des différentes fiches.

Voici la présentation des modules dans GLPI

Chaque utilisateur et groupe d’utilisateur peuvent être configuré pour avoir un accès restreint à chaque module et sous module.

Page 10: rapport de stage 1 - CRUZ Fabien

10

3.1.2. OCS

D'origine française OCS est actuellement géré par neuf personnes, ainsi que de nombreux contributeurs occasionnels (traduction, support, ...) et cela depuis 2002.

OCS est une application qui permet de faire l’inventaire de la configuration matériel, du réseau et des logiciels là où il est installé. Il permet de visualiser l’inventaire grâce à une interface web. Un télé-déploiement est également possible. De plus il est possible de gérer beaucoup d’utilisateur avec peu de moyens matériel et de bandes passantes. En effet seule une petite configuration est nécessaire ;

• Processeur 1 cœur de 1 Ghz • 2 Go de RAM • 2 Go d’espace libre

Aujourd’hui n’importe quel serveur bas de gamme peut atteindre ces performances à partir de 349,00 € chez DELL, 435,69 € chez ASUS et 440 € chez hp. Il est déconseillé d’utiliser OCS sous plateforme Windows si ce dernier gère plus de 1500 postes. Dans ce cas il est conseillé une plateforme Linux ou Unix. Le serveur OCS Inventory est supporté par 21 systèmes d’exploitation comme la plupart de distribution Linux et Unix serveur ainsi que tout les systèmes Windows sauf les versions familiales.

Schéma du fonctionnement de OCS.

Page 11: rapport de stage 1 - CRUZ Fabien

11

On peut voir sur le Schéma que l’Agent OCS renseigne les informations à OCS serveur du poste où il est installé.

Ces fonctionnalités se regroupent en 8 catégories ;

• Fonctionnalité d'inventaire, destinée à aider l'administrateur réseau ou système à posséder un état de la configuration des ordinateurs et des logiciels en place sur son réseau. Différentes informations sont collectées :

o Type o Disques logiques / partitions o Système d'exploitation o Logiciels o Ecran o Description de l'ordinateur

• Fonctionnalité de déploiement de paquets sur les ordinateurs distants. Depuis l'interface d'administration du serveur, vous pouvez télédéposer les paquets qui serons téléchargés en utilisant les protocoles HTTP/HTTPS et lancer par l'agent des ordinateurs distants. Le déploiement s’effectue en trois étapes ;

o Vous créez un paquet au travers de l'interface d'administration. o Une fois le paquet créé, vous l'activez. o Enfin, vous sélectionnez sur quels ordinateurs déployer le paquet, et vous

l’affectez.

• Interface d'administration web. Les communications entre les agents et le serveur de gestion sont effectuées en utilisant les protocoles HTTP et HTTPS. Toutes les données sont formatées en XML et Zlib compressées pour réduire l'utilisation du trafic réseau

• L’Agent OCS Inventory supporte plus de 30 systèmes d’exploitation différents dont de nombreuses distributions Linux et Unix (Mac OS X, FreeBSD, Solaris, etc…). L’agent et le serveur n’on pas besoin d’être sur le même système d’exploitation pour communiquer.

• Web Service. Depuis la version 1.0, le serveur OCS Inventory NG fournit un Web Service utilisable via SOAP en HTTP. Ce Web Service est disponible depuis le serveur de communication OCS Inventory NG.

Page 12: rapport de stage 1 - CRUZ Fabien

12

• Les plugins d’OCS Inventory NG offre la possibilité d'étendre les fonctionnalités de votre logiciel d'inventaire favori au moyen de plugins. Du côté des agents, un plugin peut être un simple script VBS pour Windows, ou un script shell sous Unix, récupérant des données qui complètent l'inventaire.

• La Découverte du réseau va dans un premier temps recherché par IP et détecter les matériels sur le réseau, même pourvu d'un pare-feu. Tous les matériels répondant à la requète sont stockés dans l'inventaire final (formaté XML) envoyé au serveur. Dans un second temps, des scans SNMP (fonctionnalité implementée dans OCS Inventory NG 2.0) permettront d'affiner les données recueillies par la découverte par IP

• Synchronisez avec GLPI, vous obtiendrez un inventaire complet et un outil de gestion vous permettant de mettre à jour vos configurations clientes, gérer les licences, etc…

3.1.3. Couple GLPI/OSC

Parmi les nombreuses fonctionnalités offertes par le couple OCS/GLPI, la gestion des logiciels et licences etc…

Le problème est assez complexe et les solutions offertes par les produits de Gestion de parc y répondent par des solutions plus ou moins sophistiquées en terme de fonctionnalités et plus ou moins simples en terme d'utilisation. OCS et GLPI offrent une solution simple et efficace pour la gestion de parc informatique.

GLPI peut se synchroniser avec OCS se qui permet un rafraîchissement automatique de GLPI. OCS serveur va interroger tous les agents (OCS) du réseau et récupérer les informations matériel et logiciel (licence, carte mère, hdd, etc…) pour faire une mise a jour de sa propre base de données. GLPI mettra à jour ses informations à jour chaque synchronisation.

GLPI a développé un "mode OCS-NG" qui permet de synchroniser automatiquement les bases de données (celle d'OCS et celle de GLPI). Cette fonctionnalité est implémentée dans l'interface d'administration de GLPI en natif. Vous pouvez choisir se que vous voulez synchroniser les différentes composantes informations générale et administrative et comment vous désirez les importer Import global ou unique.

Page 13: rapport de stage 1 - CRUZ Fabien

13

Schéma du fonctionnement du couple GLPI/OCS.

Le serveur a besoin d’un minimum de 750 Mo d’espace de disque pour l’installation de GLPI et OCS au quel il faudra ajouter l’espace requis pour le information des utilisateurs. Voici la l’espace nécessaire pour environ 80 postes ;

Base de données Taille

20Mo

10Mo

OCS nécessite un serveur XAMPP, ce dernier contient les modules Apache, Mysql, Perl, phpMyAdmin est même les bases de donnés GLPI ainsi que l’interface web (suivant l’installation).

Page 14: rapport de stage 1 - CRUZ Fabien

14

3.2. Installation serveur

Pour l’installation nous allons commencer par installer et paramétrer OCS et puis GLPI. L’installation se fera sur un ordinateur Dell optiplex 390 avec Windows 7 Professionnel 32bit. Il faut télécharger ocs serveur ici : « http://www.ocsinventory-ng.org/fr/telechargement/telecharger-serveur.html ». Et glpi ici : « http://www.glpi-project.org/spip.php?article3 ».

3.2.1. OCS

Lors de l’installation de OCS il faut bien faire attention à installer OCS avec XAMPP.

Patienter jusqu’a la fin de l’installation de OCS et de XAMPP

Page 15: rapport de stage 1 - CRUZ Fabien

15

A la fin de l’installation cette fenêtre apparait il faut cliquer sur le lien « http://localhost/security/xamppsecurity.php »

Puis entre un mot de passe pour la base de donnée sql et cocher « http » sur la ligne « PhpMyAdmin authentification: » et cliquer sur « Password changing »

Une fois effectué, ce message s’affiche « The root password was successfully changed. Please restart MYSQL for loading these changes! ». Allez dans « C:\xampp » et exécuter « xampp-control.exe » à la ligne MySql cliquer sur Stop et cliquer sur Start.

Page 16: rapport de stage 1 - CRUZ Fabien

16

Une foi l’installation terminée il faut vous rendre a l’adresse suivante : http://localhost/ocsreports/ Puis il faut remplir les champs suivants : MySQL login (le nom de votre compte phpMyAdmin) MySQL password (le mot de passe de votre compte phpMyAdmin) Name of Database (le nom de la data base que va créer ocs dans phpMyAdmin) MySQL HostName (l’ip du serveur où est installer phpMyAdmin, « localhost »)

Une foi effectué, cliquer sur « envoyer » et puis sur « Click here to enter OCS-NG GUI » Connecter vous grâce au login « admin » mot de passe « admin »

Page 17: rapport de stage 1 - CRUZ Fabien

17

Ensuite changez le mot de passe admin comme il est demandé en haut.

Allez dans le dossier « C:\xampp\htdocs\ocsreports » et supprimer le fichier « install.php » Il est également demandé de changer le mot de passe phpMyAdmin du compte ocs. Allez sur phpMyAdmin et connecter avec le login « ocs » et mdp « ocs » et changer votre mot de passe

Pour que OCS puisse de nouveau se connecter à sa base de donné il faut changer le mot de passe du fichier « dbconfig.inc.php » dans « C:\xampp\htdocs\ocsreports » ligne 6 et du fichier « ocsinventory-server.conf » dans « C:\xampp\apache\conf\extra » ligne 31

Page 18: rapport de stage 1 - CRUZ Fabien

18

3.2.2. GLPI

Créez un fichier glpi dans « C:\xampp\htdocs » et décompresser glpi dedans Ensuite allez à l’adresse suivante « http://localhost/glpi » Sélectionner français et continuer jusqu’à ici : Il suffi de saisir : Serveur MySQL (localhost) Utilisateur MySQL (root) Mot de passe MySQL (le mdp sélectionner lors du paramétrage de phpMyAdmin)

Ensuite sélectionnez « Créer une nouvelle base ou utiliser une base existante » et nommé la nouvelle base de donnée « glpiweb ».

Page 19: rapport de stage 1 - CRUZ Fabien

19

Cliqué sur « continuer » puis « Utiliser GLPI » Attention bien noter :

• glpi/glpi pour le compte administrateur (Peut tout faire) • tech/tech pour le compte technicien (Peut gérer les tickets mais il n’administre rien) • normal/normal pour le compte normal (Peut créer un ticket et visualiser toute les info) • post-only/postonly pour le compte postonly (Peut créer un ticket)

Connectez-vous en administrateur et allez dans « administration » et « utilisateurs » pour modifier le mdp de tous les mutilateurs y compris le votre.

Page 20: rapport de stage 1 - CRUZ Fabien

20

3.3. Paramétrage serveur

3.3.1. Synchronisation GLPI/OCS

Synchronisation Serveur

La synchronisation serveur permet de synchroniser les bases de données de GLPI et OCS (cf. 3.1.3. Couple GLPI/OCS) Allez dans « Configuration », « Générale » puis cliquer sur l’onglet « inventaire » et enfin placez « Activer le mode OCSNG : » sur « oui ».

Après avoir cliqué sur « valider » vous êtes redirigé sur « Configuration », « Mode OCS NG ». Cliquer sur « localhost » est metter le mdp du compte mysql « ocs ».

Si la synchronisation réussie le message encadré en rouge doit apparaître. Pour paramétrer la synchronisation cliquer sur « option d’importation » et sélectionner les informations qui vous intéressent.

Page 21: rapport de stage 1 - CRUZ Fabien

21

Placez le paramètre « Utiliser le dictionnaire logiciel d'OCSNG » sur « oui ».

Page 22: rapport de stage 1 - CRUZ Fabien

22

Filtrage Logiciel

Le filtrage logiciel permet de remonter que certain logiciel sur GLPI et de créer des groupements de logiciel pour ne pas polluer GLPI.

Connectez vous sur OCS puis aller dans « configuration ».

Ensuite cliquer sur l’onglet « Filtres ».

Placez le paramètre « INVENTORY_FILTER_ON » sur « on ». Allez dans « dictionnaire » et « nouveau ».

Page 23: rapport de stage 1 - CRUZ Fabien

23

Transférer les logiciels dans « Ignore » pour qu’ils ne soient pas synchroniser et dans « Unchanged » pour qu’ils soient synchronisés. Faite un « force update » dans glpi est vous verrez apparaître tout les logiciels de la liste « Unchanged »

Page 24: rapport de stage 1 - CRUZ Fabien

24

3.3.2. OCS

IP Discover

L’IP Dicover permet de scanner et de répertorier chaque ip se trouvent sur le même masque de sous réseau que le serveur. Pour configurer l’IpDiscover connecter vous à OCS, cliquer sur « Réseau (x) » « IpDiscover » puis « Afficher tous mes réseaux ».

Voici ce qui doit apparaître :

1. description réseau 2. Adresse de sous réseau 3. Nombre d’ip scanner et inventoriés 4. Nombre d’ip scanner 5. Nombre d’agent ocs

Si vous cliquer sur « 111 » dans la colonne « Non inventoriés » Une liste de tous les ip scanner s’affiche vous pouvez enregistrer chaque host comme une imprimante ou téléphone où l’on ne peut pas installer OCS.

Page 25: rapport de stage 1 - CRUZ Fabien

25

Télé-déploiement

Le télédéploiement permet d’installer ou de transmettre des données sur toutes les machines du réseau et en même temps. Il est possible d’effectuer un télédéploiement via OCS.

Le champ action permet d’effectuer plusieurs manipulations différentes :

1. Stocker (transférer un fichier dans un répertoire distinct du client) 2. exécuter (exécuter une commande comme pour invite de commande) 3. lancer (lancer un programme comme un fichier exécutable)

Si vous activez la fonction « Prévenir utilisateur » il est possible d’afficher un message d’avertissement pendant un temps défini. De plus on peut donner le droit à l’utilisateur de stopper le télédéploiement ou de le remettre à plus tard.

Page 26: rapport de stage 1 - CRUZ Fabien

26

Il reste à activer le télédéploiement en cliquant sur « activer » avec l’option « MANUELLE »

puis valider .

Page 27: rapport de stage 1 - CRUZ Fabien

27

3.3.3. GLPI

Pour paramétrer GLPI il suffit d’aller dans l’onglet « configuration ».

Chaque sous onglet permet de gérer une ou plusieurs fonctionnalités de GLPI.

• Configurer les intitulés : Certaines listes de sélections déroulantes sont paramétrables dans GLPI. La définition des lieux, des statuts de matériels, des catégories de tickets, des noms des logiciels et des constructeurs.

• Configurer les composants : Un composant matériel est défini par un type, un

nom, un fabricant (à sélectionner dans une liste déroulante renseignée depuis la configuration des intitulés ou directement depuis l'icône d'ajout apposée à la liste déroulante)

• Configurer les notifications : GLPI dispose d'une fonction de notifications.

Celle-ci permet de recevoir des messages pour certaines actions prédéfinies. Elle s'appuie sur 2 notions :

1. modèle : permet de formater les messages de notifications. 2. notification : association d'un modèle pour un événement donné et

définition de ses destinataires. Pour activer cette fonction, il faut paramétrer la messagerie qui va recevoir les notifications. Il faut renseigner le mode d’envoi (attention le mode PHP peut être bloqué par le serveur qui hébergeait glpi) l’hôte et le port.

Page 28: rapport de stage 1 - CRUZ Fabien

28

Et enfin il faut définir les cas où la notification est envoyée.

• Configurer les SLAs : Des niveaux d'escalades peuvent être définis au sein d'un SLA. Chaque niveau déclenche des actions automatiques permettant la résolution du ticket dans les meilleurs délais. Un niveau se déclenche avant ou après la date d'échéance du SLA en fonction du délai défini. Par exemple, un jour avant l'échéance, le ticket est affecté au support de niveau 2 et sa priorité passe à Haute.

Il faut paramétrer soit même chaque niveau avec un temps limite de résolution.

Voici 2 exemples de niveau de SLA.

• Configurer les paramètres centraux : L'apparence générale de l'application est paramétrable : types de graphiques par défaut, nombre de décimales pour les montants, nombre maximum de caractères affichés dans les listes, nombre maximum de caractères affichés pour les URL, nombre maximum de résultats de recherche à afficher par page...

Page 29: rapport de stage 1 - CRUZ Fabien

29

• Configurer les contrôles : Cette fonctionnalité permet de rendre l'ajout ou la mise à jour d'un objet d'inventaire impossible si un autre possède déjà une valeur identique. Ce mécanisme s'applique sur les ajouts manuels, mais aussi sur l'import depuis une source externe comme OCSNG.

• Configurer les actions automatiques : Pour chaque action, il est possible de

configurer : 1. La fréquence d'exécution ; 2. Le statut : Permet de désactiver si besoin l'action ; 3. Le mode d'exécution : Interne (déclenché par la navigation des

utilisateurs, par défaut lors de l'installation standard) ou Externe (plus robuste mais nécessitant une configuration système) ;

4. La plage horaires d'exécution : Permet de désactiver certains traitements la nuit par exemple ;

5. Le temps en jours de conservation des journaux : qui sont stockés dans la base de données.

Il est possible de modifier une action automatique la fréquence, la plage d’exécution, etc… On peut même déclencher les actions prématurément.

Page 30: rapport de stage 1 - CRUZ Fabien

30

• Configurer Authentification : Une authentification permet aux utilisateurs de se

connecter avec le login et le mdp de leur poste ou de leur session et de récupérer leurs informations personnelles (nom, mail, téléphone, etc).

Pour pouvoir paramétrer l’authentification avec le serveur LDAP il faut aller dans « C:\xampp\php » afin d’ouvrir les 3 fichiers « php.ini » « php.ini-development » et « php.ini-production ». Il faut ensuite modifier la ligne « ;extension=php_ldap.dll » en supprimant le « ; ». De plus, allez dans le « panneau de configuration/système » dans « Paramètres système avancés » , « variables d’environnement » puis modifier la variable système « Path » et rajouter « ;C:\xampp\php » a la fin.

Page 31: rapport de stage 1 - CRUZ Fabien

31

Ensuite valider et redémarrer le serveur apache. Et enfin il faut paramétrer la connexion avec le serveur LDAP.

• Configurer les collecteurs : Un collecteur permet d'importer un courriel depuis une boîte, et de le transformer en ticket dans GLPI. Un mécanisme de routage permet d'affecter celui-ci à une entité de destination. Un collecteur est associé à une adresse de messagerie. Il est possible d'ajouter autant de collecteurs que l'on désire. Bien entendu, plus leur nombre est élevé, plus le processus d'import des courriels est long.

• Configurer le Mode OCSNG : Cette section permet de configurer le mode

OCSNG. Pour que le menu apparaisse, il faut que le mode OCSNG soit activé dans la configuration. Voir 3.3.1 Synchronisation GLPI/OCS.

• Configurer les liens externes protocolés : Chaque type de matériel inventorié

dans GLPI peut être associé à un ensemble de liens vers des applications externes. Ceux-ci sont visibles depuis l'onglet Liens des différentes fiches.

• Configurer les plugins GLPI : Les plugins permettent d'ajouter de nouvelles

fonctionnalités à GLPI. La totalité des plugins préalablement téléchargés et installés sont listés dans la page Configuration > Plugins.

Page 32: rapport de stage 1 - CRUZ Fabien

32

Paramétrage des profils

Un profil défini à un utilisateurs ses droits sur l’utilisation, la configuration ou l’administration de GLPI. Il est possible de configurer les droits des utilisateurs via les onglets « administration », « Profils ». Nous avons choisi de garder trois profils à savoir : - Super-Admin (qui a tout droit) - Technician (qui gère les tickets) - Self-Service (peut créer un ticket).

Il suffit de cliquer sur le profil pour le modifier. Il est possible de ::

1. Gérer les droits des onglets : Inventaire, Gestion et Outils. 2. Gérer les droits de l’onglet Assistance. 3. Gérer le temps de vie d’un ticket crée par les utilisateurs. 4. Gérer les droits des onglets : Administration et Configuration. 5. Permet de voir quel utilisateur est associé à ce profil.

Page 33: rapport de stage 1 - CRUZ Fabien

33

Paramétrage des gabarits de tickets

Il est possible de personnaliser les formulaires de ticket en cliquant sur « assistance ».

Cliquer sur « Gérer » et créer un gabarit de ticket.

Cliquer sur le nom du gabarit (il s’affiche en haut après l’avoir créer) pour pouvoir personnaliser le gabarit de ticket. Chaque gabarit est disponible en deux versions standard et simplifier que l’on peut modifier. Voici la liste exhaustive des champs que l’on peut prédéfinir, supprimer ou rendre obligatoire.

Page 34: rapport de stage 1 - CRUZ Fabien

34

1. Modifier le nom et la définition. 2. Ajouter des champs indispensables à la validité dur ticket. 3. Ajouter des champs déjà remplie (le champ peut être modifier par l’utilisateur). 4. Supprime un champ du gabarit. 5. Permet de visualiser l’interface standard. 6. Permet de visualiser l’interface simplifiée.

Quelques exemples de champs prédéfinis.

Voici a quoi peut ressembler un ticket après son paramétrage. Les champs avec « * » correspondent aux champs obligatoires. Dans les champs prédéfinis on donne une indication sur la fonction de ce dernier.

Page 35: rapport de stage 1 - CRUZ Fabien

35

Paramétrage des entités

Les entités permettent de segmenter et de hiérarchiser GLPI. C'est-à-dire que l’entité racine accèdera à toutes ses entités enfant mais ces derniers ne se verront pas. Une des utilités des entités est de dissocier les filiales d’un groupe de sociétés, communément appelée la gestion multi entités. On pourra donc gérer séparément les différentes entreprises sans se polluer des informations des autres. Les gabarits de tickets sont attribuables aux entités via « Administration / Entités ». On peut modifier directement le gabarit de ticket de l’entité racine qui est attribué par défaut sur tous les profils.

Entité racine

KIMO

Users Tickets Ordinateurs …

KGF

Users Tickets Ordinateurs …

Page 36: rapport de stage 1 - CRUZ Fabien

36

Pour créer des entités, il suffit de cliquer sur le « + » et de modifier dans l’onglet « assistance » le gabarit.

Page 37: rapport de stage 1 - CRUZ Fabien

37

3.4. Installation Client

Il faut télécharger le fichier client ici « http://www.ocsinventory-ng.org/fr/telechargement/telecharger-agent.html » puis décompresser le fichier et lancer « OCS-NG-Windows-Agent-Setup.exe ». Attention il faut que le type d’installation soit en « network inventory »

Il faut entrer l’adresse du serveur OCS en si on installe le client sur le serveur l’adresse va être « http://localhost:80/ocsinventory » ou remplacer localhost par l’ip du serveur ex : « http://192.168.1.10:80/ocsinventory »

Page 38: rapport de stage 1 - CRUZ Fabien

38

Laisser « Proxy Type » sur « None »

Et enfin cocher « Immediatly launch inventory (= /NOM)

Page 39: rapport de stage 1 - CRUZ Fabien

39

Terminer l’installation et un icône de notification apparait cliquer droit dessus et sur « Run OCS Inventory NG Agent now ».

Allez ensuite sur l’interface web de OCS normalement vous devriez voir un ordinateur inventorier.

Attention la remontée des informations au serveur peut prendre quelque minutes. Il est possible d’automatiser l’installation grâce à un scripte « .bat » qui installe l’agent OCS ou qui le met à jour. « @echo off ECHO ******************************************************************************* ECHO **** Installation automatisee par GPO de l'Agent OCS Inventory NG **** ECHO **** Par Jerome MICHAUX **** ECHO **** Inspire du script de Philippe BEAUMONT **** ECHO **** Version 1.01 - 17/05/2011 **** ECHO **** **** ECHO **** A utiliser dans une GPO au demarrage de l'ordinateur **** ECHO ******************************************************************************* REM **** Indiquer ici la version de l'agent. Ce numero est verifié au démarrage de l'ordinateur. REM **** Le fait de changer le numéro provoquera une mise à jour. set VERSION=20020 REM **** URL d'acces au serveur OCS. Peut être un nom DNS ou une IP. set OCSSERVER=srv-ocs.monentreprise.local

Page 40: rapport de stage 1 - CRUZ Fabien

40

REM **** Indiquer ici le chemin complet vers l'executable de l'installation d'OCS Agent (chemin CIFS) set INSTALLSERVER=\\srv-fichier\tools$\ocs REM **** ================================= **** REM **** NE PAS TOUCHER AU CODE CI DESSOUS **** REM **** ================================= **** IF EXIST "%programfiles(x86)%" goto 64b echo Systeme 32 bits detecte set PROGFOLDER=%programfiles% echo Dossier d'installation : %PROGFOLDER%\OCS Inventory agent goto suite :64b echo Systeme 64 bits detecte set PROGFOLDER=%programfiles(x86)% echo Dossier d'installation : %PROGFOLDER%\OCS Inventory agent :suite IF EXIST "%PROGFOLDER%\OCS Inventory agent\OCSInventory.exe" goto checkupgrade echo Installation %INSTALLSERVER%\OCS-NG-Windows-Agent-Setup.exe /S /SERVER=%OCSSERVER%/ocsinventory /NOSPLASH /DEBUG /NOW /NO_SYSTRAY IF NOT ERRORLEVEL 0 goto end echo %VERSION% > "%PROGFOLDER%\OCS Inventory agent\DEPLOYEDVERSION.txt" goto end :checkupgrade type "%PROGFOLDER%\OCS Inventory agent\DEPLOYEDVERSION.txt" | find "%VERSION%" > nul IF ERRORLEVEL 1 goto upgrade IF ERRORLEVEL 0 goto end :upgrade echo Upgrade Requise %INSTALLSERVER%\OCS-NG-Windows-Agent-Setup.exe /S /SERVER=%OCSSERVER%/ocsinventory /NOSPLASH /UPGRADE /DEBUG /NOW /NO_SYSTRAY IF NOT ERRORLEVEL 0 goto end echo %VERSION% > "%PROGFOLDER%\OCS Inventory agent\DEPLOYEDVERSION.txt" :end » Le batch sera lancer à chaque démarrage via un GPO.

Page 41: rapport de stage 1 - CRUZ Fabien

41

4. Déploiement

4.1. Tests

Installation de l’agent OCS via le batch

On lance le batch, l’installation s’effectue et la fenêtre se ferme.

On peut vérifier que l’installation s’est bien effectuée dans « C:\Program Files\OCS Inventory Agent »

Page 42: rapport de stage 1 - CRUZ Fabien

42

On peut vérifier la version dans le fichier « DEPLOYEDVERSION.txt ». Elle doit correspondre à la version indiquée dans le batch.

Page 43: rapport de stage 1 - CRUZ Fabien

43

Mise à jour de l’agent OCS via le batch

On modifie la version 2030 => 2040 et le chemin du fichier d’installation dans le fichier .bat.

On lance le batch qui reconnaît qu’une installation a déjà eu lieu. La mise à jour s’effectue et la fenêtre se ferme.

On vérifie que le mise à jour a fonctionnée.

Page 44: rapport de stage 1 - CRUZ Fabien

44

Pour finir on peut voir que le poste est bien inventorié sur OCS.

Page 45: rapport de stage 1 - CRUZ Fabien

45

Importation des données d’OCS sur GLPI

Il existe deux types d’importations : - L’importation automatique qui a été vue précédemment (cf. 3.3.3 GLPI) - L’importation manuelle que nous pouvons lancer à partir de l’onglet « action automatique ».

On regarde dans l’onglet « inventaire » si les ordinateurs son bien synchronisés.

Quand on clique sur un ordinateur on peut accéder à différentes informations concernant le poste comme : les composants, les logiciels, la gestion financière, les tickets…

Page 46: rapport de stage 1 - CRUZ Fabien

46

Importation des comptes LDAP sur GLPI

Après avoir configurer un lien avec le serveur Active Directory, un nouvel onglet « Liaison annuaire LDAP » est apparu (cf. 3.3.3. GLPI, Paramétrage des profils).

Deux choix s’offrent à nous : - La « synchronisation des utilisateurs déjà importés » permet la mise à jour des informations des personnes. - L’ « importation de nouveaux utilisateurs » va ajouter les comptes sélectionnés.

Avec le moteur de recherche nous sélectionnons directement les utilisateurs à importer.

Après avoir réussi les importations des ordinateurs (OCS) et des utilisateurs (LDAP), nous avons collecté beaucoup d’informations que l’on peut lier entre elles. De plus d’autres champs comme la gestion financière, les immobilisations sont disponibles, ce qui correspond au besoin de l’entreprise en termes de gestion de parc (cf. 2.1).

Page 47: rapport de stage 1 - CRUZ Fabien

47

Gestion des incidents

En se connectant avec un utilisateur nous pouvons créer un ticket grâce à un formulaire. L’utilisateur remplit au minimum les champs obligatoires puis envoie le message.

Quand un technicien reçoit un ticket, il doit se l’attribuer pour le traiter. L’utilisateur sera averti par email à chaque modification du ticket s’il le souhaite.

Page 48: rapport de stage 1 - CRUZ Fabien

48

Le ticket peut est attribué à un technicien.

Avec les différents onglets on peut intervenir sur le ticket :

1. Permet de visualiser et de suivre le ticket. 2. Permet de faire une demande de matériel, financière ou tout se qui n’est pas du ressort

du technicien en charge du ticket. 3. Permet d’administrer des taches aux techniciens. 4. Permet de déterminer le coût de l’intervention. 5. Permet de répondre à l’utilisateur pour lui expliquer la démarche à suivre pour

résoudre son problème et placer cette solution dans la base de connaissances. 6. Permet de visualiser le temps de résolution de ce ticket. 7. Permet d’envoyer ou de recevoir un fichier envoyé lors de la création du ticket. 8. Permet de mettre le statut du ticket en « non résolu ».

Une fois traité, le technicien clôture le ticket et celui-ci est archivé.

Page 49: rapport de stage 1 - CRUZ Fabien

49

4.2. Mise en production

Je n’ai pas pu faire la mise en production faute de temps mais j’ai établi un planning qui organisera le déploiement. Dans un premier temps, nous effectuerons le déploiement sur le siège social. Il se déroulera sur trois semaines avec une sélection de plusieurs services par semaine. Pour la première semaine nous commencerons par une trentaine de PC du côté administratif. La première action sera d’ajouter le script batch dans la GPO des personnes concernées. Puis nous vérifierons sur OCS/GLPI que les données soient bien remontées. Enfin nous ajouterons les informations concernant les utilisateurs et les PC.

Services Nombres Postes Date Actions

N°1 N°2 N°3 N°4

Direction 2

Sem

ain

e 1

Ajout du script dans la GPO des

services concernés

Vérification des remontées

Ajout des

informations utilisateurs (LDAP,

email…)

Ajouts des informations PC (N° immos, financière,

lieu…)

Qualité 4

Accueil 3

Comptabilité 7

RH 4

Achats 7

Communication 5

Logistique 10

Commerce 40

Sem

ain

e 2

SAV 20

BE 38

Sem

ain

e 3

Production 25

Laboratoire 35

Total 200

Page 50: rapport de stage 1 - CRUZ Fabien

50

Dans un second temps, nous déploierons OCS/GLPI dans toutes les agences de KIMO en suivant la même procédure.

Agences Nombres Postes Date Actions

N°1 N°2 N°3 N°4

Aix 4

Sem

ain

e 4

Ajout du script dans la GPO des

services concernés

Vérification des remontées

Ajout des informations

utilisateurs (LDAP, email…)

Ajouts des informations PC (N° immos, financière,

lieu…)

Lille 4

Paris E 23

Paris O 8

Lyon 14

Rennes 5

Strasbourg 4

Toulouse 10

Total 72

Et enfin nous finirons par les différentes filiales.

Filiales Nombres Postes Date Actions

N°1 N°2 N°3 N°4

Taulou 20

Sem

ain

e 5

Ajout du script dans la GPO des

services concernés

Vérification des remontées

Ajout des informations

utilisateurs (LDAP, email…)

Ajouts des informations PC (N° immos, financière,

lieu…)

Freller 14

Katrem 5

Total 39

Pour finir, la durée total du déploiement sera de 5 semaines et nous aurons des remontées d’informations de tous les équipements réseaux de KIMO ainsi que de ses filiales.

Page 51: rapport de stage 1 - CRUZ Fabien

51

5. Evolution Les modularités de OCS et GLPI va permettre dans un futur à moyen terme de les faire évoluer d’une par les mise à jour et d’autre par les plugins en tout genre. Une évolution est déjà tracée étant donné que le serveur est sur une plateforme Windows et qu’il est recommandé de ne pas dépasser 1500 postes. Un projet est déjà en marche pour passer d’une plateforme Windows à Red Hat distribution Linux ce qui permettra de dépasser 1500 postes dans un futur lointain. Il est envisagé de metre en place une cartographie pour visualiser le parc informatique via une interface graphique qui pourrait ressembler à ça :

Un système à code bar existe en plugin sur GLPI « http://plugins.glpi-project.org/spip.php?article137 » se qui pourrait permettre d’identifier chaque PC grâce a un code bar avec une douchette laser.

Page 52: rapport de stage 1 - CRUZ Fabien

52

6. Conclusion

6.1. Personnelle

Ce stage m’aura permis de développer mes connaissances sur le kit d'installation XAMPP ainsi que sur la gestion de parc informatique et le télé déploiement. J’ai pu découvrir comment se mener un projet au sein d’une entreprise, même si sa mise en œuvre n’est pas terminée à 100%. J’ai également pu voir le coté humain du service informatique, car nous avons préparé des ordinateurs portables mis au rebut pour que des enfants malades puissent aller sur Internet à l’hôpital. J’ai pu voir comment fonctionnait la mise en domaine des postes clients et comprendre l’intérêt et les enjeux des droits des utilisateurs.

6.2. Professionnelle

Je pense avoir apporté à l’entreprise une source de documentation sur laquelle le service informatique peut s’appuyer en cas de problème. De plus les techniciens verront leur rendement augmenté et leur suivi informatiques s’améliorer grâce à GLPI et OCS. La gestion financière va permettre un re-calibrage des investissements pour une économie à long terme. Grâce aux compétences que j’ai acquises lors de mes cours, j’ai pu qualifier et réparer des pannes sur des postes utilisateurs. J’ai également réinstallé des systèmes d’exploitation ainsi que des logiciels sur des postes de production.

Page 53: rapport de stage 1 - CRUZ Fabien

53

7. Remerciements

Je tiens tout d’abord à remercier Melle. MOULINET, PDG du groupe K.G.F, de m’avoir accueilli comme stagiaire au sein de sa société.

Je remercie également M. VERZEROLI, mon maître de stage, responsable informatique, pour ses conseils et la confiance qu’il m’a accordé tout au long de mon stage.

Enfin, je tiens à remercier M. BURLAN, M. MOUCHES, pour les conseils et l’aide qu’il mon apporté pendant la durée de mon stage.

Page 54: rapport de stage 1 - CRUZ Fabien

54

8. Glossaire

Plugin : aussi nommé add-on est est un paquet qui complète un logiciel hôte pour lui apporter de nouvelles fonctionnalités.

SLA : Le Service Level Agreement met par écrit l’attente de deux parties sur le contenu des prestations, leurs modalités d'exécution

Helpdesk : Un halpdesk et logiciel de support qui offre une interface web et qui peut offrir des fonctions comme la délégation des tickets et la gestion des niveaux de services / SLA.

Télé-déployment : Le télé-deployment permet d’installer un même logiciel ou autre sur plusieurs voire tous les ordinateurs d’un réseau en même temp.

AD : L’Active Directory est le nom du service d'annuaire de Microsoft qui permet de recenser toutes les informations concernant le réseau, que ce soit les utilisateurs, les machines ou les applications.

Multi entités : possibilité de gérer des parcs indépendants

Zlib : zlib est une bibliothèque logicielle de compression de données. Elle implémente l'algorithme de compression deflate et peut créer des fichiers au format gzip.

XML : est un langage informatique de balisage générique qui dérive du SGML (langage

normalisé de balisage généralisé). Cette syntaxe est dite extensible car elle permet de définir différents espaces de noms, c'est-à-dire des langages avec chacun leur vocabulaire et leur grammaire.

http, https : http est un protocole de communication client-serveur développé pour le World Wide Web. HTTPS (avec S pour secured, soit « sécurisé ») est la variante du HTTP sécurisée par l'usage des protocoles SSL ou TLS.

SOAP : est un protocole de RPC orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur

Linux Unix : Linux et Unix sont des système d’exploitation décliner en distribution le plus souvent open source à l’instar de Windows.

Script VB : est un langage interprété. Il ne nécessite pas de compilation avant d'être exécuté.

Scripte Shell : Le shell c'est le programme que tout utilisateur d'Unix utilise, c'est celui qui prend les commandes de l'utilisateur et les passe (généralement) au système d'exploitation pour être exécutées.

SNMP : est un protocole de communication qui permet aux administrateurs réseau de gérer les équipements du réseau, de superviser et de diagnostiquer des problèmes réseaux et matériels à distance.

Page 55: rapport de stage 1 - CRUZ Fabien

55

Perl : C'est un langage interprété, polyvalent, et particulièrement adapté au traitement et à la manipulation de fichiers texte, notamment du fait de l'intégration des expressions régulières dans la syntaxe même du langage. L'association chargée du développement et de la promotion de Perl est The Perl Foundation. En France, les Mongueurs de Perl promeuvent ce langage, notamment via les Journées Perl.

MySql : MySQL est un système de gestion de base de données (SGBD). Selon le type d'application, sa licence est libre ou propriétaire. Il fait partie des logiciels de gestion de base de données les plus utilisés au monde, autant par le grand public (applications web principalement) que par des professionnels.

RPC : En informatique et en télécommunication, RPC (Remote Procedure Call) est un protocole réseau permettant de faire des appels de procédures sur un ordinateur distant à l'aide d'un serveur d'applications. Ce protocole est utilisé dans le modèle client-serveur pour assurer la communication entre le client, le serveur et des éventuels intermédiaires.

LAPD : Lightweight Directory Access Protocol (LDAP) est à l'origine un protocole permettant l'interrogation et la modification des services d'annuaire. Ce protocole repose sur TCP/IP. Il a cependant évolué pour représenter une norme pour les systèmes d'annuaires, incluant un modèle de données, un modèle de nommage, un modèle fonctionnel basé sur le protocole LDAP, un modèle de sécurité et un modèle de réplication.

Apache : Apache HTTP Server, souvent appelé Apache, est un logiciel de serveur HTTP produit par l'Apache Software Foundation. C'est le serveur HTTP le plus populaire du Web. C'est un logiciel libre avec un type spécifique de licence, nommée licence Apache.

Page 56: rapport de stage 1 - CRUZ Fabien

56

9. Problèmes rencontrés

9.1. Démarrage de apache

Lors de ma première installation j’ai installé ocs et xampp séparément mais après un redémarrage le serveur apache refusé de démarrer. Le problème a disparu quand j’ai réinstallé xampp via l’installeur de ocs.

9.2. Remonté d’informations client à serveur

Après l’installation du client aucune information ne remonter sur le serveur ocs. En réalité il fallait attendre quelques minutes.

9.3. Activation LDAP du serveur apache

Pour activer le LDAP d’apache il faut retiré le « ; » de la ligne « ;extension=php_ldap.dll » dans les fichiers suivant « C:\xampp\php\php.ini », « C:\xampp\php\php.ini-development » et « C:\xampp\php\php.ini –production ». Il faut également aller dans « Paramètres système avancés », « variables d’environnement » puis modifier la variable système « Path » et rajouter « ;C:\xampp\php » à la fin.

9.4. Accès au serveur xampp en réseau

Par défaut on ne peut pas accéder au serveur xampp d’un autre poste en réseau.

Page 57: rapport de stage 1 - CRUZ Fabien

57

Il faut modifier le fichier « httpd-xampp.conf » qui est dans « C:\xampp\apache\conf\extra » et mettre un « # » au début des lignes 118 à 132.