Le Thu, 17 Nov 2011 18:40:00 +0100 Arnaud Quette <aquette....@gmail.com> a écrit:
>Hi Guillaume, Walid and the list, Hi > >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)! 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 ++ _______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev