Hi Guillaume, Walid and the list,<br><br>I'm grouping my answers to you.<br><br><div class="gmail_quote">2011/11/15 Guillaume Rousse <span dir="ltr"><<a href="mailto:guillomovitch@gmail.com" target="_blank">guillomovitch@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le 15/11/2011 15:30, Arnaud Quette a écrit :<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, would you be interested in working with me on this topic?<br>
How can we proceed?<br>
Which kind of integration would be best, ie providing a formated files,<br>
or using languages binding or program calls?<br>
</blockquote></div>
Hellp Arnaud.<br>
<br>
This is quite interesting idea. Especially if you're willing to provide the code directly :P<br></blockquote><div><br>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.<br>

 </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The first point is to determine how to extract UPS informations. In fusioninventory, they are currently two different ways for this:<br>
- local devices are managed in local inventory task, using whatever command/tool available<br>
- remote devices (thoses with an IP adress, basically) are managed in net inventory task, using only SNMP currently<br>
<br>
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 ?<br>



<br>
In this case, UPS support would mean two additional pieces of code.<br>
<br>
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.<br>



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



<br>
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:<br>
<a href="https://github.com/fusinv/fusioninventory-agent/blob/2.2.x/lib/FusionInventory/Agent/Task/Inventory/Input/Generic/Printers.pm" target="_blank">https://github.com/fusinv/<u></u>fusioninventory-agent/blob/2.<u></u>2.x/lib/FusionInventory/Agent/<u></u>Task/Inventory/Input/Generic/<u></u>Printers.pm</a><br>



<br>
Of course, feel free to ask if I'm not clear enough.<span><font color="#888888"><br></font></span></blockquote></div><br clear="all">First, NUT provides support for UPS, and also PDU (sort of manageable powerstrip) and servers power supplies.<br>

UPS can be local (serial or USB) or networked (SNMP).<br>NUT only support natively SNMP PDU (12 MIBs currently, with ~8 more stagging).<br>And IPMI support is only local, but network support is planned.<br><br>So these devices pertain to both local and remote categories.<br>

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

<br>Thus, I propose you the following 2 steps approach, which is the same I proposed to OCS (minus USB):<br><br>1) use the nut-scanner [1] for a quick integration.<br><br>A Perl wrapper is planned (as for the existing "jNutScanner" [2]), that would help this effort.<br>





Any Perl contrib is welcome BTW ;-)<br><br>This requires the nut-scanner binary to installed on the local system, that is:<br>- the server, for SNMP scans<br>- the agents for USB and still for IPMI (remote support planned) scans<br>



<br>Here is an example SNMP scan, in quiet mode with parsable output:<br><br>$ /path/to/nut-scanner -SPq --mask_cidr <a href="http://166.99.250.58/24" target="_blank">166.99.250.58/24</a><br><br>SNMP:driver="snmp-ups",port="<div class="gmail_quote">

166.99.250.64",desc="Eaton 5PX",mibs="mge",community="public"<br>

SNMP:driver="snmp-ups",port="166.99.250.26",desc="Evolution",mibs="mge",community="public"<br>SNMP:driver="snmp-ups",port="166.99.250.67",desc="DELL",mibs="ietf",community="public"<br>



SNMP:driver="snmp-ups",port="166.99.250.7",desc="DBQ10634/5",mibs="aphel_revelation",community="public"<br>SNMP:driver="snmp-ups",port="<a href="tel:166.99.250.118" value="+16699250118" target="_blank">166.99.250.118</a>",desc="EATON",mibs="ietf",community="public"<br>



SNMP:driver="snmp-ups",port="<a href="tel:166.99.250.118" value="+16699250118" target="_blank">166.99.250.118</a>",desc="Eaton 5PX 1500",mibs="pw",community="public"<br>SNMP:driver="snmp-ups",port="<a href="tel:166.99.250.118" value="+16699250118" target="_blank">166.99.250.118</a>",desc="Eaton 5PX",mibs="mge",community="public"<br>




<br>Note: the same device may be exposed several times, if it supports several MIBs (as for <a href="tel:166.99.250.118" value="+16699250118" target="_blank">166.99.250.118</a> above)!<br>
<br>

And here is another one for USB devices:<br><br>$ /path/to/nut-scanner -UPq<br>
USB:driver="bcmxcp_usb",port="auto",vendorid="0592",productid="0002",bus="002"<br>USB:driver="usbhid-ups",port="auto",vendorid="0463",productid="FFFF",bus="002"<br>


<br>A possible variation of this would be a new nut-scanner option, that would display a list of supported devices:<br>- "VendorID:ProductID" for USB<br>- "sysOID:otherTestOID" for SNMP<br><br>This would be sufficient for a generic USB or SNMP iterator in FI<br>
<br>2) configure and launch snmp-ups and/or USB driver(s) + upsd to get more (all) details<br><br>As told previously, the results of a NUT scan is very basic.<br>These are not sufficient for inventory, and even less for GLPI.<br>

<br>But many details can then be gathered using NUT [3] and its client interface (Perl binding available [4]).<br>




See [5] for examples of UPS and PDU data reported by NUT, so that you can match with GLPI requirements or needs.<br><br>That method requires to setup NUT to talk to the SNMP/USB devices, but that is not a big deal.<br>The nut-scanner output can be used (either the parsable, or the direct nut ups.conf format)<br>


<br><br>So, does the above 2 steps suits you?<br>How can we collaborate on this topic and integrate this work?</div>Would you be open to working with OCS team too SNMP?<br><br>On GLPI, I'm not sure of which exact data to inject into it.<br>
As per our standard namespace [6], the most interesting for assets mgt are:<br>- the device.* collection (model, mfr, serial and type)<br>- ups.mfr.date and battery.mfr.date<br><br>But you will probably have a better point of view than mine.<br>
<br>cheers,<br>
Arnaud<br><span>--<br>[1] nut-scanner manpage(doc to be published with the next release)<br><a href="http://www.networkupstools.org/docs/man/nut-scanner.html">http://www.networkupstools.org/docs/man/nut-scanner.html</a><br>
[2] <a href="http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co">http://anonscm.debian.org/viewvc/nut/trunk/scripts/java/jNut/src/main/java/org/networkupstools/jnut/Scanner.java?view=co</a><br>
[3] NUT architecture<br><a href="http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html">http://www.networkupstools.org/docs/developer-guide.chunked/ar01s02.html</a><br>[4] UPS::Nut client Perl module: <a href="http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a">http://www.networkupstools.org/projects.html#_a_href_http_search_cpan_org_search_dist_ups_nut_ups_nut_a</a><br>
[5] examples of NUT data output:<br>UPS: <a href="http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co">http://anonscm.debian.org/viewvc/nut/trunk/data/evolution500.seq?view=co</a><br>PDU: <a href="http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co">http://anonscm.debian.org/viewvc/nut/trunk/data/epdu-managed.dev?view=co</a><br>
[6] </span><a href="http://www.networkupstools.org/docs/developer-guide.chunked/apa.html">http://www.networkupstools.org/docs/developer-guide.chunked/apa.html</a><br>-- <br>Linux / Unix Expert R&D - Eaton - <a href="http://powerquality.eaton.com" target="_blank">http://powerquality.eaton.com</a><br>

Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org/" target="_blank">http://www.networkupstools.org/</a><br>
Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>Free Software Developer - <a href="http://arnaud.quette.free.fr/" target="_blank">http://arnaud.quette.free.fr/</a><br><br>