Rapport de Paul-Louis rageot








télécharger 107.69 Kb.
titreRapport de Paul-Louis rageot
page1/2
date de publication26.03.2017
taille107.69 Kb.
typeRapport
ar.21-bal.com > loi > Rapport
  1   2


AFPA 2012 - TSGERI 7

Rapport de Paul-Louis RAGEOT

Stage en entreprise du 27/08/2012 au 19/10/2012

Sommaire

Remerciements

1. Présentation de l’entreprise

1.1. La société d’accueil

1.2. Le service

2. Présentation du contexte

2.1. Présentation de l’environnement

2.2. Le besoin

2.3. Les taches envisagées

3. Description des tâches effectuées

3.1. Démarche adoptée

3.2. Descriptif des tâches

3.3. Difficultés rencontrées

3.4. Apprentissages effectués

4. Conclusion

Remerciements :

Avant de commencer à vous décrire mon stage dans ce rapport, je tiens tout d’abord à remercier l’entreprise O2, qui m’a permis d’acquérir une expérience supplémentaire dans le monde du travail, tout en me fournissant un espace de travail adéquat dans l’optique d’améliorer mes performances dans l’informatique.

En particulier un grand merci à Monsieur Matthias TROTTIER et à toute son équipe qui m’ont aidé pendant toute la durée de ma PAE et qui m’ont permis de mettre en place mon projet.

Enfin, je tiens à remercier Monsieur Renaud SIBILLE, Directeur des Systèmes d’informations ainsi que Monsieur Guillaume RICHARD, PDG de l’entreprise O2, pour leur accord et leur soutien dans l’observation et l’optimisation de leur service informatique.

1. Présentation de l’entreprise :

1.1. La société d’accueil :

O2 est un groupe de sociétés de services à la personne, agréées par l’État, spécialisées en ménage-repassage, garde d’enfants et aide aux seniors au domicile des particuliers. L’origine du Groupe O2 remonte à 1996, avec la 1ère plateforme privée de services à la personne créée à Lille.

Avec 140 agences et près de 4 500 communes couvertes, le Groupe O2 dispose du réseau intégré de services à domicile le plus étendu de France. Le Groupe O2, dont le siège social est basé au Mans, emploie 8 000 salariés, dont plus de 7100 intervenants à domicile.

Le magazine "L'entreprise" indique que la société O2 est la 2ème entreprise française la plus prometteuse : O2 est classée 9ème de la catégorie des entreprises françaises qui recrutent le plus en CDI en 2012.

1.2. Le service :

Mon stage se déroule au siège de l’entreprise O2, au Mans, au sein du service informatique, qui est structuré en 2 parties distinctes :

  • développement du logiciel Odyssée (8 personnes)

  • administration système et réseau (5 personnes).

J’intègre le 27/08/2012 la section réservée à l’administration du réseau dans le but de contribuer à son fonctionnement et à son amélioration.

Avec Matthias TROTTIER, Responsable administrateur système réseau, je découvre l’architecture réseau que je décrirai plus précisément dans une section suivante, et je suis intégré à son équipe composée des 4 personnes suivantes :

- Mickael CHABROUX, chargé de la maintenance du parc informatique, qui maintient l’approvisionnement en ressource informatique.

- Matthieu MARIE, apprenti en alternance, chargé de l’assistance auprès des utilisateurs et ayant pour projet de créer un VPN plus rapide entre le siège et les agences situées partout en France.

- David BOUCHARD, tout juste diplômé d’une autre formation AFPA située a Lille, chargé de l’assistance auprès des utilisateurs. Il crée et améliore aussi des scripts facilitant le déploiement de ressources informatiques diverses sur tout le parc.

- Bich Lan HA, chargée principalement de la télégestion. Elle gère les téléphones qui sont fournis aux intervenants ainsi que les forfaits auprès des opérateurs

Dans ce groupe, je prends alors en charge diverses tâches, principalement l’aide aux utilisateurs (avec David BOUCHARD, Mickael CHABROUX et Matthieu MARIE), la télégestion (avec Bich Lan HA) et la mise en place d’un serveur OCS Inventory permettant de faire un inventaire automatisé sur tout le parc.

2. Présentation du contexte :

2.1. Présentation de l’environnement :

Dans cette partie, je vais présenter les différentes ressources informatiques dans l’entreprise.

En premier lieu, voici une représentation du système mis en place :

Sur ce schéma, on peut constater que nous avons 3 pôles principaux :

  • le Siège se situant au Mans

  • le Datacenter se situant sur Paris

  • les Agences se situant partout en France

Ces 3 pôles sont tous reliés de différentes manières. Une connexion VPN a été installée entre le Siège et le Datacenter, permettant un transfert de données rapide entre les serveurs grâce à une fibre. Les agences, elles, sont reliées au Datacenter par Extranet. Les adresses externes de leur accès Internet sont enregistrées sur un serveur au Datacenter, ce qui permet d’authentifier leur connexion au réseau O2.

