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

Thu Nov 17 17:40:00 UTC 2011

Hi Guillaume, Walid and the list,

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

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?
Would you be open to working with OCS team too SNMP?

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)
- ups.mfr.date and battery.mfr.date

But you will probably have a better point of view than mine.

cheers,
Arnaud
--
[1] nut-scanner manpage(doc to be published with the next release)
http://www.networkupstools.org/docs/man/nut-scanner.html
[2]
http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co
[3] NUT architecture
http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html
[4] UPS::Nut client Perl module:
http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a
[5] examples of NUT data output:
UPS:
http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co
PDU:
http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co
[6] http://www.networkupstools.org/docs/developer-guide.chunked/apa.html
-- 
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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20111117/9c964a36/attachment-0001.html>