Trace: » Best Practices

Best Practices

[draft] This document is intended to summarize good practice and feedback accumulated deployments of OCS and GLPI enterprise.

Before you start

You can read the GLPI project documentation on the wiki.

Before installing GLPI, you should first understand:

Installing GLPI

Versions

It is strongly recommended to install in production:

  • RC versions
  • svn versions

This applies both to GLPI and to the plugins.

For plugins, we must ensure that:

  • the plugin is declared stable
  • it works with the version that you install GLPI
  • that you have the right prerequisites (PHP version, OS, etc.).

No assurance of quality of the code is implemented for the plugins. Their implementation may vary depending on who writes them. The names of the maintainers is written in the list of plugins on the site GLPI.

Platform

OCS Inventory and GLPI support the following platforms:

  • Linux
  • Unix
  • Windows
  • Mac OS X

On Linux, some distributions provide standard packages for OCS and GLPI:

  • Fedora / Redhat / CentOS: OCS and GLPI and some plugins are available in the official repositories
  • Debian: OCS and GLPI offers in deposits
  • Ubuntu: OCS and GLPI available in universe
  • Mandriva
  • FIXME: fill with other distributions

There is a procedure for installing GLPI on the wiki.

While setting up OCS

FIXME

  • talk about the importance of the TAG
  • management of duplicates

Deployment of OCS

It is necessary to consider the deployment of OCS. Take into account the following:

  • type of platforms (Windows, Linux, Unix, Mac OS X, etc.).
  • the method of deployment expected (automatic for the client, manually on the servers)
  • the presence of a Windows domain controller with Active Directory
  • the number of tags that will be used

On Unix and Linux there is no automated process to deploy the agent. It is possible to use against the packages provided by the distributions (if available, for example for Fedora / Redhat / CentOS).

On Windows it is possible to automatically deploy the agent. Indeed, the SCO provides an executable named OcsLogon.exe offers the following features:

  • verification of the agent installation
  • installation of the agent and operation thereof
  • Update Agent

Before setting up GLPI

When to use entities, groups and places?

Entities

The idea of multiple entities is to allow GLPI to separately manage segments of installations, while allowing easy consolidation of data from various installations. This may be interesting for a company whose management is hierarchical and where people should have a vision of the installation at different levels. A user may be linked to several entities with different rights. These rights may be inherited by the sub entities or not.

Examples:

  • a company that manages several clients: one can define an entity by score
  • an administration that has branches and units: it may be interesting to use the entities (wisely, as we shall see later)

Groups

This concept allows for clusters. These can be diverse:

  • user group, to manage groups of jurisdiction to the Helpdesk for example
  • Services: You can gather materials, tickets and users to recreate the concept of service

Locations

Location attaches a geographic location to equipment and users. Locations are defined as a tree to represent location data as accurately as possible.

Example:

#10 Wall Street, New York> Building A> 1st Floor> Room 225

Recursion

Recursion makes objects in a sub-entity visable when viewing an entity. This allows you to define objects as either global or local.

Example:

  • a global supplier to all entities will be declared in the entity's highest, recursive (sub-entities to yes in the interface)
  • a local supplier: to be declared in the entity to which it relates (as non-entity)

When choosing to use entities or groups:

FIXME: explain what ENTAILED each of these concepts Definition of entities and locations

It is better to explain the concept of entity and places. Indeed, these concepts are structured for the development of the application in a client. A good practice is to define with the client, on paper, the hierarchy to implement.

Warning: Many entities may slow the application and may lead to a large surplus of rules!

Creating rules for the allocation of machines to entities

l must be set up different criteria for the allocation of machines to entities. Using the plugin mass_ocs_import helps in verification and refining the rules. It has a tab that lists all machines not imported with the display data from OCS. Thus, one can detect what criteria do not check the rule.

In the case of an environment with many entities, it will be helpful to use the following procedure:

  • OCS deploy the agent on a single machine of the entity
  • verify that the sync process works and that the machine is back in GLPI
  • check the data in GLPI lift compared to those of OCS

if the data are correct, start the deployment of agents on the posts

<note warning> Warning: In order to have good performance it is necessary to know the engine rules. In the case of assignments of machines to entities, the engine stops at the first matching rule found. It is therefore appropriate to place rules that will be used in many or all entities first in the list. <note>

Definition of profiles

In the same way that it is better to define the entities hierarchy before starting the configuration of GLPI, it is best to plan personnel profiles. It is important to study the profiles default implementation, because they meet generic needs.

Centralized management of authorizations from LDAP

The rules for allocating rights and profiles can delegate the daily management of authorizations to the LDAP directory. Generally associated with a profile GLPI membership in an LDAP group. A rule of employment can:

  • affect an entity a person
  • a profile for a person
  • enable / disable a person
  • affect an entity and a profile for a person

Mapping GLPI groups with LDAP groups

GLPI offers the possibility of making the correspondence between groups created in its base and others who come from the directory. GLPI migration from another system of park management

The installation of OCS and GLPI can occur where: Establishing a system of park management in a pristine environment migration of a system of fleet management system (free or proprietary) “automation” of the management of the park, where it was previously managed manually (eg in an Excel spreadsheet or Calc)

In 2 cases, it is possible to retrieve data from the existing system, so you do not manually type in GLPI. This plugin uses the injection of CSV files.

Export of existing data

  1. Identify the data to retrieve
  2. Make an export to CSV format:
    • from an Excel spreadsheet or Calc, this is easy
    • from an existing tool, use the export capabilities of it, or make scripts to do this

We must make a CSV file by type of data to be imported into GLPI. For example:

  • a file for machines
  • one for network equipment
  • etc..

Import data into GLPI

Preparation before injection into a production system

It may be wise to create a test instance of GLPI to test the quality of the data to be injected to avoid polluting your production system with bad data. This test instance consists of:

  • GLPI with a copy of the production base
  • plugin data_injection

Set your template files in the plugin and test them. At the end of the import data are generated:

  • a report (in HTML or PDF) on the execution of scripts
  • CSV file containing only the lines have been injected

Procedure to Inject data

  1. Install plugin injection data CSV (data_injection) on GLPI Prod.
  2. Create “models” from those of the basis of qualification.
  3. Verify the order in which to inject the data (see examples below)
  4. Verify that the data has been inserted

Example: You get a tool preceding the financial information of existing machines (purchase date, warranty period, etc..) As well as connections to an active network (name of the asset + shipping) You export this tool network equipment that will not be recovered by OCS (hubs, switches). You have the number of port equipment. Procedure:

  1. Create a model of injection equipment for your network
  2. Inject your network hardware indicating mappings in the number of ports of equipment
  3. GLPI will create materials and ports (if you inject a switch 16 ports, 16 ports will be created automatically in GLPI)
  4. Create a model injection computers
  5. Inject your computers indicating mappings in the name of the active network port on which it is connected
  6. GLPI will create the computer and tries to connect to the port on the specified asset automatically

Connecting OCS / GLPI

GLPI interfaces natively with OCS Inventory in order to recover its inventory automatically. GLPI can:

  • aggregate data from multiple servers OCS
  • back material data
  • up the software (with or without the dictionary OCS)
  • back the keys of register of Windows machines

GLPI can not:

  • change the configuration of OCS
  • update the dictionary OCS
  • pilot deployment of OCS applications

OCS Inventory NG and GLPI are in place, what to do next?

Now that your system is in place, you can read: