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....@gmail.com>: > > > > 2012/6/10 Luiz Angelo Daros de Luca <luizl...@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 > > >
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser