Hi Guillaume, Walid and the list, I'm grouping my answers to you.
2011/11/15 Guillaume Rousse <guillomovi...@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/
_______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev