[Nut-upsuser] [Nut-upsdev] SNMP agent for NUT

Thu Jun 28 09:22:49 UTC 2012

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>