Le serveur Odyssée situé sur le Datacenter distribue un service sur toute l’entreprise. Il constitue l’ERP de l’entreprise. Traitant tous les aspects « métiers », il est le maillon central du service informatique. Ce système étant utilisé par tous les salariés, il est constamment amélioré par l’équipe de développement (avec une mise à jour mensuelle).

Tous les serveurs sont installés sur une architecture Linux, avec des services Freeware (gratuit). Ce système permet donc d’utiliser des outils puissants qui demandent uniquement d’investir sur des machines physiques.

Serveurs mis en place :

Avant de commencer à décrire les différents serveurs mis en place dans l’entreprise, je tiens à rappeler que le système d’exploitation est uniquement du Linux. Il n’y a donc pas de frais sur les licences, vu que tous les services proposés sont du Freeware en Open source.

Voici une liste des serveurs déployés sur le réseau O2 :

  • Serveurs Postfix (serveur de messagerie électronique)

  • Serveurs IMAP (serveur de messagerie électronique, stocke les mails)

  • Serveurs Ldap (annuaire électronique)

  • Serveur Ocs Inventory (gère et automatise l’inventaire du parc)

  • Serveur Samba (domaine)

  • Serveur ProxMox (gère les machines virtuelles, télégestion)

  • Serveurs Données (compta, paie)

  • Serveur Asterisk (VOIP)

  • Serveur Zabbix (surveillance réseau, serveurs)

2.2. Le besoin :

J’intègre l’entreprise du 27/08/2012 au 19/10/2012, sur une période où la charge de travail devient très importante.

En effet, la rentrée scolaire correspond à un recrutement important d’intervenants et de salariés pour palier à la demande sur le marché. Le support devient alors plus important puisque l’on doit fournir l’équipement nécessaire aux utilisateurs. Je participe donc immédiatement au support informatique dans plusieurs domaines que je décrirai dans une partie suivante.

Je participe aussi à la mise à jour de l’inventaire sur le serveur OCS Inventory. Des agents OCS sont déployés à l’aide d’un script de démarrage sur tous les postes de l’entreprise, mais il arrive que certains ne répondent plus (OS différent, problème de connexion ou panne de matériel). Je contacte donc chaque agence afin de mettre à jour notre liste et de réinstaller l’agent OCS pour un inventaire automatisé.

En même temps, je cherche à mettre en place un projet. Après avoir étudié comment fonctionnait ce système d’automatisation de l’inventaire, je choisis, en accord avec Matthias TROTTIER, de mettre en place de mon côté un serveur OCS Inventory que je décrirai dans une partie suivante.

2.3. Tâches envisagées :

Voici donc les principales tâches qui m‘étaient attribuées lors de ce stage :

  • Analyse des différentes procédures internes,

  • Mise a jour de l’inventaire sur OCS Inventory,

  • Recherche et réalisation d’un projet,

  • Participation au support.

Sur toutes ces tâches, il n’y a que la mise à jour de l’inventaire sur OCS qui n’a pas été fini. Le nombre important d’éléments à inventorier et le manque de temps disponible de la part des agences, dû à une période très chargée, ne m’ont pas permis de terminer cette tâche à temps. La poursuite de cette tâche sera confiée à un nouveau stagiaire arrivant juste après moi. Les autres tâches ont été réalisées.

3. Description des tâches effectuées :

3.1. Démarche adoptée :

Pour mener à bien toutes mes tâches, je les ai répartie sur un planning que je me suis fixé. Je précise que je passe mes deux premières semaines à ne faire que du support afin d’acquérir une certaine expérience dans les différentes démarches à suivre. Ensuite, je décide, an accord avec Matthias TROTTIER, de couper mes journées en 2 moitiés :

  • participation au support et mise à jour de l’inventaire :

Une partie de ma journée consistait à venir en aide aux utilisateurs. Je consultais donc les tickets sur Odyssée pour choisir mes différentes interventions. Avant de prendre contact avec un utilisateur pour une intervention, je prends le temps d’analyser le problème et de prendre toutes les informations nécessaires pour apporter une solution rapidement. Pour un gain de temps supplémentaire, je choisissais en priorité des agences où un inventaire était nécessaire. De ce fait, après leur avoir apporté mon aide, j’avais toute leur attention pour procéder à un inventaire sur leur agence.

  • Recherche d’information et mise en place de mon projet personnel :

L’autre partie de ma journée concernait la réalisation de mon projet. Je commence par rassembler un maximum d’informations sur mon sujet avant de me lancer complètement dans la mise en place de celui-ci, une mauvaise préparation pouvant apporter beaucoup d’imprévus et une perte de temps.

3.2. Descriptif des tâches :

Je séparerai cette section en 2 parties :

1°) Participation au support :

Dans cette partie, j’expliquerai toute la partie support qui consiste à fournir une aide et un soutien aux salariés et utilisateurs des ressources informatiques dans l’entreprise. C’est un point très important qui consiste à apporter des solutions lorsqu’il y a des pannes informatiques ou simplement à donner des réponses lorsque les utilisateurs se retrouvent bloqués dans un logiciel.

