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

[David DURIEUX]

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?

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

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

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

David Durieux
++