Trace: » 7 - Partie Administration

7 - Partie Administration

Utilisateurs

Cette partie fonctionne exactement de la même façon que les éléments de l'inventaire. Vous pouvez ajouter, modifier, supprimer des utilisateurs ou rechercher et exporter la liste des utilisateurs. Vous pouvez aussi exporter la liste des utilisateurs en PDF, SYLK ou CSV.

Vous pouvez aussi désactiver des utilisateurs si besoin.

Au niveau des droits : par défaut, vous avez le choix entre 4 profils :

  • Super-Admin : Accès à toute la console centrale de GLPI et au paramétrage de l'application.
  • Admin : Accès à toute la console centrale de GLPI et à la modification tous les éléments excepté la configuration.
  • Normal : Accès à toute la console centrale de GLPI uniquement en lecture seule.
  • Post-only : Accès à la partie Helpdesk de GLPI (Nouveau ticket / Suivi des tickets / Réservation et FAQ publique.

Tous les droits peuvent être modifiés depuis la version 0.68 avec la gestion des profils (voir plus bas). De plus L'affichage de la gestion des utilisateurs dépend du profil de l'utilisateur connecté.. Il peut donc varier selon le profil.

Groupes

La version 0.68 de GLPI introduit la notion de groupes. Elle permet de rassembler des utilisateurs dans des groupes afin d'attribuer des matériels à ces groupes et permettre un suivi de ces matériels communs.

Si vous utilisez l'authentification externe, vous pouvez importer directement vos utilisateurs dans des groupes créés préalablement dans GLPI.

L'affichage de la gestion des groupes dépend du profil de l'utilisateur connecté. Il peut donc varier selon le profil.

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 hiérarchique et où les personnes doivent avoir une vision du parc à différents niveaux.

L'idée de la multi-entité est d'ajouter une couche supplémentaire pour créer des ensembles avec des droits qui leur sont propres. Ces ensembles s'appellent des entités.

Exemple : On considère la hierarchie suivante :

          EM
    |------|------|
   EA            EB
  |   |        |    |
EA1   EA2     EB1   EB2

L'entité mère (EM) possède deux filiales (EA et EB) qui possèdent à leur tour deux départemts chacune (EA1, EA2, EB1 et EB2). Chaque entité possede une vision de son parc et des entités qui lui sont affiliées.

  • EM a une vision de son parc et de toutes les entités.
  • EA a une vision de son parc et de EA1 et EA2
  • EA1 ne voit que son parc.

Un utilisateur pouvant être rattaché à plusieurs entités avec des droits différents. Ces droits pouvant être conservés sur les entités filles ou non.

Par défaut, cette version s'installe avec une entité générique, appelée entité racine.

Dans cette interface vous pouvez donc créer de nouvelles entités, modifier des entités existantes, ou les supprimer.

L'utilisation des entités n'est pertinente que si vous souhaitez disposer d'un cloisonnement relativement étanche entre les unités organisationnelles (multi-parcs par exemple). Dans beaucoup d'autres cas, il est préférable d'utiliser les fonctionnalités offertes par les “groupes”.

L'affectation automatique des utilisateurs et des matériels est possible grâce au paramétrage de règles.

Règles

Il est possible dans GLPI de définir un ensemble de règles chargé de réaliser des actions automatiquement.

Règles d'affectation des utilisateurs

Il existe 2 types de règles d'affectations :

  • règles d'affectation statiques : la règle a été définie pour un utilisateur donné par l'administrateur
  • règles d'affectation dynamiques : la règle est définie en utilisant le moteur de règles. Son exécution est automatique et ne nécessite aucune action de l'administrateur

Il existe une règle implicite qui affecte les profils ayant l'attribut “Profil par défaut” (post-only en standard) lors de la création d'un utilisateur. Pensez à modifier cet attribut si vous ne souhaitez pas ce comportement.

Ne pas oublier de supprimer l'affectation à l'entité racine qui a été faite par le script de migration . En effet, si vous ne le faites pas, l'utilisateur aura à la fois le profil que vous allez définir, plus l'appartenance à l'entité racine !

Une règle est composée de :

  • un nom, une description et un rang
  • une liste de critères (extensibles)
  • 3 actions
    • assigner une entité
    • assigner un profil
    • droit d'accès récursif oui/non

le moteur ne s'arrête pas après la première règle vérifiée

il est possible d'affecter plusieurs profils/entités à une personne

Points importants concernant les règles d'affectation des utilisateurs

Pour qu'un utilisateur puisse accéder à une entité, il faut qu'il matche :

  • soit une règle qui donne affectation à une entité et affectation d'un profil
  • soit une règle qui donne affectation à une entité ET une autre qui donne affectation d'un profil

Si une règle indique juste l'affectation d'un utilisateur à une entité, alors le profil par défaut sera appliqué automatiquement pour celle-ci.

Il est possible de combiner les 2 types de règles :

  • une règle A définissant l'accès à une entité 1
  • une règle B définissant l'accès à une entité 2
  • une règle C affectant un profil P1 à l'utilisateur
  • une règle D définissant l'accès à l'entité 3 avec le profil P2

Le moteur va exécuter les règles dans l'ordre suivant :

  • affectation à l'entité 3 avec profil P2
  • affectation à l'entité 1 avec profil P1
  • affectation à l'entité 2 avec profil P1

Règles d'affectation des machines

Les machines sont affectées automatiquement à une entité via une règle.

Une règle est composée de :

  • un nom, une description et un rang
  • une liste de critères (extensibles)
  • 1 actions : assigner une entité

Le moteur s'arrête après la première règle vérifiée

L'ordre d'exécution des règles est important

Il faut optimiser l'ordre d'exécution des règles en fonction du nombre de machines qui vont remonter (mettre en premier les entités qui auront le plus de machines, pour améliorer les performances du moteur de règles)

Règles d'affectation des logiciels à une catégorie

Avec la version 0.70, il est désormais possible de grouper des logiciels par catégories afin de simplifier l'affichage dans la liste des logiciels d'un ordinateur.

Des exemples de règles sont disponibles sur le wiki développeur

Dictionnaires

Depuis la version 0.71, il est possible de définir des dictionnaires.

Ces dictionnaires permettent de disposer de règles qui vont modifier les valeurs de certaines données remontées par OCS. A l'heure actuelle, celles-ci sont :

  • nom du logiciel
  • version du logiciel
  • fabricants
  • modèles (ordinateurs, moniteurs, imprimantes, réseau, téléphones, périphériques)
  • types (ordinateurs, moniteurs, imprimantes, réseau, téléphones, périphériques)
  • OS (nom, service pack, version)

Les dictionnaires sont lancés pendant les traitements automatiques suivants :

  • l'import OCS
  • l'injection de fichiers CSV
  • l'ajout d'un intitulé

Il est possible de lancer le dictionnaire sur des données déjà en base :

  • dans le formulaire de liste des règles, cliquez sur le bouton “Rejouez le dictionnaire”
  • pour les logiciels : sélectionner massivement et choisissez “Rejouer le dictionnaire” dans la liste des logiciels

Fonctionnement du dictionnaire

Le dictionnaire fonctionne de la manière suivante :

  • la donnée à entrer à base (provenant d'OCS ou du plugin data_injection) passe par le dictionnaire
  • le moteur de règle rejoue toutes les règles concernant ce type de données, et s'arrête à la première vérifiée
  • la donnée modifiée est retournée par le dictionnaire et insérée en base

Pour réappliquer le dictionnaire sur une base existante, il suffit d'aller dans la liste des règles de celui-ci, et de cliquer sur le bouton “Rejouer le dictionnaire”. Dans le cas du dictionnaire des logiciels, il est possible de préciser un fabricant, afin de limiter l'exécution du moteur à celui-ci (l'application sur l'ensemble des logiciels est longue).

A noter : un script est disponible dans le répertoire scripts de GLPI (compute_dictionnary.php), qui permet de lancer les dictionnaires depuis la ligne de commande. Cela permet de s'affranchir des problèmes de limite d'exécution, et propose un gain de temps apréciable.

Pré-requis

Si votre base est conséquente, il vous faudra faire bien attention à la valeur du memory_limit de PHP. En effet, les traitements peuvent être très longs.

Dictionnaire des logiciels

Ces règles permettent de modifier les informations suivantes d'un logiciel :

  • nom du logiciel
  • version
  • fabricant

L'utilisation d'expressions régulières (regex) permet de renseigner le numéro de version d'un logiciel depuis son nom.

Par exemple pour le logiciel suivant :

  • nom : MyCompany MySoft v6.4
  • version : 1
  • fabricant : aucun

Il est possible de faire une règle qui permet de transformer ses données en :

  • nom : MySoft
  • version : 6.4
  • fabricant : MyCompany

Des exemples de règles sont disponibles sur le wiki

Dictionnaire des fabricants

Ce dictionnaire permet de nettoyer la liste des fabricants.

Profils

La version 0.68 de GLPI introduit la notion de profils. Il est possible de gérer l'ensemble des droits de l'application GLPI à l'aide de profils et de les associer aux utilisateurs.

Vous pouvez donc créer des nouveaux profils, modifier des profils existants, ou les supprimer.

2 interfaces sont configurables :

1. Helpdesk

Cette interface rassemble les droits liés au helpdesk publique : Créer un ticket, ajouter des suivis, voir les suivis publics (les siens et ceux des intervenants sur le tickets), voir les tickets de ses groupes, l'accéder aux réservations, à la FAQ et modifier son mot de passe.

La liaison avec les matériels pour la création de tickets vous permet de choisir si l'utilisateur peut poster des tickets uniquement sur le matériel auquel il est rattaché (champ utilisateur dans le détail d'un matériel) ou s'il peut poster sur tout le matériel de l'inventaire. De plus, grâce à la zone de sélection, vous pouvez spécifier sur quel type de matériel, il peut faire des demandes d'interventions.

2. Centre de contrôle

Cette interface rassemble les droits liés à la console centrale, et donc à tout ses composants (inventaire, assistance, gestion, outils, plugins, administration).

  • Inventaire

Accès, lecture, écriture sur l'ensemble des matériel inventoriés. Ceci permet de configurer, l'accès au détail du matériel ainsi que la gestion des champs le concernant.

  • Général

Accès, lecture, écriture sur l'onglets notes dans le détail d'un matériel, à la modification de son mot de passe, ainsi qu'aux notes publiques présentes sur l'accueil de la console centrale.

  • Gestion

Accès, lecture, écriture sur les documents, les entreprises, et les informations financières de matériel.

  • Assistance

Accès, lecture, écriture sur la partie Helpdesk de la console centrale de GLPI.

  • Outils

Accès, lecture, écriture sur le mode OCS-NG, les rapports, la réservation, la base de connaissances et la FAQ publique. NB : la base de connaissances se différencie de la FAQ publique par le fait que celle-ci affiche les items publics et privés contrairement à la FAQ publique qui n'affiche que les items publics.

  • Administration

Accès, lecture, écriture sur la configuration de GLPI.

Si vous supprimez le profil super-admin ou si vous l'associez dans “Droits de l'interface Helpdesk” en tant que Profil par défaut, l'accès à la configuration de GLPI peut être définitivement perdue.

L'affichage de la gestion des profils est fonction du profil dont l'utilisateur connecté dépend. Il peut donc varier selon le profil.

Transferts

Depuis la version 0.70 de GLPI et l'apparition de la notion “d'entités”, il est possible de définir des profils de transferts pour les mutations d'éléments entre entités.

Cette fonctionnalité permet notamment de passer d'un GLPI mono entité à un GLPI multi-entités en utilisant les transferts.

Comment faire un transfert :

  1. il faut que vous ayez un profil qui est le droit de faire des transferts (Administration/Profil/Partie Administration)
  2. il faut configurer les actions faites par le transfert (Administration/Transfert)
  3. il faut que le profil qui va effectuer le transfert ait une visibilité sur l'entité cédante et sur l'entité prenante (le plus simple est d'utiliser un profil récursif depuis l'entité racine)
  4. positionnez-vous sur l'entité racine
  5. depuis la liste des machines, vous sélectionner celle à transférer
  6. choisissez Tranférer et Valider
  7. dans Mode de transfert, vous verrez la liste des configurations de transfert créée en point 2
  8. sélectionnez l'entité dans laquelle sera transféré le matériel
  9. cliquez sur Transférer
  10. vérifiez dans la nouvelle entité que le matériel s'y trouve bien

Attention : le lieu et le groupe seront à adapter pour la nouvelle entité

Données / Sauvegarde

Edité par Jérémy Hernandez

1. Introduction


Il est possible de faire une sauvegarde des données de la table automatiquement de la base de données glpi directement dans le système.

Avant toutes modifications, se référer à cette documentation du wiki:

http://www.glpi-project.org/wiki/doku.php?id=fr:config:crontab

2. Recommendations


Pour cela, il faut implémenter un petit script bash qui va effectuer la sauvegarde et la déposer dans le répertoire ../glpi/files/_dumps sous la forme d'un fichier .sql

Il est nécessaire de prévoir donc les droits d'écriture dans ce répertoire. Et d'avoir des accès admin sur le serveur de bases de données MySQL.

3. Script backup.sh


Créer le script suivant à travers votre éditeur de texte préféré et le sauvegarder avec l'extension .sh

#!/bin/sh
user="-u root"
mdp="-pvotremotdepasse"
chm="/srv/www/htdocs/glpi/files/_dumps"
 
# Dump base GLPI
 
mysqldump $user $mdp glpi > $chm/$(date +%Y-%m-%d).glpi.backup.sql

4. Ordonnancement


Il faut maintenant paramétrer l'ordonnanceur, soit la crontab en lançant la commande suivante:

crontab -e

Il faut alors ajouter la ligne suivante pour effectuer la sauvegarde quotidienne:

55 23 * * * sh /srv/www/htdocs/glpi/backup.sh

5. Résultats


Ainsi, la base de données GLPI est sauvegardée quotidiennement et est recopiée dans le répertoire _dumps.

http://www.glpi-project.org/wiki/lib/exe/fetch.php?media=fr:manuel:admin:test.gif

6. Avantages et bénéfices


L'avantage de cette sauvegarde automatisée permet à l'administrateur d'avoir une reprise d'activité instantanée si la base GLPI est corrompue dans la nuit et ainsi bénéficier d'une sauvegarde fraiche de la veille.

Jérémy Hernandez 2009/08/26 15:36—-=)

Journaux

Cette zone vous permet de visualiser et de trier l'historique des logs. Le degré et la conservation des logs est paramétrable dans le menu Configuration - Générale - Niveau de journalisation .