Pour gérer les incidents techniques, l’entreprise O2 utilise un ERP développé en interne nommée « Odyssée », qui permet de créer et gérer des tickets. L’annuaire LDAP est relié à ce logiciel. Ainsi, lorsqu’un utilisateur crée un ticket avec les choix du type de problème, son nom et sa localisation sont enregistrés dans le ticket d’incident. Du côté des administrateurs, les tickets sont tous classés selon les catégories choisies par l’utilisateur.

En choisissant une catégorie, on fait apparaître tous les tickets des utilisateurs dans une nouvelle fenêtre :

On peut donc connaître la nature du problème avec plus de détails, ce qui permet de les corriger plus rapidement. Ce système est très important car il permet d’aider rapidement les utilisateurs, qui n’ont pas de perte de temps dû à l’attente, et surtout de diminuer la charge de travail des administrateurs.

J’ai donc participé aux interventions sur divers problèmes durant ce stage et me suis intéressé en particulier à plusieurs cas : les mails, les imprimantes, les créations de compte et la télégestion.

Evidemment, il faut aussi prendre en compte que l’utilisateur n’a pas forcément de connaissances en informatique. Il est donc impératif de demander un maximum de détails :

  • l’origine du problème,

  • le type de message d’erreur,

  • depuis quand cela se produit

  • les manipulations qui aurait été faite par l’utilisateur auparavant.

Souvent, les problèmes sont bénins et ne demandent pas d’intervention sur le poste. Il suffit d’expliquer calmement la cause du problème et indiquer la marche à suivre pour débloquer la situation. Si le problème ne peut être résolu en contactant simplement l’utilisateur par tchat ou par téléphone, on peut aussi prendre la main sur son poste grâce au logiciel VNC viewer. De notre côté, un service d’écoute VNC est installé et du côté des utilisateurs, c’est un exécutable VNC qui, lancé par l’utilisateur, permet de prendre la main sur le PC à distance. On peut alors résoudre l’incident plus facilement en décrivant à la fin de notre intervention les différentes modifications effectuées aux utilisateurs.

L’entreprise comptant beaucoup d’employés et les tickets étant nombreux, mes interventions étaient concentrées sur les quatre catégories de tickets citées ci-dessus pour une meilleure efficacité :

  • Catégorie 1 = Mails :

Lors de mes interventions sur des problèmes relatifs aux mails, j’ai rencontré plusieurs types de soucis. La principale raison des tickets est généralement en lien avec des problèmes d’envoi ou de réception des mails après un changement de poste ou de salarié. Ce genre de souci se règle rapidement après avoir pris la main sur le poste et modifié la configuration de l’adresse mail.

Il convient de vérifier que l’adresse mail correspond à l’utilisateur en fonction sur le poste et aussi s’assurer que le smtp est bien adapté au type de box sur lequel le PC est branché. Par exemple, pour une livebox, nous utiliserons le smtp « smtp.orange.fr » et pour une freebox « smtp.free.fr ». Par ailleurs, si la box est une free, un smtp a été spécialement conçu pour l’entreprise O2, donc on utilisera généralement « smtp.o2.fr ».

On peut aussi avoir affaire à un problème de signature sur le mail. Pour résoudre cela, on utilisera un script permettant à un utilisateur lambda de l’installer lui-même.

L’archivage des mails est aussi important, pour ne pas perdre de données. Nous ferons donc en sorte sur chaque employés ait son fichier « .pst » et que celui-ci ne soit pas supprimé avant d’avoir bien vérifié que les données n’ont plus d’importance.

Pour ce qui est du « maildrop », nous le modifierons directement sur le compte de l’utilisateur dans le LDAP. Cela facilite les modifications et permet de faire différentes listes d’envois groupés.

La fréquence de ce type d’intervention se situe à 20% de mon support.

  • Catégorie 2 : Imprimantes :

Les interventions sur les imprimantes sont assez basiques car il s’agit généralement de soucis dus aux voyants. Pour vérifier un potentiel problème technique, on envoie donc la procédure du constructeur aux utilisateurs afin qu’ils vérifient eux-mêmes s’il est possible de débloquer la situation. Après avoir tout vérifié et si la panne est toujours présente alors nous intervenons pour vérifier leur test et, en cas de panne confirmée, nous prenons contact avec le constructeur pour un remplacement de matériel.

Il faut aussi bien vérifier si l’imprimante est toujours ou non sous garantie auprès du constructeur, cela évite des dépenses superflues.

On peut aussi rencontrer un utilisateur qui ne détecte plus l’imprimante ou qui a besoin d’en installer une nouvelle. Dans les deux cas, il suffit de vérifier que l’imprimante est bien branchée et installée sur un PC, et la mettre en partage sur le réseau à partir de celui-ci. Pour les installations des drivers, on prendra simplement la référence de l’imprimante pour rechercher le driver correspondant sur le site du constructeur. Ensuite, il suffit de connecter les différents utilisateurs sur cette imprimante à partir du partage réseau.

La fréquence de ce type d’intervention se situe à 20% de mon support.

  • Catégorie 3 : Gestion des comptes :

La gestion des comptes se sépare en 2 parties : la création d’un compte et la modification de celui-ci.

Pour créer un compte, on se connecte avec Putty sur le LDAP. A partir de là, on lance simplement l’exécutable pour créer le compte avec les différentes informations requises sur le nouveau salarié.

Une fois le compte créé à partir de la console, on pourra le modifier sur une page web. On retrouvera dessus tout l’annuaire et toutes les informations que l’on aura rentrées sur chaque utilisateur dans la console.

C’est donc à partir de cette interface web que l’on pourra modifier plus simplement les données sur chaque utilisateur, que ce soit la modification d’un mot de passe, d’un « maildrop » ou tout simplement d’une suppression du compte.

La fréquence de ce type d’intervention se situe à 10% de mon support.

  • Catégorie 4 : Télégestion :

Je donnerai d’abord une explication concernant la télégestion. Le fonctionnement est simple : les intervenants à domiciles possèdent un téléphone portable munis d’une caméra. Avec celle-ci, ils scannent un QR Code au début et à la fin de leur prestation qui est directement envoyé sur Odyssée. Cette information sur les durées des prestations permet notamment à la direction financière de générer les factures à destination des clients et les paies à destination des salariés.

La télégestion est la partie la plus compliquée pour les interventions. Il faut prendre en compte qu’il y a environ 8000 téléphones portables actifs dans l’entreprise et qu’il faut approvisionner les stocks constamment. Si un intervenant a un téléphone défectueux, il ne peut plus scanner les codes, donc il ne peut plus justifier son temps de travail. Il devient donc nécessaire de bien vérifier la liste des téléphones opérationnels et prévoir une quantité suffisante pour palier à une panne.

Pour cela, nous avons un fichier Excel qui fait l’inventaire de toute la flotte de téléphone portable en entreprise. C’est avec ces renseignements que l’on va vérifier le nombre de téléphones portables disponibles sur chaque agence et en commander, si besoin.

Lorsque les agences envoient une demande pour une commande de téléphones, les mails arrivent sur un serveur IMAP avec une adresse commune à tout le service réseau informatique. Cela nous permet de traiter les demandes plus rapidement en répartissant les tâches entre les différents techniciens. Lorsqu’une demande est validée, on envoie la demande à l’entreprise ASO (qui s’occupe des livraisons de matériaux informatiques avec notre configuration pré-installée) qui s’occupe d’envoyer la commande directement sur l’agence concernée. S’il y a assez de téléphone opérationnel sur le siège, alors c’est à nous d’envoyer la commande à l’agence.

On classe donc les pannes sur 2 branches majeures, matériel et logiciel.

Pour la partie « matériel », si une panne quelconque se déclenche sur un téléphone et que les procédures de dépannage ne donnent rien, il est renvoyé au siège. Celui-ci est alors vérifié par le service informatique, tant au niveau matériel que logiciel. Si le portable est utilisable, il est mis à jour et prêt à être renvoyé en agence. Sinon, les pièces en bon état sont conservées, le reste jeté, et on prend commande d’un nouveau téléphone.

Si une agence a besoin de nouveau téléphone, dû à un recrutement, en plus de son stock actuel, elle nous envoie un mail sur une adresse spécialisée dans les commandes de téléphone. Nous vérifions le nombre de téléphone en stock sur l’agence et nous commandons la quantité de téléphones nécessaire.

Pour la partie « logiciel », il y a plusieurs paramètres à vérifier. Les téléphones sont connectés à un point d’accès nommé « APNO2 », qui permet de transmettre les scanners des intervenants directement sur les serveurs, ce qui permet de suivre leurs interventions. C’est le 1er point à vérifier, car si les paramètres du point d’accès sont mauvais, il y aura une alerte sur odyssée, prévenant que l’intervenant n’a pas respecté son planning, alors que ce n’est peut-être pas le cas. Ensuite, il faut bien vérifier que le logiciel « O2 Mobilité » est bien synchronisé avec le téléphone : le numéro dans « O2 Mobilité » et celui du téléphone doivent être exactement le même, sinon le scanner sera faussé.

Il peut bien évidement y avoir d’autres pannes comme une mémoire pleine ou un bug sur le système du téléphone. Dans ces cas-là, on lancera un « hard reset » sur le téléphone pour qu’il soit comme à la sortie d’usine puis, s’il fonctionne, on reconfigurera tous les paramètres.

Pour faciliter la configuration des téléphones, un serveur SMS a été mis en place. Il permet d’envoyer des SMS pour configurer le point d’accès ou installer le programme « O2 Mobilité » plus rapidement.

Comme le nombre de téléphone est très important, le nombre d’intervention est par conséquent lui aussi très élevé. La charge de travail est donc répartie entre tous les techniciens pour permettre de fournir un nombre de téléphone suffisant pour chaque agence.

