2012/6/10 Luiz Angelo Daros de Luca <[email protected]> > Hello guys, >
Hello Luiz > I was some years ago when I sent something to this list. > yup, Google told me it was in 2009, on the megatec driver... > NUT is a great tool but lacks SNMP management. It can access a device > using SNMP > but I found no way to read NUT values using SNMP. It would be very > useful in order to integrate with > network management software based on SNMP. As I did not find a > solution, I wrote it myself. > well, there is (was/will be) one, but never finished nor integrated: - a set of 3 tasks, among which 2 are agent related: https://alioth.debian.org/pm/task.php?group_project_id=31&group_id=30602&func=browse - a patch with an agent based on RFC1628 (so limited to 1 UPS, no multiple devices, no PDU nor whatever...) https://alioth.debian.org/tracker/index.php?func=detail&aid=312563&group_id=30602&atid=411544 > I wrote a MIB file and a SNMP agent for net-snmp (pass_persist) in > order to expose the contents of upsc command to SNMP softwares. I > works simply by adding to snmpd.conf: > > pass_persist .1.3.6.1.4.1.26376.99 /my/path/to/snmp.nut -f > > The script and MIB files are at: > > https://github.com/luizluca/nut-snmpagent > > It is, for sure, not finished. I did not find a IANA enterprise > number, that is no costs to register, for NUT so I > spoofed my company one. I'm still using a fake upsc output in order to > have a more complex mix of devices. > I collected some output examples in the documentation but I might > still missed some special case. > I can provide some .dev files for simulation using dummy-ups driver. this should help you in testing corner cases... note that there is already a .dev and a .seq in the source distribution, "data" sub directory. Also, I did not extensively tested it with real hardware. Anyway, my > UPS is quite simple for that. > > I got two minor doc bugs in the process. The first is that the > driver.version.data, that I found in some examples, its not listed as > a variable. > right, there are still some data missing in nut-names.txt, but I'm ramping up to fix these lacks. driver.flag.* driver.parameter.* => scripts/augeas/nutupsconf.aug ==> ups_fields stores all drivers parameters and flags (no distinction here yet between VAR_VALUE and VAR_FLAG) The other is the description of "power.minimum" as "Maximum seen > apparent power (VA)". > the is a typo error, fixed in r3653. thanks for your report. Note that we may investigate future mechanisms to share data mapping and descriptions, that would ease maintenance work on the SNMP agent. > I would appreciate some feedback/help/suggestions in any part of the > solution. I'm willing to release it with any permissive license. > The agent might not fit the requirements of all users (it is written > in ruby with a lot of metaprogramming) but the MIB file > seems to be in a good shape, expect for the missing IANA number. BTW, > I'm no SNMP expert. > all this is great! the SNMP agent (and a NUT MIB, or generic power devices MIB) is one of the things I've not had time to take care for years. I'm also going to look at the IANA process to get an OID for NUT. this should probably be under "org" and not "enterprise", as for the generic "UPS MIB" (aka RFC-1628, located under mgmt.mib-2) that said, I'm not a fan of Ruby. moreover, the general layout of the below MIB should be reworked a bit to match 1:1 NUT naming scheme (Ie the NUT data collections). more info below... Regards, > > PS: Just for an example, the current output that I get from a snmpwalk > is like this (for 6 devices): > > NUT-MIB::deviceIndex.1 = INTEGER: 1 > NUT-MIB::deviceIndex.2 = INTEGER: 2 > NUT-MIB::deviceIndex.3 = INTEGER: 3 > NUT-MIB::deviceIndex.4 = INTEGER: 4 > NUT-MIB::deviceIndex.5 = INTEGER: 5 > NUT-MIB::deviceIndex.6 = INTEGER: 6 > NUT-MIB::deviceName.1 = STRING: ups2 > NUT-MIB::deviceName.2 = STRING: xxx > NUT-MIB::deviceName.3 = STRING: upsoutlet > NUT-MIB::deviceName.4 = STRING: ups3p1 > NUT-MIB::deviceName.5 = STRING: ups3p2 > NUT-MIB::deviceName.6 = STRING: ups3 > NUT-MIB::deviceDesc.1 = STRING: UPS2 10 KVA Lacerda Titan Black tri-mono > 10KVA (220v) Serial A08823221 > NUT-MIB::deviceDesc.2 = STRING: Fictious > NUT-MIB::deviceDesc.3 = STRING: Example outlet > NUT-MIB::deviceDesc.4 = STRING: phases1 > NUT-MIB::deviceDesc.5 = STRING: phases2 > NUT-MIB::deviceDesc.6 = STRING: test3 > NUT-MIB::deviceModel.1 = STRING: Titan Black tri-mono 10KVA > NUT-MIB::deviceModel.2 = STRING: Titan Black tri-mono 10KVA > NUT-MIB::deviceModel.6 = STRING: Ellipse MAX 1100 > NUT-MIB::deviceMfr.1 = STRING: Lacerda Sistemas de Energia > NUT-MIB::deviceMfr.2 = STRING: Lacerda Sistemas de Energia > NUT-MIB::deviceMfr.6 = STRING: EATON > NUT-MIB::deviceSerial.1 = STRING: A08823221 > NUT-MIB::deviceSerial.2 = STRING: A08823221 > NUT-MIB::deviceSerial.6 = STRING: ADKK22008 > NUT-MIB::deviceType.1 = STRING: ups > NUT-MIB::deviceType.2 = STRING: ups > NUT-MIB::deviceType.6 = STRING: ups > NUT-MIB::upsStatus.1 = STRING: OL > NUT-MIB::upsStatus.2 = STRING: OL > NUT-MIB::upsStatus.6 = STRING: OL CHRG > NUT-MIB::upsModel.6 = STRING: Ellipse MAX 1100 > NUT-MIB::upsMfr.6 = STRING: EATON > NUT-MIB::upsSerial.6 = STRING: ADKK22008 > NUT-MIB::upsVendorid.6 = STRING: 0463 > NUT-MIB::upsProductid.6 = STRING: ffff > (...) > <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev> I would more see something like this (including the collection name in the path): NUT-MIB::device.deviceIndex.1 = INTEGER: 1 NUT-MIB::device.deviceName.1 = STRING: ups2 NUT-MIB::device.deviceDesc.1 = STRING: UPS2 ... NUT-MIB::device.deviceModel.1 = STRING: Titan Black tri-mono 10KVA NUT-MIB::device.deviceMfr.1 = STRING: Lacerda Sistemas de Energia (...) NUT-MIB::inputCurrentNominal.1 = INTEGER: 27.00 would give something like NUT-MIB::input.l1.inputCurrent.nominal (equivalent to NUT "input.L1.current.nominal: 27.0") a few notes: - I'm still thinking about the added value of repeating the collection name for each leaf. Ie device.deviceIndex Vs device.Index the first (your current approach) is probably more in phase with SNMP best practices, - I'm still unsure on the right device index place. you have used leaf indexes (Ie, indexes are located on the leaf), while NUT native approach would more be "root" indexes. that would give something like NUT-MIB::[index].collection.data so, for the 1rst NUT device: NUT-MIB::0.device.name NUT-MIB::0.device.model (...) the root would also contain: NUT-MIB::server.{info,version} and possibly a devices list, or at least a device count (Ie how many devices you can iterate on...) - for the 1rst round, I'm more interested in stabilizing the MIB tree, to have a stable *numeric* set. Exact string names have a lower priority. - the "MAYBE" on commands (and settings) is to be removed. this is also part of the SNMP interface, though it should be used only in SNMP v3 mode (v1 is a security mess!). - part of the requirements, I'd like the agent to be able to work in standalone or sub agent mode. so, to conclude this first mail, you did a great work! I've sadly not enough time to fully enter the loop with you. but I'm willing to devote all the support and time I can to push and complete this effort (including IANA process). on your side, are you willing to continue (and maybe enter the NUT team for the long run) or just to contribute what you did so far? cheers, Arnaud -- Linux / Unix / Opensource Engineering Expert - Eaton - http://opensource.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
