[Nut-upsdev] SNMP agent for NUT

Mon Jun 11 12:44:18 UTC 2012

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>