Hi, 2011/11/17 David DURIEUX <[email protected]>: > Le Thu, 17 Nov 2011 18:40:00 +0100 > Arnaud Quette <[email protected]> a écrit: > >>Hi Guillaume, Walid and the list, > > Hi > >> >>I'm grouping my answers to you. >> >>2011/11/15 Guillaume Rousse <[email protected]> >> >>> 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?
that this device serves data from various points of the SNMP tree, instead of just 1. generally speaking, a SNMP manager (ie, the one that serves / provide SNMP data, and that is generally a device) exposes generic data through MIB2 (.iso.org.dod.internet.mgmt.mib-2), and more specific data. The main (or sole) entry point for these specific data is defined via sysOID (.iso.org.dod.internet.mgmt.mib-2.system.sysObjectID) This device does the same, but also expose some more MIBs, generally for compatibility Vs features >> >>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) so do we in NUT, with currently 12 MIBs and... Take a closer look at this file, which defines support for 3 PDU MIBs: http://anonscm.debian.org/viewvc/nut/trunk/drivers/eaton-mib.c?view=co&content-type=text%2Fplain NUT is already an abstraction layer that standardize data from different MIBs and protocols (serial, USB, SNMP, XML/HTTP) >>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. seems to be the same, or almost. but it's maybe time to add another "standard" method through a NUT integration ;-) >> >>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 ? ups.mfr.date: UPS manufacturing date (opaque string) battery.date: Battery change date (opaque string) battery.mfr.date: Battery manufacturing date (opaque string) So 3 data that may be interesting to consider for GLPI, and managing services related to these devices. 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/ _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
