Trace: » Bonnes pratiques

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.

Avant de vous lancer

Vous pouvez regarder les présentations du projet GLPI présentes sur le wiki.

Il ne sert à rien de se lancer tête baissée dans l'installation de GLPI. Il convient tout d'abord de comprendre :

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.)

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.

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
  • FIXME : complèter avec les autres distributions

Il existe une procédure d'installation de GLPI sur le wiki.

Bien mettre en place OCS

FIXME

  • 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 ?

Entités

L'idée de la multi-entité est de fournir un GLPI permettant de segmenter la gestion des parcs tout en permettant une consolidation facile des données des différents parcs. Cela peut-être intéressant pour une entreprise dont la gestion est hierarchique et où les personnes doivent avoir une vision du parc à différents niveaux. Un utilisateur pouvant être rattaché à plusieurs entités avec des droits différents. Ces droits pouvant être être conservés sur les entités filles ou non.

Exemples :

  • une société qui gère plusieurs clients : on peut définir une entité par client
  • une administration qui dispose de directions et unités : il peut être intéressant d'utiliser les entités (à bon escient, comme nous le verrons par la suite)

Groupes

Cette notion permet de faire des regroupements. Ceux-ci peuvent être de différentes natures :

  • groupement d'utilisateur, pour gérer des groupes de compétence pour le Helpdesk par exemple
  • services : permet de regrouper des matériels, tickets et utilisateurs afin de recréer la notion de service

Lieux

Le lieu permet de placer géographiquement des matériels et des utilisateurs. Ils sont définis telle une arborescence, afin de représenter au mieux ce qu'il y a dans la réalité.

Exemple :

20 rue de Paris > Batiment A > 1r étage > Salle 225

Récursivité

La récursivité consiste à rendre visible dans les sous-entités un objet. Cela permet de traiter les problèmatiques d'objets globaux/locaux.

Exemple :

  • un fournisseur global à toutes les entités sera déclaré dans l'entité la plus haute, récursif (sous-entités à oui dans l'interface)
  • un fournisseur local : sera déclaré dans l'entité auquel il se rattache (sous-entité à non)

Quand choisir d'utiliser des entités ou des groupes ?

FIXME : 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

Il faut bien définir en amont les différents 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

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).

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 profils 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

  1. Recensez les données à récupérer
  2. 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

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.

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 :

  1. Créez un modèle d'injection pour votre matériel réseau
  2. Injectez votre matériel réseau en indiquant dans les mappings le nombre de ports du matériel
  3. 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)
  4. Créez un modèle d'injection d'ordinateurs
  5. Injectez vos ordinateurs en indiquant dans les mappings le nom de l'actif réseau et port sur lequel il sera connecté
  6. 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

OCS Inventory NG et GLPI sont en place, que faire ensuite ?

Maintenant que tout votre système est en place, vous pouvez regarder :