Nut upsdev - Nov 2011 - Adding power devices support to Fusion Inventory

Dear Fusion Inventory fellows,

I've been thinking about working on adding power devices knowledge to
inventory systems for years.
Following the last Ubuntu Developer Summit, I know have an "excuse" to
do
so:
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-cloud-power-management

My below proposition is related to the above blueprint. So please keep in
mind that the target is also to be able to provide these info to Fusion
Inventory , so that it can in turn provide these to Cobbler / Orchestra.

Power devices are UPS, PDU, server power supplies and solar controllers, as
supported by the Network UPS Tools (NUT) project.
NUT is the major free software for dealing with such devices:
http://www.networkupstools.org/

NUT has some internal automation that allows to extract these information
(USB IDs, SNMP sysOIDs, IPMI PSU,...) from the drivers (so no declaration
redundancy), in order to generate support files (udev, upower, ...) or
tools such as the NUT scanner:
http://www.networkupstools.org/docs/man/nut-scanner.html

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?

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20111115/db753c19/attachment.html>

On 15/11/2011 15:30, Arnaud Quette wrote:
> Dear Fusion Inventory fellows,
>
> I've been thinking about working on adding power devices knowledge to 
> inventory systems for years.
> Following the last Ubuntu Developer Summit, I know have an
"excuse" to
> do so:
>
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-cloud-power-management
>
> My below proposition is related to the above blueprint. So please keep 
> in mind that the target is also to be able to provide these info to 
> Fusion Inventory , so that it can in turn provide these to Cobbler / 
> Orchestra.
>
Hello Arnaud,

If FusionInventory collects theses new data, then it should be displayed 
in the asset management software (in our case GLPI). What kind of data 
must should be stored and are interesting to display ?
There may be some work to do to add theses new informations on the GLPI 
side.

Walid.

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>

Hi Gon?ri,

2011/11/17 Gon?ri Le Bouder <goneri at
rulezlan.org>:
> On Thu, Nov 17, 2011 at 09:20:15PM +0100, Arnaud Quette wrote:
>> Hi,
>
> Hello all,
>
> I'm interest to start the integration on the agent side (local
inventory).
> There no UPS here. Is there a way to emulate it?
sure.
I've attached an updated (and not yet published) version of the NUT
simulation info.
You will find everything you need to simulate as many UPS, PDU, (...) you want.
Since manpages links are broken, also use the online version:
http://www.networkupstools.org/docs/man/index.html
> We provide tarball of Perl, FusionInventoy-Agent and the dependencies
> to simplify the inventory of the machine. Basicly, the sysadmin, has
> just to extract and run the agent.
> This is very useul when a decent Perl is not available and there is no
> compiler (for example, an ancient Solaris or HP-UX)
> ?http://prebuilt.fusioninventory.org
> Is it possible to prepare a minimalist nut distribution just for
> local inventory and embed it with the agent? Does nut have a lot of
> external dependency itself?
NUT is included in small footprint appliances (10 Mb) such as Opengear
devices, so this should not be an issue.
A full (Ie including the world) distribution on Linux weights ~4 Mb
But you will be able to cut it down to 2Mb or even more... at least on Linux.
- 350 Kb for (5) USB drivers
- 94 Kb for snmp-ups
- 54 Kb for nut-ipmipsu
- 43 Kb simulation driver
- 200 Kb lib (nut client and scan)
- 14 kb nut-scanner binary
- 26 Kb for Nut.pm
- 51 Kb for upsd, but you can also directly talk to drivers and remove
upsd (ex: if you just want to launch drivers from time to time, to
update data...)
- ...

NUT depends on libc/equiv + libusb + libsnmp (Net SNMP) for your requirements.
For other options (SSL, IPMI, ...) requirements, check this chapter
and the following:
http://www.networkupstools.org/docs/user-manual.chunked/aphs01.html
> Is it possible to use nut on Windows?
sure, NUT now runs on all OSs, including Windows (not yet as complete
/ mature as Unix versions), Linux*, OS X, BSD*, HP-UX, Aix, Solaris,
Qnx, ...

Windows and other packages are available:
http://www.networkupstools.org/download.html#_binary_packages

cheers,
Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20111117/cac66f9c/attachment-0001.html>