Background

There always has existed an administrative need for tracking and cataloging physical devices under one's administrative control, from the simple perspective of knowing which devices are within the scope of control, to the broader view of knowing how systems are installed, configured, and accounted for through a device's lifespan. Historically, this has been a manual process of gathering meta-information about a device (device particulars such as location, function, cost, etc), then to couple that with the device's technical specification to craft a larger picture regarding the device, then to catalog all devices within the administrative control to gain a full list of resources. Until every machine is delivered with GPS sensors, or some sort of intelligence built-in, this will remain as at least a partially manual process. The goal, of course, is to automate this process as much as possible, with a human to double-check the validity of the information aggregated.

We have evolved this process over the past decade. Initially, the process entailed gathering all the information manually and stored within the CS LDAP directory see Official CS sub-oid space for specific placeholder information, which then became accessible via webpage or LDAP query within CS. The problem with this schema was that the system information constantly needed to be updated, else the information became stale and/or incorrect. "Constantly" may be understating the problem, because physical locations change, hardware configurations are upgraded/changed, and installed software gets upgraded, causing the function of any particular device to evolve. Further exacerbating the problem, devices may perform in a temporary or transitory fashion, complicating the particulars in the context of inventory.Since we recognized this methodology as a problem, we started over again from scratch, having learned that there will always be particulars about devices that only humans are aware, yet need to track (because humans forget, or change their minds). Instead of the midpoint between human knowledge of a device and machine knowledge leaning toward the human side, giving the machine the benefit of any doubt alleviates the administrative effort -- even if a device reports technical particulars incorrectly, it is still better than a human guess. With this in mind, a new philosophy surfaced: Let machines leverage themselves to update the inventory. This works well for technical particulars, but less so for information outside the device, of course. An arbitrary machine may be fully aware of what type of processor, amount of memory, or even whether it has particular software installed, yet the device is not aware that it is in room 112 or that it is a desktop machine that is no longer under warranty. Having most of the information automatically updated relieves the administrator from most of the administrative burden in the information gathering process.

Given that philosophy, we implemented OCS-ng (ocsinventory-ng.org), an automated IT asset management system. Software installed onto each system uses native tools to query and format technical particulars, which is then sent to a central inventory catalog. From there, the catalog is viewable via webpage for human consumption. Because this provides only some of the inventory information necessary, and very little of the human-aware administrative data, this only partly solves the overall problem.

GLPI (www.glpi-project.org) was implemented in CS to help administrators access and review (and possibly edit if necessary) technical particular data gathered from OCS-ng in its automation. GLPI presents a much richer context to the administrator, with the added ability to classify, relocate or otherwise update administrative information either in bulk or individually. It also implements the concept of "entities". In GLPI, an entity is a hierarchical partition in which assets or resources are placed to be managed specially within a certain context. For example, in GLPI there is a CS entity, but this can be further subdivided into research group entities, managed by research group or "CS" as a whole.

Installation and configuration

OCSng

On each Linux host, install the OCS-ng agent. This has been RPMified, and is located at: ocsinventory-agent. This package consists of a CS-specific setting causing the system to report its own technical particulars to the OCS-ng system within CS, x-inventory1.cs.caltech.edu. Since it is an RPM, the native tools used to gather technical particulars about the system become dependencies of the software, making it easier to install needed tools for efficiency of the system automation.

On each Windows or Mac OSX host, install the OCS-ng agent. This is available on the windows file server in the software repository, and available via the [OCS-NG site][1].

The other high-level component in the OCS-ng system is the management server. Details for installing and configuring the management server can be retrieved here.

GLPI

Installation instructions for the GLPI system can be retrieved from the GLPI Wiki. The GLPI system is able to import, automatically or manually, host technical particulars directly from OCSng. From that point, there exists two copies of technical particulars for each device reported via OCSng. This is an administrative step, however, also easily automated through the GLPI system in that system particulars in GLPI can be automatically or manually synchronized with system particulars in OCSng. To avoid confusion, data in OCSng is never modified by humans, and data within GLPI may be modified from an administrative standpoint and not any technical specifications, lest the update process from OCSng -> GLPI will overwrite technical particulars.

Screenshots

#####Inventory screen for OCSng: !img ocsng.png

#####Machine view in OCSng: !img ocsng-machine.png

#####Inventory screen for GLPI: !img GLPI.png

#####Machine view in GLPI: !img glpi-machine.png

-- DavidLeBlanc - 2019-10-07