Pour chacune de ces interventions, qu’elle soit simple ou non, il faut toujours avoir un choix très rigoureux dans ces propos auprès des utilisateurs. Leur donner trop de détails sur l’intervention pourrait les embrouiller et à l’inverse, ne pas leur fournir assez d’explication donnerait l’impression que le problème n’est pas résolu. C’est pour cela qu’une explication claire est obligatoire, sous peine de voir l’utilisateur revenir quelques instants plus tard avec la sensation que le problème subsiste, vous faisant perdre du temps.

La relation que l’on entretient avec les utilisateurs est un point très important de mon point de vue, car c’est à partir de là que l’on pourra leur apprendre à résoudre quelques soucis de leur côté. En dehors du gain de temps, le travail avec les utilisateurs sera aussi plus agréable.

La fréquence de ce type d’intervention se situe à 50% de mon support.

2°) Présentation du Projet :

Pour mon projet, j’ai décidé de mettre en place un serveur OCS Inventory sur une Debian Linux, ce qui permet d’inventorier le parc informatique automatiquement. Après plusieurs expériences en entreprise, je me suis rendu compte que l’inventaire du parc informatique est souvent géré à la main, en alimentant un fichier Excel basique manuellement, ce qui est une charge de travail souvent importante (selon la taille de l’entreprise bien sûr) et surtout une perte de temps très importante dans la mesure où l’inventaire est rapidement obsolète. Je choisis aussi de le coupler à un GLPI pour obtenir une interface différente de notre inventaire ainsi qu’une gestion des tickets en ajoutant un annuaire LDAP à celui-ci.

L’avantage de mettre en place un serveur comme celui-ci est donc tout simplement d’alléger la charge de travail et d’automatiser l’inventaire du parc informatique. Les ressources nécessaires sont minimes étant donné qu’il ne suffit que d’un serveur pouvant héberger une machine virtuelle Debian. Les éléments pour installer OCS sont en Opensource, donc gratuit, ce qui est un avantage très convaincant dans une entreprise. Pour suivre une installation propre, je me réfère au site wiki.ocsinventory-ng.org/index.php/ qui fournit une explication très détaillée du produit ainsi qu’une aide accessible pour tout novice en linux.

Pour installer mon serveur, je décide de mettre en place une machine virtuelle sur un serveur ProxMox se trouvant sur notre réseau. Je choisis bien sûr de monter cette machine virtuelle sur une plage d’adresse de test. Ainsi j’isole mon serveur et ne perturbe pas les serveurs en production. Je mets en place une Debian (seulement par préférence, libre à chacun de choisir sa licence linux) avec l’adresse 192.168.2.69.

Une fois l’installation de la Debian terminée sur le serveur ProxMox, on se connecte dessus avec Putty. La première manipulation à faire avant de commencer à installer OCS est d’installer tous les modules nécessaires à l’installation :

On commence avec un simple :

apt-get update afin d’avoir tous les paquets disponibles.

apt-get upgrade pour que ceux-ci soient à jour.

Ensuite on installe les paquets « make » et  « build-essential »

apt-get install make

apt-get install build-essential

Avec ces paquets, on peut installer divers éléments nécessaires au bon fonctionnement d’OCS.

On installe ensuite le serveur de base de données :

apt-get install mysql

et on le configure dans :

/etc/mysql/my.cnf

max_allowed_packet = 32 M

On change au passage la ligne

bind-adress=127.0.0.1 en bind-adress=0.0.0.0

ce qui permet de nous connecter à distance sur la base de données (avec SQL yog par exemple) et pas seulement en local.

On passe à l’installation du serveur web et des différents modules :

apt-get install apache 2 php5 php5-mysql php5-gd

apt-get install libxml-simple-perl libcompress-zlib-perl libdbi-perl libdbd-mysql-perl libapache-dbi-perl libnet-ip-perl libsoap-lite-perl
On met à jour CPAN :
perl –MCPAN –e shell

install CPAN

reload CPAN

YAML

XML::Entities

Nmap::Parser

libproc-daemon-perl

exit
apt-get install nmap snmp
Après l’installation de tous ces modules, on passe à l’installation du serveur OCS Inventory NG. Dans ce rapport, j’utilise la version 2.0.5 disponible sur le site : http://www.ocsinventory-ng.org/fr/telechargement/telecharger-serveur.html

On crée notre base de données « ocsweb » :
create database ocsweb;

On télécharge donc le fichier source :
wget https://launchpad.net/ocsinventory-server/stable-2.0/2.0.5/+download/OCSNG_UNIX_SERVER-2.0.5.tar.gz
On décompacte le fichier :

tar -xzf OCSNG_UNIX_SERVER-2.0.5.tar.gz

On lance ensuite l’installation du serveur :

cd OCSNG_UNIX_SERVER-2.0.5

./setup.sh

On suit ensuite l’installation par défaut :

