Hello guys, I was some years ago when I sent something to this list. 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. 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. 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. The other is the description of "power.minimum" as "Maximum seen apparent power (VA)". 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. 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 NUT-MIB::upsFirmware.6 = STRING: 5102AH NUT-MIB::upsTemperature.1 = INTEGER: 47.0 NUT-MIB::upsTemperature.2 = INTEGER: 47.0 NUT-MIB::upsLoad.1 = INTEGER: 43 NUT-MIB::upsLoad.2 = INTEGER: 43 NUT-MIB::upsLoad.6 = INTEGER: 0 NUT-MIB::upsDelayStart.1 = INTEGER: 180 NUT-MIB::upsDelayStart.2 = INTEGER: 180 NUT-MIB::upsDelayStart.6 = INTEGER: 30 NUT-MIB::upsDelayShutdown.1 = INTEGER: 30 NUT-MIB::upsDelayShutdown.2 = INTEGER: 30 NUT-MIB::upsDelayShutdown.6 = INTEGER: 20 NUT-MIB::upsTimerStart.6 = INTEGER: -1 NUT-MIB::upsTimerShutdown.6 = INTEGER: -1 NUT-MIB::upsPowerNominal.6 = INTEGER: 1100 NUT-MIB::upsBeeperStatus.6 = STRING: enabled NUT-MIB::upsType.1 = STRING: online NUT-MIB::upsType.2 = STRING: online NUT-MIB::inputVoltage.1 = INTEGER: 215.0 NUT-MIB::inputVoltage.2 = INTEGER: 215.0 NUT-MIB::inputVoltageNominal.1 = INTEGER: 220.0 NUT-MIB::inputVoltageNominal.2 = INTEGER: 220.0 NUT-MIB::inputVoltageExtended.6 = INTEGER: no(0) NUT-MIB::inputTransferLow.6 = INTEGER: 165 NUT-MIB::inputTransferHigh.6 = INTEGER: 285 NUT-MIB::inputSensitivity.6 = STRING: normal NUT-MIB::inputCurrentNominal.1 = INTEGER: 27.00 NUT-MIB::inputCurrentNominal.2 = INTEGER: 27.00 NUT-MIB::inputFrequency.1 = INTEGER: 60.0 NUT-MIB::inputFrequency.2 = INTEGER: 60.0 NUT-MIB::inputFrequency.4 = INTEGER: 50.0 NUT-MIB::inputFrequency.5 = INTEGER: 50.1 NUT-MIB::inputFrequencyNominal.1 = INTEGER: 60.0 NUT-MIB::inputFrequencyNominal.2 = INTEGER: 60.0 NUT-MIB::inputTransferBoostLow.6 = INTEGER: 185 NUT-MIB::inputTransferTrimHigh.6 = INTEGER: 265 NUT-MIB::inputPhases.4 = INTEGER: 3 NUT-MIB::inputPhases.5 = INTEGER: 3 NUT-MIB::outputVoltage.1 = INTEGER: 221.0 NUT-MIB::outputVoltage.2 = INTEGER: 221.0 NUT-MIB::outputVoltage.5 = INTEGER: 120.0 NUT-MIB::outputVoltage.6 = INTEGER: 230.0 NUT-MIB::outputVoltageNominal.6 = INTEGER: 230.0 NUT-MIB::outputFrequencyNominal.5 = INTEGER: 60.0 NUT-MIB::outputFrequencyNominal.6 = INTEGER: 50.0 NUT-MIB::outputCurrent.5 = INTEGER: 244.20 NUT-MIB::outputPhases.4 = INTEGER: 3 NUT-MIB::outputPhases.5 = INTEGER: 1 NUT-MIB::batteryCharge.1 = INTEGER: 100.0 NUT-MIB::batteryCharge.2 = INTEGER: 30.0 NUT-MIB::batteryCharge.6 = INTEGER: 100.0 NUT-MIB::batteryChargeLow.6 = INTEGER: 20.0 NUT-MIB::batteryVoltage.1 = INTEGER: 274.60 NUT-MIB::batteryVoltage.2 = INTEGER: 273.60 NUT-MIB::batteryVoltageNominal.1 = INTEGER: 240.00 NUT-MIB::batteryVoltageNominal.2 = INTEGER: 240.00 NUT-MIB::batteryRuntime.6 = INTEGER: 2525 NUT-MIB::batteryType.6 = STRING: PbAc NUT-MIB::outletIndex.3.0 = INTEGER: 0 NUT-MIB::outletIndex.3.1 = INTEGER: 1 NUT-MIB::outletIndex.3.2 = INTEGER: 2 NUT-MIB::outletIndex.6.0 = INTEGER: 0 NUT-MIB::outletIndex.6.1 = INTEGER: 1 NUT-MIB::outletId.3.0 = STRING: 0 NUT-MIB::outletId.3.1 = STRING: 1 NUT-MIB::outletId.3.2 = STRING: 2 NUT-MIB::outletId.6.0 = STRING: 1 NUT-MIB::outletId.6.1 = STRING: 2 NUT-MIB::outletDesc.3.0 = STRING: Main Outlet NUT-MIB::outletDesc.3.1 = STRING: PowerShare Outlet 1 NUT-MIB::outletDesc.3.2 = STRING: PowerShare Outlet 2 NUT-MIB::outletDesc.6.0 = STRING: Main Outlet NUT-MIB::outletDesc.6.1 = STRING: PowerShare Outlet 1 NUT-MIB::outletSwitch.3.1 = INTEGER: on(1) NUT-MIB::outletSwitch.3.2 = INTEGER: on(1) NUT-MIB::outletStatus.6.1 = INTEGER: on(1) NUT-MIB::outletSwitchable.3.0 = INTEGER: yes(1) NUT-MIB::outletSwitchable.3.1 = INTEGER: yes(1) NUT-MIB::outletSwitchable.3.2 = INTEGER: yes(1) NUT-MIB::outletSwitchable.6.0 = INTEGER: no(0) NUT-MIB::outletSwitchable.6.1 = INTEGER: no(0) NUT-MIB::outletAutoswitchChargeLow.3.1 = INTEGER: 0 NUT-MIB::outletAutoswitchChargeLow.3.2 = INTEGER: 0 NUT-MIB::outletDelayShutdown.3.1 = INTEGER: -1 NUT-MIB::outletDelayShutdown.3.2 = INTEGER: -1 NUT-MIB::outletDelayStart.3.1 = INTEGER: -1 NUT-MIB::outletDelayStart.3.2 = INTEGER: -1 NUT-MIB::driverName.1 = STRING: blazer_ser NUT-MIB::driverName.2 = STRING: blazer_ser NUT-MIB::driverName.6 = STRING: usbhid-ups NUT-MIB::driverVersion.1 = STRING: 2.6.2 NUT-MIB::driverVersion.2 = STRING: 2.6.2 NUT-MIB::driverVersion.6 = STRING: 2.4.1-1988:1990M NUT-MIB::driverVersionInternal.1 = STRING: 1.51 NUT-MIB::driverVersionInternal.2 = STRING: 1.51 NUT-MIB::driverVersionInternal.6 = STRING: 0.34 NUT-MIB::serverInfo = STRING: serverinfo example NUT-MIB::serverVersion = STRING: test server version NUT-MIB::threephaseDomain.4.input.mains.none = INTEGER: input(1) NUT-MIB::threephaseDomain.4.input.mains.l1 = INTEGER: input(1) NUT-MIB::threephaseDomain.4.input.bypass.l1l2 = INTEGER: input(1) NUT-MIB::threephaseDomain.4.output.load.none = INTEGER: output(2) NUT-MIB::threephaseDomain.4.output.load.l1 = INTEGER: output(2) NUT-MIB::threephaseDomain.5.input.mains.none = INTEGER: input(1) NUT-MIB::threephaseDomain.5.input.mains.n = INTEGER: input(1) NUT-MIB::threephaseDomain.5.input.mains.l2 = INTEGER: input(1) NUT-MIB::threephaseDomain.5.input.mains.l3l1 = INTEGER: input(1) NUT-MIB::threephaseDomain.5.output.load.none = INTEGER: output(2) NUT-MIB::threephaseSubdomain.4.input.mains.none = INTEGER: mains(1) NUT-MIB::threephaseSubdomain.4.input.mains.l1 = INTEGER: mains(1) NUT-MIB::threephaseSubdomain.4.input.bypass.l1l2 = INTEGER: bypass(2) NUT-MIB::threephaseSubdomain.4.output.load.none = INTEGER: load(4) NUT-MIB::threephaseSubdomain.4.output.load.l1 = INTEGER: load(4) NUT-MIB::threephaseSubdomain.5.input.mains.none = INTEGER: mains(1) NUT-MIB::threephaseSubdomain.5.input.mains.n = INTEGER: mains(1) NUT-MIB::threephaseSubdomain.5.input.mains.l2 = INTEGER: mains(1) NUT-MIB::threephaseSubdomain.5.input.mains.l3l1 = INTEGER: mains(1) NUT-MIB::threephaseSubdomain.5.output.load.none = INTEGER: load(4) NUT-MIB::threephaseContext.4.input.mains.none = INTEGER: none(0) NUT-MIB::threephaseContext.4.input.mains.l1 = INTEGER: l1(2) NUT-MIB::threephaseContext.4.input.bypass.l1l2 = INTEGER: l1l2(8) NUT-MIB::threephaseContext.4.output.load.none = INTEGER: none(0) NUT-MIB::threephaseContext.4.output.load.l1 = INTEGER: l1(2) NUT-MIB::threephaseContext.5.input.mains.none = INTEGER: none(0) NUT-MIB::threephaseContext.5.input.mains.n = INTEGER: n(1) NUT-MIB::threephaseContext.5.input.mains.l2 = INTEGER: l2(3) NUT-MIB::threephaseContext.5.input.mains.l3l1 = INTEGER: l3l1(10) NUT-MIB::threephaseContext.5.output.load.none = INTEGER: none(0) NUT-MIB::threephaseCurrent.4.input.mains.l1 = INTEGER: 133.00 NUT-MIB::threephaseCurrent.5.input.mains.n = INTEGER: 3.40 NUT-MIB::threephaseCurrent.5.input.mains.l2 = INTEGER: 48.20 NUT-MIB::threephaseCurrent.5.output.load.none = INTEGER: 244.20 NUT-MIB::threephaseVoltage.4.input.bypass.l1l2 = INTEGER: 398.3 NUT-MIB::threephaseVoltage.5.input.mains.l3l1 = INTEGER: 405.4 NUT-MIB::threephaseVoltage.5.output.load.none = INTEGER: 120.0 NUT-MIB::threephasePower.4.output.load.l1 = INTEGER: 35700 NUT-MIB::threephasePowerfactor.4.output.load.none = INTEGER: .82 NUT-MIB::threephaseFrequency.4.input.mains.none = INTEGER: 50.0 NUT-MIB::threephaseFrequency.5.input.mains.none = INTEGER: 50.1 NUT-MIB::threephaseFrequencyNominal.5.output.load.none = INTEGER: 60.0 --- ? ?? Luiz Angelo Daros de Luca, Me. ? ? ? ? ? ? luizluca at gmail.com
2012/6/10 Luiz Angelo Daros de Luca <luizluca at gmail.com>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120611/175b4c94/attachment.html>
Hi again Luiz, 2012/6/10 Luiz Angelo Daros de Luca <luizluca at gmail.com>> Hello guys, > > I was some years ago when I sent something to this list. > (...) > 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. >I've just fixed this one in the trunk, r3657. thanks for your report, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120612/049f2226/attachment.html>
Hi Luiz,> I read your email only now. Gmail marked it as "unimportant" :-) Sorry. >damn gmail ;-)> I might read it with attention and I'll answer you soon. >sorry, I'm still lagging behind my TODO stack. I still have the same (high) interest in your work, but also still lack time to do things... cheers, Arnaud 2012/6/11 Arnaud Quette <aquette.dev at gmail.com>:> > > > 2012/6/10 Luiz Angelo Daros de Luca <luizluca at gmail.com> > >> > >> 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 > >> (...) > > > > > > 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 > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20120628/70eb1653/attachment-0001.html>