Differences

This shows you the differences between two versions of the page.

Link to this comparison view

fr:manuel:bonnespratiques [2008/11/27 12:48]
wawa
fr:manuel:bonnespratiques [2015/07/03 11:46]
Line 1: Line 1:
-====== Bonnes pratiques ====== 
-[draft] 
-Ce document a pour but de synthétiser les bonnes pratiques et retours d'​expériences accumulés par les déploiements d'OCS et GLPI en entreprise. 
  
-===== Installation de GLPI ===== 
-==== Versions ==== 
- 
-Il est fortement déconseillé d'​installer en production :  
-  * des versions RC 
-  * des versions svn 
- 
-Ceci est valable à la fois pour GLPI mais aussi pour les plugins. 
- 
-Pour les plugins, il faut s'​assurer que : 
-  * le plugin est déclaré stable 
-  * qu'il fonctionne avec la version GLPI que vous installez 
-  * que vous avez bien les bons pré-requis (version de PHP, OS, etc.) 
- 
-<note warning> 
-Aucune assurance de qualité du code n'est mise en place pour les plugins. Leur réalisation peut varier en fonction de la personne qui les écrit. 
-Le nom des mainteneurs est écrit dans la liste des plugins sur le site GLPI. 
-</​note>​ 
- 
-==== Plate-forme ==== 
-OCS Inventory et GLPI supportent les plate-formes suivantes : 
-  * Linux 
-  * Unix 
-  * Windows 
-  * Mac OS X 
- 
-Sur Linux, certaines distributions proposent en standard des paquets pour les 2 logiciels : 
-  * Fedora/​Redhat/​CentOS : OCS et GLPI, ainsi que quelques plugins sont disponibles dans les dépôts officiels 
-  * Debian : propose OCS et GLPI dans les dépôts ​ 
-  * Mandriva 
-  * TODO : complèter avec les autres distributions 
- 
-Il existe une [[fr:​install:​tutoriauxdistrib|procédure d'​installation de GLPI]] sur le wiki. 
- 
-===== Bien mettre en place OCS ===== 
-TODO : 
-  * parler de l'​importance du TAG 
-  * gestion des doublons 
- 
-==== Déploiement des agents OCS ==== 
-Il est nécessaire de bien penser le déploiement des agents OCS. 
-Il faut prendre en compte les données suivantes : 
-  * type de plate-formes (Windows, Linux, Unix, Mac OS X, etc.) 
-  * la méthode de déploiement attendue (automatique pour les postes clients, manuelle sur les serveurs) 
-  * la présence d'un contrôleur de domaine Windows avec Active Directory 
-  * le nombre de TAGs qui seront utilisés 
- 
-Sur Unix et Linux il n'​existe pas de procédure automatisée de déploiement de l'​agent. 
-Il est possible par contre d'​utiliser les paquets fournis par les distributions (si disponible, comme par exemple pour Fedora/​Redhat/​CentOS). 
- 
-Sur Windows il est possible de déployer de manière automatisée l'​agent. En effet, le projet OCS met à disposition un exécutable nommé OcsLogon.exe qui offre les fonctionnalités suivantes : 
-  * vérification de l'​installation de l'​agent 
-  * installation de l'​agent et mise en service de celui-ci 
-  * mise à jour de l'​agent 
- 
-===== Avant de mettre en place GLPI ===== 
- 
-==== Quand utiliser des entités, des groupes et des lieux ? ==== 
-TODO : expliquer ce qu'​entraine chacun de ces concepts 
- 
-==== Définition des entités et des lieux ==== 
-Il est préférable de bien expliquer la notion d'​entité et de lieux. En effet, ces notions sont structurantes pour la  mise en place de l'​application dans un contexte client. 
-Une bonne pratique est de définir avec le client, sur papier, la hiérarchie à implémenter. ​ 
- 
-Attention : un grand nombre d'​entités peut ralentir l'​application et peut entraîner un gros surplus de règles ! 
- 
-==== Création de règles d'​affectation des machines à des entités ==== 
-l faut bien définir en amont les différences critères d'​affectation des machines à des entités. 
-L'​utilisation du plugin mass_ocs_import permet d'​aider à la vérification et à l'​affinage des règles. En effet il dispose d'un onglet qui liste les machines non importées, avec l'​affichage de données provenant d'OCS. Ainsi, on peut détecter quels critères ne vérifient pas la règle. 
- 
-Dans le cas d'un environnement avec beaucoup d'​entités,​ il pourra être intéressant d'​utiliser le mode opératoire suivant : 
-  * déployer l'​agent OCS sur une seule machine de l'​entité 
-  * vérifier que le processus de synchro fonctionne et que la machine est remontée dans GLPI 
-  * vérifier les données remontées dans GLPI par rapport à celles d'OCS 
-si les données sont correctes, lancer le déploiement des agents sur les postes 
- 
-<note warning> 
-Attention : afin de gagner en performances il faut connaître le fonctionnement du moteur de règles. Dans le cas des affectations de machines à des entités, il s'​arrête à la première règle trouvée. Il convient donc de placer en premier de la liste les règles qui vont être appliquées le plus de fois (c'est à dire les règles d'​affectation au entités les plus grosses). 
-</​note>​ 
- 
-==== Définition des profils ==== 
-De la même manière qu'il est préférable de définir la hérarchie des entités avant de commencer la configuration de GLPI, il est préférable de penser aux profls des personnes. 
-Il est important de bien étudier les profils par défaut de l'​application,​ car ceux-ci répondent ​ à des besoins génériques. 
- 
-=== Gestion centralisée des habilitations depuis l'​annuaire LDAP === 
-Les règles d'​affectation des droits et des profils permettent de déléguer la gestion quotidienne des habilitations à l'​annuaire LDAP. 
-En général on associe un profil GLPI à l'​appartenance à un groupe LDAP. 
-Une règle d'​affectation permet : 
-  * d'​affecter une entité une personne 
-  * un profil à une personne 
-  * activer/​désactiver une personne 
-  * d'​affecter une entité et un profil à une personne 
- 
-=== Mapping des groupes GLPI avec des groupes LDAP === 
-GLPI offre la possibilité de faire la correspondance entre des groupes crées dans sa base et d'​autres qui proviennent de l'​annuaire. 
- 
-===== Migration vers GLPI depuis un autre système de gestion de parc ===== 
-L'​installation d'OCS et GLPI peut intervenir dans les cas suivants : 
-mise en place d'un système de gestion de parc dans un environnement vierge 
-migration d'un système de gestion de parc existant (libre ou propriétaire) 
-« automatisation » de la gestion du parc, là où cela était géré manuellement auparavant (par exemple dans une feuille Excel ou Calc) 
- 
-Dans les 2 derniers cas, il est possible de récupérer des données du système existant, afin de  ne pas les resaisir manuellement dans GLPI. Ce processus utilise le plugin d'​injection de fichiers CSV. 
- 
-===Export des données existantes === 
-  - Recensez les données à récupérer 
-  - Réalisez un export au format CSV : 
-    * depuis une feuille Excel ou Calc, cette opération est facile 
-    * depuis un outil existant, utilisez les capacités d'​export de celui-ci, ou réalisez des scripts afin d'y arriver 
- 
-<note warning> 
-Il faut réaliser un fichier CSV par type de données à importer dans GLPI. Par exemple : 
-  * un fichier pour les machines 
-  * un pour les matériels réseau 
-  * etc. 
-</​note>​ 
- 
-==== Import des données dans GLPI ==== 
- 
-=== Préparation avant l'​injection dans une base de production === 
-Il peut être judicieux de monter une plate-forme de qualification afin de faire un test des données à injecter, avant de « polluer » sa base de production en cas d'​erreur. 
-Cette plate-forme se compose de : 
-  * un GLPI avec une copie de la base de production 
-  * le plugin data_injection 
- 
-Définissez vos modèles de fichiers dans le plugin et testez les. A la fin de l'​import des données sont générés : 
-  * un rapport (en HTML ou PDF) sur l'​exécution des scripts 
-  * un fichier CSV ne contenant que les lignes n'​ayant pû être injectées 
- 
-=== Injection des données en production === 
-1.Installez le plugin d'​injection de données CSV (data_injection) sur le GLPI de prod.  
-2.Créez des « modèles » ​ à partir de ceux de la base de qualification. 
-3.Vérifiez l'​ordre dans lequel vous allez injecter des données (voir exemples ci-dessous) 
-4. Vérifiez que le données ont bien été inséré 
- 
-Exemple : 
-Vous récupérez d'un outil précédent les information financières de machines existantes (date d'​achat,​ durée de garantie, etc.) ainsi que les connexions à un actif réseau (nom de l'​actif + port) 
-Vous exportez de cet outil les matériels réseau qui ne seront pas remontés par OCS (hubs, switchs). Vous disposez du nombre de port par matériel. 
-Procédure : 
-  - Créez un modèle d'​injection pour votre matériel réseau 
-  - Injectez votre matériel réseau en indiquant dans les mappings le nombre de ports du matériel 
-  - GLPI  va créer les matériels et les ports associés (si vous injectez un switch 16 ports, alors 16 ports seront crées automatiquement dans GLPI) 
-  - Créez un modèle d'​injection d'​ordinateurs 
-  - Injectez vos ordinateurs en indiquant dans les mappings le nom de l'​actif réseau et port sur lequel il sera connecté 
-  - GLPI va créer l'​ordinateur et va tenter de le connecter au port de l'​actif spécifié automatiquement 
- 
-===== Connexion OCS/GLPI ===== 
-GLPI s'​interface nativement avec OCS Inventory, afin de récupérer son inventaire automatique. 
-GLPI peut : 
-  * agréger les données de plusieurs serveurs OCS 
-  * remonter les données matérielles 
-  * remonter les logiciels (avec ou sans le dictionnaire OCS) 
-  * remonter les clefs de registre des machines Windows 
- 
-GLPI ne peut pas : 
-  * modifier la configuration d'OCS 
-  * mettre à jour le dictionnaire OCS 
-  * piloter le déploiement d'​applications OCS