Do you wish to continue ([y]/n)? 
Which host is running database server [localhost] ? 
On which port is running database server [3306] ? 
Where is Apache daemon binary [/usr/sbin/apache2] ? 
Where is Apache main configuration file [/etc/apache2/apache2.conf] ? 
Which user account is running Apache web server [www-data] ? 
Which user group is running Apache web server [www-data] ? 
Where is Apache Include configuration directory [//etc/apache2/conf.d/] ? 
Where is PERL Intrepreter binary [/usr/bin/perl] ? 
Do you wish to setup Communication server on this computer ([y]/n)? 
Where to put Communication server log directory [/var/log/ocsinventory-server] ? 
Do you wish to continue ([y]/n] ? 
Do you allow Setup renaming Communication Server Apache configuration file to 'z-ocsinventory-server.conf' ([y]/n) ? 
Do you wish to setup Administration Server (Web Administration Console) on this computer ([y]/n)? 
Do you wish to continue ([y]/n)? 
Where to copy Administration Server static files for PHP Web Console [/usr/share/ocsinventory-reports] ? 
Where to create writable/cache directories for deployement packages and IPDiscover [/var/lib/ocsinventory-reports] ? 

Pour plus de sécurité, on crée un nouvel utilisateur que l’on nommera « admin ». Comme utiliser le compte root pour se connecter aux bases de données est dangereux, il est conseillé de se servir d’un autre utilisateur.

GRANT ALL PRIVILEGES ON ocsweb.* TO 'admin'@’%’ 
identified by 'password';
flush privileges;
quit

Dans la console mysql, on rentre ces lignes afin de créer un utilisateur « admin » avec mot de passe, ayant tous les droits sur la base de données « ocsweb ». On utilise le signe ‘%’ pour autoriser cet utilisateur à se connecter à distance sur la base de données « ocsweb » avec ses identifiants. On peut maintenant se connecter depuis un autre poste sur notre base de données « ocsweb » avec le compte « admin » :

On édite ensuite le fichier /etc/apache2/conf.d/z-ocsinventory-server.conf pour vérifier que les lignes sont bien correctes :

Nos informations étant correctes, on augmente alors la taille des fichiers qu’Apache peut télécharger dans le fichier /etc/php5/apache2.php.ini :

On redémarre le service Apache :

/etc/init.d/apache2 restart

On modifie maintenant les informations contenues dans /usr/share/ocsinventory-reports/ocsreports/dbconfig.inc.php pour qu’elles correspondent avec celles rentrées précédemment dans notre fichier « z-ocsinventory-server.conf » :

On peut accéder dès lors à l’installation à partir d’une page web en rentrant l’adresse http://192.168.2.69/install.php. On configure alors l’accès à notre base de données :

On obtient alors :

On valide et attend la fin d'exécution du script. A partir de là, la base de données de OCS est bien configurée et le site est accessible avec le login Admin / Admin. On modifie ce compte par défaut dans les options :

Notre site OCS Inventory est installé et prêt à être utilisé. A présent, il nous faut installer un Agent OCS sur un client pour vérifier que les informations sont bien transmises sur le serveur et accessibles à partir de l’interface web.

Installation de l’agent OCS sur un Client Windows :

Notre serveur OCS est installé et prêt à être utilisé. Il faut maintenant installer un agent sur un pc pour tester la transmission de données. Je choisis alors un ordinateur de bureau avec Windows XP et je configure un agent OCS dessus :

On télécharge donc l’Agent sur cette adresse : https://launchpad.net/ocsinventory-windows-agent/2.0/2.0.5/+download/OCSNG-Windows-Agent-2.0.5.zip

L’installation est plutôt simple, il suffit de lancer le setup et de bien rentrer l’adresse sur site lorsqu’il est demandé. Nous rentrons donc les coordonnées comme nous l’avons paramétré précédemment : http://192.168.2.69/ocsinventory

Pour les options suivantes, on laisse par défaut. Nous reviendrons sur le fichier .conf par la suite afin de modifier et expliquer les différentes fonctions. En attendant, l’installation est terminée et l’ordinateur est bien remonté dans la base de données.

Pour mon projet personnel, je décide ensuite de coupler mon OCS inventory avec GLPI.

Configuration du GLPI :

Après avoir installé tous les paquets et modules nécessaires à la mise en place du serveur OCS, il n’est pas nécessaire d’installer des modules complémentaires.

On peut donc télécharger directement l’archive de GLPI :

wget https://forge.indepnet.net/attachments/download/1314/glpi-0.83.6.tar.gz

Puis on décompresse notre archive :

tar –xzf glpi-0.83.6.tar.gz

On copie ensuite le fichier dans notre dossier apache pour y accéder sur une interface web :

cp –r glpi cd /var/www/

Je précise qu’il faut bien donner les droits supplémentaires aux répertoires files/ et config/ :

chmod 777 files

chmod 777 config

On redémarre le service apache : /etc/init.d/apache2 reload

Et maintenant, le reste de l’installation se poursuit sur une page web avec l’adresse de notre serveur : http://192.168.2.69/glpi

Au tout début de l’installation, nous n’aurons qu’à choisir la langue et le début de l’installation. Une première étape va vérifier que tous les modules communiquent bien avec le GLPI :

L’étape suivante nous demande de préciser où se trouve notre base de données et de rentrer notre login pour y accéder :

La connexion faite, on choisit de créer une nouvelle base de données que l’on nommera GLPI_ :

Avant de continuer la configuration de notre gpli, on modifie l’accès à la base de données comme pour notre OCS. On rajoute donc les droits pour la base de données « GLPI_ » à notre utilisateur « admin » :

A présent, notre serveur glpi est installé mais il ne communique pas encore avec notre serveur OCS. Avant de les connecter, il faut modifier les comptes par défaut qui ont été créé, à savoir :

. glpi / glpi pour un compte administrateur

. tech / tech pour un compte technicien

. Ainsi que 2 autres comptes.

On va donc se connecter sur le compte administrateur et modifier tous ces comptes qui ne sont pas vraiment sécurisés :

Je modifie mon propre compte en le nommant root et en changeant mon mot de passe, et je supprime les autres comptes par défaut.

Maintenant que ma connexion est un peu plus sécurisée, je débute la connexion entre GLPI et OCS. Il faut se rendre dans le menu OCSNG que l’on doit activer dans Configuration > Générale > Inventaire. Ici, on active le mode OCSNG :

Dans ce menu OCSNG, devenu accessible, on s’aperçoit alors que la communication se fait bien entre les bases de données d’OCS et de GLPI :

Ensuite, on règle le détail d’information dans l’onglet « options d’importation ». C’est en réglant tous les onglets sur import global que l’on aura un maximum d’information sur notre parc informatique  et sans doublons.

On peut maintenant importer les informations se trouvant sur OCS et les afficher sur GLPI. Dans le menu Outils>OCSNG, on pourra choisir d’importer la nouvelle liste de machines à inventorier sur OCS :

Voici donc les informations de mon ordinateur envoyées sur le serveur OCS avec l’agent, et importer dans GLPI :

Je peux aussi choisir de mettre en place un système de ticket, qui permettra aux utilisateurs de faire diverses demandes à propos d’un souci technique. On relie donc notre LDAP de test avec notre GLPI dans le menu Configuration>Authentification :

Ainsi, dans le menu « Annuaires LDAP », on choisit de rajouter un nouveau lien vers notre annuaire de test :

Une fois le lien fait, on importe tous les utilisateurs de l’annuaire dans le menu Administration>Utilisateurs>Annuaires LDAP :

Maintenant, nous avons toute une liste d’utilisateurs faisant partie de notre domaine ayant la possibilité de poster des tickets sur l’adresse de notre GLPI en se loguant avec leur Login de session habituel.

Après avoir terminé cette installation, on lancera un backup de notre serveur à partir du ProxMox pour avoir une image propre pour une éventuelle restauration en cas de problème :

On pourra choisir de restaurer cette image à partir de l’interface web ProxMox si besoin.

Pour rajouter une sécurité supplémentaire, on configure un script qui fera un backup hebdomadaire de notre base de données. On se sert ensuite de cron pour l’exécuter quotidiennement. On installera le script dans la racine/root sous le nom « dump »:

Je choisis de faire un script supplémentaire pour un backup de GLPI sous le nom de « dumpglpi »

On rend ensuite le script exécutable avec cette commande :

chmod ug+x /root/dump

On édite maintenant le fichier crontab pour y ajouter une tâche :

crontab –e

Voici les modifications que l’on y apportera :

Cette modification indique que le backup des bases de données « ocsweb » et « GLPI-» se fera tous les lundi, mardi, mercredi, jeudi et vendredi à 14h40.

On vérifie alors si notre backup s’est bien effectué :

On s’aperçoit alors que notre back up a bien eu lieu le vendredi 19/10/2012 à 14h40.

3.3. Difficultés rencontrées :

Lors de la mise en place de ce projet, j’ai été confronté à différents problèmes. Le temps dont nous disposons est assez restreint et des imprévus sont vite arrivés. J’ai pris du retard par exemple avec certains utilisateurs n’ayant aucune connaissance en informatique et ne possédant plus de connexion internet. L’intervention se faisant alors par téléphone, il faut diriger l’utilisateur en « aveugle » pour apporter une solution, ce qui est très compliqué quand celui-ci vous apporte des informations peu claires ou peu exploitables.

D’autres pertes de temps sont survenues lors de la mise en place du serveur OCS/GLPI. Quelques erreurs basiques, dont la modification des fichiers de configuration du MySQL et de Apache sont survenues au début du projet. Elles furent corrigées après avoir consulté les logs et les types d’erreur puis recherché leur solution sur différents forums sur internet.

Ensuite, une fois le serveur mis en place, j’ai tenté d’optimiser la sécurité en paramétrant le SSL. Par manque de temps, je n’ai pu paramétrer tout ce que je voulais, à savoir une connexion forcée sur un https. La connexion sur https était disponible mais le blocage sur le http ne s’est pas fait. Après avoir modifié mes fichiers de configuration, je bloque d’avantage en forçant une connexion avec une validation de certificat, ce qui se solde par un échec à cause d’une erreur lors de la conception de mon certificat. Lors de mon test, la connexion nécessitait bien une validation de certificat, mais celui-ci étant erroné, l’interface web de mon serveur n’était plus accessible.

Si j’avais eu plus de temps disponible, j’aurais de nouveau modifié la génération de certificat et au passage, j’aurais apporté une solution de télé déploiement des agents sur les différents postes clients.

3.4. Apprentissages effectués :

Durant cette PAE, je pense avoir acquis une bonne expérience en entreprise. Grâce au support, j’ai développé une meilleure compréhension et relation avec les utilisateurs de ressources informatiques. En effet, il faut apprendre à adopter un langage simple sans utiliser de détail technique. On vulgarise l’informatique afin de dépanner plus rapidement les utilisateurs. Cela demande un temps d’adaptation en fonction des utilisateurs qui s’y connaissent ou pas.

L’architecture étant sous Linux, j’ai grandement développé mon expérience personnelle sur ce système. Etant plus habitué au système Windows Server, je ne pouvais qu’apprendre en me retrouvant face à cette configuration. Le fait de construire un serveur sur un OS que l’on ne maîtrise pas forcément, fait que l’on apprend à maîtriser chaque modification que l’on apporte dessus. En établissant les liens entre chaque service, on développe notre compréhension petit à petit ainsi que notre intérêt. Ayant appris essentiellement sur Windows, j’ai eu moins de facilité à commencer mon projet sous Linux. Mais je me suis surtout aperçu que j’avais beaucoup plus de personnalisations possibles sur Linux que sous une licence Windows. De plus, tout le service que j’ai construit ne coûte absolument rien en terme de licence, ce qui est un atout très fort pour une entreprise.

Ce système ayant un coût très réduit, il est possible que je sois amené à rencontrer ce type d’organisation dans une entreprise future. En effet, ayant regardé différentes offres d’emploi sur le marché, j’ai pu constater que beaucoup d’entreprises demandaient une certaine connaissance en Linux et moins sur Windows. Ce stage m’aura donc apporté beaucoup pour mes projets futurs.

4. Conclusion :

Je tiens tout d’abord à remercier l’équipe qui m’a vraiment très bien accueilli durant ces 2 mois. Elle a toujours été présente lorsque je rencontrais des problèmes, et toujours disponible pour répondre à mes questions. Ce stage a répondu à mes attentes car je voulais m’entraîner sur une architecture Linux. J’ai trouvé ce travail très intéressant et enrichissant puisqu’il s’agissait pour moi d’un domaine peu connu où j’aimerais améliorer mes compétences.

J’ai pu atteindre la plupart de mes objectifs. La construction d’un serveur permettant d’inventorier, l’apport d’une aide aux utilisateurs et l’amélioration de mes compétences en entreprise. Avec cette expérience supplémentaire, j’acquiers certains automatismes dans la gestion de temps et le travail en groupe. L’intégration dans de futurs groupes se fera plus simplement et plus rapidement pour un travail meilleur.

Annexe Installation :
  1   2

similaire:

Rapport de Paul-Louis rageot iconLes Deux Coeurs de Louis XVII par Laure de La Chapelle
«Il s’agit du coeur d’un parent de Marie-Antoinette, mais c’est aux historiens de démontrer que c’est Louis xvii», nous avons vu...

Rapport de Paul-Louis rageot iconDrouot richelieu vendredi 25 fevrier – salle 2 à 14h
«Louis»; ou encore une lettre du roi pour la convocation des États de Bourgogne datée du 30 mars 1671, donnée à Saint-Germain-en-Laye,...

Rapport de Paul-Louis rageot iconLouis Moinet est né à Bourges, en 1768. Au collège, IL se fait remarquer...
«le développement et l’encouragement de l’horlogerie, l’une des plus belles sciences de l’esprit humain». Dans ce cadre, IL entretient...

Rapport de Paul-Louis rageot iconLe rapport de la commission animée par le sénateur Louis de Brossia...
Partager les informations susceptibles de permettre sa (celle de l’enfant) protection ! Cette formulation s’impos–t-elle comme telle...

Rapport de Paul-Louis rageot iconHist. 11 Louis XIV : l’absolutisme (1661-1715)
«la Cour». Les nobles deviennent dépendants de Louis XIV et cherchent à lui plaire. Le roi contrôle aussi les artistes et les écrivains....

Rapport de Paul-Louis rageot iconAtelier de l’artiste avec les dessins préparatoires pour les murs...
«ouvert» une dernière fois en septembre 2012 pour les journées du patrimoine. Ernest Pignon-Ernest et d’autres artistes ont été invités...

Rapport de Paul-Louis rageot iconBibliographie générale Sources Addison Joseph, Remarks on Several...
«Nouvelle Salle de l’École des beaux-arts, peinte par M. Paul Delaroche», La Presse, 12 décembre 1841

Rapport de Paul-Louis rageot iconPaul Beliveau

Rapport de Paul-Louis rageot iconPaul wilmott contact

Rapport de Paul-Louis rageot iconIncandela jean-Paul








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com