<br><div class="gmail_quote">2012/6/10 Luiz Angelo Daros de Luca <span dir="ltr"><<a href="mailto:luizluca@gmail.com" target="_blank">luizluca@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello guys,<br></blockquote><div><br>Hello Luiz<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I was some years ago when I sent something to this list.<br></blockquote><div><br>yup, Google told me it was in 2009, on the megatec driver...<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

NUT is a great tool but lacks SNMP management. It can access a device using SNMP<br>
but I found no way to read NUT values using SNMP. It would be very<br>
useful in order to integrate with<br>
network management software based on SNMP. As I did not find a<br>
solution, I wrote it myself.<br></blockquote><div><br>well, there is (was/will be) one, but never finished nor integrated:<br>- a set of 3 tasks, among which 2 are agent related:<br><a href="https://alioth.debian.org/pm/task.php?group_project_id=31&group_id=30602&func=browse">https://alioth.debian.org/pm/task.php?group_project_id=31&group_id=30602&func=browse</a><br>
- a patch with an agent based on RFC1628 (so limited to 1 UPS, no multiple devices, no PDU nor whatever...)<br><a href="https://alioth.debian.org/tracker/index.php?func=detail&aid=312563&group_id=30602&atid=411544">https://alioth.debian.org/tracker/index.php?func=detail&aid=312563&group_id=30602&atid=411544</a><br>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I wrote a MIB file and a SNMP agent for net-snmp (pass_persist) in<br>
order to expose the contents of upsc command to SNMP softwares. I<br>
works simply by adding to snmpd.conf:<br>
<br>
pass_persist .1.3.6.1.4.1.26376.99 /my/path/to/snmp.nut -f<br>
<br>
The script and MIB files are at:<br>
<br>
<a href="https://github.com/luizluca/nut-snmpagent" target="_blank">https://github.com/luizluca/nut-snmpagent</a><br>
<br>
It is, for sure, not finished. I did not find a IANA enterprise<br>
number, that is no costs to register, for NUT so I<br>
spoofed my company one. I'm still using a fake upsc output in order to<br>
have a more complex mix of devices.<br>
I collected some output examples in the documentation but I might<br>
still missed some special case.<br></blockquote><div><br>I can provide some .dev files for simulation using dummy-ups driver.<br>this should help you in testing corner cases...<br>note that there is already a .dev and a .seq in the source distribution, "data" sub directory.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, I did not extensively tested it with real hardware. Anyway, my<br>
UPS is quite simple for that.<br>
<br>
I got two minor doc bugs in the process. The first is that the<br>
driver.version.data, that I found in some examples, its not listed as<br>
a variable.<br></blockquote><div><br>right, there are still some data missing in nut-names.txt, but I'm ramping up to fix these lacks.<br><br><br>driver.flag.*<br>driver.parameter.*<br>=> scripts/augeas/nutupsconf.aug<br>
==> ups_fields stores all drivers parameters and flags (no distinction here yet between VAR_VALUE and VAR_FLAG)<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

