[Nut-upsdev] [Fusioninventory-devel] Adding power devices support to Fusion Inventory

Thu Nov 17 20:20:15 UTC 2011

Hi,

2011/11/17 David DURIEUX <d.durieux at siprossii.com>:
> Le Thu, 17 Nov 2011 18:40:00 +0100
> Arnaud Quette <aquette.dev at gmail.com> a écrit:
>
>>Hi Guillaume, Walid and the list,
>
> Hi
>
>>
>>I'm grouping my answers to you.
>>
>>2011/11/15 Guillaume Rousse <guillomovitch at gmail.com>
>>
>>> Le 15/11/2011 15:30, Arnaud Quette a écrit :
>>>
>>>  So, would you be interested in working with me on this topic?
>>>> How can we proceed?
>>>> Which kind of integration would be best, ie providing a formated
>>>> files, or using languages binding or program calls?
>>>>
>>> Hellp Arnaud.
>>>
>>> This is quite interesting idea. Especially if you're willing to
>>> provide the code directly :P
>>>
>>
>>indeed, but not everything: if we want this effort to succeed, I will
>>only be able to complete the NUT side (see below) with you working on
>>the FI side.
>>
>>
>>> The first point is to determine how to extract UPS informations. In
>>> fusioninventory, they are currently two different ways for this:
>>> - local devices are managed in local inventory task, using whatever
>>> command/tool available
>>> - remote devices (thoses with an IP adress, basically) are managed
>>> in net inventory task, using only SNMP currently
>>>
>>> Some kind of devices, such as printers, can belong to both
>>> categories: small ones are locally controlled on a specific host,
>>> while larger ones are autonomous. I guess UPS are quite similar in
>>> this regard, some of them being attached by an USB link to a
>>> controller host, others having their own network device, right ?
>>>
>>> In this case, UPS support would mean two additional pieces of code.
>>>
>>> Local inventory support is just a matter of adding a new additional
>>> inventory module, in perl, for the local inventory task. There is
>>> also a new section definition to add to the inventory data
>>> structure, but that's trivial to do.
>>>
>>> Remote inventory support is a bit more complex. First, we need an
>>> SNMP description model (just a mapping of OIDs against specific known
>>> properties), but as currently this task only manage printers and
>>> network devices, we also need to define those properties, and add
>>> explicit support in the task code itself.
>>>
>>> So, the easiest way to start would be the local support. Have a look
>>> at the generic local printer module, in the 2.2.x branch, it should
>>> give you some idea on how to proceed:
>>> https://github.com/fusinv/**fusioninventory-agent/blob/2.**
>>> 2.x/lib/FusionInventory/Agent/**Task/Inventory/Input/Generic/**Printers.pm<https://github.com/fusinv/fusioninventory-agent/blob/2.2.x/lib/FusionInventory/Agent/Task/Inventory/Input/Generic/Printers.pm>
>>>
>>> Of course, feel free to ask if I'm not clear enough.
>>>
>>
>>First, NUT provides support for UPS, and also PDU (sort of manageable
>>powerstrip) and servers power supplies.
>>UPS can be local (serial or USB) or networked (SNMP).
>>NUT only support natively SNMP PDU (12 MIBs currently, with ~8 more
>>stagging).
>>And IPMI support is only local, but network support is planned.
>>
>>So these devices pertain to both local and remote categories.
>>
>>I've thought a lot about that, for both FusionInventory and OCS
>>Inventory NG, and came to the conclusion that extracting all the
>>needed data for both inventory and assets management (Ie GLPI) would
>>either be identical to nut-scanner, or would need too much revamp in
>>the NUT code. In either case, this would almost be a Perl
>>reimplementation of NUT, which is probably not desirable, at least for
>>maintenance reasons!
>>
>>Thus, I propose you the following 2 steps approach, which is the same I
>>proposed to OCS (minus USB):
>>
>>1) use the nut-scanner [1] for a quick integration.
>>
>>A Perl wrapper is planned (as for the existing "jNutScanner" [2]), that
>>would help this effort.
>>Any Perl contrib is welcome BTW ;-)
>>
>>This requires the nut-scanner binary to installed on the local system,
>>that is:
>>- the server, for SNMP scans
>>- the agents for USB and still for IPMI (remote support planned) scans
>>
>>Here is an example SNMP scan, in quiet mode with parsable output:
>>
>>$ /path/to/nut-scanner -SPq --mask_cidr 166.99.250.58/24
>>
>>SNMP:driver="snmp-ups",port="
>>166.99.250.64",desc="Eaton 5PX",mibs="mge",community="public"
>>SNMP:driver="snmp-ups",port="166.99.250.26",desc="Evolution",mibs="mge",community="public"
>>SNMP:driver="snmp-ups",port="166.99.250.67",desc="DELL",mibs="ietf",community="public"
>>SNMP:driver="snmp-ups",port="166.99.250.7",desc="DBQ10634/5",mibs="aphel_revelation",community="public"
>>SNMP:driver="snmp-ups",port="166.99.250.118
>>",desc="EATON",mibs="ietf",community="public"
>>SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton 5PX
>>1500",mibs="pw",community="public"
>>SNMP:driver="snmp-ups",port="166.99.250.118",desc="Eaton
>>5PX",mibs="mge",community="public"
>>
>>Note: the same device may be exposed several times, if it supports
>>several MIBs (as for 166.99.250.118 above)!
>
> Several MIBs ? what did it mean?

that this device serves data from various points of the SNMP tree,
instead of just 1.
generally speaking, a SNMP manager (ie, the one that serves / provide
SNMP data, and that is generally a device) exposes generic data
through MIB2 (.iso.org.dod.internet.mgmt.mib-2), and more specific
data.
The main (or sole) entry point for these specific data is defined via
sysOID (.iso.org.dod.internet.mgmt.mib-2.system.sysObjectID)
This device does the same, but also expose some more MIBs, generally
for compatibility Vs features

>>
>>And here is another one for USB devices:
>>
>>$ /path/to/nut-scanner -UPq
>>USB:driver="bcmxcp_usb",port="auto",vendorid="0592",productid="0002",bus="002"
>>USB:driver="usbhid-ups",port="auto",vendorid="0463",productid="FFFF",bus="002"
>>
>>A possible variation of this would be a new nut-scanner option, that
>>would display a list of supported devices:
>>- "VendorID:ProductID" for USB
>>- "sysOID:otherTestOID" for SNMP
>>
>>This would be sufficient for a generic USB or SNMP iterator in FI
>>
>>2) configure and launch snmp-ups and/or USB driver(s) + upsd to get
>>more (all) details
>>
>>As told previously, the results of a NUT scan is very basic.
>>These are not sufficient for inventory, and even less for GLPI.
>>
>>But many details can then be gathered using NUT [3] and its client
>>interface (Perl binding available [4]).
>>See [5] for examples of UPS and PDU data reported by NUT, so that you
>>can match with GLPI requirements or needs.
>>
>>That method requires to setup NUT to talk to the SNMP/USB devices, but
>>that is not a big deal.
>>The nut-scanner output can be used (either the parsable, or the direct
>>nut ups.conf format)
>>
>>
>>So, does the above 2 steps suits you?
>>How can we collaborate on this topic and integrate this work?
>
> In fact, for the SNMP part, we use/create SNMP models for each device.
> In these models, we have link between OID and value
> (exemple .1.3.6.1.2.1.1.6.0 => Location). With this method, we can get
> many informations easily (MIBs are not very nice)

so do we in NUT, with currently 12 MIBs and...
Take a closer look at this file, which defines support for 3 PDU MIBs:
http://anonscm.debian.org/viewvc/nut/trunk/drivers/eaton-mib.c?view=co&content-type=text%2Fplain

NUT is already an abstraction layer that standardize data from
different MIBs and protocols (serial, USB, SNMP, XML/HTTP)

>>Would you be open to working with OCS team too SNMP?
>
> I don't know the OCS methods for SNMP, may be a little different than
> our implementation.

seems to be the same, or almost.
but it's maybe time to add another "standard" method through a NUT
integration ;-)

>>
>>On GLPI, I'm not sure of which exact data to inject into it.
>>As per our standard namespace [6], the most interesting for assets mgt
>>are:
>>- the device.* collection (model, mfr, serial and type)
>>-
>>
>>But you will probably have a better point of view than mine.
>
> For device collection, it reuired yes ;)
> What is ups.mfr.date and battery.mfr.date ?

ups.mfr.date: UPS manufacturing date (opaque string)
battery.date: Battery change date (opaque string)
battery.mfr.date: Battery manufacturing date (opaque string)

So 3 data that may be interesting to consider for GLPI, and managing
services related to these devices.

cheers,
Arnaud
-- 
Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/