The other is the description of "power.minimum" as "Maximum seen<br>
apparent power (VA)".<br></blockquote><div><br>the is a typo error, fixed in r3653. thanks for your report.<br>Note that we may investigate future mechanisms to share data mapping and descriptions, that would ease maintenance work on the SNMP agent.<br>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would appreciate some feedback/help/suggestions in any part of the<br>
solution. I'm willing to release it with any permissive license.<br>
The agent might not fit the requirements of all users (it is written<br>
in ruby with a lot of metaprogramming) but the MIB file<br>
seems to be in a good shape, expect for the missing IANA number. BTW,<br>
I'm no SNMP expert.<br></blockquote><div><br>all this is great!<br>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.<br><br>I'm also going to look at the IANA process to get an OID for NUT.<br>
this should probably be under "org" and not "enterprise", as for the generic "UPS MIB" (aka RFC-1628, located under mgmt.mib-2)<br><br>that said, I'm not a fan of Ruby.<br>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).<br>
more info below...<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards,<br>
<br>
PS: Just for an example, the current output that I get from a snmpwalk<br>
is like this (for 6 devices):<br>
<br>
NUT-MIB::deviceIndex.1 = INTEGER: 1<br>
NUT-MIB::deviceIndex.2 = INTEGER: 2<br>
NUT-MIB::deviceIndex.3 = INTEGER: 3<br>
NUT-MIB::deviceIndex.4 = INTEGER: 4<br>
NUT-MIB::deviceIndex.5 = INTEGER: 5<br>
NUT-MIB::deviceIndex.6 = INTEGER: 6<br>
NUT-MIB::deviceName.1 = STRING: ups2<br>
NUT-MIB::deviceName.2 = STRING: xxx<br>
NUT-MIB::deviceName.3 = STRING: upsoutlet<br>
NUT-MIB::deviceName.4 = STRING: ups3p1<br>
NUT-MIB::deviceName.5 = STRING: ups3p2<br>
NUT-MIB::deviceName.6 = STRING: ups3<br>
NUT-MIB::deviceDesc.1 = STRING: UPS2 10 KVA Lacerda Titan Black tri-mono 10KVA (220v) Serial A08823221<br>
NUT-MIB::deviceDesc.2 = STRING: Fictious<br>
NUT-MIB::deviceDesc.3 = STRING: Example outlet<br>
NUT-MIB::deviceDesc.4 = STRING: phases1<br>
NUT-MIB::deviceDesc.5 = STRING: phases2<br>
NUT-MIB::deviceDesc.6 = STRING: test3<br>
NUT-MIB::deviceModel.1 = STRING: Titan Black tri-mono 10KVA<br>
NUT-MIB::deviceModel.2 = STRING: Titan Black tri-mono 10KVA<br>
NUT-MIB::deviceModel.6 = STRING: Ellipse MAX 1100<br>
NUT-MIB::deviceMfr.1 = STRING: Lacerda Sistemas de Energia<br>
NUT-MIB::deviceMfr.2 = STRING: Lacerda Sistemas de Energia<br>
NUT-MIB::deviceMfr.6 = STRING: EATON<br>
NUT-MIB::deviceSerial.1 = STRING: A08823221<br>
NUT-MIB::deviceSerial.2 = STRING: A08823221<br>
NUT-MIB::deviceSerial.6 = STRING: ADKK22008<br>
NUT-MIB::deviceType.1 = STRING: ups<br>
NUT-MIB::deviceType.2 = STRING: ups<br>
NUT-MIB::deviceType.6 = STRING: ups<br>
NUT-MIB::upsStatus.1 = STRING: OL<br>
NUT-MIB::upsStatus.2 = STRING: OL<br>
NUT-MIB::upsStatus.6 = STRING: OL CHRG<br>
NUT-MIB::upsModel.6 = STRING: Ellipse MAX 1100<br>
NUT-MIB::upsMfr.6 = STRING: EATON<br>
NUT-MIB::upsSerial.6 = STRING: ADKK22008<br>
NUT-MIB::upsVendorid.6 = STRING: 0463<br>
NUT-MIB::upsProductid.6 = STRING: ffff<br>
(...)<br><a href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev" target="_blank"></a></blockquote></div><br>I would more see something like this (including the collection name in the path):<br>NUT-MIB::device.deviceIndex.1 = INTEGER: 1<br>
NUT-MIB::device.deviceName.1 = STRING: ups2<br>NUT-MIB::device.deviceDesc.1 = STRING: UPS2 ...<br>
NUT-MIB::device.deviceModel.1 = STRING: Titan Black tri-mono 10KVA<br>
NUT-MIB::device.deviceMfr.1 = STRING: Lacerda Sistemas de Energia<br>(...)<br>
<br>NUT-MIB::inputCurrentNominal.1 = INTEGER: 27.00<br>would give something like<br>NUT-MIB::input.l1.inputCurrent.nominal<br>(equivalent to NUT "input.L1.current.nominal:  27.0")<br><br>a few notes:<br>- I'm still thinking about the added value of repeating the collection name for each leaf.<br>
Ie device.deviceIndex Vs device.Index<br>the first (your current approach) is probably more in phase with SNMP best practices,<br>- I'm still unsure on the right device index place.<br>you have used leaf indexes (Ie, indexes are located on the leaf), while NUT native approach would more be "root" indexes.<br>
that would give something like<br>NUT-MIB::[index].collection.data<br><br>so, for the 1rst NUT device:<br>NUT-MIB::<a href="http://0.device.name">0.device.name</a><br>NUT-MIB::0.device.model<br>
(...)<br><br>the root would also contain:<br>NUT-MIB::server.{info,version}<br>
and possibly a devices list, or at least a device count (Ie how many devices you can iterate on...)<br><br>- for the 1rst round, I'm more interested in stabilizing the MIB tree, to have a stable *numeric* set.<br>Exact string names have a lower priority.<br>
<br>- the "MAYBE" on commands (and settings) is to be removed.<br>this is also part of the SNMP interface, though it should be used only in SNMP v3 mode (v1 is a security mess!).<br><br>- part of the requirements, I'd like the agent to be able to work in standalone or sub agent mode.<br>
<br>so, to conclude this first mail, you did a great work!<br>I've sadly not enough time to fully enter the loop with you.<br>but I'm willing to devote all the support and time I can to push and complete this effort (including IANA process).<br>
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?<br><br>cheers,<br clear="all">Arnaud<br>-- <br>Linux / Unix / Opensource Engineering Expert - Eaton - <a href="http://opensource.eaton.com" target="_blank">http://opensource.eaton.com</a><br>
Network UPS Tools (NUT) Project Leader - <a href="http://www.networkupstools.org" target="_blank">http://www.networkupstools.org</a><br>Debian Developer - <a href="http://www.debian.org" target="_blank">http://www.debian.org</a><br>
Free Software Developer - <a href="http://arnaud.quette.free.fr" target="_blank">http://arnaud.quette.free.fr</a><br><br>